I recently tried this because I needed something lightweight for using with fvwm95 and I like what I've seen so far. I'm not too fond of KDE or GNOME because of their bloat and lack of speed.
I have some comments and suggestions though.
Since the developement seems to be tied in with that of Fvwm95, shouldn't they both be in this project and developed together?
One thing that seems strange is that both Fvwm95 and the explorer need the icons for an application manually configured. A simple default would make sense, like picking "[execname].icon.xpm" and "[execname].mini.xpm" in the iconpath as default pixmaps without explicit configuration.
I was also kind of surprised to see the explorer and desktop as separate applications while the desktop really replicates a set of functions already present in the explorer itself. It would make sense to merge the two and use for instance "explorer --desktop" to invoke it as the desktop process.
Some more control for the application itself would also be nice. For instance setting the type of frame fvwm95 uses could be set by the application and parsed to fvwm95 by xclass. This could also be done for presence on the taskbar or system tray for instance.
I'll try to have a look in the code myself, but since I'm not familiar with the xclass code and under tight time constraints, I'm not sure if/when I can do anything useful.
Good luck with the project, I'll be following it with interest.
Thank you for your comments and suggestions, they are very much appreciated.
Yes, it would be a good idea to bring fvwm95 to sourceforge as well, and I'm planning to do it soon. I haven't touched fvwm95's source code for some years now, since it is very stable, and it works just fine for me. It might not have as many bells and whistles as kde/gnome have, but it is very reliable.
Just a few words about the desktop and explorer being separate applications: yes, they are logically similar, but there are some important differences at the implementation level that makes the coding much simpler if implemented separatedly.
One of the biggest differences results from the fact that the desktop application accesses directly the root window and manages the icons there. Thus, the standard OXListView widget could not be used "as is", and needed to be replaced with a special version.
Also, since much of the explorer functionality is not needed in the desktop application (i.e. no tree view, no need to switch between big and small icons, only one directory is managed, etc), the resulting code is a lot smaller (at least in my machine the statically liked executable is less than the half of the size of the explorer), and the memory used by the running application is correspondingly smaller. That's something important to consider since the desktop application is always kept running, while the explorer is only started every now and then. Machines with small amount of RAM would benefit most from that approach.
I agree fvwm95 is very fast and stable, which is what attracts me to it, I hate all the bloated system with the useless gimmicks. I like features as much as the next person, but they have to be useful and efficiently implemented.
You're right about the desktop of course. But there's also functionality that needs to be duplicated. For instance, you want the content sensitive menus for objects on the desktop to be the same as in the explorer. And with objects on the desktop you have quite a lot of dialogs which are shared as well (properties, new object and more), so it makes sense to at least build the two from the same sources. Maybe it's an idea to put some of the common functionality in a separate library. Apart from saving memory (when using shared libraries anyway), a lot of those functions get again duplicated in the common file choose dialogs for instance. Maybe the windows division between a library for the plain widget set and another one for common dialogs and related function would be useful for this project too.
I'm fetching the code from CVS right now and I'll have a look how far things have progressed.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.