Re: First deprecate APIs and then remove them in the next major version

On Samstag, 16. Dezember 2017 12:05:03 CET Sébastien Wilmet wrote: > On Fri, Dec 15, 2017 at 11:10:46AM -0500, Matthias Clasen wrote: > > I know this may sound harsh, but: If you want things to work differently, > > send patches. In theory. In practice you send patches and then you get a response

Re: First deprecate APIs and then remove them in the next major version

On Samstag, 16. Dezember 2017 14:17:11 CET Matthias Clasen wrote: > > I mean to me it looks like nobody even considered in the past to keep old > > APIs > > at all. Currently it is just a common rule "ok, we are now on the next > > major > > version branch, we are now safe to do whatever we want

Re: First deprecate APIs and then remove them in the next major version

On Mittwoch, 13. Dezember 2017 12:33:34 CET Emmanuele Bassi wrote: > On 13 December 2017 at 12:05, Sébastien Wilmet wrote: > > Ideally, a new major version of a library should only remove deprecated > > APIs. > The short answer is: that's not how library development works,

Re: First deprecate APIs and then remove them in the next major version

On Mittwoch, 13. Dezember 2017 16:55:41 CET Emmanuele Bassi wrote: > - GTK supports parallel installation of different major API versions > - symbols, types, properties, and signals deprecated in a major API > version continue to exist forever (and possibly work as well) > - new major versions

Re: gtk 3 stuck menu bug on Mac

On Freitag, 17. November 2017 00:51:25 CET Christian Schoenebeck wrote: > What I found out so far is that whenever this problem occurs, both of the > following two checks in function gtk_menu_motion_notify() (gtkmenu.c) return > false and the function is thus aborted at t

Re: gtk 3 stuck menu bug on Mac

On Montag, 20. November 2017 08:04:20 CET you wrote: > >> Since this issue only seems to happen on Mac, and since it worked > >> flawlessly on > >> Mac before, and since I see the Quartz implementation hasn't really > >> changed > >> (significantly) in the last couple years, was there some kind of

gtk 3 stuck menu bug on Mac

Hi! I am currently investigating a menu handling bug of Gtk 3.22.26 on Mac (Quartz implementation). It happens quite often that Gtk 3 menus on Mac stop processing any mouse events. So when that happens, i.e. menu items are no more highlighted when moving the mouse pointer over them, nor do the

Gtk Builder and item id

Hi, I noticed that the current Gtk Builder XML parser does not accept an id for "item" elements. Please consider the attached patch to address this. Background: it should be possible to query menu items at runtime to change their labels (text) at any time. CU Christian---

Re: Gtk Builder and item id

On Dienstag, 7. November 2017 22:23:01 CET you wrote: > Hi; > > thanks for your patch; GTK uses Bugzilla to track issues, > contributions, and requests for enhancements. > > Please, file a bug at: > https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B and attach > your patch, so it won't get

Re: gtk 3 stuck menu bug on Mac

ght review this patch. CU Christian On Montag, 20. November 2017 15:43:37 CET Christian Schoenebeck wrote: > Actually I have no idea where I would find those "OS X build patches". > > Anyway, I decided to be pragmatic and I am now using the attached patch to > addre

Re: First deprecate APIs and then remove them in the next major version

On Sonntag, 24. Dezember 2017 10:26:48 CET Paul Davis wrote: > > The trend among DAW apps is going towards process separation for plugins > > (one > > process for all instances of a plugin). No plans for that in Ardour yet? > > ​It doesn't scale. ​Certainly not to the session size that we're

Re: First deprecate APIs and then remove them in the next major version

On Samstag, 23. Dezember 2017 10:47:08 CET Paul Davis wrote: > ​actually, my impression from interactions with the author is that GTK > didn't make their life miserable at all. > > however, the issues that have been mentioned before regarding host/plugin > toolkit interactions did make their (and

Re: gtk_menu_item_set_accel_path()

On Donnerstag, 8. Februar 2018 16:32:05 CET Christian Schoenebeck wrote: > And in fact that C code works perfectly even with Gtk 3, but gtkmm3 is doing > something differently than in above's C code: in the Gtk::MenuItem > constructor they explicitly create an acceleration label for the

Re: gtk_menu_item_set_accel_path()

On Donnerstag, 8. Februar 2018 20:21:52 CET Christian Schoenebeck wrote: > Ok, the attached quick hack (on gtkmm3) fixed that issue for me. With that > patch the acceleration keys are now correctly displayed again with gtkmm3. > But obviously I have no idea whether the accelerat

Re: gtk_menu_item_set_accel_path()

On Donnerstag, 8. Februar 2018 12:17:06 CET Daniel Boles wrote: > > are correctly updated with the expected textual representation of the > > keyboard > > accelerator key(s) (i.e. "Ctrl c", "F1", etc.), however the menu item's > > GtkAccelLabel would never be displayed on screen. > > I think we'd

gtk_menu_item_set_accel_path()

Hi! I am currently debugging gtk_menu_item_set_accel_path(): when using that function then keyboard accelerator key(s) are not displayed in the menu item at all. Has anybody looked into this bug before? What I found out so far is that the the menu item's