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...
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!
• 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. 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. As always, just my €0.01.... Cheers Albrecht. [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/>
Attachment:
pgpEdLMClm3xv.pgp
Description: PGP signature