// 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
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.
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/
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/an
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 d
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
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 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; on
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 toolk
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-lis
>> 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
compati
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
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 tim
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 co
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
ex
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
> > >
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
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. F
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 GtkSource
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
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 understa
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
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?
>
>
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
> 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.
A
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 does
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 p
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 al
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
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 tha
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 explanat
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 wo
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
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 wo
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 d
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 ha
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 bu
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 distributi
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 m
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
too
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 w
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
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
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 firs
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
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
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 lib
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,
>
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 miss
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 G
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
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
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 Wayl
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
> st
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
> >
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
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-
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
> betwe
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
> deve
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
hi Benjamin;
it's going to be a long email... :-)
On 2011-09-06 at 14:26, Benjamin Otte wrote:
> Emmanuele Bassi 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+;
> >
Exciting topic.
Just a few comments scattered through the email...
On Tue, 2011-09-06 at 14:26 +, Benjamin Otte wrote:
> Emmanuele Bassi gmail.com> writes:
> >
> > a) drop GTK+, move to Clutter and port the complex widges over;
> > b) re-implement Clutter inside GTK+;
> > c) use Clutt
Emmanuele Bassi 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 i
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
> >usin
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
65 matches
Mail list logo
