Cleaning up libxfcegui4...
Erik Harrison
erikharrison at gmail.com
Wed May 3 17:28:10 CEST 2006
On 5/2/06, Brian J. Tarricone <bjt23 at cornell.edu> wrote:
> -----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
I think more of the trouble comes from our long release cycle for
4.even versions of Xfce. We wind up deciding on the version of Gtk+ to
support after about month three, and then in 9 months we've seen
several major releases of Gtk+. Supporting the last stable version is
pretty reasonable, it's just that Gtk moves faster than us
> 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.
>
Won't a libegg (or possibly, a libblindmouse?) solution bypass this anyway?
> -brian
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (MingW32)
>
> iD8DBQFEV+lD6XyW6VEeAnsRAgXhAJ9iGY05t0wD+3Vvot6ZzWf68S2ZTACfV0QM
> oR2nxTei9puNWQuCzkExR+s=
> =JC9l
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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."
More information about the Xfce4-dev
mailing list