Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Start in system tray opens the main window when the watchlist is empty

Ouverte Adaptée aux débutants
#699 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 3 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
76/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
csharp
Domaine
backend, desktop

Piste de recherche

Lisez les lignes 48–62 de ApplicationHostService.vb et les lignes 84–100 de MainWindowViewModel.vb, puis suivez l’effet du démarrage dans la zone de notification et de la liste de surveillance vide sur la visibilité de la fenêtre. Reproduisez le lancement avec StartInSystemTray activé et sans dossier surveillé, puis comparez avec un dossier surveillé. Le travail est terminé lorsque les deux cas démarrent masqués dans la zone de notification et que le comportement existant de fermeture dans la zone de notification reste correct.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Tested on official v4.0.0-beta.12, Windows 11 25H2 (26200.9711), ASUS Vivobook S 15 / Snapdragon X Elite X1E-78-100 / 16 GB RAM, .NET 10.0.13. Both the native ARM64 application and the official x64 application were tested directly on this ARM laptop. Additional component checks used unchanged libraries extracted from the x64 release, with the release's embedded manifest. No Intel/AMD PC was tested. Only disposable files were used. Most testing was automated with Codex, with human assistance identified where applicable. Related build request: #556.

Reproduction

  1. Enable Settings -> Start CompactGUI in system tray.
  2. Have no watched folders.
  3. Exit the app and start it without folder arguments.

Expected: start hidden in the tray as requested.
Actual: the main Home window opens. Reproduced on two fresh launches at 13:40:50 and 13:41:31 BST on 21 October 2026. Saved StartInSystemTray was true and the watchlist had zero entries. The visible main window was enumerated before any activation.

ARM64 positive control: the same setting with exactly one disposable watched folder started hidden and stayed running. ARM64 tray Open, Exit/Cancel and Exit/Yes also passed separate human-assisted checks.

Source explanation
ApplicationHostService lines 48–62 shows the window, then calls ClosingCommand when tray startup is requested. MainWindowViewModel.Closing lines 84–100 only hides/minimizes it when WatchedFolders.Count is nonzero.

Startup visibility should be applied independently of the close-to-tray policy for watched folders.

Related #371 introduced the preference. The later #682 change concerns registry autostart registration; the tested behavior here is visibility on a manual launch with the saved preference. Master was not built or runtime-tested.

Direct x64 GUI follow-up (21 October 2026, BST)

The official x64 application also reproduced the empty-watchlist failure on two fresh launches. The saved StartInSystemTray preference was true, watcher.json contained zero folders, and no folder arguments were supplied. A visible main window was enumerated before any activation in both runs:

Start time Child environment Observation before activating the app
18:22:15 IridiumIO omitted from this child only Main window visible
18:23:14 Existing normal IridiumIO value present Main window visible

The normal-environment repeat shows that the separate Settings-button environment condition is not needed for this startup defect. This is now directly reproduced in both release builds on the same ARM laptop. The x64 positive control also passed at 18:48:14: with StartInSystemTray=true, exactly one disposable watched folder and no folder arguments, the process stayed running with no visible main window. A window inventory found no x64 main window and the process MainWindowHandle was 0 before any activation. This reproduces the same empty/nonempty watchlist distinction in both builds. Separate human-assisted x64 checks subsequently passed: tray Open restored the window; Home/Watcher/Settings and maximize/restore repainted normally; Exit/Cancel kept the app running; Exit/Yes closed it. The process exit was independently confirmed. These manual checks used the isolated x64 copy with DisableHardwareRendering=true; a later automated run after restoring default hardware rendering also showed updating Home/Watcher and maximize/restore. This does not alter the reproducible empty-watchlist startup defect. Native Intel/AMD hardware remains untested.

Langage dominant
Visual Basic .NET
Étoiles
8.9k
Forks
343
Merge moyen
3 j 18 h
PR mergées (30 j)
7

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de IridiumIO/CompactGUI

Toutes les issues de IridiumIO/CompactGUI

Issues similaires

Plus d'issues Backend & API Design

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.