What are the objectives for Xfce 4.4?

[Brian J. Tarricone]

Benedikt Meurer wrote:

> 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.

Yes, there are.  I think we can all agree that people are pretty picky 
as to what they think makes for a good file manager GUI.  Now, 
obviously, it's not possible to provide different management 
capabilities for the icons on the desktop itself: you're going to end up 
with the same "properties" dialog regardless of your preferred file 
manager, etc.  But I don't see desktop icons having a "file management" 
role attached to them.  The desktop itself is single-level.  Sure, you 
can put folders on the desktop, but accessing the contents of those 
folders should be offloaded to the file manager - whichever FM the user 
wants to use.  Now, what do you do with files?  You open them.  Fine, 
the desktop will do that.  This is complicated.  You delete them.  Fine, 
the desktop will do that.  This is simple.  You modify properties on the 
file (permissions, etc.).  The desktop will do this, and that's pretty 
simple too.  You move/copy them.  The desktop will not handle this, 
aside from being a drag source and a drag destination.  The source or 
target is always going to be a file manager, not another part of the 
desktop.  Moving the file around on the desktop itself is not a file 
management task at all; it just involves changing some desktop-specific 
metadata.

The main problem is opening files....

> (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.

Yeah.  Opening files.  MIME databases and file associations and all that 
crap.  Personally, I don't think a MIME server is that big of a deal.  
You pass it a file name, and it either a) "launches" the file, or b) 
returns some kind of interesting MIME-related data about the file 
(whatever).  Frankly, I think it's stupid to build MIME capabilities 
into one single application (in this case, the file manager).  What 
happens if the panel wants to launch a file?  We could do some nifty 
things with this, like allowing people to put files in drawers without 
having to care what app is used to read it.  Why does the desktop need 
to be app-centric?  But if the MIME data engine is in the file manager, 
either you have to hardcode the launcher app into the panel launcher 
entry when it's added (what happens if the user changes his/her mind 
later and installs a different app to handle it?), pass the file off to 
the file manager to launch it (so why not just use a MIME daemon?), or 
build MIME-handling functionality into the panel as well (which is the 
exact problem you're describing).  So basically, what you're advocating 
is building the MIME-handling functionality into the file manager, and 
requiring that any desktop app will have to go through the file manager 
if they want to do any MIME-related tasks.  If users don't like our file 
manager, then they're stuck installing and (indirectly) using it if they 
want the panel or the desktop to be able to launch apps properly.  
Unless we want to create a user-configurable abstraction for launching 
files as well, like gnome-open (or whatever it is), which doesn't seem 
like the best idea to me.

> (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.

I'd certainly want it to be configurable, assuming the desktop isn't a 
part of the file manager.

> 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.

I'm not at all convinced that there's no advantage, and I still see 
several flexibility-related drawbacks to your approach.  And if 
xfdesktop is going to be relegated to a non-default app that most people 
probably won't notice, it's going to be less likely that anyone's going 
to want to hack on it (myself included).  I'm not trying to sound like 
I'll drop work on it if I don't get my way, but I'm just saying that it 
doesn't seem too fun to me to hack on an app that most people probably 
aren't going to use.  Now, if this is the direction we're going to take 
for 4.4, I'd like to know ASAP so I can decide how much time I want to 
put into xfdesktop.  Xfmedia still needs a lot of work, and I'd rather 
not spend my time elsewhere if it's not really worth it.

Regards,
Brian