Todo list for Xfce 4.4

[Benedikt Meurer]

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

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

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

> * 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 
this purpose).

> * 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?

[x]

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

Definetly!

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

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

> 	Jasper

Benedikt