What are the objectives for Xfce 4.4?

[Biju Chacko]

Benedikt Meurer wrote:
> Biju Chacko wrote:
>> * 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.

Perhaps symlinks to a single binary? My feeling is that all these 
services need to be provided by the same codebase for maintainability. 
How this codebase is run (multi-process, single process, user-visible or 
  not) is secondary.

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

The categories can be decided later.

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

There seem to be many issues with editing the fd.o menu, but if it can 
be made to then nothing like it.

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

I wouldn't know -- I haven't used KDE since 1.x days.

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

You misunderstand me ... not necessarily a single package, but 
definitely a separate project with separate objectives, timelines, etc. 
Mixing user-type applications and desktop environment type stuff will 
only cause focus to be diluted.

-- b