What are the objectives for Xfce 4.4?

Benedikt Meurer benedikt.meurer at unix-ag.uni-siegen.de
Tue Feb 1 21:55:55 CET 2005

Brian J. Tarricone wrote:
> Benedikt Meurer wrote:
>> Brian J. Tarricone wrote:
>>> Well, sorta.  I think we should have a really stripped-down file view 
>>> widget with file-management capabilities in libxfcegui4 (or if it 
>>> ends up being to large, perhaps its own library).  Xfdesktop can 
>>> optionally create an instance of this widget (by dlopen()ing it if 
>>> its in its own library) for the desktop, and a separate file manager 
>>> binary could do something similar, and implement a configuration 
>>> interface and a host of other nifty things.  But this file manager 
>>> need not be in the core.
>>> I'm really *really* against folding desktop management duties into 
>>> the file manager a la nautilus.  It just doesn't make sense, IMHO, 
>>> and makes it difficult for users to a) use Xfce's file manager with a 
>>> different DE, or b) use Xfce with a different file manager.  I'm 
>>> actually surprised that was suggested, as it seems like quite the 
>>> opposite of modularity.
>> I really *klemmer* this idea. I don't see why a file manager shouldn't 
>> be desktop-independent, or why it should reduce Xfce's modularity,
> Huh?  You're advocating making the filemanager integrated with the 
> desktop (or the desktop integrated with the file manager, take your 
> pick), which makes the file manager less desktop-independent.  If we go 
> with your plan, this means that, if you want to run Xfce with rox's file 
> manager, or nautilus, you either have to run rox's pinboard/nautilus' 
> desktop manager, or run without a desktop.  If you'd rather use 
> something like Jens' filer, which doesn't manage the desktop, you have 
> to run what is essentially two file managers just to get a desktop.  
> Conversely, if someone wants to use Xfce's file manager with another DE, 
> there's the problem of having to do something braindead like 
> --no-desktop with nautilus.
> Taking two things that are separate (and not really all that related, 
> IMO), and making them into one integrated piece sounds like the 
> definition of "reducing modularity" to me.
>> but I see that such a `file view widget library' will surely become a 
>> maintaince problem.
> I'm curious to know why.  It's only a maintenance problem if you 
> maintain it poorly, or design the interface in a half-assed manner.  
> Again, it's all about modularity: why reinvent file management 
> capabilities all over the place when you can keep the basic 
> functionality in one place?

I see what you are targeting at, the KDE model, with kdesktop to manage 
the desktop and konqueror as the `windowed' file manager, so here are a 
few basic things to remember if you really plan to go this way:

(a) the 'Desktop' - if used as a file manager view - is an integral part 
of the desktop, so there's not two different things here.

(b) if you decouple the desktop file management component from the 
windowed file management component, you can of course put the code in 
shared libraries, so it'll be shared by all process, but a process 
consists not only of code (text) sections, but also data sections, and 
depending on the actual implementation, there can be a lot of data for 
the running instances (a very simple example is the mime database). Then 
you'll face the basic problem that KDE faced before already: How to 
reduce the overhead? Well, several solutions here, you can use daemon 
processes and IPC to manage shared data, or use shared memory, etc... 
but all solutions that come to mind currently don't look like 
lightweight solutions actually.

(c) For the desktop file manager view, if you open a directory, you'll 
have to launch the windowed file manager view. You can either make the 
file manager to launch configurable, or if you want consistency, you'll 
launch the windowed file manager itself. So, there's no gain in 
splitting the stuff, you'll just turn simple things into complex things.

There are some other things to consider, but I think you got the point. 
So afterall, there's no advantage of splitting the file manager for Xfce 
(remember, we're not KDE). What you want is probably to keep xfdesktop 
around for people that don't want the desktop file manager.

>    -b


More information about the Xfce4-dev mailing list