Re: Preparing for Gtk+ version 4
- From: Peter Bloomfield <PeterBloomfield bellsouth net>
- To: balsa-list gnome org
- Subject: Re: Preparing for Gtk+ version 4
- Date: Thu, 19 Jan 2017 19:04:06 -0500
Hi Albrecht:
On 01/19/2017 01:53:34 PM Thu, Albrecht Dreß wrote:
Hi Peter:
Am 19.01.17 00:52 schrieb(en) Peter Bloomfield:
We have only recently rationalized Balsa's git structure for Gtk+ version 3, and version 4 is already in
development. Trying to build Balsa in jhbuild against Gtk+ master shows that the API, still unstable, has
changed materially. We need a strategy to take advantage of the new version, while continuing to support
building with the stable version 3.
Unfortunately, there are still distos (e.g. Debian and Ubuntu) shipping with 2.4.*. Did anyone point their
package maintainers to Balsa 2.5? I mentioned this earlier [1] on this list, but never got a reply...
Anyone?
Options include:
• adding a configure option --with-gtk-api-version, defaulting to 3, and using conditional compilation to
have a single tree that will build with either version;
IMHO, this should not be the preferred way. Conditional code is hard to read and to maintain. There is
still a lot to weed out in master!
Agreed.
• creating a gtk4 branch for experimental building with version 4;
• creating a gtk3 branch for continuing to build with version 3, and using master to prepare for version 4.
The first option looks clumsy; the GtkBox API has changed, and requires 200+ changes in 30+ files, and that's
just one change! The second option mirrors how we handled the version 2 => version 3 transition, and that
became painful because of delays in the transition for dependencies. So I'm inclined towards the third option;
the downside is that enhancements and bug fixes need to be applied to both branches, and the enthusiasm for that
fades over time.
I vote for option 2 (i.e. a new gtk4 branch). The simple reason is again with disto maintainers. After a long period
of silence and no new releases, balsa-master became the new "stable" branch only last autumn, which has been
picked up by some distos. Changing the branches again, and using master for completely unstable stuff will be
confusing and thus does not seem to be a good idea to me. Anyway, a Gtk4 version of Balsa will appear in the
mainstream distos only when the gtk4 libs have stabilised, which may still take some time.
Yes, I'm still unsure about when we'll start to see the new API in the distros. Versions are currently in the 3.[89].x
stage, and at least one source has 4.0 in early 2019(!)--but whether the first "stable" version will be then,
or earlier, or later, is not clear to me.
If a new branch is created, *please* re-consider applying a consistent coding style (see the discussion in
[2]). The whole style is somewhat messed up, which also makes the code difficult to read and thus rather
error-prone.
The discussion last year ended in the assessment that no good formatter application is available. I
meanwhile discovered uncrustify [3] and UniversalIndentGUI [4] which together offer (IMHO) everything needed.
I installed uncrustify--its config file is quite intimidating! Do you have a proposal for one? My first
attempt to install UniversalIndentGUI didn't go well--I didn't see an RPM file, and I don't feel like
installing qt to build from source...
As always, just my €0.01....
Cheers
Albrecht.
Best,
Peter
[1] <https://mail.gnome.org/archives/balsa-list/2016-December/msg00004.html>
[2] <https://mail.gnome.org/archives/balsa-list/2016-February/msg00010.html>
[3] <http://uncrustify.sourceforge.net/>
[4] <http://universalindent.sourceforge.net/>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]