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

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

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

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

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

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