Tools/manage tools/shortcuts: More help while defining shortcuts

[Stefan Wagner]

I enjoy much the possibility to define my own tools, and combine them with shortcuts.

I admit that it wouldn't be wise to redefine the mosts often used ones like Ctrl-C, Ctrl-V.

However, I often write programs in Scala or Java and like to compile and run them by hotkeys.

I have ALT-j (java) and Ctrl-J (javac) defined, and would like to use something for Scala, but Ctrl-S is already used for "Save".

The first problem with this is, that it isn't indicated, that the keystroke is occupied by something else, it is even shown in the menu. Since the keys are spread all over the menu, it is hard to find a free one. I thought, that Ctrl-K would be a nice alternative, since K can be pronounced like C in German in many cases, and "kompilieren" would be easy to recognize. It's occupied too for "inKremental search" which I rarely use, and so we approach the 3rd aspect of this problem: If I could define an Image to be shown in the toolbar, or building a button from words like "scalac", "scala", ..., the accessibility would be much better.

Conclusion: I have 3 related feature-requests:
 * inform the user, if a hotkey is occupied
 * allow the user to overwrite hotkeys (ask for confirmation to avoid accidentally overwriting popular commands, the user didn't think of)
 * allow the user to define buttons for the toolbar - (by image, by words, by both).

Thanks for your help. If you rewrite Gedit from Scratch in Java or Scala, I would submit a patch. :)

Btw.: I'm still using Gedit 2.30.3 which came with XUbuntu 10.04, but I consulted the List of changes since then, and found no related entry. This is more a feature request/maybe usability bug.

[Sebastien Bacher (seb128)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

[Stefan Wagner (wagner-stefan)]

Okay - slowly understanding the system and intention . Bug 678460 at https://bugzilla.gnome.org/show_bug.cgi?id=678460 .

Offtopic:

This bugreporting system needs reworking too, if bugreporting should be made simple and people should be encouraged to do it again.

As it stands now, I can't encourage newcomers to report bugs. From here they are guided to another side, where you have to register, where you are encouraged to read multiple documents before proceeding. Then again, you have to select what product (gedit), ok - you read the bugdatabase whether the bug has been reported (insert keywords) - it hasn't and now again you have to insert which product (gedit) and which keywords.

As a user, I don't know who is responsible, and don't want to repeat myself over and over again. There has to be a button in the help menu, whihc guides me to the right place. The product (gedit) should be already known then. Entering the keywords for search, should automatically select them for my new bugreport, if I create one from there.

I'm glad that creating an additional account was simplified (OpenID).

[Sebastien Bacher (seb128)]

> if bugreporting should be made simple and people should be encouraged to do it again.

We don't discourage bug report but we don't need extra report as well, we already get bugs report a magnitude higher than what our workforce allows us to work on, in fact we need less bugs or to ignore all non high priority issues. We do tend to take care and act about important system issues, we don't have the resources to deal with extra tools shortcut handling from the text editor sort of bugs though, they are just too specialized corner cases and are better dealt with the app writers