#1802 GUI State management implementation#1807
Conversation
- Added testing class for modals
- Added logging to IdeGuiStateManager. - Added functionality, that selecting a different project now switches the IdeContext to the new project.
- Added testing class for modals
- Added logging to IdeGuiStateManager. - Added functionality, that selecting a different project now switches the IdeContext to the new project.
…t-for-gui' into devonfw#1785-implement-modals-in-idecontext
- Added functionality, that selecting a different project now switches the IdeContext to the new project.
…plementation' into devonfw#1802-state-management-implementation
…r other ui feature branches
- added DI for IdeGuiStateManager.switchContext
Coverage Report for CI Build 25731784551Coverage increased (+0.06%) to 70.686%Details
Uncovered ChangesNo uncovered changes found. Coverage Regressions31 previously-covered lines in 3 files lost coverage.
Coverage Stats💛 - Coveralls |
…reading the list of workspaces/projects instead of reading those from the UI
…nager, when switchContext(Path rootDirectory, ...) is called.
This reverts commit 6f92d93.
…tateManager is now set when calling getInstance(), allowing us to provide a getInstance() method with a DI parameter
… getInstance()) (see previous commit)
…can be extended by tests
…plementation' into devonfw#1802-state-management-implementation
…eGuiStateManager;
…IdeGuiStateManager
- not automatically select a workspace - to seperate concerns of which functions update the workspace combobox and which the project combobox
…low new Select-Project-Then-Select-Workspace UI logic (previous commit)
459f762 to
6c44432
Compare
…of own implementation
…plementation' into devonfw#1802-state-management-implementation
hohwille
left a comment
There was a problem hiding this comment.
@laim2003 thanks for your PR.
I like the general design and you added many valuable fixes and improvements for the GUI.
I still have some doubts about the singleton and static member access approach.
Typically this will sooner or later cause trouble.
Maybe we can avoid this where possible.
Please avoid this extensive copy&paste of pointless and confusing properties, plugin settings that are never used, etc.
The golden rule for ide-projects for test is to keep them as minimalistic as possible.
Every line from such file and every entire file that can be removed without the test failing should be removed.
|
|
||
| <!-- jar for test classes --> |
There was a problem hiding this comment.
why removing this comment that could be helpful to explain the execution?
| import java.util.List; | ||
| import java.util.stream.Stream; | ||
|
|
||
| import org.jline.utils.Log; |
| private final ArrayList<String> projectNames = new ArrayList<>(); | ||
| private final HashMap<String, ArrayList<String>> workspaces = new HashMap<>(); |
There was a problem hiding this comment.
| private final ArrayList<String> projectNames = new ArrayList<>(); | |
| private final HashMap<String, ArrayList<String>> workspaces = new HashMap<>(); | |
| private final List<String> projectNames = new ArrayList<>(); | |
| private final Map<String, List<String>> workspaces = new HashMap<>(); |
You can even create custom Java classes to add more semantics since structures like Map<String, List<String> are hard to understand. If it was Map<String, Workspaces> it would be easier to understand esp. when Workspaces has reasonable JavaDoc.
However, I would question why we should store and cache the workspaces for all projects...
Your current code will never refresh the caches (surely you could be calling refreshProjects()) and therefore never shows updated information when a new workspace is created after the GUI was launched. When a project is changed, we should IMHO always refresh the newly selected project's workspaces and afford the 20ms to read them from the disc (again).
| DOCKER_EDITION=docker | ||
| FOO=foo-${BAR} | ||
| TEST_ARGS1=${TEST_ARGS1} user1 | ||
| TEST_ARGS2=${TEST_ARGS2} user2 | ||
| TEST_ARGS3=${TEST_ARGS3} user3 | ||
| TEST_ARGS7=user7 | ||
| TEST_ARGS10=user10 | ||
| TEST_ARGSb=userb | ||
| TEST_ARGSc=${TEST_ARGS1} userc | ||
| TEST_ARGSd=${TEST_ARGS1} userd |
There was a problem hiding this comment.
the basic project was the first ide-project that we created.
It was misused later by many testers who were too lazy to create a new ide-project for their specific purpose.
Therefore all crazy things ended up in this basic project.
Please not not copy & paste all this mess into the gui module.
Nobody will ever understand why we have this here in gui and the true answer will be: "for nothing"...
| DOCKER_EDITION=docker | ||
| FOO=foo-${BAR} | ||
| TEST_ARGS1=${TEST_ARGS1} user1 | ||
| TEST_ARGS2=${TEST_ARGS2} user2 | ||
| TEST_ARGS3=${TEST_ARGS3} user3 | ||
| TEST_ARGS7=user7 | ||
| TEST_ARGS10=user10 | ||
| TEST_ARGSb=userb | ||
| TEST_ARGSc=${TEST_ARGS1} userc | ||
| TEST_ARGSd=${TEST_ARGS1} userd |
| JAVA_VERSION=17* | ||
| MVN_VERSION=3.9.0 | ||
| ECLIPSE_VERSION=2023-03 | ||
| INTELLIJ_EDITION=ultimate | ||
| IDE_TOOLS=mvn,eclipse | ||
| BAR=bar-${SOME} |
| DOCKER_EDITION=docker | ||
| FOO=foo-${BAR} | ||
| TEST_ARGS1=${TEST_ARGS1} user1 | ||
| TEST_ARGS2=${TEST_ARGS2} user2 | ||
| TEST_ARGS3=${TEST_ARGS3} user3 | ||
| TEST_ARGS7=user7 | ||
| TEST_ARGS10=user10 | ||
| TEST_ARGSb=userb | ||
| TEST_ARGSc=${TEST_ARGS1} userc | ||
| TEST_ARGSd=${TEST_ARGS1} userd |
| DOCKER_EDITION=docker | ||
| FOO=foo-${BAR} | ||
| TEST_ARGS1=${TEST_ARGS1} user1 | ||
| TEST_ARGS2=${TEST_ARGS2} user2 | ||
| TEST_ARGS3=${TEST_ARGS3} user3 | ||
| TEST_ARGS7=user7 | ||
| TEST_ARGS10=user10 | ||
| TEST_ARGSb=userb | ||
| TEST_ARGSc=${TEST_ARGS1} userc | ||
| TEST_ARGSd=${TEST_ARGS1} userd |
This PR fixes #1802
Implemented changes:
Main points:
Checklist for this PR
Make sure everything is checked before merging this PR. For further info please also see
our DoD.
mvn clean testlocally all tests pass and build is successful#«issue-id»: «brief summary»(e.g.#921: fixed setup.bat). If no issue ID exists, title only.In Progressand assigned to you or there is no issue (might happen for very small PRs)with
internal