Hotkey-system should be consistent

[Braunch]

JabRef version <3.3>

I have taken a look on the JabRef default Hotkeys. I encountered some inconsistent key bindings like different variants for saving on "alt + F", "ctrl + alt + F" and then one on "F11". Also I do not see how the F1-F9 keys got their bindings. It seems quiet random.
Also there are Hotkeys that require pressing four keys at once. This is not very user freindly.
I also think navigating through the JabRef GUI would be way faster, if there was a hierarchical "tab" like "ctrl + tab". This should follow the frames hierarchy e.g from the toolbar to the tabs to the entry table to the entry editor and so on. To determine if changes are necessary and to find a solution suitable for all users, I would like to start a discussion here. Feel free to contribute.

[koppor]

Related #615

[koppor]

Refs #213 (comment), because it was wished that alt-f works for selected entries.

[mlep]

ESC allows to close the window or panel in most of cases. This should be consistent (all windows and panels).

Currently (JabRef-3.4dev--snapshot--2016-04-19--master--990b0e5.jar), the window after "Get BibTeX data from DOI" cannot be closed with the ESC key.

[Braunch]

I want to bring @mairdl and @koppor private discussion about hotkey presets to the public. In my opinion using choosable presets is quiet handy. If you could save and load your personalized hotkey bindings, we could create a (in our opinion) enhanced hotkey system without forcing users to use it. All we need is the possibility to load a setup in the "Customize key bindings" dialog.

[tobiasdiez]

Aren't custom hotkey bindings stored in preferences? Then exporting and importing preferences already functions as loading keybinding presets. I wouldn't complicate the story by adding other import & export options (this is all code we have to maintain for a probably nearly-never required function).

So making a consistent default keyboard shortcuts scheme should be the primary target.

[Siedlerchr]

Fully agree. should be stored in Preferences.

Default shortcuts should should be consistent with other applications.
e.g. F1 for help, CTRL+S, CTRL+Shift + S for saving and saving as, CTRL-X,
CTRL-V etc, CTRL-F and F3 for search
are in my opinion the important ones.
I think some of the default shortucts, e.g. for closing an application are
already implemented in java by default.

In gernal the ALT Key should be avoided as a single shortuct, because it is
used OS-default for menomics key.

Addtionally the tab order of the labels and textfields in dialogs should be
consistent, too.

2016-05-30 14:04 GMT+02:00 Tobias Diez notifications@github.com:

Aren't custom hotkey bindings stored in preferences? Then exporting and
importing preferences already functions as loading keybinding presets. I
wouldn't complicate the story by adding other import & export options (this
is all code we have to maintain for a probably nearly-never required
function).

So making a consistent default keyboard shortcuts scheme should be the
primary target.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1225 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AATi5O0E1GBUW0PhwLVqlvnxW5qvEYaMks5qGtJRgaJpZM4IJyGI
.

[simonharrer]

Also think about the toggling behavior. In Intellij, one can toggle one/off some additional parts of the app with ALT+number. It works like this:

if(part of window is hidden) -> show and set focus
if(part of window is shown and has focus) -> hide
if(part of window is shown but has no focus) -> set focus

Something similar would also make sense for JabRef with the groups, open office, entry preview/editor and the web search element.

[Braunch]

I am going to the existing shortcuts right now. Does someone know what "next panel 2" and "previous panel 2" in the entry editor are supposed to do? Because nothing happens when I press that.

[Braunch]

Would this be a useful key binding?
Alt +
1 - focus entry table
2 - entry/preview editor (preview: short/long version of preview)
3 - groups
4 - open office
5 - web search
6 - hide/show toolbar

[simonharrer]

Hm, maybe even separate entry preview and entry editor, as they behave quite differently. I, for instance, never use the preview and only want to use the entry editor or nothing at all. As the hide/show of the toolbar I would not put there, or may be at the number 9, as it is semantically not the same - it is not a window I can show/set focus/hide.

[simonharrer]

Regarding "next panel 2" and "previous panel 2", I do not know. Maybe a look in the source code could help?

[Braunch]

I encountered that there are shortcuts for creating new entries for seven different entry-types:

• article
• book
• inbook
• masterthesis
• procceedings
• unpublished
• phdthesis

Is there a reason why those are the only ones that have a customized key bindings?
@mairdl and I came up with the idea that it would be nice to have the possibility to choose which entry types have key bindings. So there would be up to e.g. five actions you could choose an entry type to be created. Any feedback on that idea?

[simonharrer]

Do not give the user too much choice, as this is harder to implement and maintain. We try to simplify the usage of JabRef, and not make it more complicated.

[mairdl]

I understand that it would decrease simplicity in some way. But on the other hand it would increase usability for some users.

At the moment we are thinking of something like having a dropdown with entry types where "New entry type" actions are, e.g. instead of "New article" you would have the dropdown menu.

[simonharrer]

I think, simplicity is key to have a good usability. Best example is Apple, and a lot of other apps in the App Stores out there which simply ignore 20% of the feature requests and focus on the common 80%, making them bug free and without too much customization possibilities. This is the way we want to have JabRef.

When you click on "New entry", a new popup opens where all entries are there and the user can choose the one we wants to create. This can also be reused.

[mairdl]

After some disscusion with @koppor we came to the conclusion that this might be too complex. If there i something new you'll hear about it.

[Braunch]

When we implement the toggle functionality, should we keep the old hotkeys for the web search e.g?

[mairdl]

@obraliar suggested some changes to the Database Properties Dialog, he thinks it would be nice if you delete save actions with the DELETE button. I have to agree with him, do you also think this change is a good idea?

[matthiasgeiger]

Yes this makes sense. The same functionality would be useful in the "Cleanup entries" dialog, too. Configuration is noe needed for this short-cut I think.

For the other "global" KeyBindings configured through the KeyBindings dialog: Before implementing the changes it would be great if you can present us an overview of your plans. I think a table: "Functionality" | "KeyBinding old" | "KeyBinding new" should do.
This would ease discussing here...

[Siedlerchr]

Database Properties and Cleanup dialog use the same sub-Component
When I remeber correctly the same Sub-Component is also used somewhere in
the Properties.

2016-06-06 14:21 GMT+02:00 Matthias Geiger notifications@github.com:

Yes this makes sense. The same functionality would be useful in the
"Cleanup entries" dialog, too. Configuration is noe needed for this
short-cut I think.

For the other "global" KeyBindings configured through the KeyBindings
dialog: Before implementing the changes it would be great if you can
present us an overview of your plans. I think a table: "Functionality" |
"KeyBinding old" | "KeyBinding new" should do.
This would ease discussing here...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#1225 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AATi5MyypDDnLY2cNxBcZ0eNRuSPiqCmks5qJBDZgaJpZM4IJyGI
.

[Braunch]

PR: #1525

[Braunch]

PR of toggle also merged: #1605

[stefan-kolb]

@JabRef/developers Can this be closed with the current state?!

[matthiasgeiger]

Yes, I think so.