Re: Preparing for Gtk+ version 4

[Peter Bloomfield <PeterBloomfield bellsouth net>]

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/>