What are the objectives for Xfce 4.4?

[Brian J. Tarricone]

Meh, time to trim.  This reply stack is getting nasty.

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

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

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

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

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

Yeah, my laziness and tendency to procrastinate is constantly at war 
with a lingering desire to be a perfectionist...

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

Then by all means, show me the money!  Er, code.  And design draft, 
which interests me more.

    -b