Re: Gtk+4.0

[Peter Weber]

// edit: 4.0 -> 4.90
or 4.90 and 5.0 will less likely.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Peter Weber]

On Wed, 14 Sep 2016 16:12:15 +0100, Davin McCall 
wrote:
> I think removing deprecated API when incrementing the major version is
> acceptable...

That's is what I wonder about. I'm just pedantic and likely misreading
this line:

> When bumping to a new major version deprecated API will be removed.
[1]
https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/

Wouldn't it be much more convenient to introduce required and projected
API-Breaks at the start of a new development-series e.g. at 3.90 (so now,
during this days?), 4.90 and so on? So especially developers of GNOME and
others which follow the development-series would have an easier life,
because subsequent breaks between 3.90 and 4.00 or 4.0 and 5.0 will less
likely.

Peter
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Davin McCall]

On 12/09/16 19:35, philip.chime...@gmail.com wrote:
I won't have time to reply to this and Peter's new messages just now; 
but Davin, I'm curious to know if the plan from [1] addressed some of 
your concerns.


[1] 
https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/



To a large degree, yes. The new plan seems much more sensible, in my 
view, than the original proposal. Having a distinct numbering scheme for 
development releases is important. I think removing deprecated API when 
incrementing the major version is acceptable, though I would still argue 
against doing so in cases where it does not create a clear maintenance 
burden.


(Put it this way: can the old API be implemented in terms of the new? If 
so, do it once and you never need touch it again. If not, does this 
indicate a shortcoming of the new API?).


For the most part, though, I think the plan as outlined will alleviate 
the concerns of many developers.


In lieu of a better reply, one thing that I'm reading from the above 
is that it might be good to do a GTK blog post on what our best 
practices are for API design. We do have them; the API doesn't just 
emerge from the code; but it would be a really great idea to 
illuminate what goes on.


I'm glad to hear that, and I for one would be interested in reading such 
a blog post.


For what it's worth, the current desires to break API I would say 
mostly stem from needing to get rid of API that was designed in a 
different era, and is holding things back by making too many 
assumptions about the underlying tech stack.


Yes, I certainly understand the need, on occasion, to remove or 
incompatibly change API that cannot feasibly be made to work with new 
developments. I think that there does need to be awareness, however, 
that changing API creates a burden elsewhere (in external projects that 
use the API). Removing deprecated API may sometimes be necessary, but if 
it is done over-zealously it forces other projects to continuously track 
API changes or choose instead to stick with an old, stable API which (no 
matter how long-term its support is) will eventually be obsolescent. 
Perhaps the latter is inevitable for projects that are not afforded the 
luxury of continuous ongoing maintenance, but it is still desirable to 
postpone it where possible. In my view, good API design practice tends 
to produce future-proof APIs (which can made to work even with 
unforeseen technology changes in the future). Having said that, I do 
realise it is not always possible to produce the perfect API the first 
time around.


Regards,
Davin

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[philip . chimento]

On Mon, Sep 12, 2016 at 8:14 AM Davin McCall  wrote:

> Hi,
>
> I'm not a regular poster to this list and am not subscribed. I'm posting
> here now at the suggestion of Philip Chimento, who read a blog post I wrote
> recently [1] about the GTK+ lifecycle plans that have recently been
> discussed/announced. This blog post of mine received, for whatever reason,
> a lot more attention on anything than my blog normally does (just shy of
> 20,000 views in a day, when my average views per day of the whole blog is
> around 10) - which puts me in a position such that I feel I should address
> the concerns in a more head-on (and level-headed) fashion. I'll freely
> admit the tone in the blog posting is that of an indignant rant, though I
> hope no-one is personally offended by it since that certainly wasn't my
> intention.
>
> I'm concerned at the outset that this will be dismissed by people who are,
> after all, much more involved in GTK+ than I've ever been, so I ask that
> you read this with an open mind and with the understanding that I'm writing
> this out of genuine concern that's developed from the experience of dealing
> with API breakages in various packages over a long time-frame.
>
> My concern is that the new plan lays a foundation for breaking the API on
> a more regular basis, and formalises the notion that this is ok if it
> allows innovation in the design and development of GTK. While I am all for
> innovation, I am disturbed that casual API breakage in its name is being
> legitimised, especially because I do not believe that is necessary. From
> the proposal [2], statements such as:
>
> If new features conflict with existing ones, API might be removed, rather
> than being deprecated.
>
> ... are of particular concern. Further, I don't believe that this is
> consistent with the very next point in the same document:
>
> there will be an effort to limit breakage as much as possible.
>
> "As much as possible" is a *very* strong statement. If this was really
> the aim, there would be hardly any legitimate reason to break API at all,
> making the whole plan unnecessary. I'd suggest that the latter point is
> somewhat disingenuous (even if unintentionally so); putting it bluntly,
> only one of those two points can be correct, and from the tone of the
> document, I'm assuming that it's the first one and the second is a case of
> overly-strong wording. But on the other hand, removing API instead of
> deprecating is most definitely a breaking change that can often be *easily*
> avoided, let alone "as much as possible".
>
> Please do not assume I am basing my entire concern on that point alone.
> The general feeling from the proposal and the GTK development blog post
> that I initially responded to is that API stability is very much being
> pushed to a low priority compared to the need to push development ahead. I
> understand that API breakage does sometimes need to occur, but I think this
> attitude is not a good one. In particular I think the implied notion that
> API stability and good development progress cannot coexist is incorrect.
> I would be reassured perhaps if the plan discussed what software
> development methods were in place that would help to reduce the amount of
> API breakage needed. What is the procedure for API design in GTK - if there
> indeed is one? Are APIs reviewed before they are implemented? Are they made
> available for public review? Are there any guidelines? The Best Practices
> document [3] doesn't even mention API design; why not? Are the APIs even
> designed at all? I am left with the worrying impression (hopefully not
> correct) that the API simply emerges from the code. This would certainly
> explain why API breakage might be needed on a regular basis, but that's a
> symptom of an imperfect design practice; if it is being found that the
> resulting APIs are not extensible or flexible enough for ongoing
> development and future requirements, then I strongly suggest that the
> better solution is to improve the API design methodology, rather than
> simply to legitimise casual API breakage.
>
> I understand how open-source development often works in ways that don't
> suit more traditional rigourous approaches, but I would recommend
> establishing a set of guidelines for API development, and at a minimum have
> each commit/check-in that introduces new API be reviewed against those
> guidelines by a developer not otherwise involved. Since I can't claim to
> know how GTK development proceeds there's the possibility that something
> like this (or better) already happens - in which case, perhaps my concerns
> can be dismissed; if so, please consider publishing details and updating
> the Best Practices document.
>
> Thanks for reading,
>
> Davin.
>
>
> [1]
> https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations
> [2] https://wiki.gnome.org/Projects/GTK%2B/Lifecycle
>
JFTR, this is the mail stuck in the moderation queue that I was 

Re: Gtk+4.0

[Peter Weber]

On Thu Jul 7 11:35:02 2016 GMT+0200, Davin McCall wrote:
> Hi,

Thanks for your mail. Sadly I'm currently only connected with a very slow 
throttled mobile network.

I generally think you are pointing at the right issues. The API-Desing and the 
plan behind.  The officiall announcment calmed me down a little and  sounded 
better than the previous one, I want ask a question:
It sounds like the biggest API-Breaks are delayed in the development-cycle till 
the last internal version, is that right? Or did I misunderstood that? Awkward. 
I would do that early, in the first cycle.

Three years of stability sound also better than two, while I still hope for 
nearly no breaks and the officiall announcment seems to say, that the API 
doesn't necessarily break between the stable majors if not required. Well, 
Davin is pointing at this.

I understand the need for Gtk4 (X11-Foundation inside Gtk/GDK, GSK and so on) 
itself. I'm worried that the subsequent plan to break *regulary* for 
*stability* and splitting up into to permanent branches is not what the 
application-developers need. Is it possible, that the wrong thing happens for 
the right reason? I have the feeling that Gtk want give the 
application-developers what they want, but is doing the opposite by accident?

Bye
Peter

PS: A lot of people mention CSS. Honestly, that is not part of the 
Programming-API! How much API-Break (C, C++, Python) did we faced in Gtk3? 
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Sébastien Wilmet]

On Sat, Sep 03, 2016 at 02:19:11PM +0100, Emmanuele Bassi wrote:
> On 3 September 2016 at 10:27, Sébastien Wilmet  wrote:
> 
> > The versioning looks much better. Small detail, during the next
> > development cycle, the alpha/beta/rc versions will be 3.89.x, with the
> > 3.90.0 version released in March 2017, right?
> 
> Starting at ".90" has a good round number feeling to it, and it makes
> it easier to spot the pattern — but we're still debating which minor
> version number will be assigned to the first development release of
> the cycle. We are reluctant to drop the invariant that the odd release
> numbers signal instability, so the first release in a development
> cycle would be .91, and the first "island of stability" following it 6
> months later would be .92, followed by the development cycle starting
> with .93, etc.:
> 
>   [ Development starts here ]
>   .91.0 → .91.n — development, dropping deprecated API
>   .92.0 → .92.n — partially stable
>   .93.0 → .93.n — development, with no strict blanket backward
> compatibility guarantee


Starting at .91/.92 permits a maximum of 2.5 years to reach 4.0, if the
numbers are kept in the 90's (otherwise it gets ugly with 3.100, 3.102,
etc).

Starting at .89/.90 would allow 3 years (2-3 years is what the
announcement says).

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Emmanuele Bassi]

Hi;

On 3 September 2016 at 10:27, Sébastien Wilmet  wrote:

> The versioning looks much better. Small detail, during the next
> development cycle, the alpha/beta/rc versions will be 3.89.x, with the
> 3.90.0 version released in March 2017, right?

Starting at ".90" has a good round number feeling to it, and it makes
it easier to spot the pattern — but we're still debating which minor
version number will be assigned to the first development release of
the cycle. We are reluctant to drop the invariant that the odd release
numbers signal instability, so the first release in a development
cycle would be .91, and the first "island of stability" following it 6
months later would be .92, followed by the development cycle starting
with .93, etc.:

  [ Development starts here ]
  .91.0 → .91.n — development, dropping deprecated API
  .92.0 → .92.n — partially stable
  .93.0 → .93.n — development, with no strict blanket backward
compatibility guarantee
  …

  [ Long term support starts here ]
  .0.0 → .0.n — stable
  .1.0 → .1.n — development, backward compatible
  .2.0 → .2.n — stable
  …

This would also make it easier to deal with the versioning macros
instead of adding an "89" special case.

Currently we're still working on getting the 3.22 release out; as soon
as that's done, we're going to concentrate on the development cycle
for 4.0, including the deciding the actual version that begins it.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Sébastien Wilmet]

To people who might have missed it:
https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/

Some comments:

“While the GTK+ team reserves the right to change API during development
series, this does not mean that the whole GTK+ API will constantly break
each release; only specific, and hopefully rarely used parts of the API
may change, and if the changes are too extensive they will very likely
be delayed to the next major development cycle. We’ll ensure that these
changes are well-communicated in advance.”

As a maintainer of several GNOME libraries (doing it during my free
time), this reassures me.



The versioning looks much better. Small detail, during the next
development cycle, the alpha/beta/rc versions will be 3.89.x, with the
3.90.0 version released in March 2017, right?

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Sébastien Wilmet]

On Wed, Aug 17, 2016 at 03:06:43PM +, Philipp A. wrote:
> Peter Weber  schrieb am Mo., 15. Aug. 2016 um
> 14:20 Uhr:
> 
> > Gtk is the GNOME-Toolkit and it's fine, if XFCE or Cinnamon put work
> > inside Gtk it
> > could also named the GNU-Toolkit.
> >
> 
> is this a joke? GTK means “GIMP toolkit”. always has.


Don't read "Gtk is the GNOME-Toolkit" literally. It was meant to say
that GTK+ is developed mostly by GNOME developers, for the GNOME
desktop.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Philipp A.]

Peter Weber  schrieb am Mo., 15. Aug. 2016 um
14:20 Uhr:

> Gtk is the GNOME-Toolkit and it's fine, if XFCE or Cinnamon put work
> inside Gtk it
> could also named the GNU-Toolkit.
>

is this a joke? GTK means “GIMP toolkit”. always has.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Nandakumar Edamana]

>> From time to time, it is nice to get rid of deprecated APIs, to have
less code to maintain. GTK+ 3 has quite a lot of deprecated classes. So
getting rid of those, that alone is a good reason to release GTK+ 4, in
my opinion.

Of course it is necessary. But we have to think about backward
compatibility also. Or can we prepare a separate wrapper library that
maps the obsolete API functions to the latest ones? (I know it is a
bad idea, but app developers always ask for backward compatibility).

On 8/15/16, Thomas Martitz  wrote:
> Am 15.08.2016 um 14:48 schrieb Sébastien Wilmet:
>> On Mon, Aug 15, 2016 at 02:20:25PM +0200, Peter Weber wrote:
>>> I think breaking the API/ABI because of required changes, is right,
>>> breaking API/ABI because a fixed number of months has passed doesn't
>>> make
>>> much sense.
>>  From time to time, it is nice to get rid of deprecated APIs, to have
>> less code to maintain. GTK+ 3 has quite a lot of deprecated classes. So
>> getting rid of those, that alone is a good reason to release GTK+ 4, in
>> my opinion.
>
> Tons of the deprecated APIs have no nice replacement, or no replacement
> at all. For example GtkImageMenuItem, Stock Items, GtkActivatable.
> Removing them will just make adoption of Gtk 4 even harder.
>
> Best regards.
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Thomas Martitz]

Am 15.08.2016 um 14:48 schrieb Sébastien Wilmet:

On Mon, Aug 15, 2016 at 02:20:25PM +0200, Peter Weber wrote:

I think breaking the API/ABI because of required changes, is right,
breaking API/ABI because a fixed number of months has passed doesn't make
much sense.

 From time to time, it is nice to get rid of deprecated APIs, to have
less code to maintain. GTK+ 3 has quite a lot of deprecated classes. So
getting rid of those, that alone is a good reason to release GTK+ 4, in
my opinion.


Tons of the deprecated APIs have no nice replacement, or no replacement 
at all. For example GtkImageMenuItem, Stock Items, GtkActivatable. 
Removing them will just make adoption of Gtk 4 even harder.


Best regards.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Peter Weber]

On Mon, 15 Aug 2016 14:48:46 +0200, Sébastien Wilmet 
wrote:
> On Mon, Aug 15, 2016 at 02:20:25PM +0200, Peter Weber wrote:
>> I think breaking the API/ABI because of required changes, is right,
>> breaking API/ABI because a fixed number of months has passed doesn't
make
>> much sense.
> 
>From time to time, it is nice to get rid of deprecated APIs, to have
> less code to maintain. GTK+ 3 has quite a lot of deprecated classes. So
> getting rid of those, that alone is a good reason to release GTK+ 4, in
> my opinion.

I think so. Getting rid of deprecated APIs from time to time is a required
reason :)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Sébastien Wilmet]

On Mon, Aug 15, 2016 at 02:20:25PM +0200, Peter Weber wrote:
> I think breaking the API/ABI because of required changes, is right,
> breaking API/ABI because a fixed number of months has passed doesn't make
> much sense.

>From time to time, it is nice to get rid of deprecated APIs, to have
less code to maintain. GTK+ 3 has quite a lot of deprecated classes. So
getting rid of those, that alone is a good reason to release GTK+ 4, in
my opinion.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Peter Weber]

https://media.ccc.de/v/7-inspector_gadget#download

I want suggest viewing the record of Benjamin Otte's talk about "Gtk
Para...Inspector" at GUADEC 2016! Which is, indeed, only about Gtk-4.0 and
the follwing development model!


I think Benjamin has done a great job in calming everyone down and
explaining the thinking behind the planning. You should take the time to
view it completely, but timecode 07:00 (two year-cycle and feature vs.
time-based) and timecode 10:00 (depending libraries like GktSourceView)
are interesting. Furthermore he explained to me (afterwards) very nicely
why the bump to Gtk4 itself is required, the old internals of X11 are
still built inside Gtk3 and working behind it's Wayland-backend from old
times. So cleaning the things up is necessary. I can't say if bumping to
Gtk4 would also be a good idea looking at GSK, manuelle Bassi knows this
better.


The other thing is the development-model following after first release of
Gtk4. I can feel the churn and tension between your lines "suicide"
and Emanuelles "who does the work in gtk development". Gtk is the
GNOME-Toolkit and it's fine, if XFCE or Cinnamon put work inside Gtk it
could also named the GNU-Toolkit. That naming thing is not the point.

Library-developers want a clean and lean library (API/ABI breaks), while
application-developers need stability (avoid API/ABI breaks) and both
together want new and nice features (the thing which
makes it difficult)? As longer a library keeps stable and moves also ahead
with some new features, as more tolerable and enjoyable breaks of the
API/ABI become from time to time. Everyone is willing to pay a price for a
good thing.
Just extending the stability period on four years will not fix it. It's
hard for me to explain, so bear with me. What causes a chilling effect is
the split-up into unstable and stable and that every release of the
stable-series will be a major-release, which really breaks everything. The
reasonable expectation is a system with major, minor, patches:
Major: add new features, cleans up API/ABI, break API/ABI
Minor (missing here): add new features, shouldn't break, but maybe if
absolutely required
and easy to keep up with it
Patch: and patches, doesn't break anything, doesn't add anything

This is the model of Qt and it works. Noteable, Qt has done more majors (5
vs 3) than Gtk and Qt5 has done less minors than GTK3 (10 vs 7). Maybe
also the unstable-release could be used internally as long as the
developers wish (why not rolling permanentely?), good things can be ported
back to a new minor release of Gtk4. And if the issue arises that unstable
collected cool new stuff which requires a major-release after a unkown
number of years, than this new major-release will be created and labled
Gtk5. If this happens after ~three years, okay. If this happens after ~six
years, nice. Anything longer would be a pure miracle and maybe not good
(Gtk2 is more like a dinosaur).

I think breaking the API/ABI because of required changes, is right,
breaking API/ABI because a fixed number of months has passed doesn't make
much sense. I think Benjamin is right here, application developers are
willing to pay for an API/ABI break if they receive incredible, required
new stuff they can't get in another way.

Peter

PS: Thanks for your talks on GUADEC. Sadly I missed the last day :(

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Chris Vine]

On Sun, 14 Aug 2016 22:48:24 +0100
Emmanuele Bassi  wrote:
> On Sunday, 14 August 2016, Chris Vine 
> wrote:
> 
> > On Sun, 14 Aug 2016 21:22:06 +0200
> > Sébastien Wilmet > wrote:  
> > > On Sun, Aug 14, 2016 at 07:17:34PM +0100, Chris Vine wrote:  
> > > > On Sun, 14 Aug 2016 13:40:55 +0200
> > > > Sébastien Wilmet > wrote:  
> > > > > When GTK+ breaks the API, it doesn't mean that a higher-level
> > > > > library needs to break API too. For example, GtkTextView has a
> > > > > quite stable API, so I think GtkSourceView will still have a
> > > > > stable API too, to keep backward compatibility during
> > > > > GtkSourceView 4.  
> > > >
> > > > However, if your application depends on two GTK-based
> > > > libraries, the developers for one of which proceed to adopt a
> > > > development path using unstable GTK versions and one where they
> > > > stick to stable, surely you are doomed?  Likewise if the two
> > > > libraries decide to adopt different stable versions (not
> > > > impossible with a two-year cycle for stable releases).  
> > >
> > > Yes, that's why it's more important for libraries to follow
> > > unstable GTK. For apps, it's less important.
> > >
> > > GtkSourceView will probably follow unstable GTK, while still
> > > trying to keep the GtkSourceView 4 API stable.  
> >
> > I was not referring specifically to gnome based libraries.  There
> > are plenty of others, which will definitely not want to follow the
> > unstable series.  Even a two year cycle of stable GTK versions will
> > probably be problematic for them.
> >
> > It really comes down to the question of what GTK is.  If it is the
> > GnomeToolKit (or GTK developers are happy for it to become the the
> > GnomeToolKit) then I can see the merit in the proposal.  Otherwise
> > it looks to me like a suicide note.  
> 
> 
> So, let's not beat around the bush: GNOME developers are the vast
> majority of the GTK contributors, so clearly they get to steer the
> project the way they see fit. You get to steer the project only if
> you show up and do the work.

I agree: "... If it is the GnomeToolKit (or GTK developers are happy
for it to become the  GnomeToolKit) then I can see the merit in the
proposal".  It is, and should remain, a rule of open source development
by volunteers that those who write the code have the right to make the
strategic decsions.  If not, they can vote with their feet (or with
their fork).  Having said that, I suspect but do not know that a
proportion of those writing GTK code are employed to do so, so in their
cases I suppose it is the employer who calls the shots.  Obviously,
those who make the decisions must also accept the consequences of the
decisions they make.

> I'm more interested as to why you think this new release policy of an
> API and feature stable release every two years as a "suicide note"
> considering that the whole thing has been drawn to cater to non-GNOME
> consumers of the API after listening to their complaints. GNOME app
> developers are pretty much used to keep up with bi-yearly releases,
> whereas non GNOME app developers are often complaining about cycles
> that are too fast.
> 
> If two years are still too fast we can definitely look into making
> API and feature stable cycles longer; that usually comes at a price
> of making porting more difficult, but if that is an acceptable cost
> we can definitely do feature-frozen releases every four years instead.

I fear I am not good at expressing myself.  I see the problems as: (1)
every GTK-using library that an application links to must link against
the same ABI version of GTK.  This means that all such libraries that
the application happens to use (as well as the application itself) must
go in step.  I accept that this should not be a problem if GTK becomes
the "gnome tool kit", as the gnome project can enforce its own internal
rules on this.  (2)  Bearing in mind this linking issue, I suspect a
2-year stable release cycle is likely to be too high a churn rate for
non-gnome applications and libraries.  The proposal is in my view
likely to cause non-gnome application and library developers to look
elsewhere.

I may be wrong on that.  You may be right.  Time will tell, if that is
the way it goes: this is a competitive market.

Aside from that, declaring GTK to be the "gnome tool kit" may serve to
add welcome clarity on the point.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Emmanuele Bassi]

Hi;

On Sunday, 14 August 2016, Chris Vine  wrote:

> On Sun, 14 Aug 2016 21:22:06 +0200
> Sébastien Wilmet > wrote:
> > On Sun, Aug 14, 2016 at 07:17:34PM +0100, Chris Vine wrote:
> > > On Sun, 14 Aug 2016 13:40:55 +0200
> > > Sébastien Wilmet > wrote:
> > > > When GTK+ breaks the API, it doesn't mean that a higher-level
> > > > library needs to break API too. For example, GtkTextView has a
> > > > quite stable API, so I think GtkSourceView will still have a
> > > > stable API too, to keep backward compatibility during
> > > > GtkSourceView 4.
> > >
> > > However, if your application depends on two GTK-based libraries, the
> > > developers for one of which proceed to adopt a development path
> > > using unstable GTK versions and one where they stick to stable,
> > > surely you are doomed?  Likewise if the two libraries decide to
> > > adopt different stable versions (not impossible with a two-year
> > > cycle for stable releases).
> >
> > Yes, that's why it's more important for libraries to follow unstable
> > GTK. For apps, it's less important.
> >
> > GtkSourceView will probably follow unstable GTK, while still trying to
> > keep the GtkSourceView 4 API stable.
>
> I was not referring specifically to gnome based libraries.  There are
> plenty of others, which will definitely not want to follow the unstable
> series.  Even a two year cycle of stable GTK versions will probably be
> problematic for them.
>
> It really comes down to the question of what GTK is.  If it is the
> GnomeToolKit (or GTK developers are happy for it to become the the
> GnomeToolKit) then I can see the merit in the proposal.  Otherwise it
> looks to me like a suicide note.


So, let's not beat around the bush: GNOME developers are the vast majority
of the GTK contributors, so clearly they get to steer the project the way
they see fit. You get to steer the project only if you show up and do the
work.

I'm more interested as to why you think this new release policy of an API
and feature stable release every two years as a "suicide note" considering
that the whole thing has been drawn to cater to non-GNOME consumers of the
API after listening to their complaints. GNOME app developers are pretty
much used to keep up with bi-yearly releases, whereas non GNOME app
developers are often complaining about cycles that are too fast.

If two years are still too fast we can definitely look into making API and
feature stable cycles longer; that usually comes at a price of making
porting more difficult, but if that is an acceptable cost we can definitely
do feature-frozen releases every four years instead.

Ciao,
 Emmanuele.



> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org 
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Chris Vine]

On Sun, 14 Aug 2016 21:22:06 +0200
Sébastien Wilmet  wrote:
> On Sun, Aug 14, 2016 at 07:17:34PM +0100, Chris Vine wrote:
> > On Sun, 14 Aug 2016 13:40:55 +0200
> > Sébastien Wilmet  wrote:  
> > > When GTK+ breaks the API, it doesn't mean that a higher-level
> > > library needs to break API too. For example, GtkTextView has a
> > > quite stable API, so I think GtkSourceView will still have a
> > > stable API too, to keep backward compatibility during
> > > GtkSourceView 4.  
> > 
> > However, if your application depends on two GTK-based libraries, the
> > developers for one of which proceed to adopt a development path
> > using unstable GTK versions and one where they stick to stable,
> > surely you are doomed?  Likewise if the two libraries decide to
> > adopt different stable versions (not impossible with a two-year
> > cycle for stable releases).  
> 
> Yes, that's why it's more important for libraries to follow unstable
> GTK. For apps, it's less important.
> 
> GtkSourceView will probably follow unstable GTK, while still trying to
> keep the GtkSourceView 4 API stable.

I was not referring specifically to gnome based libraries.  There are
plenty of others, which will definitely not want to follow the unstable
series.  Even a two year cycle of stable GTK versions will probably be
problematic for them.

It really comes down to the question of what GTK is.  If it is the
GnomeToolKit (or GTK developers are happy for it to become the the
GnomeToolKit) then I can see the merit in the proposal.  Otherwise it
looks to me like a suicide note.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Sébastien Wilmet]

On Sun, Aug 14, 2016 at 07:17:34PM +0100, Chris Vine wrote:
> On Sun, 14 Aug 2016 13:40:55 +0200
> Sébastien Wilmet  wrote:
> > When GTK+ breaks the API, it doesn't mean that a higher-level library
> > needs to break API too. For example, GtkTextView has a quite stable
> > API, so I think GtkSourceView will still have a stable API too, to
> > keep backward compatibility during GtkSourceView 4.
> 
> However, if your application depends on two GTK-based libraries, the
> developers for one of which proceed to adopt a development path using
> unstable GTK versions and one where they stick to stable, surely you
> are doomed?  Likewise if the two libraries decide to adopt different
> stable versions (not impossible with a two-year cycle for stable
> releases).

Yes, that's why it's more important for libraries to follow unstable
GTK. For apps, it's less important.

GtkSourceView will probably follow unstable GTK, while still trying to
keep the GtkSourceView 4 API stable.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Chris Vine]

On Sun, 14 Aug 2016 13:40:55 +0200
Sébastien Wilmet  wrote:
> On Fri, Aug 12, 2016 at 04:19:30AM +, philip.chime...@gmail.com
> wrote:
> > 4. Maintainers of libraries that depend on GTK (such as
> > GtkSourceView, VTE, WebKitGTK) are concerned about having to
> > maintain essentially a separate library for each unstable release.  
> 
> When GTK+ breaks the API, it doesn't mean that a higher-level library
> needs to break API too. For example, GtkTextView has a quite stable
> API, so I think GtkSourceView will still have a stable API too, to
> keep backward compatibility during GtkSourceView 4.

However, if your application depends on two GTK-based libraries, the
developers for one of which proceed to adopt a development path using
unstable GTK versions and one where they stick to stable, surely you
are doomed?  Likewise if the two libraries decide to adopt different
stable versions (not impossible with a two-year cycle for stable
releases).
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Sébastien Wilmet]

On Fri, Aug 12, 2016 at 04:19:30AM +, philip.chime...@gmail.com wrote:
> 4. Maintainers of libraries that depend on GTK (such as GtkSourceView, VTE,
> WebKitGTK) are concerned about having to maintain essentially a separate
> library for each unstable release.

Actually, I do not fully understand this. Can you extend a bit?

For example, imagine that GTK+ 4.0 and GtkSourceView 4.0 are released.
During the 4.1 development cycle, GTK+ breaks the API in a way that
forces GtkSourceView to also break its API. For the 4.2 release, both
GTK+ and GtkSourceView bump their SONAME.

Then in GtkSourceView, some bugfixes can be backported to the 4.0
version and new micro versions can be released, 4.0.3 etc. Exactly as it
is done now. GtkSourceView 4.0 and 4.2 are not separate libraries, it's
the same as 3.18 and 3.20, except that there is an API break between 4.0
and 4.2.

Another practical difference is that this might need several jhbuild
installations (the 4.0 installed in a certain prefix, the 4.2 in another
prefix), and switching between different jhbuildrc. I already do this
sometimes, for older versions.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Sébastien Wilmet]

On Sun, Aug 14, 2016 at 09:03:23AM -0400, Morten Welinder wrote:
> > When GTK+ breaks the API, it doesn't mean that a higher-level library
> > needs to break API too.
> 
> That depends.
> 
> You are right that a lot of API changes can be hidden.
> 
> But if the higher-level library has an API  that includes a type
> which is being removed, then the API will have to be
> changed.
> 
> And if your library depends on a feature that is being removed
> then your library probably cannot be saved with an API break.

Higher-level libraries can do their best to keep backward compatibility,
but when it is not possible, the higher-level library will also need to
bump the SONAME (without full parallel-installability for the headers
etc).

As long as the higher-level libraries communicate this clearly to their
users, I don't see it as a problem.

Of course a higher-level library developer can decide *not* to follow
GTK+ unstable, which forces some applications to also stay at GTK+
stable. Which can be a problem (the same problem with Python libraries
that are not yet ported to Python 3, so some programs are stuck at
Python 2).

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Sébastien Wilmet]

On Sun, Aug 14, 2016 at 01:05:08PM +, Philipp A. wrote:
> I tried just to read and not ask anything but no amount of reading has
> resulted in any enlightenment, so:
> 
> Why not do what almost everyone does and have 4.X mean “stable” while
> anything with alpha/beta/pre/rc means unstable?
> 
> KDE made the same mistake with the exact same version number, i.e having
> the number look stable to everyone while the software was (as they clearly
> said everywhere!) a pre-release. People used it, distros shipped it, it was
> buggy and incomplete and everybody was confused and angry as a consequence.
> Was it simply lack of historic knowledge that led to the GTK-4.0 decision?
> 
> Besides, there's no gain in specifying some arbitrary minor version to be
> suddenly stable (as it was said GTK 4, “somewhere around 4.6” would
> become). There's exclusively a disadvantage, i.e. that you can't rely on
> common sense, convention, or any other kind of rule to know if that's a
> stable version. You have to know our look it up.
> 
> Just use http://semver.org and you have something that follows the
> principle of least surprise.

See:
https://wiki.gnome.org/Projects/GTK%2B/Lifecycle

Nothing is decided yet.

There is another proposal with even/odd major versions to distinguish
between stable/unstable.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Philipp A.]

I tried just to read and not ask anything but no amount of reading has
resulted in any enlightenment, so:

Why not do what almost everyone does and have 4.X mean “stable” while
anything with alpha/beta/pre/rc means unstable?

KDE made the same mistake with the exact same version number, i.e having
the number look stable to everyone while the software was (as they clearly
said everywhere!) a pre-release. People used it, distros shipped it, it was
buggy and incomplete and everybody was confused and angry as a consequence.
Was it simply lack of historic knowledge that led to the GTK-4.0 decision?

Besides, there's no gain in specifying some arbitrary minor version to be
suddenly stable (as it was said GTK 4, “somewhere around 4.6” would
become). There's exclusively a disadvantage, i.e. that you can't rely on
common sense, convention, or any other kind of rule to know if that's a
stable version. You have to know our look it up.

Just use http://semver.org and you have something that follows the
principle of least surprise.

Sébastien Wilmet  schrieb am So., 14. Aug. 2016, 13:41:

> On Fri, Aug 12, 2016 at 04:19:30AM +, philip.chime...@gmail.com wrote:
> > 4. Maintainers of libraries that depend on GTK (such as GtkSourceView,
> VTE,
> > WebKitGTK) are concerned about having to maintain essentially a separate
> > library for each unstable release.
>
> When GTK+ breaks the API, it doesn't mean that a higher-level library
> needs to break API too. For example, GtkTextView has a quite stable API,
> so I think GtkSourceView will still have a stable API too, to keep
> backward compatibility during GtkSourceView 4.
>
> > Did I forget anything?
>
> It is expected that GNOME apps will follow the unstable GTK+ versions.
> But some GNOME apps (or other libraries, for that matter) are developed
> almost entirely by people contributing during their spare time. And the
> amount of spare time/energy/willingness to maintain code can vary widely
> between development cycles. This includes gedit. I'm not sure it is a
> good idea for gedit to follow the unstable versions of GTK+.
>
> --
> Sébastien
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Morten Welinder]

> When GTK+ breaks the API, it doesn't mean that a higher-level library
> needs to break API too.

That depends.

You are right that a lot of API changes can be hidden.

But if the higher-level library has an API  that includes a type
which is being removed, then the API will have to be
changed.

And if your library depends on a feature that is being removed
then your library probably cannot be saved with an API break.

M
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Sébastien Wilmet]

On Fri, Aug 12, 2016 at 04:19:30AM +, philip.chime...@gmail.com wrote:
> 4. Maintainers of libraries that depend on GTK (such as GtkSourceView, VTE,
> WebKitGTK) are concerned about having to maintain essentially a separate
> library for each unstable release.

When GTK+ breaks the API, it doesn't mean that a higher-level library
needs to break API too. For example, GtkTextView has a quite stable API,
so I think GtkSourceView will still have a stable API too, to keep
backward compatibility during GtkSourceView 4.

> Did I forget anything?

It is expected that GNOME apps will follow the unstable GTK+ versions.
But some GNOME apps (or other libraries, for that matter) are developed
almost entirely by people contributing during their spare time. And the
amount of spare time/energy/willingness to maintain code can vary widely
between development cycles. This includes gedit. I'm not sure it is a
good idea for gedit to follow the unstable versions of GTK+.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GTK-Next (was: Re: Gtk+4.0)

[philip . chimento]

On Tue, Jul 19, 2016 at 11:08 AM Simon McVittie <
simon.mcvit...@collabora.co.uk> wrote:

> On 09/07/16 20:42, Jasper St. Pierre wrote:
> > In fact, this could be a new plan. If we double down on Flatpak, then we
> > could simply not bump soname / major version, leave it at 4, break ABI
> > every point release, and have the ".6-multiple" releases be LTS releases
> > which are "maintained more than most".
>
> Speaking as a distribution (Debian) developer: breaking the ABI without
> bumping the SONAME is really frustrating to deal with in distributions;
> so if there will be anything that uses Gtk and is ever distributed in
> ways other than Flatpak and similar things, please manage the Gtk SONAME
> correctly.
>
> gnome-shell, gnome-control-center and gnome-settings-daemon, together
> with their forks in GNOME derivatives like Cinnamon, are among prominent
> packages that depend on Gtk but should be part of the distribution's
> release process, even in a possible future where ordinary apps are
> exclusively distributed via Flatpak. (I don't think that future has
> arrived yet, in any case.)
>

Now for the comedy part of the discussion. I'd like to follow through on
the double-down-on-Flatpak proposal, even if Jasper didn't mean it
seriously. I don't mean it entirely seriously either, since it has some
serious flaws detailed below, but it does address some of the concerns I
summarized in my email from just now [1].

The stable series would be much as in the original GTK 4 proposal, but it
would just be called "GTK". That indicates to outsiders who don't care
about release schedules and just want a GUI toolkit, that this is the
toolkit to use. GTK would receive bugfixes, and possibly backports of new
features if maintainer time and inclination allows.

The unstable series would get a different name that isn't "GTK", e.g.
"GTK-Next", and become (imagine air quotes around this) "Flatpak-only".
Air quotes because it would of course still be released as a source
tarball, and if a distro wanted to package it of course no-one could stop
them; but we would discourage it from being available through distro
package managers. Air quotes also because it wouldn't be limited to Flatpak
on Linux; I would for example be able to build GTK-Next and bundle it
inside an application bundle on Mac OSX. That use would also be encouraged,
as well as its equivalent on Snappy, as well as whatever application
sandboxing solution arises on any other platform in the future.

But as far as GNOME is concerned, GTK-Next would be released first and
foremost as part of the org.gnome.Platform Flatpak runtime.

This does cut off system components such as gnome-control-center from using
GTK-Next, as Simon pointed out above.

This would also leave applications in somewhat of an awkward position if
they wanted to use GTK-Next but needed to use a library that depends on
GTK, such as GtkSourceView, VTE, or WebKitGTK. I see two possibilities here:
1) if the library maintainer is amenable to doing the work, the library
could have a GTK-Next branch with a separate pkg-config name, and this
would be released with the same intention and through the same channels as
GTK-Next.
2) if the library maintainer is not interested, the application author
would have to port the library to GTK-Next themselves and bundle it in
their application.

The worst part of this proposal is that it makes it very hard for app
maintainers to use GTK-Next if they want to keep releasing their app in the
traditional manner, not as a Flatpak or other bundle. They could decide to
maintain a separate GTK version alongside the GTK-Next version of their
app, but that's a really crappy story to sell to developers. Maybe we could
include some tooling which would make it easy for GTK-Next to be built as
an application's internal library in pkglibdir? It might mean that in
practice the only users of GTK-Next would be applications like GNOME
Documents and GNOME Music, which would be a shame. It would also feed the
perception that GTK is primarily there for the consumption of GNOME and
other consumers are an afterthought.

The pros of this proposal are that it's crystal clear that GTK-Next is
opt-in only, and the bulk of the extra work falls onto the people who
opt-in. It removes packagers and distros from the equation entirely and so
will not cause them more work. Put bluntly, the idea is to make it harder
for app maintainers to opt-in to the unstable series if they aren't serious
about keeping up with the porting work, as well as limiting the damage they
can do if they leave an app stuck on an old version of GTK-Next.

No version numbering schemes were harmed in the making of this email.

Happy hacking everyone,
Philip C

[1] https://mail.gnome.org/archives/gtk-devel-list/2016-August/msg00015.html
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[philip . chimento]

On Sat, Jul 9, 2016 at 9:31 PM  wrote:

> On Sat, Jul 9, 2016 at 12:06 PM  wrote:
>
>> On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort 
>> wrote:
>>
>>>
>>> Here are some thoughts I have about all this, from a downstream
>>> maintainer POV.
>>>
>>
>> Thanks! It's good to get opinions from all over the place.
>>
>
> And, speaking of that, there was a blog post [1] on the GTK 4 subject that
> recently got a lot of attention on Hacker News. I reached out to the author
> and encouraged them to give their opinion here, but it seems the message is
> stalled in the moderator queue. Is there a moderator who can help?
>
> [1]
> https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations/
>

Could a moderator please help with this? At this point, the blog post is
starting to attract comments insinuating that we're suppressing the
discussion on purpose [2].

Best,
Philip C

[2]
https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations/#comment-1050
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[philip . chimento]

I realized this thread had been sitting for quite a while. GUADEC is about
to start and I'd like to summarize what's been talked about. Some of the
concerns I read from this thread are:

1. Developers are concerned about there not being enough indication of
which APIs are more likely or less likely to be overhauled in the unstable
series.

2. Maintainers of non-core GNOME apps are concerned that they will be
sucked into the unstable series; in other words that it's not opt-out
enough.

3. App developers are concerned that the stable series will be ignored in
favor of the unstable series.

4. Maintainers of libraries that depend on GTK (such as GtkSourceView, VTE,
WebKitGTK) are concerned about having to maintain essentially a separate
library for each unstable release.

5. Packagers are concerned about apps depending on a library that depends
on an unstable version of GTK, then ceasing development, leaving a
straggler package in the distro.

6. Users, maintainers, and packagers are concerned that it will be daunting
to keep up with stable GTK's 2-year API/ABI break cycle even if not
opting-in to the unstable series, and that maintainers will instead choose
to remain on GTK 3.x or GTK 2.x.

7. Distro maintainers are concerned about having to recompile the whole
world too often because of the unstable series necessitating frequent
soname changes.

Did I forget anything? Please help me summarize. I suggest phrasing it as
"$ROLE is concerned about $THING" as I believe that's conducive to thinking
about others' needs rather than a my-opinion-versus-your-opinion
discussion. (Not saying those are not good to have, but I think at this
particular stage, summarizing and understanding is more useful than hashing
it out.)

There are also the as-yet unanswered FAQs from the FAQ [1], copy-pasted
below, that I think we should try to answer by the end of GUADEC:

- Why can't the stable release cadence be longer than 2 years?
- Why can't the stable releases stay supported for longer than 2 years?
- Why release API-breaking major versions on a cadence? Can't you just do
it only when necessary?
- How about a GtkPrivate library and #define I_WANT_UNSTABLE_API?
- How can I support both the stable and unstable releases?
- How will this affect theme developers, since they don't get to choose
what version to target like app developers do?

By the way, Christian: Peter suggested turning this post of yours [2] into
a post on the GTK blog, would you be interested in doing that?

Best,
Philip C

[1] https://wiki.gnome.org/Projects/GTK%2B/Lifecycle/FAQ
[2] https://mail.gnome.org/archives/gtk-devel-list/2016-June/msg00032.html
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Peter Weber]

On Sun, 2016-07-10 at 13:36 -0700, Jasper St. Pierre wrote:
> On Sun, Jul 10, 2016 at 1:28 PM,  wrote:
> > On Sat, Jul 9, 2016 at 1:14 PM Peter Weber  > m> wrote:
> > 
> > 
> > No, nothing about any of this proposal forces people to use
> > Flatpak.

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


Thanks for the clarifications :)
Peter
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Paul Davis]

I'm thinking of the "current,revision,age" psuedo-standard.


On Mon, Jul 11, 2016 at 5:19 PM, Behdad Esfahbod  wrote:

> On Mon, Jul 11, 2016 at 1:47 PM, Paul Davis 
> wrote:
> > If soname was changed in keeping with the nominal "standard", it
> wouldn't be
> > that much of an issue. The soname would indicated added API, internal
> fixes,
> > and no change to public API/ABI. No?
>
> Humm.  I don't quite follow.  Common practice for "added API, internal
> fixes,
> > and no change to public API/ABI" is to keep the soname.
>
> > On Mon, Jul 11, 2016 at 4:29 PM, Behdad Esfahbod 
> wrote:
> >>
> >> I also think bumping soname every six months would be disaster.  It
> >> was painful enough when libstdc++, libpng, libssl, etc changed soname
> >> every few years.
> >>
> >> On Thu, Jul 7, 2016 at 11:23 AM, Emilio Pozuelo Monfort
> >>  wrote:
> >> > Hi,
> >> >
> >> > On 21/06/16 16:26, Peter Weber wrote:
> >> >> I don't see here an active discussion about Gtk+4.0[1]? So I'm trying
> >> >> to
> >> >> write about my thoughts, in a careful way. In the first moment, I
> >> >> thought
> >> >> this is a good idea and just the numbering is misleading. Stability
> is
> >> >> what
> >> >> developers want, we need it, we love it. With a few days distance,
> >> >> numbering is just a small issue, I see this now entirely different
> and
> >> >> three major issues:
> >> >
> >> > Here are some thoughts I have about all this, from a downstream
> >> > maintainer POV.
> >> >
> >> > My concern with this new scheme is that GTK+ libraries will have to
> bump
> >> > the
> >> > soname every 6 months (if they want to support the latest GTK+). That
> >> > can be
> >> > manageable for say vte or gnome-desktop, although it may be bad if
> 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.
> >> >
> >> > But do you expect WebKitGTK+ to bump the ABI every 6 months?
> >> >
> >> > I feel like the X.[024] releases are just snapshots of a development
> >> > branch,
> >> > with X.6 being the stable release, and I wonder if X.[024] shouldn't
> >> > clearly be
> >> > labelled as that, regardless of what version number is chosen (be it
> >> > 4.0,
> >> > 3.99.0, 4.0beta1 or whatever).
> >> >
> >> > Cheers,
> >> > Emilio
> >> > ___
> >> > gtk-devel-list mailing list
> >> > gtk-devel-list@gnome.org
> >> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> >>
> >>
> >>
> >> --
> >> behdad
> >> http://behdad.org/
> >> ___
> >> gtk-devel-list mailing list
> >> gtk-devel-list@gnome.org
> >> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> >
> >
>
>
>
> --
> behdad
> http://behdad.org/
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Behdad Esfahbod]

On Mon, Jul 11, 2016 at 1:47 PM, Paul Davis  wrote:
> If soname was changed in keeping with the nominal "standard", it wouldn't be
> that much of an issue. The soname would indicated added API, internal fixes,
> and no change to public API/ABI. No?

Humm.  I don't quite follow.  Common practice for "added API, internal fixes,
> and no change to public API/ABI" is to keep the soname.

> On Mon, Jul 11, 2016 at 4:29 PM, Behdad Esfahbod  wrote:
>>
>> I also think bumping soname every six months would be disaster.  It
>> was painful enough when libstdc++, libpng, libssl, etc changed soname
>> every few years.
>>
>> On Thu, Jul 7, 2016 at 11:23 AM, Emilio Pozuelo Monfort
>>  wrote:
>> > Hi,
>> >
>> > On 21/06/16 16:26, Peter Weber wrote:
>> >> I don't see here an active discussion about Gtk+4.0[1]? So I'm trying
>> >> to
>> >> write about my thoughts, in a careful way. In the first moment, I
>> >> thought
>> >> this is a good idea and just the numbering is misleading. Stability is
>> >> what
>> >> developers want, we need it, we love it. With a few days distance,
>> >> numbering is just a small issue, I see this now entirely different and
>> >> three major issues:
>> >
>> > Here are some thoughts I have about all this, from a downstream
>> > maintainer POV.
>> >
>> > My concern with this new scheme is that GTK+ libraries will have to bump
>> > the
>> > soname every 6 months (if they want to support the latest GTK+). That
>> > can be
>> > manageable for say vte or gnome-desktop, although it may be bad if 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.
>> >
>> > But do you expect WebKitGTK+ to bump the ABI every 6 months?
>> >
>> > I feel like the X.[024] releases are just snapshots of a development
>> > branch,
>> > with X.6 being the stable release, and I wonder if X.[024] shouldn't
>> > clearly be
>> > labelled as that, regardless of what version number is chosen (be it
>> > 4.0,
>> > 3.99.0, 4.0beta1 or whatever).
>> >
>> > Cheers,
>> > Emilio
>> > ___
>> > gtk-devel-list mailing list
>> > gtk-devel-list@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>>
>>
>>
>> --
>> behdad
>> http://behdad.org/
>> ___
>> gtk-devel-list mailing list
>> gtk-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>



-- 
behdad
http://behdad.org/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Paul Davis]

If soname was changed in keeping with the nominal "standard", it wouldn't
be that much of an issue. The soname would indicated added API, internal
fixes, and no change to public API/ABI. No?

On Mon, Jul 11, 2016 at 4:29 PM, Behdad Esfahbod  wrote:

> I also think bumping soname every six months would be disaster.  It
> was painful enough when libstdc++, libpng, libssl, etc changed soname
> every few years.
>
> On Thu, Jul 7, 2016 at 11:23 AM, Emilio Pozuelo Monfort
>  wrote:
> > Hi,
> >
> > On 21/06/16 16:26, Peter Weber wrote:
> >> I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to
> >> write about my thoughts, in a careful way. In the first moment, I
> thought
> >> this is a good idea and just the numbering is misleading. Stability is
> what
> >> developers want, we need it, we love it. With a few days distance,
> >> numbering is just a small issue, I see this now entirely different and
> >> three major issues:
> >
> > Here are some thoughts I have about all this, from a downstream
> maintainer POV.
> >
> > My concern with this new scheme is that GTK+ libraries will have to bump
> the
> > soname every 6 months (if they want to support the latest GTK+). That
> can be
> > manageable for say vte or gnome-desktop, although it may be bad if 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.
> >
> > But do you expect WebKitGTK+ to bump the ABI every 6 months?
> >
> > I feel like the X.[024] releases are just snapshots of a development
> branch,
> > with X.6 being the stable release, and I wonder if X.[024] shouldn't
> clearly be
> > labelled as that, regardless of what version number is chosen (be it 4.0,
> > 3.99.0, 4.0beta1 or whatever).
> >
> > Cheers,
> > Emilio
> > ___
> > gtk-devel-list mailing list
> > gtk-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
>
> --
> behdad
> http://behdad.org/
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Behdad Esfahbod]

I also think bumping soname every six months would be disaster.  It
was painful enough when libstdc++, libpng, libssl, etc changed soname
every few years.

On Thu, Jul 7, 2016 at 11:23 AM, Emilio Pozuelo Monfort
 wrote:
> Hi,
>
> On 21/06/16 16:26, Peter Weber wrote:
>> I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to
>> write about my thoughts, in a careful way. In the first moment, I thought
>> this is a good idea and just the numbering is misleading. Stability is what
>> developers want, we need it, we love it. With a few days distance,
>> numbering is just a small issue, I see this now entirely different and
>> three major issues:
>
> Here are some thoughts I have about all this, from a downstream maintainer 
> POV.
>
> My concern with this new scheme is that GTK+ libraries will have to bump the
> soname every 6 months (if they want to support the latest GTK+). That can be
> manageable for say vte or gnome-desktop, although it may be bad if 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.
>
> But do you expect WebKitGTK+ to bump the ABI every 6 months?
>
> I feel like the X.[024] releases are just snapshots of a development branch,
> with X.6 being the stable release, and I wonder if X.[024] shouldn't clearly 
> be
> labelled as that, regardless of what version number is chosen (be it 4.0,
> 3.99.0, 4.0beta1 or whatever).
>
> Cheers,
> Emilio
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list



-- 
behdad
http://behdad.org/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[philip . chimento]

On Sun, Jul 10, 2016 at 3:51 PM John Tall  wrote:

> On Sat, Jul 9, 2016 at 9:06 PM,  wrote:
> > I'm expecting this will become less and less of a problem as apps move
> to Flatpak as a means of distribution.
>
> As far as I know Flatpak only targets GNU/Linux, and at the moment
> only targets a handful of distros. I make software for not only
> GNU/Linux but also Windows, FreeBSD and macOS. I use many libraries
> including GTK+. I don't know yet if or how these changes will impact
> me, all I know is that the way things are right now works just fine
> for me.
>

Let me state categorically:

Nothing in this proposal forces anyone to use Flatpak.

Though I am excited about Flatpak if that wasn't obvious by now, I myself
also make software for other platforms than Linux and contribute quite a
lot of my time towards keeping GTK and other libraries buildable on Mac OS
X.

I really don't want to turn this thread into a discussion of the merits of
Flatpak. What I did (more explanation here [1]) was try to answer a
question, essentially "What if some app developer does ?"
that I would previously, before Flatpak existed, have answered "Well, don't
do that then." Instead, I can now say "I hope fewer people will do  because of Flatpak."


> I'm worried that we're breaking things that already work for lots of
> us in order to fix inconveniences that some people have. I don't want
> to drastically change the way I make and distribute software just
> because one of the many libraries that I use has decided to do things
> differently. If things need to change then do whatever is necessary
> but please, let the old stuff also continue to work.
>

If you track the long-term supported releases of GTK with your software,
then you shouldn't need to change anything in the way you make and
distribute it.

Regards,
Philip C

[1] https://mail.gnome.org/archives/gtk-devel-list/2016-July/msg9.html
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[John Tall]

On Sat, Jul 9, 2016 at 9:06 PM,  wrote:
> I'm expecting this will become less and less of a problem as apps move to 
> Flatpak as a means of distribution.

As far as I know Flatpak only targets GNU/Linux, and at the moment
only targets a handful of distros. I make software for not only
GNU/Linux but also Windows, FreeBSD and macOS. I use many libraries
including GTK+. I don't know yet if or how these changes will impact
me, all I know is that the way things are right now works just fine
for me.

I'm worried that we're breaking things that already work for lots of
us in order to fix inconveniences that some people have. I don't want
to drastically change the way I make and distribute software just
because one of the many libraries that I use has decided to do things
differently. If things need to change then do whatever is necessary
but please, let the old stuff also continue to work.

John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Jasper St. Pierre]

On Sun, Jul 10, 2016 at 1:28 PM,  wrote:

> On Sat, Jul 9, 2016 at 1:14 PM Peter Weber 
> wrote:
>
>> Hi!
>>
>> On Sat, 2016-07-09 at 19:06 +, philip.chime...@gmail.com 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.


> Regards,
> Philip C
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>


-- 
  Jasper
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[philip . chimento]

On Sat, Jul 9, 2016 at 1:14 PM Peter Weber  wrote:

> Hi!
>
> On Sat, 2016-07-09 at 19:06 +, philip.chime...@gmail.com 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.

Regards,
Philip C
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Peter Weber]

Hi!

On Sat, 2016-07-09 at 19:06 +, philip.chime...@gmail.com 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+?

While Flatpak offers some nice features (especially easy install of
out-of-repo software), it includes so many problems that it cannot
replace package-management. The constant work done by the
downstream-maintainers makes GNU/Linux so well usable, it is not burden
but a duty.

Flatpak problems:
* increased memory consumption
* security fixes are not available for all applications
* basically all things dynamic-libraries have fixed...
* security and door-keeper function of distributions lost
* much more work for developers

If Gtk+ is allowed to be installed within a Flatpak the increased memory
consumption will be vast. I pretty sure that Jasper is right about the
"targets", including Gtk+ is not(?) allowed because it will blow up your
system.

More about the issues with Flatpak (Archlinux):
http://kmkeen.com/maintainers-matter/2016-06-16-11-31-07-560.html

Solving a problem with another problematic approach isn't a good idea.

Peter

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Jasper St. Pierre]

On Sat, Jul 9, 2016 at 12:36 PM,  wrote:

> On Sat, Jul 9, 2016 at 12:13 PM Jasper St. Pierre 
> wrote:
>
>> On Sat, Jul 9, 2016 at 12:06 PM,  wrote:
>>
>>> On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort <
>>> poch...@gmail.com> wrote:
>>>
 Hi,

 On 21/06/16 16:26, Peter Weber wrote:
 > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying
 to
 > write about my thoughts, in a careful way. In the first moment, I
 thought
 > this is a good idea and just the numbering is misleading. Stability
 is what
 > developers want, we need it, we love it. With a few days distance,
 > numbering is just a small issue, I see this now entirely different and
 > three major issues:

 Here are some thoughts I have about all this, from a downstream
 maintainer POV.

>>>
>>> Thanks! It's good to get opinions from all over the place.
>>>
>>> My concern with this new scheme is that GTK+ libraries will have to bump
 the
 soname every 6 months (if they want to support the latest GTK+). That
 can be
 manageable for say vte or gnome-desktop, although it may be bad if 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.

>>>
>>> I'm expecting this will become less and less of a problem as apps move
>>> to Flatpak as a means of distribution.
>>>
>>
>> How does Flatpak solve this problem?
>>
>
> If an app was released as a Flatpak, it would target a Flatpak runtime.
> There would not be a choice between targeting VTE-for-GTK-4.2 or
> VTE-for-GTK-4.4, and so distributions would not need to ship a
> VTE-for-GTK-4.2 straggler that some app was still targeting.
>

Er, so, with this model, we're working around the fact that we're breaking
ABI without changing the soname? If we're relying on Flatpak to solve this,
why bother bumping the soname at all and releasing new stable versions?
It's effectively no different from having GTK+ 4.8, since it still breaks
every release.

In fact, this could be a new plan. If we double down on Flatpak, then we
could simply not bump soname / major version, leave it at 4, break ABI
every point release, and have the ".6-multiple" releases be LTS releases
which are "maintained more than most".

This doesn't solve the fact that application development is more difficult
inside a Flatpak, and not all application authors are going to have to want
to maintain Flatpaks and an infrastructure to build and test them.


> But do you expect WebKitGTK+ to bump the ABI every 6 months?

>>>
>>> That does seem to point to a problem — if an app uses Library X which
>>> does follow the unstable GTK series, and Library Y which doesn't, then the
>>> app developer is forced to stick to the stable series of GTK and an old
>>> version of Library X in order to accommodate Library Y.
>>>
>>> Any thoughts?
>>>
>>> I feel like the X.[024] releases are just snapshots of a development
 branch,
 with X.6 being the stable release, and I wonder if X.[024] shouldn't
 clearly be
 labelled as that, regardless of what version number is chosen (be it
 4.0,
 3.99.0, 4.0beta1 or whatever).

>>>
>>> In my opinion the label "unstable release" communicates exactly that.
>>> I'm not sure what "development branch" communicates that "unstable release"
>>> doesn't?
>>>
>>
>> The convention in GNOME up until know has been that even numbers are for
>> stable releases, and odd ones are for unstable releases. I didn't know GTK+
>> 4.0 would be considered an unstable release.
>>
>
> There are several different version numbering schemes proposed on this
> wiki page [1]. I was referring to the term "unstable release" versus
> "development branch".
>

The messaging here is very confused and inconsistent, and I think that's
one of our major stumbling blocks here. I would be happier with "4.0alpha",
"4.0beta", "4.0rc", "4.0final" or similar, rather than the .[024] which
imply stability with our current version naming scheme.


> [1] https://wiki.gnome.org/Projects/GTK%2B/Lifecycle
>

-- 
  Jasper
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[philip . chimento]

On Sat, Jul 9, 2016 at 12:13 PM Jasper St. Pierre 
wrote:

> On Sat, Jul 9, 2016 at 12:06 PM,  wrote:
>
>> On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort 
>> wrote:
>>
>>> Hi,
>>>
>>> On 21/06/16 16:26, Peter Weber wrote:
>>> > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying
>>> to
>>> > write about my thoughts, in a careful way. In the first moment, I
>>> thought
>>> > this is a good idea and just the numbering is misleading. Stability is
>>> what
>>> > developers want, we need it, we love it. With a few days distance,
>>> > numbering is just a small issue, I see this now entirely different and
>>> > three major issues:
>>>
>>> Here are some thoughts I have about all this, from a downstream
>>> maintainer POV.
>>>
>>
>> Thanks! It's good to get opinions from all over the place.
>>
>> My concern with this new scheme is that GTK+ libraries will have to bump
>>> the
>>> soname every 6 months (if they want to support the latest GTK+). That
>>> can be
>>> manageable for say vte or gnome-desktop, although it may be bad if 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.
>>>
>>
>> I'm expecting this will become less and less of a problem as apps move to
>> Flatpak as a means of distribution.
>>
>
> How does Flatpak solve this problem?
>

If an app was released as a Flatpak, it would target a Flatpak runtime.
There would not be a choice between targeting VTE-for-GTK-4.2 or
VTE-for-GTK-4.4, and so distributions would not need to ship a
VTE-for-GTK-4.2 straggler that some app was still targeting.

But do you expect WebKitGTK+ to bump the ABI every 6 months?
>>>
>>
>> That does seem to point to a problem — if an app uses Library X which
>> does follow the unstable GTK series, and Library Y which doesn't, then the
>> app developer is forced to stick to the stable series of GTK and an old
>> version of Library X in order to accommodate Library Y.
>>
>> Any thoughts?
>>
>> I feel like the X.[024] releases are just snapshots of a development
>>> branch,
>>> with X.6 being the stable release, and I wonder if X.[024] shouldn't
>>> clearly be
>>> labelled as that, regardless of what version number is chosen (be it 4.0,
>>> 3.99.0, 4.0beta1 or whatever).
>>>
>>
>> In my opinion the label "unstable release" communicates exactly that. I'm
>> not sure what "development branch" communicates that "unstable release"
>> doesn't?
>>
>
> The convention in GNOME up until know has been that even numbers are for
> stable releases, and odd ones are for unstable releases. I didn't know GTK+
> 4.0 would be considered an unstable release.
>

There are several different version numbering schemes proposed on this wiki
page [1]. I was referring to the term "unstable release" versus
"development branch".

[1] https://wiki.gnome.org/Projects/GTK%2B/Lifecycle
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[philip . chimento]

On Sat, Jul 9, 2016 at 12:06 PM  wrote:

> On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort 
> wrote:
>
>> Hi,
>>
>> On 21/06/16 16:26, Peter Weber wrote:
>> > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to
>> > write about my thoughts, in a careful way. In the first moment, I
>> thought
>> > this is a good idea and just the numbering is misleading. Stability is
>> what
>> > developers want, we need it, we love it. With a few days distance,
>> > numbering is just a small issue, I see this now entirely different and
>> > three major issues:
>>
>> Here are some thoughts I have about all this, from a downstream
>> maintainer POV.
>>
>
> Thanks! It's good to get opinions from all over the place.
>

And, speaking of that, there was a blog post [1] on the GTK 4 subject that
recently got a lot of attention on Hacker News. I reached out to the author
and encouraged them to give their opinion here, but it seems the message is
stalled in the moderator queue. Is there a moderator who can help?

[1]
https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations/

Regards,
Philip C
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Jasper St. Pierre]

On Sat, Jul 9, 2016 at 12:06 PM,  wrote:

> On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort 
> wrote:
>
>> Hi,
>>
>> On 21/06/16 16:26, Peter Weber wrote:
>> > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to
>> > write about my thoughts, in a careful way. In the first moment, I
>> thought
>> > this is a good idea and just the numbering is misleading. Stability is
>> what
>> > developers want, we need it, we love it. With a few days distance,
>> > numbering is just a small issue, I see this now entirely different and
>> > three major issues:
>>
>> Here are some thoughts I have about all this, from a downstream
>> maintainer POV.
>>
>
> Thanks! It's good to get opinions from all over the place.
>
> My concern with this new scheme is that GTK+ libraries will have to bump
>> the
>> soname every 6 months (if they want to support the latest GTK+). That can
>> be
>> manageable for say vte or gnome-desktop, although it may be bad if 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.
>>
>
> I'm expecting this will become less and less of a problem as apps move to
> Flatpak as a means of distribution.
>

How does Flatpak solve this problem?


> But do you expect WebKitGTK+ to bump the ABI every 6 months?
>>
>
> That does seem to point to a problem — if an app uses Library X which does
> follow the unstable GTK series, and Library Y which doesn't, then the app
> developer is forced to stick to the stable series of GTK and an old version
> of Library X in order to accommodate Library Y.
>
> Any thoughts?
>
> I feel like the X.[024] releases are just snapshots of a development
>> branch,
>> with X.6 being the stable release, and I wonder if X.[024] shouldn't
>> clearly be
>> labelled as that, regardless of what version number is chosen (be it 4.0,
>> 3.99.0, 4.0beta1 or whatever).
>>
>
> In my opinion the label "unstable release" communicates exactly that. I'm
> not sure what "development branch" communicates that "unstable release"
> doesn't?
>

The convention in GNOME up until know has been that even numbers are for
stable releases, and odd ones are for unstable releases. I didn't know GTK+
4.0 would be considered an unstable release.


> Regards,
> Philip C
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>


-- 
  Jasper
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[philip . chimento]

On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort 
wrote:

> Hi,
>
> On 21/06/16 16:26, Peter Weber wrote:
> > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to
> > write about my thoughts, in a careful way. In the first moment, I thought
> > this is a good idea and just the numbering is misleading. Stability is
> what
> > developers want, we need it, we love it. With a few days distance,
> > numbering is just a small issue, I see this now entirely different and
> > three major issues:
>
> Here are some thoughts I have about all this, from a downstream maintainer
> POV.
>

Thanks! It's good to get opinions from all over the place.

My concern with this new scheme is that GTK+ libraries will have to bump the
> soname every 6 months (if they want to support the latest GTK+). That can
> be
> manageable for say vte or gnome-desktop, although it may be bad if 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.
>

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

But do you expect WebKitGTK+ to bump the ABI every 6 months?
>

That does seem to point to a problem — if an app uses Library X which does
follow the unstable GTK series, and Library Y which doesn't, then the app
developer is forced to stick to the stable series of GTK and an old version
of Library X in order to accommodate Library Y.

Any thoughts?

I feel like the X.[024] releases are just snapshots of a development branch,
> with X.6 being the stable release, and I wonder if X.[024] shouldn't
> clearly be
> labelled as that, regardless of what version number is chosen (be it 4.0,
> 3.99.0, 4.0beta1 or whatever).
>

In my opinion the label "unstable release" communicates exactly that. I'm
not sure what "development branch" communicates that "unstable release"
doesn't?

Regards,
Philip C
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Emilio Pozuelo Monfort]

Hi,

On 21/06/16 16:26, Peter Weber wrote:
> I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to
> write about my thoughts, in a careful way. In the first moment, I thought
> this is a good idea and just the numbering is misleading. Stability is what
> developers want, we need it, we love it. With a few days distance,
> numbering is just a small issue, I see this now entirely different and
> three major issues:

Here are some thoughts I have about all this, from a downstream maintainer POV.

My concern with this new scheme is that GTK+ libraries will have to bump the
soname every 6 months (if they want to support the latest GTK+). That can be
manageable for say vte or gnome-desktop, although it may be bad if 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.

But do you expect WebKitGTK+ to bump the ABI every 6 months?

I feel like the X.[024] releases are just snapshots of a development branch,
with X.6 being the stable release, and I wonder if X.[024] shouldn't clearly be
labelled as that, regardless of what version number is chosen (be it 4.0,
3.99.0, 4.0beta1 or whatever).

Cheers,
Emilio
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Debarshi Ray]

Hey,

On Tue, Jun 21, 2016 at 05:07:46PM +0100, Simon McVittie wrote:
> On 21/06/16 15:26, Peter Weber wrote:
> > 2. Add experimental features through external libraries (libsexy and so
> > on?)
> 
> A series of tiny libraries is not a great way to build a coherent
> platform, and each of those libraries needs to manage its API, ABI and
> stability too. We've been here with libgnomewhatever, libsexy, libegg,
> libunique and so on.
> 
> (There are also technical considerations here: widgets in GTK proper can
> make use of internal interfaces that third-party widgets can't, and
> linking a large number of tiny libraries has a measurable startup cost
> for applications.)

We have libgd [1] where some of the new additions to GTK+ in recent
times were prototyped. HeaderBar, Revealer and Stack/StackSwitcher
come to mind.

Cheers,
Rishi

[1] https://git.gnome.org/browse/libgd

pgpcSBxVomH9F.pgp
Description: PGP signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Peter Weber]

On Thu Jun 23 23:16:58 2016 GMT+0200, philip.chime...@gmail.com wrote: 
> I've tried to capture some of the discussion that we've had so far, on-list
> and off, in this FAQ [1]. I also added some points for further discussion,
> such as the longer cycle length you mentioned above.
> 
> Regards,
> Philip C
> 
> [1] https://wiki.gnome.org/Projects/GTK%2B/Lifecycle/FAQ
>

Thank you Philip! Also for the questions at the bottom.

Bye
Peter
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[philip . chimento]

On Thu, Jun 23, 2016 at 9:29 AM Peter Weber 
wrote:

> On Tue, 21 Jun 2016 17:07:46 +0100, Simon McVittie
>  wrote:
> > Ideally, we'd choose the trade-off such that projects that want to stick
> > to a stable-branch version are happy with its stability, while also not
> > feeling that they are missing out on too much new stuff by doing so. A
> > year is probably too fast? 5 years is probably too slow? I don't know
> > what the right middle ground between those two is, but 2 years sounds
> > like a good first guess.
>
> I started to think about it this. I tend to compare Gtk with Qt, but they
> are not the same. On the other hand, Gtk and Qt are only major
> platform-independent toolkits and largely used on GNU/Linux. The active
> phase of Gtk2 lasted from 2001 - 2011 and it is still maintained in 2016,
> which is a scary long time. Qt's cycle is much shorter, they moved from
> 2.x till 5.x in same time frame.
>
> The current proposal will split Gtk into stable branch, which will break
> in an insupportable* short-period of two years. Even if some major
> applications will move immediately to a stable release, they will already
> use the out-dated within two years. Furthermore GNOME will not use "Gtk",
> GNOME will use it's own Gtk which will likely look and feel different in
> several ways(HIG?). I'm afraid support for at least the development Gtk,
> the stable Gtk and the old-stable Gtk will be required also.
>
> * Thank you English language for this word!
>
> 10 Years are too long and 2 years are too short. Right? Is it better to
> break the API/ABI clearly once and keep it stable for some years, maybe a
> range between 4 to 6 years? In this area compatible (non-breaking)
> features
> can be added. I'm feeling far more comfortable with this idea. This sounds
> similiar to Qt and maybe it's a good approach:
>
> + all applications will largely use the same toolkit (good for users)
> + reliable planning (application developers)
> + necessary API/ABI break (library developers)
> + less maintenance burden (library developers)
> - not so many freedom through API/ABI break (library developers)
>
> I would prefer a faster and more firm cycle.
>

I've tried to capture some of the discussion that we've had so far, on-list
and off, in this FAQ [1]. I also added some points for further discussion,
such as the longer cycle length you mentioned above.

Regards,
Philip C

[1] https://wiki.gnome.org/Projects/GTK%2B/Lifecycle/FAQ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Peter Weber]

Hello!

Writing this on webmail-client. Please bear with me.

On Tue, 21 Jun 2016 12:12:46 -0700, Christian Hergert
 wrote:
> Sorry for the long post, I tried to condense it, unsuccessfully.
> ...

Thanks! That is a valuable insight into the development and changes of
Gtk3. An inspiration for the Gtk-Blog?


On Tue, 21 Jun 2016 17:07:46 +0100, Simon McVittie
 wrote:
> Thanks for starting this discussion.
> 
> A new stable-branch every 2 years is certainly not set in stone, just
> like there's no reason there *has* to be a new stable release of Debian
> approximately every 2 years. It's a trade-off between two factors. If
> stable releases are too frequent, you're right that third-party
> developers will either spend a disproportionate amount of time catching
> up with the latest version, or go looking for something else. If stable
> releases are not frequent enough, third-party developers will find that
> they can't have the latest features or fixes (including the things that
> can't be fixed without breaking API!) other than by using the unstable
> branch.
> 
> ...
> 
> Ideally, we'd choose the trade-off such that projects that want to stick
> to a stable-branch version are happy with its stability, while also not
> feeling that they are missing out on too much new stuff by doing so. A
> year is probably too fast? 5 years is probably too slow? I don't know
> what the right middle ground between those two is, but 2 years sounds
> like a good first guess.

I started to think about it this. I tend to compare Gtk with Qt, but they
are not the same. On the other hand, Gtk and Qt are only major
platform-independent toolkits and largely used on GNU/Linux. The active
phase of Gtk2 lasted from 2001 - 2011 and it is still maintained in 2016,
which is a scary long time. Qt's cycle is much shorter, they moved from
2.x till 5.x in same time frame.

The current proposal will split Gtk into stable branch, which will break
in an insupportable* short-period of two years. Even if some major
applications will move immediately to a stable release, they will already
use the out-dated within two years. Furthermore GNOME will not use "Gtk",
GNOME will use it's own Gtk which will likely look and feel different in
several ways(HIG?). I'm afraid support for at least the development Gtk,
the stable Gtk and the old-stable Gtk will be required also.

* Thank you English language for this word!

10 Years are too long and 2 years are too short. Right? Is it better to
break the API/ABI clearly once and keep it stable for some years, maybe a
range between 4 to 6 years? In this area compatible (non-breaking)
features
can be added. I'm feeling far more comfortable with this idea. This sounds
similiar to Qt and maybe it's a good approach:

+ all applications will largely use the same toolkit (good for users)
+ reliable planning (application developers)
+ necessary API/ABI break (library developers)
+ less maintenance burden (library developers)
- not so many freedom through API/ABI break (library developers)

I would prefer a faster and more firm cycle.

> I'm not one of the people doing the work, so I can't make an informed
> comment on what future plans would require an API/ABI break. However, if
> the people writing the code say they would benefit from API/ABI breaks,
> it seems sensible to believe them.

True and valid! Christian also has written much about this.


How is the contact between the Gtk-Team with the application-developers of
GIMP, Inscape, Pidgin, MySQL-Workbench, Geeqie, Firefox, LibreOffice,
Wireshark, Gummi...[growing list of my day-to-day stuff]? I would ask them
for their oppinions. In the end, they will use it.

Bye
Peter


PS: Posting about the plans was a good decision, even if the churn is
annoying.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Number of dynamically linked libraries (Was: Re: Gtk+4.0)

[Simon McVittie]

On 23/06/16 11:22, Sébastien Wilmet wrote:
> On Wed, Jun 22, 2016 at 05:19:19PM +0100, Simon McVittie wrote:
>> If there is a compelling advantage to splitting up libraries, of course,
>> by all means do so.
> 
> I have an example: gspell:
> https://wiki.gnome.org/Projects/gspell

To be clear, I'm not arguing that things like gspell shouldn't be a
separate library; I think GNOME's current level of modularity is about
right. However, there is such a thing as too much modularity: it isn't
quite as simple as "splitting libraries is always good".

-- 
Simon McVittie
Collabora Ltd. 

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Number of dynamically linked libraries (Was: Re: Gtk+4.0)

[Sébastien Wilmet]

On Wed, Jun 22, 2016 at 05:19:19PM +0100, Simon McVittie wrote:
> If there is a compelling advantage to splitting up libraries, of course,
> by all means do so.

I have an example: gspell:
https://wiki.gnome.org/Projects/gspell

The non-GUI parts could be implemented in GIO, with an extension point
to not hard-depend on Enchant. And the GUI parts could be implemented in
GTK+.

I created gspell as a separate library for a few reasons:

With a GIO extension point, a new library would anyway need to be
created. And I thought that dlopening a library was as bad for startup
time as a hard dependency. Now I know that a GIO extension point would
actually be slightly better.

Be able to iterate on the API more freely, and have something working
(and used in several apps) in less time. Now gspell-1 has a stable API,
but nothing prevents me from bumping to gspell-2 to break the API,
making the new major version parallel-installable. In GIO, it is not
possible.

Be the maintainer. If I wanted to integrate spell checking in GIO and
GTK+, I would still be busy with that project. With a separate library,
it was done in 6 months, working on and off on it (and part-time).

Having the code self-contained. Having all the spell-checking related
code in one repository. The biggest *.c file contains 1400 lines. Mixing
all that code in GtkTextView would make the code less clear, in my
opinion.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Number of dynamically linked libraries (Was: Re: Gtk+4.0)

[Sébastien Wilmet]

On Wed, Jun 22, 2016 at 08:47:02PM +0200, Bastien Nocera wrote:
> Link it against gtk-3.0-wayland instead of both the x11 and wayland
> versions, and try again? My nautilus links against 25 X libraries, both
> the old-school versions and the xcb async versions. And to wayland libs
> as well as Wayland.

Yes by looking at the ldd output in more details, there is not a lot of
GNOME or GTK+ libraries.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Number of dynamically linked libraries (Was: Re: Gtk+4.0)

[Sébastien Wilmet]

On Wed, Jun 22, 2016 at 05:19:19PM +0100, Simon McVittie wrote:
> On 22/06/16 13:14, Sébastien Wilmet wrote:
> > Time for another Project Ridley?
> 
> Maybe; or maybe the benefit of those 30 extra libraries outweighs their
> cost (CPUs are faster now than in the GNOME 2 days after all), but we
> still shouldn't introduce more without good reasons.
> 
> If there is a compelling advantage to splitting up libraries, of course,
> by all means do so.
> 
> > And it doesn't count the dlopen'ed libraries, like for the GIO extension
> > points.
> 
> The application potentially has an opportunity to provide feedback to
> the user before it loads all of those, at least.
> 
> "Properly linked" hard dependencies seem likely to be a bigger issue for
> GUI responsiveness than dlopen'd modules and *their* dependencies,
> because we can't display anything (not even an empty window) until ld.so
> has finished thinking about the relocations for hard dependencies, and
> handed over control to main().

So, if someone wants to optimize application startup time, the features
that rely on a GIO extension point can be initialized later, after the
window is shown.

Or maybe some extension points could be replaced by swallowing the lib
into GIO.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Number of dynamically linked libraries (Was: Re: Gtk+4.0)

[Bastien Nocera]

On Wed, 2016-06-22 at 14:14 +0200, Sébastien Wilmet wrote:
> On Tue, Jun 21, 2016 at 05:07:46PM +0100, Simon McVittie wrote:
> > > 2. Add experimental features through external libraries (libsexy
> > > and so
> > > on?)
> 
> 
> 
> > and linking a large number of tiny libraries has a measurable
> > startup
> > cost for applications.
> 
> https://blogs.gnome.org/alexl/2008/10/07/towards-a-ridley-based-platf
> orm/
> 
> """
> Before:
> 
> ldd `which nautilus` | wc -l
> 91
> 
> After:
> 
> ldd `which nautilus` | wc -l
> 60
> """
> 
> Now:
> 
> ldd `which nautilus` | wc -l
> 98

Link it against gtk-3.0-wayland instead of both the x11 and wayland
versions, and try again? My nautilus links against 25 X libraries, both
the old-school versions and the xcb async versions. And to wayland libs
as well as Wayland.

> Time for another Project Ridley?

It's nearly 8 years later, and the costs of linking to all those
libraries is likely hidden by even the slowest of NANDs, eMMCs or SSD.
Even a stock GNOME install will have all those cached by the OS by the
time you get to launch nautilus.

There might be benefits to reducing the library count, but startup
speed isn't likely to be one.

> And it doesn't count the dlopen'ed libraries, like for the GIO
> extension
> points.
> 
> --
> Sébastien
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Number of dynamically linked libraries (Was: Re: Gtk+4.0)

[Simon McVittie]

On 22/06/16 13:14, Sébastien Wilmet wrote:
> Time for another Project Ridley?

Maybe; or maybe the benefit of those 30 extra libraries outweighs their
cost (CPUs are faster now than in the GNOME 2 days after all), but we
still shouldn't introduce more without good reasons.

If there is a compelling advantage to splitting up libraries, of course,
by all means do so.

> And it doesn't count the dlopen'ed libraries, like for the GIO extension
> points.

The application potentially has an opportunity to provide feedback to
the user before it loads all of those, at least.

"Properly linked" hard dependencies seem likely to be a bigger issue for
GUI responsiveness than dlopen'd modules and *their* dependencies,
because we can't display anything (not even an empty window) until ld.so
has finished thinking about the relocations for hard dependencies, and
handed over control to main().

-- 
Simon McVittie
Collabora Ltd. 

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Number of dynamically linked libraries (Was: Re: Gtk+4.0)

[Sébastien Wilmet]

On Tue, Jun 21, 2016 at 05:07:46PM +0100, Simon McVittie wrote:
> > 2. Add experimental features through external libraries (libsexy and so
> > on?)



> and linking a large number of tiny libraries has a measurable startup
> cost for applications.

https://blogs.gnome.org/alexl/2008/10/07/towards-a-ridley-based-platform/

"""
Before:

ldd `which nautilus` | wc -l
91

After:

ldd `which nautilus` | wc -l
60
"""

Now:

ldd `which nautilus` | wc -l
98

Time for another Project Ridley?

And it doesn't count the dlopen'ed libraries, like for the GIO extension
points.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Christian Hergert]

Sorry for the long post, I tried to condense it, unsuccessfully.

On 06/21/2016 07:26 AM, Peter Weber wrote:
> After five years we see now Firefox and
> LibreOffice (?) on Gtk3, and progress on Gimp and Inscape, Gtk3 was
> released in 2011. From the developers side, we will forced to choose
> between to nasty options, an already outdated stable API/ABI or a shiny new
> API/ABI, which will break fast.

In retrospect, telling everyone we are going to break things in 3.x when
we branched was not the greatest strategy. However, we have gotten a lot
of core plumbing fixed and 3.x looks a lot less like the 2.x series,
which is right out of 1998.

I've worked on a few very large gtk+ applications this millennium, and
we avoided 3.x for both stability and availability reasons. Neither of
those are much of a concern for me these days.

However, it cannot be underestimated the amount of work that moving from
2.x → 3x was. The entire ecosystem of desktop software was changing
during that time-frame and applications needed to adapt not only to new
API, but to new paradigms. Lots of abstractions have been added that
allow us to have more leeway over the original X design of event
dispatches everywhere. But if you aren't using them (and stuck with the
ancient X-style event handling in your port) you might not get 100%
expected results.

For example, a very large percentage of computers released today come
with touchscreens. Whether you like it or not, we need to support the
hardware that exists. Moving to GtkGesture was a huge step in the right
direction but ultimately changes how you write input for widgets (very
much for the better!).

Now, how about things like overlay scrollbars? Every platform uses them
by default now, and implementing them required changing our drawing
model a bit and some size-request machinery. How about the people that
rely on those scrollbar troughs to draw marks on-top? If we have
"opt-in" nobody will use it correctly. If we have "opt-out" nobody will
use it at all but would remain "ABI stable" in the semantic sense.

Going forward we have even more ambitious goals. We'd like to see
GtkContainer, as it exists today, become obsolete. GtkWidgets will be
able to have children (and internal CSS Gadgets were step 1). No longer
will we need to implement widgets like GtkEntry with custom drawing, we
can simply have composition of widgets.

Even more radically, we need to change the drawing model from one based
on immediate mode rendering to something that is more easily implemented
with GPUs. This necessitates removing things like cairo drawing in the
normative case. If we always render the UI with cairo, we have to do
full texture uploads on every frame. Clearly this will not do. (For
those about to suggest cairo-gl we tried that in the last decade and no,
it's not a good idea). Some of this can be implemented in 3.x (which is
happening now), but has the potential for unforeseen side-effects.

We should be able to remove cairo from the normative case and preserve
immediate mode rendering for those that require it (or fallback). It
could also allow those who wish to use other drawing libraries like skia
to do so independently of gtk+.

Version numbering aside, we want to enable application authors to
release software that has been tested to work correctly. (As opposed to
"untested" with the current model). This is possibly the best way to
move forward, however flatpak is another excellent way to do so.

My current concern is more about theme authors. Let me start by saying I
think the result is a zero-sum game, but this will require new work by
theme authors. On one side it will be easier to know a theme works
correctly (and will be stable). On the other side theme authors will
need to write more theme variants.

-- Christian


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[philip . chimento]

On Tue, Jun 21, 2016 at 7:34 AM Peter Weber 
wrote:

> Hello!
>
> I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to
> write about my thoughts, in a careful way. In the first moment, I thought
> this is a good idea and just the numbering is misleading. Stability is what
> developers want, we need it, we love it. With a few days distance,
> numbering is just a small issue, I see this now entirely different and
> three major issues:
>
> 1. Separating official applications from GNOME, away from all other major
> applications
> 2. Very short stable-release-cycle, every two years an API/ABI-Break is
> really bad for all
> 3. No actual reason to break the API/ABI of Gtk3.x, but stability is the
> most important part for a toolkit
>
>
>
> I hope you don't hate me now.


Quite the opposite, thanks for starting the discussion. I think many people
who were at the hackfest are still recovering from travel and catching up
what they missed at work, so no-one started a thread on this.


> I'm trying to elaborate this:
> 1. Separating official applications from GNOME, away from all other major
> applications:
> Applications will be splitted in modern and outdated ones. Users will see
> modern applications from GNOME and a lot of old stuff, mainly well-known
> applications. As time of writing, neither Gimp, Inkscape, Geeqie, Pidgin
> nor Geany merged to Gtk3. After five years we see now Firefox and
> LibreOffice (?) on Gtk3, and progress on Gimp and Inscape, Gtk3 was
> released in 2011.


In my opinion, this is what the proposal tries to solve. I think a common
message is that outside applications don't want to risk porting to GTK 3
because it's not stable enough. I hope that once GTK 4 is released and
declared stable, then applications like Firefox and LibreOffice would be
confident enough to start porting right away. Especially if we can have
some decent porting guides in place when the new stable release rolls
around.

I'm not sure about this, but I suspect the jump between GTK 2 and 3 was
quite a lot larger than the jump between GTK 4 and the following stable
version will be. Since GTK 2 reigned for 10 years, there were a whole lot
of breaking changes that had to happen at once when the opportunity arose.


> From the developers side, we will forced to choose
> between to nasty options, an already outdated stable API/ABI or a shiny new
> API/ABI, which will break fast.
>

Even if the tradeoff is as bad as you describe, it's better than the one
that application developers get in the current situation: a 10-years
(instead of 1.5 years) outdated stable API/ABI or a shiny new API/ABI which
is not expected to break between releases but in practice it does anyway.

I'm hoping the tradeoff will not be as bad as you describe though :-) Two
years is a much shorter cycle and the stable version will not get as
outdated. As for tracking the unstable series, well, it's definitely opt-in
for a reason, and you shouldn't do it unless you are OK to deal with the
breakage. I expect though that given the option of a two-year stable
series, most developers outside of GNOME will use the stable series. I
certainly plan for my side projects to track the stable series.

If I can finish writing it, I'll add a FAQ page to the wiki today that will
try to illustrate better what the benefits and drawbacks are for
application developers.

2. Very short stable-release-cycle, every two years an API/ABI-Break is
> really bad for all:
> If the API/ABI becomes stable every fourth release or two years, this is
> to short for the developers to adapt. Constant breaking is bad for
> developers! We will see a lot of different stable API/ABIs used within
> years (or not, which isn't better). And the Gtk+-Team will have to support
> a lot of stable-branches: Gtk2, Gtk+3, Gtk4 (two years later), Gtk5(four
> years later) and so on.
> This sounds like very much work and is bad for the Gtk+-team. Currently
> the Gtk+-Team has to support Gtk2 and Gtk3, only.
>

I believe the idea is to support one stable and one unstable release at the
same time. In my opinion, if GTK 8 is the current stable version and you're
still on GTK 3, then that should be equivalent to if you're still using GTK
1 in 2016...

Furthermore the alignment to Debian/Ubuntu LTS sounds like a permanent
> delayed cycle building on top of each other. I don't expect many developers
> to catch up with unstable/upstream or even using "git clone://", in case of
> Ubuntu or Debian this could happen:
> -> LTS -> Stable API/ABI -> Developers start adapting
> -> Subsequent LTS -> Adapted applications available -> But already new
> stable API -> Developers start adapting again
>

This is a good point and it seems like the stable GTK should pick a
judicious time to release that fits with distros' release cycles.


> 3. No actual reason to break the API/ABI of Gtk3.x, but stability is the
> most important part for a toolkit:
> Nobody named a reason, why it is 

Re: Gtk+4.0

[Simon McVittie]

Thanks for starting this discussion.

On 21/06/16 15:26, Peter Weber wrote:
> Users will see
> modern applications from GNOME and a lot of old stuff, mainly
> well-known applications. As time of writing, neither Gimp, Inkscape,
> Geeqie, Pidgin nor Geany merged to Gtk3. After five years we see now
> Firefox and LibreOffice (?) on Gtk3, and progress on Gimp and
> Inscape, Gtk3 was released in 2011.

I am neither a GTK user nor a frequent GTK app developer, but as far as
I can tell, a large part of this has been because non-GNOME projects
have been reluctant to move to GTK 3.x due to its perceived instability.
They're finally moving to GTK 3.x anyway, because it has features they
want, whatever those features are (potentially different for each
project, but Wayland is one that I've heard cited).

> From the developers side, we will
> forced to choose between to nasty options, an already outdated stable
> API/ABI or a shiny new API/ABI, which will break fast.
...
> Very short stable-release-cycle, every two years an API/ABI-Break

Which is it - very short, or so long that it's already outdated? :-)

A new stable-branch every 2 years is certainly not set in stone, just
like there's no reason there *has* to be a new stable release of Debian
approximately every 2 years. It's a trade-off between two factors. If
stable releases are too frequent, you're right that third-party
developers will either spend a disproportionate amount of time catching
up with the latest version, or go looking for something else. If stable
releases are not frequent enough, third-party developers will find that
they can't have the latest features or fixes (including the things that
can't be fixed without breaking API!) other than by using the unstable
branch.

We have exactly the same opposing pressures in Debian, and we've chosen
to compromise on a cycle of around 2 years, but the compromise that's
right for us isn't necessarily exactly the right one for GNOME. As a
data point, we get criticized for releasing too slowly, and we also get
criticized for releasing too fast - I tend to assume this means we must
be doing something right :-)

Ideally, we'd choose the trade-off such that projects that want to stick
to a stable-branch version are happy with its stability, while also not
feeling that they are missing out on too much new stuff by doing so. A
year is probably too fast? 5 years is probably too slow? I don't know
what the right middle ground between those two is, but 2 years sounds
like a good first guess.

> Nobody named a reason, why it is really necessary to break the
> API/ABI. Wayland? Already done (great job!). A lot of new featuers?
> Already done and doing (great job!).

I'm not one of the people doing the work, so I can't make an informed
comment on what future plans would require an API/ABI break. However, if
the people writing the code say they would benefit from API/ABI breaks,
it seems sensible to believe them.

For two prominent examples: Wayland is in the past, but it did need an
API/ABI break - Gtk 2 didn't have it, Gtk 3 does. CSS-based theming
didn't remove any C symbols, but it did change the meaning of existing
code, which wasn't treated as an ABI break but arguably should have been.

> Microsoft (stability) and Qt
> (stability) are investing lot of in this, for decades.

Sure, and I think the key words there might be: investing a lot.
Changing the things you do want to change, without breaking the things
you don't want to change, becomes prohibitively expensive after a while.
I shudder to think how much time and money Microsoft must have spent on
maintaining their "bug-for-bug compatibility" policy in the Windows 95
era. (It's perhaps interesting to note that even Microsoft have backed
away from taking backwards-compatibility to such extremes - even with
their massive resources, it was holding them back.)

Of course, there's a very easy way to make a library
backwards-compatible forever: stop changing it, and do all new
development under a new name (so that library users can choose either).
That's unsatisfactory because its bugs will never get fixes. If we
refine that by continuing to make low-risk/high-reward fixes to the
version with the old name, while focusing new development on the new
name, that's exactly a parallel-installable stable-branch: at the moment
the old name is GTK 2, and the new name is GTK 3.

> 1. Tiring, but with the most impact, keep Gtk3 as stable as possible while
> carefully adding new things

That has been the intention for GTK 3 since 2011, and before that, for
GTK 2 since 2002; but it seems as though every 6 months, we see
complaints that GTK has broken something. Maybe those complaints were
all caused by application developers relying on things that specifically
should not be relied on, but I think it's more likely that in at least
some of those cases, we're running into situations where a semantic
change genuinely did break applications. If we assume that to be true,
then either GTK 

Re: GTK+ 4.0 and Clutter 2.0: rainbows and unicorns

[Benjamin Otte]

Emmanuele Bassi ebassi at gmail.com writes:
 
   a) drop GTK+, move to Clutter and port the complex widges over;
   b) re-implement Clutter inside GTK+;
   c) use Clutter between GDK and GTK+;

I would translate that as:
a) tell GTK developers their code is crap
b) tell Clutter developers their code is crap
c) make Clutter and GTK developers work together on the best of both worlds

I have a good idea what solution causes the least tension here... ;)

 the Clutter UI description format is JSON and not XML because I honestly
 don't like XML at all, and GtkBuilder/GtkBuildable was in the wrong
 position in the stack (GTK instead of GLib) and exposing the wrong API
 (GMarkup to create custom parsers); on the other hand, ClutterScript
 made JSON-GLib possible. 
 
I still maintain that the person that writes and maintains the parser and the UI
for editing gets to decide what format we use. I can handcraft JSON and XML
files that test GTK. I can even handcraft binary files to break things if I need
to. And nobody else does care, because they'll all be using the editor anyway.
(right? :))
Last but not least, I can also live with JSON existing in Clutter and XML
existing in GTK. One of them will not work on the GTK level, so 

 Clutter also has some cool concepts like Constraints, which are similar
 to SizeGroups/Alignments; Actions, which are objects that set up actors
 to provide high level concepts like click/long-click, gesture
 recognition, drag and drop; and Effects, which are post-processing
 filters that use GPU shaders or rendering to offscreen framebuffers.
 
So, let's say we think these concepts are awesome and we want them in GTK. In
particular, actions are something I'd want in GTK preferably right now so that
when we do the switch in event bubbling, there's not that many event handlers
left to fix. How do we do that? We don't want to introduce GTK API that is in
effect identical to the Clutter API. And we don't want to depend on Clutter. Is
there a solution that can work for this?

 obviously, we cannot shove Clutter as it is inside GTK and call it a
 day: both Clutter and GTK would require extensive API changes.
 
 there are a couple of different ways of incorporating Clutter inside
 GTK. one is going the CoreAnimation route, and have GtkWidget exposing a
 ClutterActor as part of its class; essentially, any GtkWidget would be
 able to embed a ClutterActor - and be embedded inside a ClutterActor.
 
There is one thing I'd like to do, and that is providing state for the drawing
operations we do in GTK. An entry would no longer need to do complex
computations whenever it draws[1] (frame, text, progressbar and icons) and
doesn't need to do complex border, margin and padding computations for each of
them, but it would just have Frame, Text, Progressbar and Icon render objects,
that took care of this job. They'd of course need to hook into the CSS theming
infrastructure to get their rendering informations. And it seems to me it's a
good idea to use ClutterActors for that.

If in the end we make GtkWidget a ClutterActor or if we just delegate stuff, I
don't think that matters a lot. In particular because changing from one to the
other just requires changing 3 lines of code. ;)

   - drop containers and make the scene graph explicitly part of the
 ClutterActor API;

The question of how to present containers in the public API is an interesting
one. I poked you about this on IRC, so I won't go into the arguments here and
don't want you to answer, but I'll point it out anyway so people reading this
can think about it:
There is 3 consumers of a container interface to an Actor/Widget:
1) someone implementing a subclass of the Actor/Widget
2) application developers using Actors/Widgets and reading API documentation
3) development tools like glade
They all need to be able but not confused about what they are allowed to do and
what they aren't allowed to do. So group 1 needs the ability to add child actors
to any actor, but groups 2 and 3 should never do that unless the actor really is
a container.
Basically, you want to expose a protected add/remove() function and only make it
public for real containers. Do we have a way how we support this in GObject?

   - drop Rectangle, Texture, and CairoTexture sub-classes and move
 towards a delegate approach for painting the contents of the
 actor;
   - fully retained painting model using primitives;

Could you elaborate on the reasons for that a bit more? From looking at WebKit
(who has a render object/html element split), GTK and Clutter (who don't, but
apparently want to have) and talking to Tim about Rapicorn[2] (which has very
few real widgets that render themselves and everything else is a container of
those widgets) I've never managed to find the ideal split here. Because the
render objects definitely need to be used for layout (their size is kinda
important) and input (you need to know if you clicked on them after all). And at
that point they are pretty 

Re: GTK+ 4.0 and Clutter 2.0: rainbows and unicorns

[Tristan Van Berkom]

Exciting topic.

Just a few comments scattered through the email...

On Tue, 2011-09-06 at 14:26 +, Benjamin Otte wrote:
 Emmanuele Bassi ebassi at gmail.com writes:
  
a) drop GTK+, move to Clutter and port the complex widges over;
b) re-implement Clutter inside GTK+;
c) use Clutter between GDK and GTK+;
 
 I would translate that as:
 a) tell GTK developers their code is crap
 b) tell Clutter developers their code is crap
 c) make Clutter and GTK developers work together on the best of both worlds
 
 I have a good idea what solution causes the least tension here... ;)
 
  the Clutter UI description format is JSON and not XML because I honestly
  don't like XML at all, and GtkBuilder/GtkBuildable was in the wrong
  position in the stack (GTK instead of GLib) and exposing the wrong API
  (GMarkup to create custom parsers); on the other hand, ClutterScript
  made JSON-GLib possible. 
  
 I still maintain that the person that writes and maintains the parser and the 
 UI
 for editing gets to decide what format we use. I can handcraft JSON and XML
 files that test GTK. I can even handcraft binary files to break things if I 
 need
 to. And nobody else does care, because they'll all be using the editor anyway.
 (right? :))
 Last but not least, I can also live with JSON existing in Clutter and XML
 existing in GTK. One of them will not work on the GTK level, so 

For the record, having a common serialization framework would make
things much, much easier for the guys trying to generate this stuff.

If, for instance GtkBuilder was indeed GBuilder, and would have been
the obvious choice for ClutterScript... 

The result would have been:
   - Someone creates clutter-gtk widgets (already done)
   - Someone easily integrates the clutter widget into Glade catalog
 (some have done privately, quite easy to do as it stands)
   - The 'GtkClutter' widget could simply extend the definition
 of it's xml with the GBuildable interface, simply by creating
 ClutterActors from the embedded GBuilder xml.

All ClutterActors, simply by nature of being GObjects, would be
automatically supported by Glade, the only remaining work to be
done to create clutter projects in Glade would be the UI.

However unfortunately, things did not go down this road, and so
we are that much further from editing ClutterScript, at least
from Glade (and combined with GTK+ from Glade).


 
  Clutter also has some cool concepts like Constraints, which are similar
  to SizeGroups/Alignments; Actions, which are objects that set up actors
  to provide high level concepts like click/long-click, gesture
  recognition, drag and drop; and Effects, which are post-processing
  filters that use GPU shaders or rendering to offscreen framebuffers.
  
 So, let's say we think these concepts are awesome and we want them in GTK. In
 particular, actions are something I'd want in GTK preferably right now so that
 when we do the switch in event bubbling, there's not that many event handlers
 left to fix. How do we do that? We don't want to introduce GTK API that is in
 effect identical to the Clutter API. And we don't want to depend on Clutter. 
 Is
 there a solution that can work for this?
 
  obviously, we cannot shove Clutter as it is inside GTK and call it a
  day: both Clutter and GTK would require extensive API changes.
  
  there are a couple of different ways of incorporating Clutter inside
  GTK. one is going the CoreAnimation route, and have GtkWidget exposing a
  ClutterActor as part of its class; essentially, any GtkWidget would be
  able to embed a ClutterActor - and be embedded inside a ClutterActor.
  
 There is one thing I'd like to do, and that is providing state for the drawing
 operations we do in GTK. An entry would no longer need to do complex
 computations whenever it draws[1] (frame, text, progressbar and icons) and
 doesn't need to do complex border, margin and padding computations for each of
 them, but it would just have Frame, Text, Progressbar and Icon render objects,
 that took care of this job. They'd of course need to hook into the CSS theming
 infrastructure to get their rendering informations. And it seems to me it's a
 good idea to use ClutterActors for that.
 
 If in the end we make GtkWidget a ClutterActor or if we just delegate stuff, I
 don't think that matters a lot. In particular because changing from one to the
 other just requires changing 3 lines of code. ;)
 
- drop containers and make the scene graph explicitly part of the
  ClutterActor API;
 
 The question of how to present containers in the public API is an interesting
 one. I poked you about this on IRC, so I won't go into the arguments here and
 don't want you to answer, but I'll point it out anyway so people reading this
 can think about it:
 There is 3 consumers of a container interface to an Actor/Widget:
 1) someone implementing a subclass of the Actor/Widget
 2) application developers using Actors/Widgets and reading API documentation
 3) 

Re: GTK+ 4.0 and Clutter 2.0: rainbows and unicorns

[Emmanuele Bassi]

hi Benjamin;

it's going to be a long email... :-)

On 2011-09-06 at 14:26, Benjamin Otte wrote:
 Emmanuele Bassi ebassi at gmail.com writes:
  
a) drop GTK+, move to Clutter and port the complex widges over;
b) re-implement Clutter inside GTK+;
c) use Clutter between GDK and GTK+;
 
 I would translate that as:
 a) tell GTK developers their code is crap
 b) tell Clutter developers their code is crap
 c) make Clutter and GTK developers work together on the best of both worlds
 
 I have a good idea what solution causes the least tension here... ;)

I know you intended this for comedic effects, but (to be serious for a
second) I don't think ditching either toolkit would be seen as a
judgement on the quality of the code. I know that there are lots of
places in both where the code is crap — but even if we reimplemented
either toolkit on top of the other, a lot of the code would be
salvageable.

the issue is, as usual, is resources. we can pool the (small) resources
we have or just start quasi-from-scratch and take (WARNING: number
pulled out of my arse) five times as much.

  the Clutter UI description format is JSON and not XML because I honestly
  don't like XML at all, and GtkBuilder/GtkBuildable was in the wrong
  position in the stack (GTK instead of GLib) and exposing the wrong API
  (GMarkup to create custom parsers); on the other hand, ClutterScript
  made JSON-GLib possible. 
  
 I still maintain that the person that writes and maintains the parser and the 
 UI
 for editing gets to decide what format we use. I can handcraft JSON and XML
 files that test GTK. I can even handcraft binary files to break things if I 
 need
 to. And nobody else does care, because they'll all be using the editor anyway.
 (right? :))
 Last but not least, I can also live with JSON existing in Clutter and XML
 existing in GTK. One of them will not work on the GTK level, so 

I totally agree: we need a UI tool, and the UI tool can decided whatever
to use — after all, libglade existed for years outside of GTK and
everything was (almost) fine.

the real issue is the format chosen when a widget (or an actor) want to
intercept the deserialization or the serialization process, and
intervene.

ClutterState's description inside JSON is really ad hoc; same goes for
GtkListStore in XML. you don't want to encode that inside the parsing
code, because that would make third party objects impossible to define.
the crux of the matter is that both the GtkBuildable and ClutterScriptable
interfaces expose the parsing mechanism (and format) inside the API —
GMarkupParser for the former, and JsonNode for the latter.

nowadays we have a serialization/deserialization format in GVariant, but
then again, you'd have to deserialize an on-disk format like JSON or XML
into GVariant first. well, JSON-GLib already can... ;-)

  Clutter also has some cool concepts like Constraints, which are similar
  to SizeGroups/Alignments; Actions, which are objects that set up actors
  to provide high level concepts like click/long-click, gesture
  recognition, drag and drop; and Effects, which are post-processing
  filters that use GPU shaders or rendering to offscreen framebuffers.

 So, let's say we think these concepts are awesome and we want them in GTK. In
 particular, actions are something I'd want in GTK preferably right now so that
 when we do the switch in event bubbling, there's not that many event handlers
 left to fix. How do we do that? We don't want to introduce GTK API that is in
 effect identical to the Clutter API. And we don't want to depend on Clutter. 
 Is
 there a solution that can work for this?

no idea. if we don't want to depend on Clutter then we'll have to write
that code somewhere — and the code is tightly coupled with the signals
and with the event handling code. the Actions in Clutter, for instance,
use captured-event on the stage, as well as other API like suspending
the picking when dragging an actor around; or disabling the motion event
throttling when doing gesture recognition; or detecting the actor
underneath the pointer to check for a drop point.

- drop containers and make the scene graph explicitly part of the
  ClutterActor API;
 
 The question of how to present containers in the public API is an interesting
 one. I poked you about this on IRC, so I won't go into the arguments here and
 don't want you to answer, but I'll point it out anyway so people reading this
 can think about it:
 There is 3 consumers of a container interface to an Actor/Widget:
 1) someone implementing a subclass of the Actor/Widget
 2) application developers using Actors/Widgets and reading API documentation
 3) development tools like glade
 They all need to be able but not confused about what they are allowed to do 
 and
 what they aren't allowed to do. So group 1 needs the ability to add child 
 actors
 to any actor, but groups 2 and 3 should never do that unless the actor really 
 is
 a container.
 Basically, you want to expose a 

Re: GTK+ 4.0 and Clutter 2.0: rainbows and unicorns

[Andres G. Aragoneses]

Small question Emanuelle:

On 08/31/2011 04:10 PM, Emmanuele Bassi wrote:
 Giovanni Campagna recently submitted a GDK backend for Clutter[0]which
 I'm fairly keen on merging during 1.9 (the cycle for Gnome 3.4) and
 using as the default backend when compiled on X11.


Oh, does that mean that a Clutter animation could work (if using this 
Gdk-backend for Clutter) with a non-X11 GDK Backend like the Broadway 
backend?


Thanks

 Andres

--

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 4.0 and Clutter 2.0: rainbows and unicorns

[Emmanuele Bassi]

hi;

On 2011-09-01 at 11:18, Andres G. Aragoneses wrote:
 
 Small question Emanuelle:
 
 On 08/31/2011 04:10 PM, Emmanuele Bassi wrote:
 ...
 Giovanni Campagna recently submitted a GDK backend for Clutter[0] which
 I'm fairly keen on merging during 1.9 (the cycle for Gnome 3.4) and
 using as the default backend when compiled on X11.
 ...
 
 Oh, does that mean that a Clutter animation could work (if using
 this Gdk-backend for Clutter) with a non-X11 GDK Backend like the
 Broadway backend?

Clutter already supports non-X11 backends like Windows and Quartz; what
GDK would provide is a single API to use a wrapper for the surface to
draw on and windowing system events.

on Windows, we could have a D3D backend for Cogl - we said multiple
times that it would be a welcomed addition, if anyone wants to work on
it; there's also the ANGLE project, which provides a GL implementation
on top of the Direct3D shading language, and that can be used as a
stop-gap. finally, GL works fine on Windows, so we can use GL there.

OS X already uses OpenGL, so it's not a problem.

Broadway is another matter entirely, though. Broadway is essentially
rendering content into image buffers and sending them over the wire to
an HTTP client; this is incompatible with GL, for obvious reasons, but
it's not stricly impossible to implement something like the GPU
rendering pipeline that Chrome implements for its multi-process split: a
Broadway backend for Cogl would send commands to a renderer process,
for instance. alternatively there's still the possibility to write a
WebGL backend as a command pipeline.

Clutter also has backends for Wayland, for native framebuffers using
EGL, and for Android, just for the sake of completeness.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list