Web lists-archives.com

Re: Gtk+4.0

On Sun, Jul 10, 2016 at 1:28 PM, <philip.chimento@xxxxxxxxx> wrote:
On Sat, Jul 9, 2016 at 1:14 PM Peter Weber <peter.weber@xxxxxxxxxxxx> wrote:

On Sat, 2016-07-09 at 19:06 +0000, philip.chimento@xxxxxxxxx wrote:

> I'm expecting this will become less and less of a problem as apps move
> to Flatpak as a means of distribution.

Uhuuu. I'm sorry, but this is bad.

This mixes two completely different problems together, packaging and a
toolkit. So enforcing Flatpak on distributions, developers and users
should solve a problem with Gtk+?

No, nothing about any of this proposal forces people to use Flatpak.

The problem Emilio mentioned was,

> some third party apps pick a dependency on the vte for GTK+ 4.2 but don't update it for GTK+ 4.4, as then distros would need to ship an increasing number of versions that are unlikely to get any support upstream.

In my opinion, the expectation is that app developers who sign on to the unstable series will see it through until the next long-term stable release, and not abandon development while still targeting an unstable release, leaving distros to package GTK 4.2, GTK 4.4, VTE-for-GTK-4.2, VTE-for-GTK-4.4, etc. because apps are all stuck at different versions.

Of course, nothing is stopping developers from doing that anyway. The same way nothing is stopping me right now from putting this line in my app's configure.ac:
PKG_CHECK_MODULES([APP], [gtk+-3.0 >= 3.18 gtk+-3.0 < 3.20])
However, if I did that then any distros trying to package it would quite rightly complain.

I'm saying that if an app developer feels the need to do that, then they will be better off targeting a Flatpak runtime.

Having said all this, I'm thinking about sketching out a proposal that doubles down on Flatpak like Jasper was suggesting. Paradoxically I think it might seem more palatable to more people... more updates later.

I intended my proposal as an strawman explanation that I thought was obviously silly. It wasn't a serious proposal, and I don't think it's the correct direction for the project to move in.
Philip C

gtk-devel-list mailing list

gtk-devel-list mailing list