Thunar tips and tricks
I was recently reminded of two Thunar features which are useful and not very well known.
First, Thunar comes by default with a fancy mouse gesture feature. The mouse gestures must be done with a middle click, if you don't have one, it can often be emulated by pressing the left and the right button at the same time. To perform a mouse gesture, press the middle button without releasing it, move the mouse in the direction required by the gesture and release the button. The following gestures are available:
- Moving the mouse up moves to the parent directory of the current directory.
- Moving the mouse down reloads the current folder.
- Moving the mouse left moves to the previous directory in the browsing history.
- Moving the mouse right moves to the next directory in the browsing history..
The second tip I recently discovered is that drag and dropping a file using the right mouse button opens a contextual menu which provides the following options: copy here, move here and link here. Link here is particularly cool, I used to launch a terminal and use ln... To use this right click drag and drop, you need to be faster than the traditional contextual menu: right click on the file/folder and start moving your mouse before the normal contextual pops up; once you release your mouse, the über-cool context menu will pop up.
Design of the Thunar Progress Dialog
Today, I merged the shared progress dialog into Thunar. I can be seen on vimeo. This evening I started thinking about the waste of space in it. For each copy/move/link/delete/trash operation we have: one icon and two lines of text, followed by another line with a progress bar (with text) and a cancel button. That's not too much and it looks kinda clean. Thunar has always hidden too detailed information from the user, like the size of the files, how many megabytes have already been transfered/deleted or what the MB/s rate is. But still, three lines of widgets for each operation is a waste of space. And the more space we waste for each operation, the earlier we have to add something like scrollbars around the widgets, as can be seen in the video.So I've made a few mockups to test alternatives. But first, let's have a look at how other file managers do it.
Nautilus / Finder
The progress dialog used in Nautilus is almost a 1:1 copy of the OS X Finder progress dialog. It too follows a three-line design with the first line either showing how many files are being transfered (e.g. Copying 2 files to "Desktop") or what files is transfered at the moment (this is what you can see in the screenshot below, which I am shameless linking here from Bob Peers' weblog). The second line contains the progress bar and a cancel button without any text and the third line shows some stats, again shown in the screenshot.
Now, the problems of this dialog are quite obvious (although not everything can be seen in the screenshot). If you're transfering more than one file, it will be almost impossible to figure out which of the progress views corresponds to this operation unless you know exactly how many files you're transfering and/or how large these are in total. Another problem is that the dialog grows and grows with each operation added to it until it finally grows beyond the height of the screen. Last but not least the progress bar and button heights are different, making the dialog look slightly unpolished.
Dolphin
I have to admit, this is a poor comparison. I couldn't find a screenshot of Dolphin's progress dialog on the net and I'm too lazy to install KDE in a virtual machine. Suffice it to say that I'm not a big fan of KDE GUIs in general. I think the KDE folks have a lot of great ideas but as nice as plasma and all that 4.x goodness may be, most of the windows and dialogs are too busy and cluttered for my taste.
Thunar Experiments
The original design can be seen on vimeo.
The first attempt of an improvement is the equivalent to Nautilus and Finder omitting the statistics by replacing them with a simple <time> remaining text on the progress bar. Like the Nautilus dialog it doesn't display the name of the current file when an operation includes multiple files. This is not shown in the screenshot, because that one is just a hard-coded mockup. All in all, this design makes it even more unlikely to find a job with multiple files again at a later point due to the left out stats.
The second mockup appends the number of files involved to the title (e.g. (1 of 2)) and because of that, it can always display the name of the file being transfered at the moment. The downside is that this of course requires the user to read more text.
Ideas and Opinions?
I'm not 100% sure which way to go here. I kinda lean towards the second mockup but since Thunar is designed to have no redundant options/elements in the GUI, I'm wondering whether the (1 of 2) isn't too much already.
What do you think? Any opinions or ideas for improvements? Sketches and descriptions are very welcome!
Xfce 4.8 Release Cycle Information
At the end of August, we've entered the development phase for the Xfce 4.8 release cycle. Today, we're hitting dependency freeze and I think this is a good time to inform you about how the cycle will look like and what we're planning to achieve for 4.8.The final 4.8 release is scheduled for April 12th, 2010, which is in about 8 months. We're trying to stick to a well-defined release policy for the first time. This includes frequent development releases of individual components and, most importantly, a time-based release cycle.
I'm confident that we can meet the schedule you can see below and would like to encourage everyone to participate in the development and continued improvement of Xfce 4.8, be it as a developer, a translator or a generally active member of the Xfce community.
Below you find detailed information about the 4.8 schedule, the release team, dependencies and planned features. This information is also available on the wiki.
Schedule
2009-08-16 - 2009-08-30: Planning phase
2009-08-31 - 2009-09-13: Extended planning phase
2009-09-13: Dependency freeze
2009-08-31 - 2010-01-31: Development phase
2010-02-01 - 2010-04-12: Release phase
2010-02-01: Xfce 4.8pre1 release / Feature freeze
2010-03-01: Xfce 4.8pre2 release / String freeze
2010-03-29: Xfce 4.8pre3 release / Code freeze
2010-04-12: Xfce 4.8 final release
Release Team
Release Manager: Jannis Pohlmann
QA Official: Stephan Arts
Release Assistants: Jérôme Guelfucci
Ali Abdallah
Yves-Alexis Perez
Robby Workman
Vincent Tunru
You can read up on the roles of these people on this page if you feel like you need to contact one of them because there's something going wrong with the development or release process.
Dependencies
Xfce 4.8 will depend on the following libraries and applications:
- cairo >= 1.0.0
- dbus-1 >= 1.0.0
- dbus-glib-1 >= 0.73
- gdk-pixbuf-2.0 >= 2.14.0
- gio-2.0 >= 2.18.0
- glib-2.0 >= 2.18.0
- gmodule-2.0 >= 2.18.0
- gobject-2.0 >= 2.18.0
- gthread-2.0 >= 2.18.0
- gtk+-2.0 >= 2.14.0
- libpng12 >= 1.2.0
- libwnck-1.0 >= 2.22
- x11 >= 1.1.0
The following dependencies are still left open:
- garcon-1 (no release yet, but used in different places)
- tumbler (no release yet, but used in different places)
- sphinx (for documentation)
Planned Features
In the following, we give you an overview of the features we are planning to implement for 4.8. Please note that due to the voluntary nature of the Xfce development, none of features are guaranteed to make it into the final release. This feature list may also not be complete as we might be able to implement even more during the cycle. This list is meant to give you an insight in what we're up to and what you might be able to expect in 8 months.
You can find a (hopefully) always up to date list on the wiki page. Each of the pages linked there contains more detailed information about the features, their implementation status and sometimes also who has taken the responsibility to work on them.
We welcome people to help in achieving these goals. All of our repositories are now managed using git (on http://git.xfce.org/) so it's easy to clone them and contribute code to Xfce.
exo
- Remove deprecated APIs and rename library to exo-1
- Add GIO module for URI handling to support gtk_show_uri()
libxfce4ui
- Port all Xfce core components to libxfce4ui instead of libxfcegui4
- Object-oriented session client
- GtkBuilder support for e.g. XfceTitledDialog
thunar
- Finish the migration to GIO/GVfs. Among other features, this will give us network browsing (windows shares, SSH, FTP etc.).
- Implement our own volume monitoring backend for GIO (based on HAL or DeviceKit-disks)
- Update thunar-volman to work with this volume monitoring backend and port it to xfconf
- Integration of remote locations in the side pane
- Improve integration of tumbler for thumbnailing
- Port all ThunarVFS thumbnailers to tumbler, write backwards-compatible tumbler plugin for thunar-thumbnailers
- Use a single progress dialog, grouping all file operations
- Extend the D-Bus interface so that e.g. xfdesktop can re-use the file properties dialog
- Startup notification support in the custom actions plugin
xfce4-appfinder
- Drop libxfce4menu and migrate to garcon
- Improve keyboard navigation
- Use startup notification when spawning applications
- Perhaps implement an extension API, so that xfce4-appfinder can act as a replacement for xfrun4 in the future.
xfce4-panel
- Finish the completely rewritten panel. This adds a lot of neat features and revamped dialogs. Amongst other things:
- Introduce an xfconf API for plugins
- Add an improved launcher plugin based on GIO, garcon and exo-desktop-item-edit
- Improved transparency support
- Better panel placement and multi-head support
xfce4-settings
- Netbook-friendly dialogs
- Improve keyboard shortcuts (seem to cause a lot of problems)
- Improve display and pointer settings dialogs
- Add a clipboard manager daemon
- Finish/fix the settings editor
xfdesktop
- Use GIO for the icon view
- Use garcon for the menu instead of libxfce4menu
- Improve icon view drawing routines
- Proper keyboard handling for the icon view
- Free icon positioning
- Allow right-click menus to be arranged differently
I think that's it. I hope you enjoy Xfce and are looking forward to the 4.8 release together with us!
Long Overdue Update
I haven't posted anything in a while, but I'm not complaining. The last month I've been mostly busy pretending to be busy. Ok, to be honest, that's not entirely true. Over at Xfce, we have achieved a lot in August:
- We've moved all Xfce repositories (including the goodies) over to Git. Kudos to Brian for doing most of the work.
- All Xfce translation updates are now submitted via Transifex. Thanks to the Transifex developers for all the support and for being such a friendly bunch. It amazes me that Dimitris, the founder of Indifex, is also active on our translations mailing list to support people!
- The migration of the Thunar core to GIO is complete and has been merged into the main development branch. The overall delta was 2.9MB, although admittedly, a big part of that is due to the removal of ThunarVFS, so I can only take credit for about 16,000 of the 24,335 insertions and 6,000 of the 41,356 deletions.
- We've kicked off the Xfce 4.8 development cycle on August 16th. The schedule and all other details are available on the wiki. Xfce 4.8 is scheduled for April 12th, 2010. Expect development releases of the various core components soon!
Other things I've been planning to blog about but didn't have the time to:
- Samuel is still busy setting up Buildbot. With less time than he had hoped for at hands this might still take a while.
- I was provided with a free Linutop 2 in June. I'd like to thank the Linutop company again for this gift! So far, I've only found the time to give it a few test boots but I'm planning to set it up as a Xfce test machine soon. Its limited hardware makes it much better platform than my rather powerful laptop and/or virtual machines for testing the speed and memory demand of Xfce.
- My thesis is progressing slowly. I think I have at least 3/4 finished now. I'll keep you posted about the result. I'm hoping to kick off the six month learning phase for my final exams before October because a friend of mine is already waiting for me. ;)
Build a project with Vala
This post is about using Vala in a project but in the end provide the C code for the releases. I think that this is very essential and that releasing source code to be build from Vala is wrong. Vala will always rewrite the code to GObjects in C, but has already proven that compiling the same code from two different versions of Vala will fail. So when you are doing releases with Vala you will break your releases sooner or later. Another good point is when the Vala code is compiled on top of patched vapi files, doing only C compilation with the releases will drop the requirement to apply them.I'll take as example the Autotools, if you are using a different tool-chain you can surely adapt it. The idea is simple, the Vala sources are only compiled in maintainer mode. When you compile the application from the development branch you will usually have a script called
autogen.sh to build the configure script that will automatically be executed with the parameter --enable-maintainer-mode. When providing the distribution tarball that is created with make distcheck, the configure script will not be run with that parameter (except if specified by hand) and the source files to build from will be filled in with the C filenames.The example below is very generic and can be copy/pasted but should be adapted.
Autoconf script
1. The initialization of Automake and the maintainer mode in the autoconf script. The Automake version is checked for 1.11 which is the first version that comes with Vala support. The extra dist-bzip2 argument is there to provide an extra bzipped distribution tarball as you guessed it.AM_INIT_AUTOMAKE([1.11 dist-bzip2])2. The check for Vala only on maintainer mode. The AM_PROG_VALAC defines the variable VALAC that can be reused inside the Makefile.am files and accepts an optional version check.
AM_MAINTAINER_MODE()
if test "x$USE_MAINTAINER_MODE" = "xyes" ; then3. It is possible to sum up the build configuration at the end of the autoconf script.
AM_PROG_VALAC([0.7.4])
if test "x$VALAC" = "x" ; then
AC_MSG_ERROR([Cannot find the "valac" compiler in your PATH])
fi
fi
echo
echo "Build Configuration:"
echo
echo "* Maintainer Mode: $USE_MAINTAINER_MODE"
if test "x$USE_MAINTAINER_MODE" = "xyes" ; then
echo
echo " * Vala: $VALAC"
echo
fi
Automake script
1. The declaration of the Vala sources and their respective compiled C sources.product_VALASOURCES = \2. Use the special BUILT_SOURCES variable to build given targets before running a dist with e.g. make distcheck. This usually done in maintainer mode, as in this case to be sure the releases won't have anything to do with Vala.
obj1.vala \
obj2.vala \
main.vala
product_VALABUILTSOURCES = $(product_VALASOURCES:.vala=.c) product.h
if MAINTAINER_MODE3. The final sources for the product are filled in with the generated Vala sources. The Vala sources are not passed to any SOURCES which is why they are passed to the special EXTRA_DIST variable.
PACKAGES = --pkg=gtk+-2.0
BUILT_SOURCES = vala.stamp
vala.stamp: $(product_VALASOURCES)
$(VALAC) --vapidir=$(srcdir) $(PACKAGES) $^ -C -H product.h
touch $@
endif
product_SOURCES = \
random-source.c \
random-header.h \
$(product_VALABUILTSOURCES)
EXTRA_DIST = $(product_VALASOURCES)
if MAINTAINER_MODE
CLEANFILES = \
$(BUILT_SOURCES) \
$(product_VALABUILTSOURCES)
endif
That's it
There are many existent Vala projects nowadays from where you can pick up new ideas, and this post is just an example amongst many others. The full example is available in the xfce4-vala bindings.Update: I corrected some mistakes seen in green in the script portions. If VALAC is unset the configure script must quit otherwise the resulting Makefiles will have empty commands instead of /usr/bin/valac. Also the generated header file must be passed to product_VALABUILTSOURCES otherwise it would have been left out from distributions as it wans't passed to any product_SOURCES nor EXTRA_DIST variables.
