Cleaning up libxfcegui4...

[Erik Harrison]

On 5/2/06, Benedikt Meurer <benedikt.meurer at unix-ag.uni-siegen.de> wrote:
> 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.
>

How long do you propose this version of libxfcegui4 hanging around.
Especially in the case of netk, lots of panel plugins, which are
poorly maintained anyway, depend on that library. If we toss
libxfcegui4 for, say 4.8, that's fine, but if it goes in 4.6 then the
interface for panel plugin writers just changes too often to expect
plugin writers to keep up.

> 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
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> http://foo-projects.org/mailman/listinfo/xfce4-dev
>


--
Erik

"If Beethoven had been killed in a plane crash at the age of 22, it
would have changed the history of music... and of aviation."