What are the objectives for Xfce 4.4?
Brian J. Tarricone
bjt23 at cornell.edu
Tue Feb 1 20:39:44 CET 2005
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
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.
> 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
> I also feel that we should have unstable releases more often.
> 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
> * 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
> * 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.
More information about the Xfce4-dev