[Thunar-dev] First code

Benedikt Meurer benedikt.meurer at unix-ag.uni-siegen.de
Sat Jun 4 20:08:19 CEST 2005


Since the number of people calling for work (both on thunar-dev and in 
private mail) has decreased dramatically since work began, I guess it's 
time to introduce some code. Maybe that will help to get people involved 
who would otherwise have trouble with the rather abstract development 
process.

I implemented some of the basic parts, that'll later form the foundation 
of the file manager. This is by no means final code, and by no means 
complete. The tarballs are available at:

http://thunar.xfce.org/download/snapshots/devel/

The base will be a single threaded application, based on the 
multi-threaded ThunarVFS module. I initially planned to export parts of 
the multi-threaded ThunarVFS functionality into the middle-layers 
(ThunarFolder and ThunarFile), but that would make things to buggy 
(there are still thread-issues with gobject <2.6) for a first version.

So, from my current plan, only the ThunarVfsMonitor and the 
copy/move/delete modules will be threaded (plus the thumbnail generator, 
but this is completly undefined currently), which gives a quite good 
tradeoff concerning performance and responsiveness while loading large 
folders (2000+ files). This can later be switched quite easily (if 
necessary) as long as the upper-layers use only ThunarFolder and 
ThunarFile, and do not access the VFS module directly (anything else 
will be considered a bug).

The ThunarFile and ThunarFolder API will need to be extended during the 
development dynamically, as the need for new functions arrives. But care 
must be taken to not blow these classes too much. Remember, Thunar 
should be simple and there's no need to implement any possible use-case. 
The ThunarFile class has a signal "changed", that will be fired whenever 
the VFS module notices that the file may have changed, you'll need to 
redisplay/reinit all data about that file (ThunarFile will automatically 
re-determine the MIME type, the icon, etc., you just use the API 
functions). Both ThunarFile and ThunarFolder are GtkObject's and thereby 
inherit the "destroy" signal, which is invoked whenever the VFS module 
notices that the file (or the file corresponding to a folder) is gone or 
there have been unrecoverable errors while trying to stat() the file. 
So, if you use ThunarFolder and ThunarFile, you'll have to watch these 
signals and perform appropriate actions.

Concerning performance: The sample code above is quite slow. Mostly 
because there's no icon cache mechanism yet.

Brian, one thing about ThunarDesktopView: For the storage of the icon 
positions and the backdrops for the various monitors, an early idea of 
mine was to store these settings into the ~/Desktop/.directory file as 
special settings (prefixed with X-Thunar). IMHO, it makes sense to store 
the information about the display of the desktop folder into the desktop 
folder and not into the ThunarPreferences. ThunarDesktopView will 
provide a D-BUS interface, which supports adjusting those settings from 
outside thunar, e.g. from a separate settings module, that can be hooked 
into xfce-mcs-manager or from a program, that periodically changes the 
wallpaper. What do you think?

greets,
Benedikt




More information about the Thunar-dev mailing list