Starting with xffm-4.3.4, individual packages which are currently part of xffm will split into individual packages (fgr, xfdiff, xfsamba, xffm-libs, etc.). SVN for these packages will still be nexted in the xffm tree. Today the first of these packages, called libtubo, is released. Libtubo is a small library that only depends on glib>=2.0. Libtubo is the engineblock behind xffm. With the library xffm communicates with other applications to do stuff like samba browsing, finding files, mounting volumes, copying and scp, and just about everything. As from today, this library can be used by any other package and does not require xffm to be installed. Source tarball is available at http://xffm.sf.net/libtubo.html where you will find complete API Reference Manual. The source is also available from svn tree under xffm/libtubo.
To keep things simple, xffm-deskview does not set the root Pixmap, but rather takes whatever Pixmap any other application sets for the root background. Unfortunately, many programs are screwy with the root Pixmap on exit. Most will not set the persist-on-exit, but will neither destroy the property. Since the atom will persist until X exits, this leaves a bogus root Pixmap. To deal with this problem, on startup xffm-deskview will automatically assume the Pixmap is bogus (even though the Pixmap set by fvwm-root —for example— is not bogus) and fall back to a solid background. Thus, to set the background image, the root Pixmap must be set by the background setting utility after xffm-deskview is up and running. I’m thinking about wrapping fvwm-root in a gtk GUI to provide this application, if I have the time. This won’t be for 4.3.3 because the release is already on the horizon.
The third GUI for xffm is coming out of the oven, and is called xffm-deskview. This GUI is a very simple filemanager that puts icons on the desktop. Popup menu, except when atop icons, is determined by the wm, if you happen to be running legacy xfwm3 or fvwm or similar. Backdrop management is left to other applications (taken from root window). The result is an application which starts up very fast and does the basic icons on the desktop thing without too much bloat.
The difficult part in this development has been the separation of GUIs and plugins from the basic xffm libraries. Now that that is done, the rest is down hill. Xffm-deskview will be part of release 4.3, scheduled for August (yeah, a month late, but the GUI-library separation *should* have been finished by 4.2, and was not).
An icon-path cache for theme icons does speed things up. The problem comes when one of the icon directories suffers modifications, because that means the icon cache needs to be regenerated. To check whether the cache need to be regenerated, look at the directories and see if they are modified. If you do this twice in a row, as when programming the algorithm, the check is quick because linux will save the directories in memory. Do it again tomorrow and it will take longer. So an acceptable solution —for xffm at least— is to use whatever cache is available and fork a separate process to check whether the cache needs regeneration. The separate process will regenerate the cache if necessary. And chances are that the active xffm will not need cache data until it is already regenerated behind the scenes. After several weeks of testing it works fine. I’m pretty happy with it because of the significant reduction in startup time.
So what’s next? I’m branching xffm-18.104.22.168 which will probably not even compile until merged into trunk. This branch will be a mayor change in structural design to ease maintainability and development of code. The idea is to push all the nonintelligeble nerdiness (yes, even I sometimes have a hard time finding my way around) into abstract reusable objects. In later versions I might fork things apart, iconview-gui, treeview-gui, file management libraries, mimetype libraries, helper applications and the like.
Anyways, I’m happy Benny showed signs of life. I was getting worried about him being in a train accident or something.
In order to keep the application quick, we must avoid loading any code until it is absolutely required (this is called “just-in-time” inventory, borrowing the concept from the automotive industry). This is one of the things that dynamic libraries are supposed to do, without any concern for the programmer. Notwithstanding, in elaborate applications it is very difficult to sort out the library dependencies amongst each other since all symbols are resolved at link time. To get around this hurdle, we use g_modules. Any library that can be dynamically linked to a program can also be loaded as a g_module. In this case, none of the library symbols are dynamically linked. With the use of some simple macros, we load the library and access the required symbol when it is required. In this fashion we can tell exactly when the library is needed and keep a very tight ship with regard to the exported symbols from the library. This is all very neat, but there is one big “but”. Whilst debugging a program, you cannot access any symbols in the library that has been loaded as a g_module. This makes debugging difficult, especially when the bug is located in the library. To get around this, when –debug=yes is specified during execution of the configure script, the g_modules are dynamically linked as .so libraries, allowing for full debug.
Currently the libraries generated from the code in the “modules” subdirectory behave in this fashion. A good deal of other code from the “libs” subdirectory will be relocated here as well as release 4.4 approaches. The dynamic libraries which pertain to the GUI interfase (treeview, gridview, deskview) will also be configured in this fashion. We don’t want any symbols from the wrong gui lying around in memory by mistake (BTW, gridview==navigational, deskview==root-window).
Basic difference between 4.0 and 4.2 trash collection: 4.0 collected a
list of all files in wastebaskets. This proved to be too much. Therefore
4.2 only tabulates a list of the wastebaskets themselves.
If you need to eliminate a single wastebasket and all its contents, just
select it and press remove button (or delete key), either from trash or
folder branch. All undeletion needs to be done by looking into a
wastebasket, selecting something and pulling it out. This is exactly
what you do when you pull something out of the wastebasket in your
office/bedroom/kitchen. Only you and God know what you want to do with a
recovered file, so xffm will not play God and leave it up to you.
The trash bin. Yes the big trash bin is not very good for undeleting
stuff. It is like going outside the office building, jumping into the
truck size garbage container and looking for the post-it note you threw
away yesterday. All this before the garbage truck comes along. This is
what MS-windows, gnome, kde expect you to do. Not very considerate.
Since the xffm trash bin is *not* meant for undeleting stuff (it’s meant
for collecting and disposing of trash, just as in the office building
analogy), undeleting from anywhere other than wastebaskets is not
supported. Yes, you can go ahead and jump into the trash bin if like to.
Good luck if you do. ;-)
Since you have to undelete from wastebaskets, you should also delete the
wastebasket when empty. If you eliminate all wastebaskets with the trash
collection branch, wastebaskets are also removed.
Yes, xffm has a different philosophy regarding trash.
With the upcoming release of 4.1.90, changes to the xfce file manager are worth mentioning. Where to begin?
- The double treeview. In 4.0.x, this feature was a different view of the *same* treeview. Which is downright confusing. With 4.1.90, both treeviews are independent. Changes to one will not affect the other.
- The main menu. Now we have independent treeviews. To which treeview do the main menu functions apply? The old menu was confusing, so we have a new one. Actions which apply on a global scale are included in the main menu, those that are treeview specific are in the popup menu (except for the “goto” commands, which gray out when ambiguity is present).
- The applications branch. This branch was fun to program, but practically useless. Click: removed and replaced by a panel toolbar. The panel toolbar is useful if you are running the file manager on a remote machine (like a server), and you want a minimalistic remote xfce4-panel. Since remote server administration is rare, this option will not be compiled unless “–enable-panel” is specified during build (something server administrators know how to do). So don’t expect to see it unless you look real hard.
- The fork executor (Tubo). Select() replaced the equivalent glib function (which happened to be buggy). This allows a much faster response for all xfsamba functions, mount/unmount, find, tar creation and other commands.
- The copy/move routines were replaced by system defined cp/mv and run by Tubo. Thus, confusion is avoided by using the same default behaviour and error messages you would get by command line execution (plus, memory footprint is cut down).
- Other things that have changed significantly (I’ll explain these some other day): trash management, dropdown toolbar buttons, sidebar, column title popups, popup menus, sort methods, recent and frequent branches, mimetype icon editor, mimetype file association, icon theme handling, in-row cell editing for name and mode and owner/group changes, use of sudo for sudoizable commands, verbose diagnostic messages, recursive scrambling/unscrambling of directories, mount/unmount of smb shares, conversion of treeview branches to plugin architechture and something else I can’t remember now.
- During the 4.1.9x and 4.2.x release period you can expect to see changes within the internal organization aimed exclusively to bug fixes, optimization and code clean up.
- When optimization and code cleanup is complete, we might be ready for testing the icon-view representation (target 4.4, God willing).