Cleaning up libxfcegui4...

[Brian J. Tarricone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 5/2/2006 2:49 PM, Benedikt Meurer 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.
> 
> 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?

I agree with you, though are you talking about for 4.4?  Seems like not
the best time to do this if we're trying to push a release out the door.

I esp. like the idea of a libegg-type library that we don't actually
package.

As for gtk wrappers, I agree that they're a pain, but *not* wrapping
missing stuff could possibly mean re-evaluating our goals a bit (like we
have any ^_~): do we care more about ease of maintenance, or supporting
older distros/OSes that may be stuck on older glib/gtk versions?  Though
you make a good point that if a certain app needs some functionality, it
should be wrapped inside the app, and not moved to the library.

	-brian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)

iD8DBQFEV+lD6XyW6VEeAnsRAgXhAJ9iGY05t0wD+3Vvot6ZzWf68S2ZTACfV0QM
oR2nxTei9puNWQuCzkExR+s=
=JC9l
-----END PGP SIGNATURE-----