Goals for next Xfce releases

[Jannis Pohlmann]

On Sun, 28 Jan 2007 19:24:26 -0200, Alexandre Moreira wrote:

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

Yes, but this will probably not be in Xfce 4.6. The screenshot you
posted is based on GnomeCanvas and there is no GtkCanvas widget in
GTK+ 2.10. Anyway, I've had something similar in mind for quite some
time now and after the Xfce menu library is done, I'll try to come up
with a design for this.

For those who don't like the idea: The current simple menu will of
course be ported to the new menu library.

> 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)
>
> https://wiki.ubuntu.com/Slab?action=AttachFile&do=get&target=mainmenu.png
>
> 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.

I really like those interfaces introduced by Novell. However, I don't
think we should adapt it too fast, 1:1. Given that there's no canvas
widget in GTK+ 2.10, we should concentrate on cleaning up the internals
by depending on D-Bus, perhaps re-designing the settings manager)
before we think over a better look'n'feel.

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

I'll likely take care of the future menu as well as the application
browser (which perhaps also includes a generic layouting system other
applications, like the settings overview, could adapt).

Regards,
  Jannis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20070128/0584460b/attachment.pgp>