Freshly pushed to the branch
next on donnatella's
github are a few commits,
some fixes and other improvements here and there of course, as well as the
addition of command exec, allowing to execute a command line as a command, and
have its output be the command's return value.
We'll see how this can be used, but first as some improvements and fixes were done on column types, let's have a quick look at how columns work in donna.
As you may already know, most things in donna aren't hard-coded, but can be configured. Columns are no exceptions, in fact donna doesn't provide columns, but columntypes.
That is, you have the "engine" of a column, that you can configure the way you want, and this combination of an engine, or columntype, a set of (generic & columntype-specific) options, and a name of course, are what's known as a column.
Options can be things such as e.g. the format to use for dates, but also which property to use. For instance, a file has 3 properties containing a date (a timestamp, really) : mtime, ctime, and atime.
And in donna, there's a columntype "time" which can be used with timestamps.
Which information will be shown is simply a matter of configuration: option
property defines which property it will use.
You can show the mtime, or the atime, or create two columns, one for each. And if in the future some nodes were to have yet another timestamp in a new property, you could very easily add a column for it.
Some columntypes do not really offer to format the information they show. The columntype name will show the node's name, and there's not much to configure there. (Though it does offer a few options when it comes to sorting.)
But for others, not everyone likes the same: when it comes to dates, permissions or even sizes, you might have your habbits, your preferred formats.
As hinted before, donna will let you configure things to your liking. But
instead of simply listing a few of the most common formats, allowing you to pick
whichever fits you best, columntypes use a format string, often set via option
It might not seem like there's a lot of choice when it comes to sizes, but some might want a rounded size to the best fitting unit, others rather have the raw size (in bytes), while some might like a size always given in KiB or MiB for instance.
All of those are available, and once again thanks to the use of format string,
you can combine them, e.g. you could use
%R (%b) to have the size rounded (to
best-fitting unit), then the raw size in bytes in between parenthesis.
Of course, if you like to save your pixels, you might like to stick with one, and put the other one in the tooltip. Indeed, most columntypes will also have an option to set the format string to be used for tooltips, as each column can provide its own tooltip.
Format strings for dates are pretty common, and supported specifiers should allow you to show your dates exactly how you want them. As always, via a right-click on the column header, submenu "Options/Column Options/Column" will list a few common formats you might like. Of course, the "Custom" option will let you enter the format of your choice.
Supported specifers are the ones provided by GLib's
should cover all possible needs. One thing that can come in handy and is
missing, though, is the age.
While having the actual date/time is obviously good, sometimes all you want to
know is how long ago was that file modified. So, donna adds specifier
show just that, how much time as passed since the timestamp (or is left, should
it be in the future). E.g: "1h 23m ago"
Simple, and potentially of great help at times.
%O which does the same, but works with a few other options, so
you can define a limit, and another format string to fallback to once the limit
is reached. E.g. show the age as long as the timestamp is from the last 7 days,
then back to a "regular" date/time format.
The same columntype, perms, handles the permissions, as well as the user (owner) and group. Of course, as seen before, you can have all information in the same column, or create as many columns as you see fit.
For permissions, the classic "rwxrwxrwx" format is available obviously. There is also a specifier to try and limit the space required, showing only one group of permissions, i.e. only one "rwx" group, the one that applies to you (e.g. group if you're not the owner of the file, but are in the group).
There's also one to always show three letters, in lowercase when you do not have the permission, in uppercase when you do. Additionally, the letter will be in a color to give out extra info: in color "none" when the permission isn't available to anyone, in regular color if other has permission, in color "group" if group has it, and in color "user" if user has it.
Permissions are checked in that order, meaning that while with color "user" only the user (owner) has the permission, while with regular color the permission if available to other, but might also be available to user and/or group.
Of course, all mentioned colors are configurable; Defaults have green as color "user", blue as color "group" and gray as color "none".
Quick example: if you see "RWx" with the "R" in black, the "W" in green and the "x" in gray, it means you can read & write, no one can execute, and only user can write. Had the "W" be in blue, it meant the group could write, whereas other could not (not saying anything about owner).
The same color can also be used for user (owner) & group names: the user name can be in color "user" when you are the owner, and the group name can be in color "group" when you're not the owner, but are in the group. IOW your name will be in green indicating you have user permissions, if not the group name will be in blue when you have group permissions. If neither are in color, you have other permissions.
Provider exec: environment variables
Provider exec allows to execute command line. It is now possible to use enviroment variables in said command line, which will be resolved to their values upon node creation.
Now when creating a node, location is processed and environment variables are
$FOOBAR will be replaced with its value (if any), quoted (to make
$"FOOBAR can be used for as-is value. Use
$$ to include a
literal dollar sign.
This is all done on node creation, so the node's location will then be the resolved string (i.e. this isn't a shell-like parsing or anything.)
This allows to use
$SHELL to open a new terminal, or
$EDITOR to edit a file
using the correct eidtor, instead of needing to "hardcode" which editor to use
in the config.
Execute something, as a command!
As seen above, executing something has been possible with donna since day one, via provider exec. In fact, donna has a few modes where it will either simply start it, or wait for it to be done, it might also parse the output expecting a full filename per line and process them as search results, or start things inside an (embedded) terminal emulator.
But now, you can also use command
exec() to execute something. How is that
different, you ask?
Well, it means donna will wait until the process is over, and then have its output by used as return value of the command. Of course, that return value could then be used as argument to yet another command...
Quick example: Are you familiar with autojump? It's a tool that given some "keywords" (partial path component) will find the most commonly used match, and show its full name on stdout.
So, if you wanted to go to
/var/cache/pacman/pkg you could use something like
autojump cac pk and it would respond with the desired path.
Usually you'd use
j which would then automatically change to the resulting
directory. How about doing the same in donna?
Simply create a new alias, as such:
[donna/aliases/j] replacement=command:tv_set_location (:active, @exec (autojump suffix=))
And now, pressing
: in donna then enterring
j cac pk will do extactly the
same, and jump to
This is, of course, only one example.
Updating autojump's database
Of course, to have "complete" support of autojump in donnatella, there's one more thing required. Everytime you actually change location, you should let autojump know about it, so it can update its database.
This can be achieved via new event "notify-dirname" which is trigerred whenever the current dirname (i.e. current location in fs) is changed. So, simply adding the following:
[events/notify-dirname] autojump=&autojump -a %d
Will do the trick.
Updating your config to benefit from all of this
Now, there's still work to do when it comes to upgrades in donna. Specifically,
there isn't currently a way to update/import new defaults, so that is a manual
operation. Archers, think of this as some king of
.pacnew handling! ;)
Here's the patch to update your donnatella.conf from v0.2.0:
- diff --git a/misc/donnatella.conf b/misc/donnatella.conf
- index b6b2a03..bb1ec4f 100644
- --- a/misc/donnatella.conf
- +++ b/misc/donnatella.conf
- @@ -814,16 +814,16 @@ trigger=command:tv_set_visual_filter (%o, size:>=%mM)
- trigger=command:tv_column_edit (%o, %n, name)
- # F6 to edit focused item (vim in a terminal)
- -trigger=exec:!vim %:n
- +trigger=exec:!$EDITOR %:n
- # F9 to view focused item (less in a terminal)
- -trigger=exec:!less %:n
- +trigger=exec:!$LESS %:n
- # Terminals
- # selection stuff -- note that this required a patched GTK (to invert range)
- @@ -957,12 +957,12 @@ trigger=command:tv_save_tree_file (%o, @ask_text (Save Tree As...,Enter the name
- name=Open Terminal Here
- -trigger=exec:!WORKDIR=%:n bash
- +trigger=exec:!WORKDIR=%:n $SHELL
- name=...In New Window
- -trigger=>WD=%:n bash
- +trigger=>WD=%:n $SHELL
Note that this obviously doesn't include the autojump support used as example, though all you need is what was said: the alias to trigger autojump, and the event to update its database.
Where to get it?
For a a complete list of all changes/bug fixes please refer to the git log.
And in case you read all that and are wondering what donnatella is, or are looking for more information, download links, etc please refer to donnatella.
As always, bug reports, suggestions or any other form of constructive criticism is very much welcome. You can open issues on github, use the thread on Arch Linux forums, or simply email me.