What are the objectives for Xfce 4.4?

[Benedikt Meurer]

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

The importance of when and what... I'm glad to see that you care about 
this as well, but I'm afraid that your attempt will fail just like the 
other previous attempts to get more `real world techniques' into Xfce... 
but, hey, maybe this time we'll manage to handle it... lets see.

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

ACK.

> Once the all the objectives of the 4.4 release have been met, we should 
> release.

s/we should release/we should create the release branch/.

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

ACK.

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

Jasper already migrated taskbar and iconbox over to the xfce4-panel, tho 
taskbar and iconbox are still separate binaries and thereby separate 
processes. Dunno how useful it would be to merge them into one service.

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

xfce4-session will most probably feature such a tool (atleast Olivier 
already requested it), although your categories don't make much sense to 
me, but thats a detail, that can be discussed when the tool is ready.

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

Xfld already includes such a menu. But the important point here is to 
import the XdgDesktopCache into libxfce4util, so other apps like the 
file manager and the app finder, that require access to .desktop files, 
can share the same cache.

In addition, we should IMHO ditch our simple menu xml format and use the 
menu-spec instead (with minor additions for the quit button and such). 
This means, the menueditor would need to be rewritten from scratch, with 
fd.o menu-editing (using Include, Exclude, Move, Deleted, etc.). I know 
that some people think that the fd.o menu-spec is cumbersome, and that 
its not trivial to implement a good parser and editor for the menu-spec. 
But thats IMHO the only way to provide a consitent, flexible and 
future-proof interface to the installed applications... just my 0.02€...

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

In the works, if...

> * Improve lockdown capabilities.

More apps should support kiosk mode, and there should be some kind of 
graphical configuration tool for sysadmins (IMHO).

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

Like in kicker?

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

I disagree (and atleast for xterminal, there'll be no merge). This 
reduces the flexibility of the maintainers and increases dependencies 
for people that don't want all those applications. Simple example, you 
want to use xterminal, but don't want to use xfmedia, then you'd need to 
install xine as well, and vice versa, you'll need D-BUS (although this 
will be optional in the near future) and Vte, although you just want to 
use xfmedia.

But I agree that several modules should be removed from Xfce core.

> * Move to a dbus-based settings system.

Ah, yeah, D-BUS... welcome to breakage! But besides the current D-BUS 
breakage, I'd want to wait until 4.6 or 4.8 and see how UniConf evolves.

> * Any other ideas....

* Elect a release manager for the 4.3 branch (and therefore for 4.4.0).

* Elect a maintainer for the 4.2 branch.

* Remove (or reorganize) modules from core: xfcalendar (merge with 
xfce-utils?), xfce4-appfinder (merge with xfce-utils?), xfce4-terminal, 
xfce4-toys (send to /dev/null?), xfce4-trigger-launcher (merge with 
xfce4-panel?), xffm.

* Merge xfwm4 and xfwm4-themes (separation can be achieved on the 
packagers level).

* Merge xfce-mcs-manager and xfce-mcs-plugins into xfce4-mcs-manager (if 
we don't jump the D-BUS train).

* xfce4-mixer backend should be a runtime option rather than a compile 
time option (atleast for Linux: ALSA or OSS).

* Merge xfprint and xfce-utils (and probably xfce4-appfinder)?

* Decide whether the new file manager should manage the desktop as well 
(yay, desktop icons! *haha*) and if so, ditch xfdesktop and merge the 
code into the fm.

* Parallel startup of applications with same priority for xfce4-session 
to optimize startup time (the increased startup time is actually a 
result of the usual XSM ping-pong-...-pong-ping).

* Developers Handbook for xfce4-dev-tools... real soon(TM).

* Reorganize the goodies panel plugins to reduce the number of separate 
modules.

* DnD for xfce4-panel.

* Some kind of composition manager configuration for xfwm4 (maybe a goodie).

* Checkpoints user interface for xfce4-session.

* Rename xfce-utils to xfce4-utils.

* Rework xfprint dialog (yep, thats me to blame).

* Helper applications framework (libxfce4util).

* Decide which non-core party apps to include with releases (either let 
users or developers vote at feature freeze time).

> What do you think?

As usual, I'm all for it, but I'm very sceptical.

> -- botsie

Bene*Yes, I'm lame*dikt