Integrating GFC into Xfce
jcf at tpg.com.au
Wed Oct 13 21:06:21 CEST 2004
Danny Milosavljevic wrote:
>Beware. It is C++ we are talking about. Binary compability will be
>broken on each and every occassion anything is changed in the gfc class
>interfaces. (more so if a "virtual" function is added/removed/changed)
>And I'd think adding a virtual function (a overridable method for a new
>signal, for example) is pretty common to do in a GUI binding.
>So I do think that keeping and distinguishing seperate versions on the
>same machine is required because of that.
>But Jeff should know better than me since I didn't touch C++ in ages ;)
>[visual c++ really makes sure one doesn't want to use it again, and
>since I learned it with that... you know ;)]
This was something I had mentioned previously. Either XFC (new name for
GFC) follows the GTK+ version numbers and installs into its own base
directory $includedir/xfc-2.x/xfc/... or it follows the Xfce version
numbers and installs into theXfce base directory $includedir/xfce4/xfc/...
If XFC follows the former then it would be independent from Xfce and
could be kept up to date with the latest GTK+ release. If XFC follows
the latter, then to ensure binary compatiblity it can only ever wrap the
minimal GTK+ dependency required by the current Xfce version, and XFC
would always tend to be behind GTK+ wrt to the inclusion of wrappers for
newer widgets. This is probably not a big problem because Xfce will
never be that far behind the latest GTK+ release with the minimal GTK+
version it requires.
I don't mind which way it works. I just want this integration to be
successful. Both alternatives have pros and cons. I guess it just
depends on how the Xfce developers see the future of XFC. I don't think
anyone would like to see XFC nothing more than 'dead-weight source code'
that offers no real benefits to Xfce. I would have thought that at some
point someone might use XFC to write an application for Xfce. If this
happens then XFC would be better included as a part of the Xfce desktop
so as to ensure binary compatibilty is never broken. This is what KDE/QT
tend to do. Each KDE release includes the QT version it is compiled with
(the qt library name suffexed with its <major.minor> version numbers).
Does anyone else have thoughts on this?
I wrote myself a small perl script to do all the text 'search and
replace' and that parts finished. It wont take long to update the
demo/example/test code and documentation so the first XFC version could
be ready in about a week, or two.
More information about the Xfce4-dev