bugMyPaint - Bugs: bug #21751, [GTK3] Cannot change keyboard...

 
 
Show feedback again

You are not allowed to post comments on this tracker with your current authentification level.

bug #21751: [GTK3] Cannot change keyboard shortcuts.

Submitted by:  Joshua Tyler <marand>
Submitted on:  Tue 04 Mar 2014 11:49:13 AM UTC  
 
Severity: 5 - BlockerPriority: 5 - Normal
Status: FixedPrivacy: Public
Assigned to: Andrew Chadwick <achadwick>Open/Closed: Closed
Release: gitPlanned Release: None
Operating System: Debian testing

(Jump to the original submission Jump to the original submission)

Wed 18 Jun 2014 05:20:56 AM UTC, comment #10:

Works for me too, thanks Andrew! As Martin said, I also struggled a bit to setup some labels, even if I know my way on Mypaint vocabulary. Especially because label names were too similar ( eg: Mirror, Mirror Horyzontal ).
Searching for items wasn't really hard ; sorting their name A~Z made it easier ; and the amount of item is not as big as in Krita or Gimp :-)

David REVOY <deevad>
Project Member
Mon 16 Jun 2014 10:14:05 PM UTC, comment #9:

Search requirement → bug #22207

Context is a pain with GtkActions and UIManager. The strings are embedded in them, and they only have two context types: "full" (which should be prolix) and "toolbar" (which needs to be terse). The problem is that most projects use the "full" context for the menu, and then read the old GNOME HIG docs which tells you to tersify strings for menu reading order (View→Fit→Window, that sort of confusing thing...)

Another reason for GActions eventually? I guess contexts are more determined by use over that rainbow -- or at least the docs explain how to write a menu containing its own strings. And there doesn't seem to be a need to define null actions just to hang a submenu (sigh.)

I'll do a usability pass on the editor and some action cleanup at a later date, but I'll close this bug now.

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Mon 16 Jun 2014 09:20:48 PM UTC, comment #8:

Works for me, thanks Andrew! And I like the key conflict management.

It still has usability problems, though. No need to keep this bug open because of that, just stating the obvious: The desperate need for a textual filter or search. The action labels which made sense in a certain menu now lack context, e.g. "smaller" and "decrease". Some actions don't seem to be useful when assigned to a key. And a lot of actions in the menu did exist just to assign a key - they can be removed from the menu now... or maybe remain there just to keep existing features and shortcuts discoverable?

Martin Renold <martinxyz>
Project Administrator
Mon 16 Jun 2014 02:54:15 AM UTC, comment #7:

Works for me. Works pretty well, in fact; I like how it shows the binding you have set up and lets you verify or change it before updating.

Two things that could improve usability, though:
1. The [Revert] button doesn't seem to do anything.
2. Is there any way to filter the actions? I know you can type a word and it skips to instances of that, but it's not as clean as having, say, a search field at the top where you type "Undo" and the list propagates with "Undo" and "Undo and Redo" actions.

I only mention #2 because it might make the huge pile of keybinds less daunting. Having some kind of grouping for them might help, too, but I don't know if that's possible, either.

--------

> Porting to QT would be a huge investment of developer time which I am not prepared to make, and we'd have to throw away tens of developer-years of invested work, and it would be an utter derail of the project. Not going to happen.


I suspected as much, which is why the bulk of the comment was about asking the Gtk3/redhat/gnome crowd for some sort of development assistance. It seems like you're stuck doing a lot of crap work because the GNOME crowd doesn't give a damn about breaking things, even between minor versions, and it's not really fair to you to be stuck dealing with it alone.

Maybe somebody from the associated projects would be willing to help out so things like this and the whole "gtk3 doesn't play nice with evdev tablets" issue can be cleaned up.

MyPaint is great software and it'd probably benefit gnome as a whole if they helped make the gtk3 version stellar, so maybe someone would want to help ;)

Also, sorry for having this clutter up the bug report, I didn't realise you had a mailing list until recently, so I didn't know of a better way to suggest it since it was related to the list of things-to-do listed here.

Joshua Tyler <marand>
Mon 16 Jun 2014 02:25:54 AM UTC, comment #6:

Okay, rethink. I want to target Ubuntu 14.04LTS (GTK+3.10) with the next release, but there are difficulties with getting everything nice with that while trying to support GTK+3.12 too.

So... let's continue to use the old accel-setting APIs for now, but introduce a new editor for the global GtkAccelMap:

https://gitorious.org/mypaint/mypaint/commit/d1fb5cfdd13e6

(Yeah, this is exactly what we've tried to avoid having to do since forever - can't avoid it now.)

Please could everyone test? The editor is in the preferences dialog, on a tab of its own. Click the key column twice to enter a replacement combination. Saving and loading is automatic.

You should find it basic, but that it works. There may be some confusion too (it doesn't make sense to bind every available action, and there are some duplicate strings for internal reasons (radio vs. regular ways of entering a mode, for example)).

--------------------

@marand: The change we'll need to make (at some point beyond 3.12) is very far from a near-total rewrite: to be honest it's in the region of a day or three's coding

Porting to QT would be a huge investment of developer time which I am not prepared to make, and we'd have to throw away tens of developer-years of invested work, and it would be an utter derail of the project. Not going to happen.

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Wed 11 Jun 2014 10:10:07 PM UTC, comment #5:

Some of that sounds good, though losing recent-files capability seems odd. All together, though, it sounds dangerously close to having to do a near-total rewrite just to get everything properly Gtk3-friendly.

Would it be possible to get help from GNOME/Redhat devs in some way for this? Deevad and I were talking about the Gtk3 port and he brought up a good point: MyPaint has the potential to be a sort of showcase app for Gtk3 and GNOME, like how Krita is becoming for KDE and Qt.

It's a great piece of software, generally well made and the Gtk2 version made a strong example of a good Gtk2 app, a must-have for anybody with a pen tablet or display. Gtk3 isn't really getting a lot of popular acceptance right now, so it could benefit them to help make MyPaint a stellar example of a good, must-have Gtk3 program in the same way it was for Gtk2.

---

Another option, though likely unreasonable, would be to port to Qt if there's a major rewrite in the future anyway. That would probably do a lot of good for the Windows port of MyPaint, and it could take advantage of some of Krita's improvements, like its tablet support, too. Krita plus MyPaint is already a killer combo that works together better than Gimp and MyPaint. ;)

Might be able to get somebody to volunteer helping with that, too.

---

The Qt port idea was what I originally intended to mention, but the idea of seeking development resources from the GNOME/Redhat people seemed like a more sensible approach, given the effort already invested into the Gtk3 port.

Either way, you should see if you can get help from one of the projects, I think; it sounds like you're going to end up with a lot of work ahead. Or maybe get somebody involved via the Google Summer of Code thing, if it's not too late.

Joshua Tyler <marand>
Wed 11 Jun 2014 11:05:07 AM UTC, comment #4:

I wish there was, but GTK has always been fairly minimal in that regards.

All is not lost, however. There's a very toylike implementation in the bloatpad.c example, and I'm investigating how to make it all play nice with GtkApplication and GtkApplicationWindow concepts, which are not so far from MyPaint's concepts of Appplication and DrawWindow, after all.

Little observations:

  • Builder XML can define accelerators in GMenuModels, but if you do that then you can't change them later (or at least, the label doesn't update; go figure). The thing to do is to define the menu structure without accels in the XML, and then override the accels from the app's config.
  • We'll get nicer startup and shutdown hooks, at least.
  • We'll probably be forced to drop the Recent Files submenu, and have to redo the mode stuff in a dumber way too. Main menus can no longer have new items added to them dynamically after being created under the new model.
  • The cleanest cross-desktop approach seems to be let the app show both the AppMenu (that thing that GNOME has that nobody else uses) and a regular menubar. We could use a GtkMenuButton on "each" main-window as a Chrome/Firefox-like "cog" button, but that may require lots of redesign. Sensible :) desktops like Xfce will still render a menu bar consisting of "<app-menu> <menu-bar-items>".
  • Other apps should in theory be able to invoke MyPaint's GActions over DBus, which is pretty cool. ISTR EasyStroke thinking about this for gestural stuff (but I may be wrong). Whatever, exposing it to the desktop like this gets you a model closer to KDE's.
Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Tue 03 Jun 2014 12:04:18 AM UTC, comment #3:

> Which is – to put it mildly – Not Helpful.


Gtk/GNOME seems to be pretty good at the "Not helpful" thing lately. :(

I'm not overly familiar with the Gtk/GNOME side since 3, so this may be an insane or dumb question, but...

Is there some sort of central location or special editor that still allows keybindings for Gtk apps? Sort of like how KDE applications all have that extensive "Configure Shortcuts" dialog you can bring up, either within an application or from KDE's System Settings (where you can access all of them).

You guys really shouldn't have to write your own keybinding editor, shortcut binding is an extremely common feature and should be provided by the toolkit in some way.

Joshua Tyler <marand>
Mon 02 Jun 2014 07:55:32 PM UTC, comment #2:

Confirmed here, under Xfce 4.10.1, Debian testing/unstable, GTK+ 3.12.2. The GTK API docs reveal why:

> GtkSettings:gtk-can-change-accels has been deprecated since
> version 3.10 and should not be used in newly-written code.
>
> This setting is ignored.
>
> -- https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-can-change-accels


Which is – to put it mildly – Not Helpful. However it does make sense in the brave new world of out-of-process appmenus squirted across dbus: the protocol would have to be more complex to support keybinding updates from both directions, I suppose.

Practically speaking, adopting GtkApplication may offer a way forward. Not wholly a bad thing, it offers some advantages. That at least would allow us to write a key-binding editor and update the menus via the central app instance.

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Thu 29 May 2014 08:20:37 PM UTC, comment #1:

I confirm, no shortcuts here too ( testing today GIT~master on a Gnome 3.10 system. ) Azerty keyboard, here, without custom keyboard shortcuts, I can't use Mypaint ...

David REVOY <deevad>
Project Member
Tue 04 Mar 2014 11:49:13 AM UTC, original submission:

Decided to update mypaint and try the gtk3 version finally, and I immediately ran into a snag: I can't update key bindings any more. The help entry still says to mouse over an entry and press a key, but doing so does nothing. Not even any sort of console output to indicate that it got a keypress at all.

If there is another way to update keybinds now, the bug here is that the "help" entry is outdated. If the help is still accurate, the bug is that it doesn't seem to work at all.

I tried using a clean config in case it was an old config issue, but no go.

Debian testing, using KDE and kwin, libgtk 3.10, and tested with the oxygen-gtk and greybird gtk3 themes.

Joshua Tyler <marand>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by martinxyz (Posted a comment)
  • -unavailable- added by achadwick (Posted a comment)
  • -unavailable- added by deevad (Posted a comment)
  • -unavailable- added by marand (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 16 Jun 2014 10:14:05 PM UTCachadwickStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Mon 16 Jun 2014 02:25:54 AM UTCachadwickStatusConfirmed=>Ready For Test
    Mon 02 Jun 2014 07:55:32 PM UTCachadwickSeverity3 - Normal=>5 - Blocker
      StatusNone=>Confirmed
      Assigned toNone=>achadwick
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup