Todo list for Xfce 4.4
benedikt.meurer at unix-ag.uni-siegen.de
Thu Jun 23 15:28:13 CEST 2005
Jasper Huijsmans wrote:
> Oh, and please respond with your ideas or comments.
I'll try to be brief.
> * check if gtk 2.4 provides things we had to provide for 2.2
> - Can GtkIconTheme be used? Gtk 2.6 has (I believe) an icon cache that might
> speed up lookup and reduce memory usage.
Yes and no: It DOES speedup icon loading IF the cache file is present
(tho, it still requires deserializing the icon data). In this case
there's another nice effect, in that the icon meta data is also cached,
which saves another open/read/close cycle. But the meta data is only
used within file managers currently, so there's not much gain for other
> * should xdg menu parsing be in one of the libs? xfdesktop and xfce4-appfinder
> use it, maybe other components will be interested as well.
Well, "xdg menu parsing" means parsing .menu files (XML) and parsing
.desktop files. We already have two .desktop file parsers in
libxfce4util. For the .menu parsing: This is highly dependent on what
you want to do with the data. E.g. the appfinder don't need to
understand .menu files in all their glory. While for a real menu, it is
necessary to have fine grained control over the loading in order to be
able to reload certain .menu files when they are changed or new files
are added, and then rebuild only the corresponding part of the menu.
What would be required in general is some kind of .desktop cache to
avoid having to read all files on startup. This cache should also be
usable from the file manager. xfdesktop-ng has such a cache, but it is
far from being perfect, was more or less a quick hack to make xfdesktop
startup fast from a live cd. If we really want to do this, then we'll
need a real solution here, at best something that is shared among
desktops, which means that somebody will have to work out a
specification and discuss it with GNOME, KDE, etc. until a solution is
found, that is generally accepted.
> * Is the mcs system still sufficient? The main limitation to me seems the fact
> that only the plugins can change the settings. The main advantage is the
> central location for configuration.
As long as we don't misuse the MCS system to store general application
settings, this is no problem. Core desktop components can life with the
fact that only the settings manager can alter settings.
For general application usage, we should better wait and see how D-CONF
Personally I tend to prefer to use GObject properties to access
preferences on a dedicated preferences object. This allows to switch the
backend quite easily by just changing the load and save operations of
that class, and also provides a simple, independent mechanism for
> * I really think we need a graphical interface to the session manager. It
> should allow people to add/remove programs from the saved session and
> probably should have a special section for Xfce desktop components. Maybe
> this requires communication between xfce4-session and desktop components to
> find out if they are running or not. I think we could use a volunteer for
> this, since Benedikt will be busy with thunar, I presume.
There are attempts to solve this problem in gnome-session, using D-BUS
communiation between the session manager and the clients. If this turns
out to be useful and applications adopt it, it'll be added to
xfce4-session as well. Besides that, there's also the 'welcome wizard'
thingy pending for xfce4-session 4.4. And xfce4-session already offers
support for checkpoints, but it's lacking a concept for the user interface.
But first, I have to rearrange some code in xfce4-session, because the
XSMP interface is not really maintainable right now. That said, larger
xfce4-session changes have to wait for the later Xfce 4.3 days.
Nevertheless, I welcome people to come up with suggestions about how to
address the issues mentioned above, esp. for the UI.
> * I wonder if, for people who don't want full-scale session management, it
> would be possible to disable this: just have xfce4-session start a list of
> programs and manage logging out. And I wonder if that would speed things up
> a bit.
I don't see any reason to do so. If somebody doesn't need session
management, he'll how to disable/deinstall xfce4-session. If you want
session management, there's not much space left for speeds up as it
requires the usual XSMP ping-pong on startup. One thing that could be
done would be to start clients with the same priority in parallel.
From the client side, applications that don't require full featured
session management should use the lightweight X11R5 way instead, like
Xfmedia and Terminal do (libexo provides the ExoXsessionClient class for
> * For the panel, see my mail about panel plans for 4.4. In summary: new plugin
> interface, multiple panels, support out-of-process plugins.
The out-of-process interface is the most important thing from my POV. As
I told you earlier, without it, we won't be able to do stuff like a
trash plugin or a volume manager plugin and such, atleast not without
major hacks (and no, loading the thunar-vfs and dependent libraries into
the panel process is not an option).
> * Thunar development has now really started. People are still reluctant to
> contribute code, it seems, so benny is mostly on his own. There is a list of
> tasks available if you check the thunar-dev mailing list archive. Benny has
> some demands about how to approach the development though, and I have a
> feeling not many people have experience with that.
I'm currently preparing a paper "Hacking on Thunar", which should make
it easier to understand the internals.
> * Do we want to move the goodies to Xfce SVN? Maybe Auke has an opinion on
> that as well, from the admin viewpoint?
> Hmm, did I miss anything? Maybe there are things in our development process
> that could be improved, e.g release management, translations management,
> website / other information sources.
> - xfce-libs: I don't think we have ever released one separately, so it may
> make sense to combine them into one package. They should still be separate
For consistent naming, I'd suggest to use "xfce4-libs" instead.
> * Documentation. We have some, but I'd like to see the user guide be a bit
> more extensive, answering more FAQ's. Have a list of things to configure
> after installation (Francois put something on the website, IIRC).
Developer documentation! gtk-doc API texts are still incomplete or
wrong. Also, the python bindings should be documented, maybe with a
tutorial (btw. if somebody figures out a good way to document pygtk
generated code, please let me know as libexo needs that as well).
More information about the Xfce4-dev