Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ported the KeyBindings dialog to JavaFX #1390

Merged
merged 2 commits into from
Jun 27, 2016

Conversation

boceckts
Copy link
Contributor

@boceckts boceckts commented May 12, 2016

The KeyBindings are now organized in categories referring to the JabRef menu titles.
The button graKey has been removed and once a entry is selected the table listens for valid key combinations. The FXAlert class has also been adjusted to listen to the closeDialog shortcut.

  • Change in CHANGELOG.md described
  • Tests created for changes
  • Screenshots added (for bigger UI changes)

keybindingsfx
keybindingsfxdefault
keybindingssuccess

@boceckts boceckts changed the title Ported the KeyBindings dialog to JavaFX [WIP] Ported the KeyBindings dialog to JavaFX May 12, 2016
@Siedlerchr
Copy link
Member

UI Looks good 👍 Just one thing you should change regarding the UI: Don't ask questions in dialogs. Because that is too much "cognitive expenditure" for the user. Label the buttons with a clear description: (e.g. Reset Keybinding, Back to Dialog).
Maybe offer a button "Restart JabRef now", if this is technically possible.

See here for a discussion on Why Questions with Yes/No are a bad idea
http://ux.stackexchange.com/questions/9946/should-i-use-yes-no-or-ok-cancel-on-my-message-box

return true;
} else {
return false;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if statement is not necessary, this could be done in one line return combination.equals(pressedCombination)

@tschechlovdev tschechlovdev added status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers and removed stupro-ready-for-internal-review labels May 17, 2016
@tschechlovdev tschechlovdev changed the title [WIP] Ported the KeyBindings dialog to JavaFX Ported the KeyBindings dialog to JavaFX May 17, 2016
@tobiasdiez
Copy link
Member

A few comments regarding the UI:

@boceckts
Copy link
Contributor Author

@tobiasdiez I have now adressed most of your comments. I called the default button Reset binding since it resets the selected binding only, except there is none selected. Also I wasn't really sure what you meant with "remove light gray column separation".
Also the issue with blank symbols in localized strings in fxml files as described in #968 still exists. For this reason you will see a '_' in the screenshots below in the Reset binding button, otherwise the fxml file can't be loaded.

Here are some new screenshots

screen shot 2016-05-25 at 16 54 19
screen shot 2016-05-25 at 16 53 44
screen shot 2016-05-25 at 16 52 53

* @param keyEvent as KeEvent
* @return true if matching, else false
*/
private boolean checkKeyCombinationEquality(KeyCombination combination, KeyEvent keyEvent) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer if you move this code to the KeyBindingPreferences class. Than you can write something like if(Globals.getKeyPrefs().checkKeyCombinationEquality(KeyBinding.CLOSE_DIALOG, event)

private final KeyBindingCategory category;


public KeyBindingViewModel(KeyBinding keyBinding, String binding, KeyBindingCategory category) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The third parameter is not required as far as I can see (if it's a binding, then its category is stored in it)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes you are right, I forgot to remove it when adding the category constructor.

@tobiasdiez
Copy link
Member

tobiasdiez commented Jun 4, 2016

Good work!
I just have a few remarks about the general usage of view models and databinding.

The idea of this ViewModels is the following:

  • Expose fields (as properties) so that the view can easily bind to them (but only expose things you really need in the view)
  • Listen to changes to the underlying data and update accordingly. These changes are then propagated to the view via the binding.
  • Expose methods which modify the underlying data, the view never calls the logic methods themselves.
  • In the best case scenario, you never access the view or its controls directly but for setting up the binding (so only in initialize()).

So in your case you have two ViewModels:
For the whole dialog:

  • Expose bindingsTree and selectedItem
  • Listen to external changes (which is setKeyBindingsRepository) and update bindingsTree then.
  • Expose methods for resetting all keys, save changes, closing the dialog and relaying key pressed events to the selected item

For the item in the table: (KeyBindingViewModel)

  • Expose displayName and binding
  • No need to listen for changes since keybindings cannot be modified except in this dialog
  • Expose methods for changing the keybinding

The reason for this "binding over everything else" philosophy is that you can easily write tests. For example:

KeyBindingDialogViewModel dialog = new blabla();
dialog.setRepository(some mocked rep);
AssertEqual(expectedTree, dialog.bindingsTree);
% If this test passes then you know that the correct things are displayed in the dialog (except if you forgot to bind the vew to `bindingsTree`)

KeyBindingDialogViewModel dialog = new blabla();
dialog.setRepository(some mocked rep);
AssertCalls(mockedRep.resetBindinings(), dialog.resetBinding());
AssertEquals(defaultTree, dialog.bindingsTree);
% Check that the dialog relays the click to the correct method and updates view (only thing that can fail is again that the binding of the buttonclick is not bound to  dialog.resetBinding()

KeyBindingDialogViewModel dialog = new blabla();
dialog.setRepository(some mocked rep);
dialog.selectedIBinding = some mocked binding view model
AssertCalls(mockedBinding.setNewBinding, dialog.keyPressed(event))

KeyBindingViewModel binding = new blabla();
AssertCalls(repository.change(), binding.setNewBinding(event))
AssertEquals("Ctrl + Alt + f4", binding.KeyBinding);

Can you please try to add these tests?

controller.setKeyBindingPreferences(keyBindingPreferences);
controller.initializeView();
keyBindingsDialog.setResizable(true);
((Stage) keyBindingsDialog.getDialogPane().getScene().getWindow()).setMinHeight(475);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be set in the fxml file?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well the minimum size of the dialog pane is already set to this dimension in the fxml file. However if you omit these lines you are able to resize the dialog window to whatever you like but not the dialog content. So all properties set in the fxml file only affect the dialog content but not the dialog window itself. With these lines omitted you could resize the dialog to a point where the content doesn't resize and it may look bugged.

screen shot 2016-06-07 at 15 04 46

@boceckts
Copy link
Contributor Author

boceckts commented Jun 7, 2016

I added some tests for the dialog view model

@Before
public void setUp() {
model = new KeyBindingsDialogViewModel();
JabRefPreferences preferences = JabRefPreferences.getInstance();
Copy link
Member

@tobiasdiez tobiasdiez Jun 7, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Try to pass a mockito mock of the preferences to the keybindingpreferences (see wiki) or mock the repository itself.

@tobiasdiez
Copy link
Member

tobiasdiez commented Jun 7, 2016

Nice! I only have some minor remarks about the naming of the tests and their general structure (only one assert per test). If these small issues are fixed, this PR can be merged from my point of view!

@boceckts
Copy link
Contributor Author

boceckts commented Jun 7, 2016

I refactored the test class.
Also I changed the FXDialogs to always show blocking dialogs and changed the way to create camel case bind names as there was a problem with the import of WordUtils.

try {
preferences.clear();
mockedPreferences.clear();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to clear it.

@tobiasdiez
Copy link
Member

Ok, ready to go from my point of view! @JabRef/developers what do you think?

@boceckts boceckts mentioned this pull request Jun 20, 2016
3 tasks
@tobiasdiez
Copy link
Member

Please rebase and remove the BibTeX localization key. Then I'll merge this in. (except if @JabRef/developers has more remarks)

@codecov-io
Copy link

codecov-io commented Jun 27, 2016

Current coverage is 28.64%

Merging #1390 into javafx will increase coverage by 17.84%

@@             javafx      #1390   diff @@
==========================================
  Files           703        704      +1   
  Lines         46304      46395     +91   
  Methods           0          0           
  Messages          0          0           
  Branches       7634       7636      +2   
==========================================
+ Hits           5000      13288   +8288   
+ Misses        40857      31976   -8881   
- Partials        447       1131    +684   

Powered by Codecov. Last updated by e22433f...15c7522

@boceckts
Copy link
Contributor Author

@tobiasdiez The BibTeX localization key is used in the KeyBindingCategory class.

@boceckts
Copy link
Contributor Author

I found out travis ci uses different import orders for javafx than what is specified in eclipse.settings. I quickly changed it in #1518 so using "organize imports" in eclipse will work for javafx.

@tobiasdiez tobiasdiez merged commit bc6f0c9 into JabRef:javafx Jun 27, 2016
@boceckts boceckts deleted the KeyBindingsFX branch July 18, 2016 10:00
@koppor
Copy link
Member

koppor commented Aug 8, 2016

Please be aware that menu translations are done using Localization.menuTitle and not by Localization.lang. See cb37296.

bruehldev pushed a commit to bruehldev/jabref that referenced this pull request Aug 30, 2016
* Initial port of the keybindings dialog to javafx

* Test javafx import order
@boceckts boceckts mentioned this pull request Oct 26, 2016
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers ui
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants