Goals for next Xfce releases

[Danny Milosavljevic]

Hi,

On Sun, 28 Jan 2007 13:09:55 +0100, Jasper Huijsmans wrote:
> Hello friends,
> 
> No this doesn't mean I want something from you ;-)

Heh. heh. he. ;-)

[...]
> Consolidate Platform
> ====================
> 
> - Cleanup and merge libraries:
>   - compat, util, netk, gui, mcs, menu (?), ...
> 
>   Is there any package that wants to depend on libutil alone? I can't
>   really think of any. In that case we could decide to have only one
>   xfce-libs package. Maybe mcs should be separate?

I'm really not that much into library discussions, because how we split up the libraries or not doesn't make noticable difference anyway.

Ideally everything that has dependent objects could just as be in it's own library (because then, the directory is smaller and hence everyone can find stuff faster).

For example netk's classes need one another, but need nothing from the rest of libxfcegui4.
Hence they _could_ be split into libnetk. The naming within the files already suggest it was that way once, so...

As for util and gui, I think this is an obvious model/view separation and should stay, because it leads to better design. Of course we could merge them and keep in mind which are model and which are view manually ;)

Then again, there is non-gui-view stuff like NETK in gui, instead of util. Strange.

> - Settings daemon. No gui, use D-Bus to get/set values and listen for
>   changes. 
> Dialogs are started from .desktop files. This will make it easier
>   to combine the interface for settings from different packages
>   (keyboard shortcuts for instance), if we want that.
>   Needs to depend on X for xsettings :( Or should that be separate?

Well, I'm still sold on my unconventional just-use-tons-of-files[1] idea for now. Once I've implemented it for everything locally, I'll be able to tell you whether it slows everything down to a crawl or uses up all the inodes or commits blasphemy to the deity of gravity or not (so far it doesn't).

Dialogs could just be normal applications (as in, executable). If you wanted to merge them, you'd dock the window from the other application (a la "mplayer -wid <xid>"). Or we could do the whole gui-is-only-xml-and-you-can-merge-them ala bonoboui.

>   Or maybe we should just use GConf? It still depends on CORBA, I guess...

Haha, everyone that reads that is dropping hir coffee right now ;)

> - Allow dependency on D-Bus for IPC. I wouldn't mind making this a hard
>   dependency for Xfce, if it enables us to integrate our components
>   better, which I think it will.

Sounds good. 

> - New infrastructure?
>   - There is a notification daemon, are there programs that would like
>     to depend on this?

I have a log watcher, paranoid as I am. So I'm all for it (although the notification-daemon lib is kinda weird to use - I have funny workarounds in place) ;)

> Core Desktop
> ============
> 
> Session manager
> ~~~~~~~~~~~~~~~
> We probably want to keep an eye on the efforts to rewrite gnome-session.

Or make our session manager wait() on applications that registered themselves.

There's another thread about this.

> Window manager
> ~~~~~~~~~~~~~~
> For me xfwm4 does everything I want it to, so I've no ideas for 4.6.

Same here, although I'm playing around with auto-grouping-of-windows-into-tabs, auto-tile-screen stuff and workspaces-as-filter here ;-)

> Desktop manager
> ~~~~~~~~~~~~~~~
> Do we want a separate program to manage the background or should it be
> part of thunar? How about the desktop menu?

I'm all for separate program. Breaking the "process = window" simplification shouldn't be done lightly, except when we target a C64 or something ;) (nautilus does the magic-desktop-overtake thing whenever one opens a file manager window and I can't say I like that much)

If by "part of thunar" you don't mean "part of the main thunar executable", then nevermind.

> Panel
> ~~~~~
> I'm very interested to know what people are missing in the current panel
> (besides CDE emulation ;-), so if you have wishes, preferably with an
> example use case, this would be a good time to let us know.

Haha. I'm still playing around with my launcher-taskbar-merge-thing[2]...

And I found something nice (although just a tasklist - no launcher) on code.google.com (I can't remember what it was called - something like "ah*-window-*") that did well on the eye candy part, like totally over-the-top animation for the "Urgent" hint and all.

> Some ideas of my own:
> - Transparency. I guess what people want is a translucent panel with
>   opaque icons. This is hard. It means we have to write our own panel
>   widgets, because every widget with a window needs to handle
>   transparency in its expose handler. Ideally Gtk would handle this with
>   a style property that could be set from a gtkrc file, but that is not
>   the case now.

Having tried panel transparency[3], I didn't like it much. After all, either
1) there is nothing below the panel, then there is no point, or
2) there is something below the panel, then it tires your eyes to have to distinguish between them on a pixel-by-pixel basis.

So while there are uses for (real) transparency, this is not it.

> - Separate desktop files for launcher items. Someone mentioned this
>   recently, I think it was benny. I'm not convinced this is necessary.
>   We already use the same structure (Name,Icon,Exec,etc...), but the
>   launcher items are not stand-alone programs, they are programs +
>   options, so we can have 10 terminals with different arguments. Why
>   would we want separate files for that?

Hmm? I don't get what you mean by "separate desktop files". Aren't they already separate? It's not like we pull something weird like the mbox format does... :)

> 
> - DND of (desktop) files directly to the panel. Yeah, that would be
>   interesting. It's not easy, since there is no free space on the panel
>   to drop anything on. It also requires launcher items to be special,
>   but I don't really have a problem with that.

That would be nice, yeah. 
If DND protocol is flexible enough, just have free spaces appear between the items once the user started dragging.

[...]
> Apps/Utilities
> ==============
> 
> No real ideas from me here. I'll just list the apps we have now:
> 
> - Printing. I never use it, so I have no complaints ;-)
> 
> - Mixer/Volume. Works for me at home, but at work I have a USB headset
>   and the mixer plugin always falls back to the soundcard, so I guess it
>   could still be improved. 

Oops. Sounds like a bug. So you change the primary soundcard in the settings plugin and it reverts?
As a workaround, you can pass the device name to "xfce4-mixer". Doesn't help you with the panel plugin, though.

I'll debug that, I guess.

> It also uses GOB, which IMO sucks, sorry Danny.

Well, the longer I program, the less I tolerate C (or C++, for that matter). So GOB at least does some of the  drudgework for me (i.e. 90% of all C code) (although some parts of GOB are strange, it works mostly without issue). I could do something similar with about 300 horror-inducing #define's, I guess. Dunno.
Or I could just convert to Lisp/Dylan/Ruby completely. *grins*

[...]
> One thing that crossed my mind when thinking about 4.6 was that I
> couldn't think of anything that would make us change to 5.0 instead of
> 4.x. So, if we're not going to change it anyway, we could pull a Sun and
> call the next version "Xfce 6". Might be good for marketing ;-)

lol. Well, we don't want to change the Widget Toolkit again, do we? ;)

cheers,
 Danny

[1] http://xfce.wikia.com/wiki/Simple_Settings
    Witness the comments at http://blog.xfce.org/?p=171#comments
    I guess some don't think that an unified namespace is worth it. 
    Oh well.
    I'm fine with the current xfce rc file approach, but _if_ we do a "config system" and it were not accessible as normal files (whether they _are_ separate disk files internally or not is beside the point) as part of the normal API, then what's the point? Obfuscation?

[2] http://traveller.sourceforge.net/

[3] For testing, I put every item into an event box of its own and then the shape combine mask was easy to calculate :)