What are the objectives for Xfce 4.4?

[Benedikt Meurer]

Brian J. Tarricone wrote:
>> Brian J. Tarricone wrote:
>>
>>> The main problem is opening files....
>>
>>
>> No, sorry, thats easy, the main problem is move/copy (atleast if you 
>> want to do it right).
> 
> 
> How so?  Really, if moving and copying a file is a hard problem, we're 
> in a lot of trouble.  I'm not saying it's *simple* - there are certainly 
> things to think about when copying a file - atomicity, async progress 
> notification, all that.  It's just that it's not a new problem, and I 
> don't find it all that interesting.

Its actually one of the most interesting parts: How to make 
move/copy/delete both fast and reliable.

>>> Yeah.  Opening files.  MIME databases and file associations and all 
>>> that crap.
>>
>> I disagree, thats no crap.
> 
> Gah - "crap" as in "big mess of complicated stuff", not as in 
> "unimportant stuff I don't care about".

Thats how I understand it, and thats why I disagree. I tends to become a 
popular sport to complain about fd.o specs, similar to the already well 
established sports of complaining about desktop environments (yeah, this 
includes Xfce as well). While this can be funny, it doesn't help us to 
solve the issue, so please, lets stay on-topic.

>>>  Personally, I don't think a MIME server is that big of a deal...
>>
>> 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?...
> 
> Stat cache?  That seems like more of a job for the C library than a 
> desktop.  Or perhaps I'm misunderstanding.

Nope, it would let to very funny (and esp. very unwanted) results if the 
C library would implement stat() caching.

I was talking about the file manager, which is mostly interested in 
file's meta data for several reasons. Meta data is determined using the 
stat() syscall. But stat calls require inode look ups, and even worse, 
disk seeks in many cases, which should be avoided at any rate. Therefore 
the stat results should be cached, so you don't need to stat() everytime 
you need the meta data (its interesting, how trivial this seems to be at 
first sight, and then, how difficult to solve it is in real, I haven't 
found a single file manager that solves this issue 100%ly - hint: symlinks).

>>>> (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.
> 
> Well, you're looking at it differently - from the perspective of having 
> a file manager with desktop management capabilities, and a separate 
> desktop manager which is used exclusively of the file manager (that is, 
> only if you don't want to use the FM at all).  I'm just not convinced 
> that's a good or worthwhile idea.  It unnecessarily duplicates code, and 
> wastes effort on an oft-unneeded software package with similar 
> function.  If you look at it from my perspective, of having a desktop 
> manager with some minimal file management capabilities (for desktop 
> icons only), and a separate file manager that just manages files, then 
> making the file manager that gets launched configurable makes perfect 
> sense - in fact I'd say it's an absolute necessity to make it flexible 
> enough for users who like different file managers.

Your arguments actually assured my feeling that this results in an 
unbreak my software option. Your point is total flexibility at any 
cost... see below.

>> 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.
> 
> You're right: it does sound complicated.  I guess when you say "simple 
> file manager" I think simple as in functionality, and leave the 
> implementation to be as complex as it needs to be to maximise 
> flexibility.  While I'm not a fan of huge complexity, I think this 
> problem is interesting enough to justify wanting to work on it.  I just 
> like having a bunch of little things that fit together to make larger 
> apps - in this case, apps with different purposes, even if that means 
> the individual parts take a big hit on complexity to make it work 
> right.  I know you like modularity too - I just take it to an extreme 
> sometimes because I absolutely love flexibility.  I'm not one of those 
> people who gets scared and indecisive when presented with 25 different 
> choices.  I love it, especially if I have the flexibility to take bits 
> and pieces from a bunch of those choices.

We actually hit the point here: flexibility. While flexibility is nice, 
it shouldn't reduce easy-of-use, maintainability, "just works"-character 
and code-quality.

Having 25 different choices may be fun for a geek (I'm no geek), but it 
confuses users (like me... if I want flexibility, I'd probably still use 
fvwm), that just want to get work done, and not waste time to figure out 
which of the 25 choices would match their needs. Sure its nice for 
playing around with options; I remember that was fun in the fvwm days, 
and in the gnome 1.4 days, but looking back, I wasted too much time to 
`unbreak my desktop'.

A moderate amount of flexibility is nice, and should definetly be 
included with Xfce, but not 100% control. Atleast not if that means 
making simple things complicated. Simple things should be easy, 
complicated things should be doable.

If somebody wants 100% control, he is most probably be a geek - or a 
gentoo user, not sure if that is the same :-) - and he *should* be able 
to find the file manager option to disable the desktop (or just pkill 
filer), and launch whatever desktop/file manager he prefers.

So, the geek (the target person for 100% flexibility) will find out 
himself for sure, and the usual user won't want/need the flexibility; 
and thats what makes me think, we are talking about a non-existing scenario.

Sure, we can hide the flexibility from the usual user, and do like the 
KDE people do. Lets leave out the "blow me"-argument for a second. Then 
we'll have hidden flexibility, that isn't accessible for the usual user, 
but only for the geek. But the geek in turn, wouldn't need the hidden 
flexibility, because he already knows (or can be told) how to gain the 
same result (pkill filer; other-desktop-manager). So we have lots of 
complexity for no real value.

And another point: Duplicating the file manager in both the filer and 
the desktop requires some kind of IPC, which in turn is incompatible 
with the "just works" requirement, since D-BUS is going to break several 
times (thanks havoc, nice idea), CORBA is not an option, communicating 
using the Xserver won't work and writing our own IPC for 4.4 and 
ditching it for 4.6 (in favour of D-BUS) sounds like a bad idea.

I think the real question is: Do we want a desktop that can handle file 
management tasks or do we just want the desktop for launchers (If we do, 
I'd like to see notes on the desktop, similar to CDE)? The former should 
be done using the file manager instance, the latter should be done using 
xfdesktop.

Seriously, I don't want to necessarily ditch xfdesktop, and I don't want 
Brian to hide under Xfmedia, I just want to avoid a completely 
unmanagable solution (I don't see the point in replacing a complicated 
file manager with an even more complicated distributed file manager).

Total control/flexibility is not a worth goal for me, since it turns 
Xfce back in the geek area, and since I'm no geek, I don't want to be 
there.

I hope you got my point.

>    -b

Benedikt