Re: GTK+ 3.24?

[Murray Cumming]

On Wed, 2017-05-03 at 18:15 -0400, Matthias Clasen wrote:
> On Wed, May 3, 2017 at 2:55 PM, Murray Cumming 
> wrote:
> > Will there absolutely positively never be any GTK+ 3.23/24
> > releases?
> > 
> > After all these years of not adding API, or deprecating API, in
> > micro
> > releases, I feel very uneasy about doing that in gtkmm 3.22.* just
> > because GTK+ seems to be doing it.
> 
> No plans for a 3.24, no. I don't think there is much of a problem
> with adding deprecations - they are really a tool to help people
> prepare for the jump to the next version. If you want to stick with
> 3.22.x, there is no reason to chase deprecations.

Yes, deprecations are indeed far less of an issue that API additions.
I'd still rather avoid them in a micro release, so it's clearer when
the API was deprecated.

> As for new API, we have been pretty careful so far, and only allowed
> some very minor additions in 3.22.x. Any examples you are thinking of
> ?

Sorry. Yes, you are right. I was sure we'd found some API additions,
but it was just deprecations.

> > But if there will never be a GTK+ 3.24, we could have a gtkmm 3.24
> > that
> > adds and deprecates API without causing too much confusion in the
> > future.
> 
> I'm afraid that a gtkmm 3.24 that is based on gtk+ 3.22 would cause
> quite a bit of confusion.

We have at least one other API (but not ABI) change (to our
Gtk::Box::pack_start() that we'd like to make in a gtkmm 3.24 release,
regardless of any GTK+ API additions, to ease porting to gtkmm 4,
though we haven't decided that yet. We can't do that in a gtkmm 2.22.x
release without upsetting people because of breaking builds. I had
hoped that a GTK+ 3.24 might exist to solve that problem for us.


Murray Cumming
murr...@murrayc.com
www.murrayc.com

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

Re: gtk-devel-list Digest, Vol 157, Issue 4

[Daniel Boles]

On 4 May 2017 at 10:44, Daniel Boles  wrote:

>
> I'm using GTK+ 3 (for the forseeable future) but have stopped using widget
> :margin and :spacing - juuust in case they get removed at some point in the
> future. There's a general trickle of things like that being removed from
> the widget side, so better safe than sorry.
>

Course, I meant removed from GTK+ 4. While I'm still focussing on GTK+ 3,
I'm trying to spot obvious changes that 4 will need, which I can do now in
3, to make the task of porting far less painful when it comes around -
especially if things look like candidates for being removed. Plus, even if
they're retained, usually the newer way is better and worth doing anyway.

If I were using GTK+ 4, the new CSS border-spacing property for Box and
Grid would avoid the need for the (horrifying but surprisingly functional)
way that I hack it into GTK+ 3. It would be really nice to see that being
added in 3, but I'm guessing that's unlikely...
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk-devel-list Digest, Vol 157, Issue 4

[Daniel Boles]

>
> Date: Wed, 03 May 2017 15:45:14 +0200
> From: Murray Cumming 
> To: Timm B?der 
> Cc: gtk-devel-list 
> Subject: Re: gtk4: gtk_box_pack_start()/end() porting
> Message-ID: <1493819114.24525.3.ca...@murrayc.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 2017-05-03 at 15:45 +0200, Timm B?der wrote:
> [snip]
> > [1]Even though spacing *should* probably be handled by the theme, so
> > the
> > theme can decide whether UIs are more spacey or more narrow, nobody
> > has
> > come up with a proper way for applications to specify that.
>
> Yes, I've never liked how applications have all these magic values
> sprinkled through their code.
>
> Thanks for the explanation.
>
> --
> Murray



In case anyone is interested in my anecdote...

I'm using GTK+ 3 (for the forseeable future) but have stopped using widget
:margin and :spacing - juuust in case they get removed at some point in the
future. There's a general trickle of things like that being removed from
the widget side, so better safe than sorry.

Doing these in CSS instead - while it involves some horrifying hacks that
almost certainly break some cases, which I don't use yet - does mean that I
can use relative units like em for spacing out my UI. That said, this also
means that (unless I start generating CSS providers on the fly) I have to
know in advance which levels of spaciness I want and define them as CSS
classes.

But, whatever the limitations may be, this is working for me right now, and
it's liberating both in the sense of cleaning up my source code and scaling
far better with changes to font size, DPI, etc.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list