Goals for next Xfce releases

Ori Bernstein rand_chars at rogers.com
Sun Jan 28 22:08:55 CET 2007


On Sun, 28 Jan 2007 13:09:55 +0100, Jasper Huijsmans <jasper at xfce.org> said:

> Hello friends,
> 
<snip thank-yous>

Hopefully for 4.6 I'll have time to make that list too =)

> 
> Consolidate Platform
> ====================
> - 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?
>  
>   Or maybe we should just use GConf? It still depends on CORBA, I guess...

I believe that simple rc files are the way to go, possibly with an inotify
(gamin/fam/whatever) watcher when available is the way to go. Not only is it
lightweight, simple, it even gets you automatic/live updates when editing
config with a text editor (<sarcasm>obviously, a huge win</sarcasm>). I think
that a simple system like this was discussed a while back, with minor
variations (eg: one file per key, etc).
 
> - 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.

I think that isn't a bad idea. Right now, you really want to have D-Bus for
a fully functional desktop anyways, so it might as well become a hard dep for
4.6
 
> - New infrastructure?
>   - There is a notification daemon, are there programs that would like
>     to depend on this?
>   - ...

While I'm not sure about the implementation details of current notification
daemons, since on my main desktop I actually don't have one running at all I'd
like to bring up some UI considerations (specifically, the ones that prevent
me from running a notification daemon):

Currently, notification daemons pop up a bubble that disappears after a
timeout, making these "urgent" notifications useless if I'm away from the
computer at the time. What I'd like to see is notifications *NOT* popping up,
but instead getting queued up for later reading, with a button glowing in the
panel (note: not blinking, glowing) to notify me that there's something
important to read. This will, hopefully, reduce the "ADD Desktop" effect that
notification bubbles seem to have ("Hey! look at me!  I'm doing something
important! Oops, time to make that thing disappear!").

> Core Desktop
> ============

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

Some lightweight eye candy might be nice. For example, if composite and
render are used, I think it should be relatively easy to display live
thumbnails in the alt-tab dialog. Still, this isn't too important. On
my desktop, I don't even use composite right now.

> 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, more or less, like the UI of xfdesktop as it is. Without desktop icons.

All I see of the desktop when working is a small corner (which I use to get to
the desktop menu), which makes having icons on it completely useless for me.
While I prefer having a separate program to manage my desktop, I don't think
it's a big issue, so long as the current icon-free desktop UI stays as is.

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

This would definitely be cool, but yes, I think you'd have to subclass many
of the GTK widgets. Perhaps requesting a feature in GTK (or even submitting
our own patch) to add a style property by 2.12 or 2.14 or something, and
requiring a new version for opaque icons may be the way to go?

> - Rewrite tasklist widget. Someone posted some interesting mockups that
>   we could try to implement. Proper operation in vertical mode would be
>   nice as well.
> 
> File manager
> ~~~~~~~~~~~~
> No lack of ideas here, I believe. One from me: do we want to try and
> integrate with Tracker for searching? It does sound more in line with
> our philosophy than Beagle.

That does sound interesting. One thing I think would be nice would just allowing
globbing in the treeview search. 

> 
> 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 ;-)

It may be nice to add an interface for installing CUPS printers, however
last I looked, that seemed pretty difficult. Still, that may have changed
in newer versions of CUPS.
 
<snip>

One item you forgot:
 - Menu editor. It would be extremely nice to get rid of one our most FAQ. "How
   do you edit the "system menu"?

   This shouldn't be too hard -- we should be able to just inline the entries
   from /usr/share/applications/ and friends in the UI, and when a user edits
   them, the .desktop files should get copied to ~/.local/share/applications
   and edited there.

> cheers,
> 
>     Jasper

-- 
Everything should be built top-down, except the first time.



More information about the Xfce4-dev mailing list