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

Implement a simple single module layout #77

Merged
merged 12 commits into from Oct 4, 2019
Merged

Implement a simple single module layout #77

merged 12 commits into from Oct 4, 2019

Conversation

s-schoen
Copy link
Contributor

PR Checklist

  • There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open an issue first and wait for approval before working on it.
  • The code follows the Google Java Style Guide.
  • JavaDoc is added / changed for public methods.
  • An example of the new feature is added to the demos.
  • Documentation of the feature is included in the README.
  • Tests for the changes are included.

What is the current behavior?

The tab bar is displayed in any case, even when only a single module is used in the workbench, see #23 .

What is the new behavior?

If only a single module is defined for a workbench, the tab bar and the add module button are not visible and the module is automatically opened at startup.

Closes #23

if there is only one module in the workbench, the tab bar
and the add module button are not displayed and the module
is opened by default
@codecov
Copy link

codecov bot commented Sep 19, 2019

Codecov Report

Merging #77 into master will increase coverage by 0.04%.
The diff coverage is 100%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master      #77      +/-   ##
============================================
+ Coverage     94.51%   94.56%   +0.04%     
- Complexity      447      454       +7     
============================================
  Files            20       20              
  Lines          1332     1342      +10     
  Branches         82       85       +3     
============================================
+ Hits           1259     1269      +10     
  Misses           57       57              
  Partials         16       16
Impacted Files Coverage Δ Complexity Δ
...va/com/dlsc/workbenchfx/view/ToolbarPresenter.java 100% <100%> (ø) 21 <8> (+5) ⬆️
.../src/main/java/com/dlsc/workbenchfx/Workbench.java 96.04% <100%> (ø) 123 <2> (+2) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c064815...dce59bf. Read the comment docs.

Copy link
Contributor

@martinfrancois martinfrancois left a comment

Choose a reason for hiding this comment

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

Thanks for the contribution! I added some comments regarding the structure of the implementation, everything else is fine. Please have a look and report back once you made the changes for us to have a look again!

/**
* Tests for {@link Workbench} in case only a single module is used
*/
public class SingleModuleWorkbenchTest extends ApplicationTest {
Copy link
Contributor

Choose a reason for hiding this comment

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

Good job on the test! 👍

@s-schoen
Copy link
Contributor Author

Thanks for the feedback and your suggestions regarding the implementation!
I'll implement the changes as soon as I have time.

@s-schoen
Copy link
Contributor Author

s-schoen commented Oct 4, 2019

I implemented your suggested approach, @martinfrancois. The codeclimate check seems to fail because the setupValueChangedListeners method in now longer than 25 lines. What would you suggest to fix this?
The only thing i can think of is to put the code in a separate private method and just call it inside setupValueChangedListeners, but this does not really contribute to cleaner code imo.

@martinfrancois
Copy link
Contributor

I implemented your suggested approach, @martinfrancois. The codeclimate check seems to fail because the setupValueChangedListeners method in now longer than 25 lines. What would you suggest to fix this?
The only thing i can think of is to put the code in a separate private method and just call it inside setupValueChangedListeners, but this does not really contribute to cleaner code imo.

I just noticed, we have 2 listeners on activeModuleProperty() in this method. Maybe you could merge them and refactor them into a method setupActiveModuleListener() and call it inside of the setupValueChangedListeners method? This would bring it down to less than 25 and make it cleaner at the same time, while I'm aware it's not your fault 😃

Copy link
Contributor

@martinfrancois martinfrancois left a comment

Choose a reason for hiding this comment

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

Thanks a lot for the changes! I added some small comments, please have a look, afterwards it should be good to merge!

@@ -51,6 +52,11 @@ public ToolbarPresenter(Workbench model, ToolbarView view) {
init();
// Adds initially a menuButton if necessary (size of items > 0)
setupMenuBtn();

// check initially whether to use the single module layout (size of modules = 1)
if (model.getModules().size() == 1) {
Copy link
Contributor

Choose a reason for hiding this comment

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

To make intention clearer and reduce duplicated code, we could refactor this check into a method on the model isSingleModuleLayout(), which we could also use it below in the listener and in the WorkbenchSkin

Copy link
Contributor

Choose a reason for hiding this comment

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

Don't forget to refractor this check as well! 😉 Afterwards it should be good to go! @s-schoen

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oops, I missed that. Thanks for pointing it out. Fixed it.

@martinfrancois martinfrancois added the enhancement New feature or request label Oct 4, 2019
Copy link
Contributor

@martinfrancois martinfrancois left a comment

Choose a reason for hiding this comment

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

@s-schoen See my comment from before ;)

Copy link
Contributor

@martinfrancois martinfrancois left a comment

Choose a reason for hiding this comment

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

Sorry, just noticed a small thing. Afterwards it should be good to go!


// check initially whether to use the single module layout (size of modules = 1)
if (model.isSingleModuleLayout()) {
view.bottomBox.setVisible(false);
Copy link
Contributor

Choose a reason for hiding this comment

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

just tested the changes and I noticed the bottomBox is still there, even after setting it to invisible. Can you please add view.bottomBox.setManaged(...); here and below, where you set the value to the same you set the visibility to? (so here it would be false as well for example).
This will hide the empty bar.

Copy link
Contributor

@martinfrancois martinfrancois left a comment

Choose a reason for hiding this comment

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

Alright, thanks a lot for the patience and the great PR! 🎉

@martinfrancois martinfrancois merged commit c552fe2 into dlsc-software-consulting-gmbh:master Oct 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

No Tabs UI
2 participants