FileChooserDialog constructors taking backend argument

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

FileChooserDialog constructors taking backend argument

Daniel Boles
Clearly these constructors could not actually achieve their stated purpose in GTK+ 3, as the backend functionality was removed already then.

In case anyone was trying to use these in gtkmm-3, should deprecation warnings be added there, too? Clearly we don't want to just remove these ctors and break code that was using them, however ineffectively.


_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FileChooserDialog constructors taking backend argument

Kjell Ahlstedt
Den 2017-03-26 kl. 23:15, skrev Daniel Boles:

> Hello,
>
> About this commit:
> https://git.gnome.org/browse/gtkmm/commit/?id=bd97e557771cdce23bdc815288db2ffdd8c083c9
>
> Clearly these constructors could not actually achieve their stated
> purpose in GTK+ 3, as the backend functionality was removed already then.
>
> In case anyone was trying to use these in gtkmm-3, should deprecation
> warnings be added there, too? Clearly we don't want to just remove
> these ctors and break code that was using them, however ineffectively.
>
>
I have marked the FileChooserDialog constructors with backend parameters
deprecated in gtkmm-3. I suppose it's almost okay to do that in the
gtkmm-3-22 branch. We have been forced to deprecate other methods there
because of recent deprecations in gtk+. According to normal rules, new
deprecations would have to wait until gtkmm 3.24.
https://git.gnome.org/browse/gtkmm/commit/?h=gtkmm-3-22&id=db8310fc15108624c0d50bcbaf73312d59b297dc
_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fwd: FileChooserDialog constructors taking backend argument

Daniel Boles
In reply to this post by Daniel Boles
On 27 March 2017 at 12:50, Kjell Ahlstedt <[hidden email]> wrote:
Den 2017-03-26 kl. 23:15, skrev Daniel Boles:
Hello,

About this commit: https://git.gnome.org/browse/gtkmm/commit/?id=bd97e557771cdce23bdc815288db2ffdd8c083c9

Clearly these constructors could not actually achieve their stated purpose in GTK+ 3, as the backend functionality was removed already then.

In case anyone was trying to use these in gtkmm-3, should deprecation warnings be added there, too? Clearly we don't want to just remove these ctors and break code that was using them, however ineffectively.


I have marked the FileChooserDialog constructors with backend parameters deprecated in gtkmm-3. I suppose it's almost okay to do that in the gtkmm-3-22 branch. We have been forced to deprecate other methods there because of recent deprecations in gtk+. According to normal rules, new deprecations would have to wait until gtkmm 3.24.
https://git.gnome.org/browse/gtkmm/commit/?h=gtkmm-3-22&id=db8310fc15108624c0d50bcbaf73312d59b297dc


Thanks!

Indeed, even GTK+ 3.22 is not strictly enforcing API freeze; as well as deprecations, there has recently been some new API added. One in particular that comes to mind is gtk_flowbox_get_child_at_pos():
https://git.gnome.org/browse/gtk+/commit/gtk/gtkflowbox.h?h=gtk-3-22&id=9679ef6b00cb087fecf772bb69ab9a2ad7429835
Shall we wrap such new methods when they arise?



_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FileChooserDialog constructors taking backend argument

Kjell Ahlstedt

Indeed, even GTK+ 3.22 is not strictly enforcing API freeze; as well as deprecations, there has recently been some new API added. One in particular that comes to mind is gtk_flowbox_get_child_at_pos():
https://git.gnome.org/browse/gtk+/commit/gtk/gtkflowbox.h?h=gtk-3-22&id=9679ef6b00cb087fecf772bb69ab9a2ad7429835
Shall we wrap such new methods when they arise?


I leave that for Murray to decide. I guess that if there will ever be a gtkmm 3.24 release, new API shall be added only there, and not in gtkmm 3.22.

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

gtkmm 3.24 or new API in gtkmm 3.22?

Murray Cumming-5
On Mon, 2017-03-27 at 14:40 +0200, Kjell Ahlstedt wrote:
> I leave that for Murray to decide. I guess that if there will ever be
> a gtkmm 3.24 release, new API shall be added only there, and not in
> gtkmm 3.22.

I still find this hard to decide. I am generally infuriated that GTK+
has added (and deprecated) API in a stable release cycle. I cannot
understand why on earth they didn't just branch for GTK+ 3.24. I don't
like breaking our promise, and confusing our API versions, just because
they did, but I guess we have to do something. At least, it's not very
much API, I suppose.

What would you (plural) prefer, out of:

1. We add (and deprecate) API in gtkmm 3.22.x.

2. We release gtkmm 3.24 with the added (and deprecated) API, though
there will (probably, but nobody really knows) be a GTK+ 3.24.

--
Murray Cumming
[hidden email]
www.murrayc.com

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gtkmm 3.24 or new API in gtkmm 3.22?

Dr. Diether Knof
Hello,

I prefer to add API in gtkmm 3.22.x.

I think it is the better choice to make the same “error” as gtk but stay with the same numbering then differ from the gtk numbering scheme.

In the case gtkmm changes to 3.24 whereas gtk stays in 3.22, if the gtk+ version 3.24 has another API change, gtkmm would have to change to 3.26, so the problem persists.

Greetings
Diether Knof

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list

attachment0 (220 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gtkmm 3.24 or new API in gtkmm 3.22?

Daniel Boles
I would agree with Dieter. But by all indications I've seen, there specifically will not be any GTK+ versions beyond 3.22. The idea is that 3.22 is the v3 version of 2.24 - the final 'minor' release of its kind, which will now only receive an arbitrary number of point releases, until its LTS ends. 2.24 is now on point release .31

This isn't to say that adding/deprecating API in 3.22 is good, but it's what we've got. If GTK+ manages to follow its own plan as laid out in the latest set of versioning blog posts, then we're not going to get a 3.24 or 3.26 or anything.

Personally, I don't know quite how to feel. I like how GTK+ 3 is trying to be actually stable - at least, more so, if we recall the huge changes to theming that arrived clumsily just a couple of even minor releases ago. But I feel like 3 could do with some more measured changes to API, worthy of a new minor release, which will now (ideally!) be harder to get into 3.22. As for GTK+ 4, right now it is exciting more in theory than practice, as a lot has yet to be worked out, and some 'cleanups' have killed functionality that I'm loathe to give up without any sign that it'll be replaced. Oh well - I'll just keep doing what I can to cherry-pick useful changes from GTK+ 4 to 3.22, when the original authors don't.

and hey, for whatever it indicates: GTK+ 4 has just hit a new milestone tonight with the release of v 3.90

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gtkmm 3.24 or new API in gtkmm 3.22?

Kjell Ahlstedt
In reply to this post by Murray Cumming-5

What would you (plural) prefer, out of:

1. We add (and deprecate) API in gtkmm 3.22.x.

2. We release gtkmm 3.24 with the added (and deprecated) API, though
there will (probably, but nobody really knows) be a GTK+ 3.24.

I agree with Diether and Daniel: Let's do as gtk+ does, even though they break the rules.
Does anyone know what other language bindings do or plan to do?


_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gtkmm 3.24 or new API in gtkmm 3.22?

Murray Cumming-5
On Sat, 2017-04-01 at 09:22 +0200, Kjell Ahlstedt wrote:
> I agree with Diether and Daniel: Let's do as gtk+ does, even though
> they break the rules.

OK. Then I don't object anymore. Thanks for being patient. Feel free to
add API in the gtkmm-3-22 branch:
https://git.gnome.org/browse/gtkmm/log/?h=gtkmm-3-22


--
Murray Cumming
[hidden email]
www.murrayc.com

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gtkmm 3.24 or new API in gtkmm 3.22?

Daniel Boles
On 5 April 2017 at 15:00, Murray Cumming <[hidden email]> wrote:
On Sat, 2017-04-01 at 09:22 +0200, Kjell Ahlstedt wrote:
> I agree with Diether and Daniel: Let's do as gtk+ does, even though
> they break the rules.

OK. Then I don't object anymore. Thanks for being patient. Feel free to
add API in the gtkmm-3-22 branch:
https://git.gnome.org/browse/gtkmm/log/?h=gtkmm-3-22

Is the recently created glibmm-2-52 branch intended as an API-breaking/adding (within limits of what the C lib does) wrapper of GLib 2.50? Maybe then, based on this decision, that stuff should just be put in glibmm-2-50 anyway?


_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gtkmm 3.24 or new API in gtkmm 3.22?

Murray Cumming-5
On Sun, 2017-04-09 at 07:20 +0100, Daniel Boles wrote:

> On 5 April 2017 at 15:00, Murray Cumming <[hidden email]> wrote:
> > On Sat, 2017-04-01 at 09:22 +0200, Kjell Ahlstedt wrote:
> > > I agree with Diether and Daniel: Let's do as gtk+ does, even
> > though
> > > they break the rules.
> >
> > OK. Then I don't object anymore. Thanks for being patient. Feel
> > free to
> > add API in the gtkmm-3-22 branch:
> > https://git.gnome.org/browse/gtkmm/log/?h=gtkmm-3-22
>
> Is the recently created glibmm-2-52 branch intended as an API-
> breaking/adding (within limits of what the C lib does) wrapper of
> GLib 2.50?

Glib 2.51/52 is meant to just target glib 2.51/52, with no API or ABI
break. glibmm-2.54 is the ABI-breaking API, which will be used with
gtkmm-4.0. It's not impossible that this will change again, I'm afraid.

I'm not aware of any API/ABI breaks in glib.

>  Maybe then, based on this decision, that stuff should just be put in
> glibmm-2-50 anyway?

I don't think there is any issue about where to put glib/glibmm API.
It's only unusual for GTK+/gtkmm.

--
Murray Cumming
[hidden email]
www.murrayc.com

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gtkmm 3.24 or new API in gtkmm 3.22?

Daniel Boles
On 14 April 2017 at 17:52, Murray Cumming <[hidden email]> wrote:
Glib 2.51/52 is meant to just target glib 2.51/52, with no API or ABI
break. glibmm-2.54 is the ABI-breaking API, which will be used with
gtkmm-4.0. It's not impossible that this will change again, I'm afraid.

I'm not aware of any API/ABI breaks in glib.

>  Maybe then, based on this decision, that stuff should just be put in
> glibmm-2-50 anyway?

I don't think there is any issue about where to put glib/glibmm API.
It's only unusual for GTK+/gtkmm.

My thought process was that now we have an allowance for adding/amending API in gtkmm-3-22, but I couldn't see an equivalent allowance for the 'stable' branch of glibmm.

This assumes that the allowance for gtkmm also covers, e.g., fixing API that was incorrect or missing, not just maintaining parity with GTK+ and its own creative uses of the term 'stable'.  Is that the case? If so, there are a few such patches that I have pushed to master and would love to see in 3.22 also.

My next thought was that I have several, perhaps more, such patches for glibmm too - which as of now were only allowed into master. If patches like this were allowed in gtkmm (and I'll soon know the answer!), to me it would make sense if glibmm made the same allowance.

I have most of these patches tagged on Bugzilla with the API tag, if that helps. I probably missed one or two, though.



_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gtkmm 3.24 or new API in gtkmm 3.22?

Murray Cumming-5
On Fri, 2017-04-14 at 18:56 +0100, Daniel Boles wrote:
> My next thought was that I have several, perhaps more, such patches
> for glibmm too - which as of now were only allowed into master. If
> patches like this were allowed in gtkmm (and I'll soon know the
> answer!), to me it would make sense if glibmm made the same
> allowance.
>
> I have most of these patches tagged on Bugzilla with the API tag, if
> that helps. I probably missed one or two, though.

We have not released glibmm 2.52.0 yet (a version of glibmm-2.24). It's
still unstable - the latest release is 2.51.6. Theoretically it should
have been released already, but we didn't do that due to the GTK+4
confusion. We should release 2.52.0 fairly soon, I guess.
https://git.gnome.org/browse/glibmm/log/?h=glibmm-2-52

Now would be the right time to add or deprecate API in glibmm-2.24,
before we make that stable release. However, we cannot break ABI.

--
Murray Cumming
[hidden email]
www.murrayc.com

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gtkmm 3.24 or new API in gtkmm 3.22?

Daniel Boles
On 16 April 2017 at 13:31, Murray Cumming <[hidden email]> wrote:
We have not released glibmm 2.52.0 yet (a version of glibmm-2.24). It's
still unstable - the latest release is 2.51.6. Theoretically it should
have been released already, but we didn't do that due to the GTK+4
confusion. We should release 2.52.0 fairly soon, I guess.
https://git.gnome.org/browse/glibmm/log/?h=glibmm-2-52

Now would be the right time to add or deprecate API in glibmm-2.24,
before we make that stable release. However, we cannot break ABI.


Thanks for the confirmation. I'll get back to those patches this week and probably post on the bugs to double-check whether they're suitable for the 2-52 branch.


_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gtkmm 3.24 or new API in gtkmm 3.22?

Murray Cumming-5
On Sun, 2017-04-16 at 17:19 +0100, Daniel Boles wrote:
> > Now would be the right time to add or deprecate API in glibmm-2.24,
> > before we make that stable release. However, we cannot break ABI.
>
>
> Thanks for the confirmation. I'll get back to those patches this week
> and probably post on the bugs to double-check whether they're
> suitable for the 2-52 branch.

I'd like to release 2.52.0 soonish, so that would be helpful. Thanks.

--
Murray Cumming
[hidden email]
www.murrayc.com

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Loading...