What are the objectives for Xfce 4.4?

[Benedikt Meurer]

Brian J. Tarricone wrote:
> 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....

No, sorry, thats easy, the main problem is move/copy (atleast if you 
want to do it right).

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

I disagree, thats no 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.

We already thought about putting the MIME handling in libexo or 
libxfce4util, and it is indeed a good idea. But as said, the MIME 
database is only a _simple_ example. For a slightly more complex 
example, the stat cache comes in mind, another efsd?...

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

Hm, but this sounds like an unbreak my software option to me. If you 
don't want to be able to have desktop icons, you can run the good old 
xfdesktop (or simply don't put icons on the desktop, but this may be to 
obvious for some geeks), or if you want desktop icons, you can enable it 
in the file manager. I don't see the third option that you are trying to 
integrate? Either you want it, or you don't want it.

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

You sound like me - take it as a compliment. Tho, remember, I'm too anal 
to do something half-assed. ;-)

But, seriously, splitting up the file manager in atleast three modules 
(windowed file manager view, desktop file manager view, library) sounds 
like a really complex solution for a *simple* file manager. To be true, 
it sounds like KDE to me - no offense against KDE, but I don't think its 
the Xfce way.

We already did a lot of research in the area of file managers, and we 
have a design draft, diagrams and sample code around. I'll try to remind 
myself to upload it at work tomorrow.

> Regards,
> Brian

Benedikt