[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