Re: Gtk+4.x and broadway ( and other remote options )
On Thu, Dec 07, 2017 at 08:57:46AM +0100, Alexander Larsson wrote: > Maybe someone else is interested in consulting work on it though? There is a list of consultancy partners here: https://www.gtk.org/support.php ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_object_ref() now propagates types
On Fri, Dec 08, 2017 at 11:26:31AM +, Philip Withnall wrote: > Note that the new behaviour requires GCC, and is only enabled if you > have defined GLIB_VERSION_MAX_ALLOWED >= GLIB_VERSION_2_56. If GLIB_VERSION_MAX_ALLOWED is not defined, does it take by default the value of the last GLib version? -- Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
First deprecate APIs and then remove them in the next major version
Hi, I'm a bit worried about how GTK+ 4 is developed. It seems that there will be a lot of API breaks that will require to adapt the code at once. Ideally, a new major version of a library should only remove deprecated APIs. It's how a library should be developed, in case the developers want to get rid of old APIs: 1. New APIs are added. 2. Old APIs are marked as deprecated (but still work). 3. In the next major version, deprecated APIs are removed. Why is it a good practice to follow that approach? Because developers using the library can port their code to the new APIs *incrementally*. The deprecated APIs still work, so the code can be ported to the new APIs, one step at a time, by writing small and testable commits (for each commit, the code can be compiled, running the unit tests, testing the GUI, etc). Not with one huge commit/branch, untestable until all the code is ported. It is more work for the library developers to keep the deprecated APIs still working, but it provides a much smoother experience for all the developers using the library (and in case of GTK+, there are a lot of users). Can I remind you that most of the biggest GTK+ apps are still using GTK+ 2? MonoDevelop, GIMP, Ardour, … With the new model of GTK+ development, each stable GTK+ 3.9x version can be seen as a new major version, so that developers can port their code to 3.90, then 3.92, etc (if those versions are in a sufficiently usable state). But currently, with how those versions are developed, it'll be quite hard to port the code, the same as the GTK+ 2 -> 3 transition, because there are direct API breaks instead of just removing deprecated APIs. So, that's it, I think when GTK+ 4.0 will be released, if it is still developed in the same way, developers will have a really bad surprise when trying to port their code. At least 2 years worth of direct API breaks… GTK+ 4 will probably be awesome for writing new applications, but it'll probably be a different story for developers wanting to port their code from GTK+ 3. GTK+ 3 was criticized for being a bit unstable. But that was not the root of the problem IMHO, the root of the problem is that there are direct API breaks (and for GTK+ 3, the CSS was not sufficiently advertised as having an unstable API; it's fine to have unstable APIs in a library, but there must be big warnings in the documentation). My 2 cents, Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: First deprecate APIs and then remove them in the next major version
On Wed, Dec 13, 2017 at 04:55:41PM +, Emmanuele Bassi wrote: > The API that gets removed in GTK+ 3.9x is deprecated in GTK+ 3.22 beforehand. No, that's not true. A recent example: https://git.gnome.org/browse/gtk+/commit/?id=2d5c82b4ecbe6ff534a1b9476080e409742daa39 "gtk: Remove GtkClipboard" The clipboard is now implemented in GDK. GtkClipboard is not deprecated in GTK+ 3.22, and the new API is not available in GDK 3.22. I think Benjamin has done a great work with the new implementation. Just a little problem: it's what I call a "direct API break", applications or higher-level libraries will need to be ported from GTK+ 3.92 to 3.94 with a big API delta, so it will result in one huge commit/branch untestable until all the code is ported [1]. It's of course much worse if porting directly from 3.22 to 4.0. [1] What I would recommend is to copy custom widgets/containers (if they are self-contained) out-of-tree, and port them individually, with a small GUI test program for each, so that they can be tested outside the whole application. -- Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: First deprecate APIs and then remove them in the next major version
On Wed, Dec 13, 2017 at 03:08:46PM -0800, Christian Hergert wrote: > On 12/13/2017 04:05 AM, Sébastien Wilmet wrote: > > Can I remind you that most of the biggest GTK+ apps are still using > > GTK+ 2? MonoDevelop, GIMP, Ardour, … > > MonoDevelop is still Gtk2 because Novell/Xamarin/Unity3d invested, quite > literally, millions of dollars on consultants to work on the OS X port > (without much interest in paying additional money to have that work > upstream'd or ported to Gtk3). Add to that the necessity to write new > bindings around G-I for Gtk♯ 3 and you can get the idea of how they see > that as risk from a business standpoint. > > Ardour could never move to Gtk3 because a number of VST plugins use Gtk2 > and you cannot mix both into the same process space. DAW authors will > often cite the necessity for plugins to be in process to allow for a > large number of tracks/plugins due to context switching. (This is a > contributing factor to why many DAWs write their own UI toolkits). Thanks for that information, I was not aware of those problems. > As for GIMP, I think the lesson I take away is that we need to recruit > people to go do the ports for important projects rather than expect them to > track us. Red Hat has shown that this strategy works in both Firefox and > LibreOffice (which are arguably the two hardest applications to port). The question is: why don't they do the port to GTK+ 3 "themselves"? Because it's hard, you say it yourself in case of Firefox and LibreOffice. With the GTK+ 2 -> 3 transition, there are a lot of "direct API breaks". With GTK+ 3 -> 4, the same is happening. Lots of direct API breaks at once, that's what makes it hard to port an application or a higher-level library. For 10k lines of code, it's entirely feasible. For 100k lines, it's feasible by a full-time employee. For an application the size of MonoDevelop, this is just unmanageable IMHO. With "soft API breaks" (i.e. just removing an API that was deprecated in a previous major version), I think this would improve a lot the situation and would avoid to repeat the same problem as GTK+ 2 -> 3. -- Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: First deprecate APIs and then remove them in the next major version
On Thu, Dec 14, 2017 at 08:02:56PM +0100, Bastien Nocera wrote: > On Thu, 2017-12-14 at 19:56 +0100, Sébastien Wilmet wrote: > > > > > With "soft API breaks" (i.e. just removing an API that was deprecated > > in > > a previous major version), I think this would improve a lot the > > situation and would avoid to repeat the same problem as GTK+ 2 -> 3. > > It already exists. Look at the "DISABLE_DEPRECATED" macros in the > current version of libraries, and which usually get removed in the +1 > version. Yes, it's a nice feature, but it doesn't solve the problem that there are a lot of direct API breaks during GTK+ 3.9x development. -- Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: First deprecate APIs and then remove them in the next major version
On Thu, Dec 14, 2017 at 08:34:51PM +, Emmanuele Bassi wrote: > On 14 December 2017 at 18:42, Sébastien Wilmet wrote: > > A recent example: > > https://git.gnome.org/browse/gtk+/commit/?id=2d5c82b4ecbe6ff534a1b9476080e409742daa39 > > "gtk: Remove GtkClipboard" > > > > The clipboard is now implemented in GDK. GtkClipboard is not deprecated > > in GTK+ 3.22, and the new API is not available in GDK 3.22. > > The new API just landed; and, yes: it's hard to deprecate the API in > this case, given that the new API has been moved down one level in the > hierarchy. GDK, GSK and GTK are now part of the same *.so library. If GtkClipboard still worked fine just before the commit that removed it, it would have been possible to first deprecate GtkClipboard and then removing it in 3.9x+2 (see my comment below). Of course if GtkClipboard didn't work anymore, then it needed to be removed. Or maybe it was possible to port GtkClipboard to the new GDK API, but this would have been more work for the GTK developers. It all depends if you want to provide a smooth experience to port apps. > Doing this work in 5 years, for GTK+ 5.0, > would not have been any easier for anybody. I don't understand why you say that. Each semi-stable 3.9x version can be seen as a new major version, since it's possible to break the API. So an API can be marked as deprecated in 3.92 and then removed in 3.94. Instead of doing a direct API break. This would make it easier to port applications. -- Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: First deprecate APIs and then remove them in the next major version
On Fri, Dec 15, 2017 at 11:10:46AM -0500, Matthias Clasen wrote: > I know this may sound harsh, but: If you want things to work differently, > send patches. > Patches to the migration guide are welcome too. > > The bulk of the work done on GTK4 so far has been done by 3 or 4 people, > only one of > which gets payed to work fulltime on GTK+. > > Maintaining compatibility layers costs and constantly gets in the way of > large-scale > refactorings like the ones that are happening in gtk 3.9x now. > > Note that we haven't really asked application developers to port to the > current 3.9x releases > yet, because they are still in flux. About the cost of compatibility layers, it reminds me an economics principle with game theory and cooperation, for example with the prisoner's dilemma: https://en.wikipedia.org/wiki/Prisoner%27s_dilemma#Strategy_for_the_prisoner's_dilemma With cooperation and compatibility layers in GTK, GTK would move forward less quickly, but it would maybe yield a better outcome globally when taking into account higher-level libraries and applications. -- Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
DhCompletion, a GCompletion replacement
Hi, Just a small announce, I've implemented recently a replacement for GCompletion in Devhelp. GCompletion is deprecated, but for some applications it's still useful to have a string completion utility. https://git.gnome.org/browse/devhelp/tree/src/dh-completion.h https://git.gnome.org/browse/devhelp/tree/src/dh-completion.c It's unit-tested and documented with gtk-doc. The API is a little different, but better suits the needs of Devhelp. It uses a GSequence internally (instead of a simple GList in GCompletion). Feel free to copy the code in your project ;-) Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
