What are the objectives for Xfce 4.4?

[Brian J. Tarricone]

Biju Chacko wrote:

> Hi all,
>
> For some reason, I seem to think that contributing a minuscule amount 
> of code a very long time ago entitles me to pontificate about xfce. I 
> probably have less right to talk than many others here, but xfce is a 
> project that I care deeply about so I'll bore all of you with some of 
> my ideas. Please bear with me. :-)
>
> IMHO, one of the reasons that we have such a long release schedule is 
> because we don't have clear criteria for declaring that a release is 
> ready.

That, plus we appear to have a problem deciding that it's ready and 
there shouldn't be anything else added.

> Basically, every now and then we start feeling that it's been a long 
> time since we did a release. So then we feature freeze whatever is in 
> CVS, stabilize it and then release.
>
> I don't think that it the right way to go.
>
> I think some of you may agree with me.

Agreed.

> Basically, we need to set some clear objectives. These objectives need 
> to be achievable, and there should be a rough idea of how much work 
> it's gonna take. We should decide which objectives should be delivered 
> with which release.
>
> Once the all the objectives of the 4.4 release have been met, we 
> should release.

That's one way of doing it, but not the only way.  Since we all have 
these "lives" outside of Xfce (bear with me...), we can come up with 
proposed feature sets all we want, but it doesn't mean they'll get done 
in the timeframe we think.  The other option is to just set a 
(reasonable) feature-freeze date, and stick with it.  This requires 
quite a bit of discipline.  That means that, if there's anything in the 
tree that's not at least beta-quality by the feature-freeze date, it 
gets backed out.  No exceptions.  I don't know that I have the 
discipline to keep with something like that (actually, I know I don't), 
but if Olivier is, and bitches at me, I tend to feel like I have no 
choice ^_~.

> I also feel that we should have unstable releases more often.

Agreed.

> So we should start deciding on objectives. Each maintainer would 
> probably have a good idea of what he wants to focus on, but I'll kick 
> off the discussion with a few ideas for 4.4, feel free to shoot down 
> whichever ones don't appeal to you:
>
> * The panel, taskbar and iconbox should be replaced by a single tool 
> that would do all three jobs. It must be possible to run multiple 
> instances of this tool.

Yeah, that would rock.  Ideally, the iconbox should just die, and the 
taskbar should be a plugin that's flexible enough to act like it's the 
iconbox.  This isn't much of a stretch, since it's already possible to 
not show the application names in the taskbar buttons.  Though, 
NetkTasklist kinda blows and should probably be rewritten.

> * We need to get rid of the concept that one module == one package. 
> The current plethora of packages is a pain and detracts from our image 
> of being lightweight. Ideally, we ought to have just xfce-core, 
> xfce-applications and xfce-devel. If we do this correctly, it should 
> still be possible for people who only want a single module (most 
> probably xfwm4) to get only it.

I'm not seeing how this would work.  The first part seems to me to be 
directly contradictory with the second.  If we have an xfce-core 
package, how do you just install xfwm4 out of it?  Think of the 
children!  Er... packagers.  I don't want to say "everyone else does it 
the single package way, so we should too", but... well, yeah.  It's done 
this way for a reason, and unless it's demonstrably better to do it 
another way (I'm not convinced it is), then it should stay the same.

> * We should have a "first run" application to configure whether you 
> want to run various parts of the environment. It should probably offer 
> sample configs (these are just ideas):
>     * Xfce (our preferred default setup)
>     * Light (only xfwm4 and xfdesktop)
>     * Ultra-light (only xfwm4 & xfrun4)
>     * CDE-ish
>     * Windows/GNOME/KDE-ish (they all look the same to me)
>     * Kiosk

Cool.

> * System Menu should be widgetized and should be fully fd.o compliant.

Yep.  Reading Benny's post, I pretty much agree that we should just 
ditch our menu format and use fd.o's.  Initially, this is what I wanted 
to do for 4.2, but then, as Benny notes, I found the fd.o spec rather 
cumbersome and annoying, and settled for something somewhere in 
between.  But yeah.  Let's ditch our menu format and I'll just import 
Benny's menu from Xfld.  JF will have to rewrite most menueditor, which 
really really sucks, but, well... Blah.

> * xffm to be replaced by a smaller, simpler, more basic file manager.

Actually, I'd like to see no file manager in the core whatsoever.  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.

> * Improve lockdown capabilities.

Sure, why not? (I personally don't care about this, but I know there are 
people who do.)

> * Panel Auto-Drawers that correspond to fd.o menu categories.

That's a neat idea, actually.

> * Move xfcalendar, xfterminal, xfmedia, mousepad into a separate 
> project called 'xfce applications'. Add all new utilities to this 
> project. Core probably already has all the modules that need to be there.

Nuh-uh.  I like maintaining Xfmedia on my own website, and that's where 
it's gonna stay.

> * Move to a dbus-based settings system.

Too early.  If we want a D-BUS-based settings system for 4.4, that'll 
push back a release considerably.  I really don't think we should have a 
hard dependency on D-BUS until it reaches 1.0 (unless they change their 
policy and guarantee API and wire-protocol compatibility before 1.0).

> * Any other ideas....
>
> What do you think?

There are a few minor features I want to add to xfdesktop, like 
different backdrops on each workspace.  For the desktop-wide stuff, I 
think it would be more productive to have a brainstorming session at 
FOSDEM, where we can all give easy realtime feedback and draw on 
whiteboards and stuff.

    -b