Goals for next Xfce releases

Alexandre Moreira alexandream at gmail.com
Sun Jan 28 22:24:26 CET 2007

2007/1/28, Ori Bernstein <rand_chars at rogers.com>:
> 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.

Talking about the menu. Is there any possibility that we'll see a
(SLED/Gnome)-like menu plugin for Xfce's panel ? I'm trying to learn
plugin development but this seems to stay waaaay out of my league for
a while until I learn all that I have to hehe.

I have some (I think) rather unusual ideas that most other users won't
agree to, and that is why I'm trying to learn how to write plugins :P

but I think a good menu that shows a bunch of favourites applications,
places, possibly some information (like mounted stuff, network, and
other weird small stuff) in a bigger-than-menu window is very nice.
(If you don't know what I'm talking about, this is somewhat like it)


More applications would bring some sort of Application Finder window
(like those you guys were thinking in adapting from Novell stuff) and
control center could launch much like the same thing with an altered
menu to display only settings-related applications.

We probably wouldn't have use for search, unless we had some kind of
tracker integration (which I think there should be at maximum an
optional feature, since not all our users would agree with this kind
of dependency)

Well, it is too long and not saying anything so, so sum it up what I
wanna know is:

I'm thinking in (much) later, when I get the grip on this panel plugin
thing (which I only started today) to try writing something like that
to Xfce. But it would be good to know before putting any deep
work/thought on it if anyone is really interested in it and if anyone
thinks in doing it, so we don't double efforts.

Alexandre Moreira.

> > cheers,
> >
> >     Jasper
> --
> Everything should be built top-down, except the first time.
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> http://foo-projects.org/mailman/listinfo/xfce4-dev

More information about the Xfce4-dev mailing list