Cleaning up libxfcegui4...

[Benedikt Meurer]

libxfcegui4 was extended with more and more stuff since the pre-4.0
days, and now contains probably more deprecated functionality than
useful functionality. Also, half of the library is not useful to many
applications (the netk stuff), while some applications like xfwm4 need
only the netk stuff and not the rest (well, the event filter stuff, but
that in turn is only used by xfwm4 so it should be moved to xfwm4).

I'd like to cleanup libxfcegui4 this way:

a) Put all netk stuff into libnetk, and
b) Start with a fresh and clean libxfce4ui (or another name, tho
libxfce4ui would be finally consistent with libxfce4util/libxfce4mcs),
containing only the dialog widget with the header mentioned in the
previous mail, and
c) let libxfcegui4 depend on libnetk and libxfce4ui.

This way the cleanup is backward compatible and all apps that require
libxfcegui4 will continue to work properly.

Next steps would be to copy app-specific stuff from libxfcegui4 to the
applications (i.e. the event filter stuff to xfwm4, the app menu stuff
to xfdesktop4, move handlers to xfce4-panel, etc.).

Afterwards we can discuss what parts of the left-over libxfcegui4 stuff
should be moved to libxfce4ui (only stuff that is not already available
in Gtk or will be available in the near future). And applications can be
fixed to use only libnetk and/or libxfce4ui. And at some point in the
future we can drop libxfcegui4 completely.

Another option would be to move the useful stuff from libxfcegui4 to
libexo (and the netk stuff to libnetk) and let applications use libexo
instead of libxfcegui4 (over time). This would require moving the
"Preferred Applications" MCS plugin to xfce4-mcs-plugins, tho, to
resolve the cyclic redundancy.

Whatever we decide, we should really try to avoid messing up one of the
core libraries this way again. A class/function should only be added to
a core library if it's useful in general and will stay useful for some
time, and app specific stuff should only be moved to a library once the
need arises to access it from other apps. Also, adding wrappers for
upcoming GTK features does not seem to be good practice; we should
either bump the required GTK version or do like libegg, with an
experimental libeggxfce or whatever, and applications copy the required
widgets and just drop them from the source once the functionality is
available in GTK.

Opinions?

Benedikt