Desktop shortcut for the GUI does not work: gui commandlet requires IDE_HOME

[quando632]

Actual behavior

The desktop/start-menu shortcut created by #1917 is generated correctly, but clicking it never starts the GUI.

The shortcut runs ideasy.exe gui, and createWindowsShortcut does not set a WorkingDirectory. Windows therefore starts the process in the directory of the target executable («IDE_ROOT»\_ide\installation\bin), which is not inside an IDEasy project. Since Gui does not override isIdeHomeRequired(), it inherits the default true from Commandlet, so the commandlet aborts:

The gui commandlet requires an IDEasy project to work.
Please run "icd <project-name>" before calling "ide gui".

A desktop shortcut is by definition launched from outside any project, so in its current form it can never work.

Reproduce

1. Install IDEasy from a release containing Allow the creation of a desktop shortcut for the GUI #1917 (ide install), so that the shortcut is created.
2. Double-click the IDEasy shortcut on the desktop or in the start menu.
3. The GUI does not appear.

Equivalent without a shortcut — run the same command from any directory outside a project:

cd C:\Users\«user»\Downloads
"C:\projects\_ide\installation\bin\ideasy.exe" gui

Verified with the working directory set both to a neutral folder and to «IDE_ROOT»\_ide\installation\bin (the directory Explorer uses when the shortcut has no WorkingDirectory). Both produce the error above. Running the identical command from within a project directory starts the GUI correctly.

Expected behavior

Double-clicking the shortcut starts the IDEasy GUI without requiring a preceding icd «project».

The GUI already supports this: ProjectManager reads the project list from IDE_ROOT and its class comment states this is intentional — "you might want to read the list of projects without being already in the project context". Project selection happens inside the GUI, so gui should require IDE_ROOT but not IDE_HOME.

IDEasy status

IDE_ROOT is set to C:\projects
Your version of IDEasy is 2026.07.002
Your operating system is windows(10.0)@x64 [Windows 11@amd64]

Note: the shortcut code is not part of release 2026.07.002 (tagged 2026-07-21); #1917 was merged on 2026-07-30. The behavior above was reproduced by invoking the gui commandlet directly, which is unchanged by #1917.

Related/Dependent issues

Sub-issue of #1917

Comments/Hints

Affects all platforms, not just Windows. The Linux .desktop entry uses Exec=«installation»/bin/ideasy gui with no Path= key, and the macOS IDEasy.command calls the binary without changing directory, so both hit the same guard.

Suggested fix: override isIdeHomeRequired() in Gui to return false while leaving isIdeRootRequired() at true.

The existing test coverage does not catch this — IdeasyCommandletTest.verifyDesktopShortcut only asserts on Windows that the two .lnk files exist, without checking target, arguments, or whether launching them succeeds.

[quando632]

Fixed on branch feature/2279-gui-shortcut-without-project.

Gui inherited isIdeHomeRequired() == true from Commandlet.java:184, so the commandlet aborted before doRun ever ran. A desktop shortcut always starts outside a project, so it could not work. Overriding it to false fixes it; isIdeRootRequired() stays true, since the launcher pom and the project list resolve relative to IDE_ROOT.

A second defect sits behind that one. SystemPath.findBinary searches tool2pathMap (SystemPath.java:287) and paths (:293), but never extraPathEntries, which is read only by toString() (:346). So ProcessContext.withPathEntry reaches the PATH of the child process but not the binary resolution of IDEasy itself, and without IDE_HOME the tool map stays empty and mvn becomes unresolvable. Registering the Maven bin directory the way LocalToolCommandlet.java:127 does resolves it:

this.context.getPath().setPath(mvn.getName(), mvnInstallation.binDir());

Verified end-to-end: the GUI now starts from a neutral working directory with IDE_HOME unset.

Follow-ups:

• The withPathEntry / findBinary asymmetry is not GUI specific and affects any caller that provides a tool that way. A fix in findBinary touches every tool invocation, so it fits better as its own issue.
• Without IDE_HOME the Maven configuration folder falls back to USER_HOME/.m2 (Mvn.java:282-283), so the shortcut needs ide-gui resolvable from there or from a remote repository. On a SNAPSHOT developer installation it is in neither. Worth confirming for a released version before relying on the shortcut.
• optional: IdeasyCommandletTest.verifyDesktopShortcut checks only that the Windows .lnk files exist, while the Linux and macOS branches assert on content.