Add option to show taskbar when Flow Launcher is opend #4177
Conversation
Co-authored-by: VictoriousRaptor <10308169+VictoriousRaptor@users.noreply.github.com>
…howing Co-authored-by: VictoriousRaptor <10308169+VictoriousRaptor@users.noreply.github.com>
Co-authored-by: VictoriousRaptor <10308169+VictoriousRaptor@users.noreply.github.com>
Co-authored-by: VictoriousRaptor <10308169+VictoriousRaptor@users.noreply.github.com>
Co-authored-by: VictoriousRaptor <10308169+VictoriousRaptor@users.noreply.github.com>
|
🥷 Code experts: Jack251970 Jack251970, jjw24 have most 👩💻 activity in the files. See details
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame: ✨ Comment |
|
Be a legend 🏆 by adding a before and after screenshot of the changes you made, especially if they are around UI/UX. |
📝 WalkthroughWalkthroughAdds an option and UI to temporarily show the taskbar when Flow Launcher is opened, new Win32 interop (MonitorFromWindow) and Win32Helper taskbar show/hide methods, and conditional calls in MainViewModel to invoke those methods based on Settings.ShowTaskbarWhenInvoked. Changes
Sequence Diagram(s)sequenceDiagram
participant UI as User / UI
participant VM as MainViewModel
participant Helper as Win32Helper
participant OS as Windows (Shell_TrayWnd)
UI->>VM: Open command
VM->>VM: Check Settings.ShowTaskbarWhenInvoked
alt enabled
VM->>Helper: ShowTaskbar()
Helper->>OS: Find Shell_TrayWnd & MonitorFromWindow
Helper->>OS: Post message to show taskbar
end
VM->>VM: Update Dispatcher / show Flow window
UI->>VM: Close command
VM->>VM: Restore keyboard/layout etc.
VM->>VM: Check Settings.ShowTaskbarWhenInvoked
alt enabled
VM->>Helper: HideTaskbar()
Helper->>OS: Post message to hide taskbar
end
VM->>VM: Finish hide sequence / delay
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Organization UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
Flow.Launcher.Infrastructure/NativeMethods.txt (1)
88-96: Remove theDeviceNotifyCallbackRoutineentry causing CsWin32 warningThe
DeviceNotifyCallbackRoutineentry at line 94 doesn't match any recognized symbol in the Win32 metadata.DEVICE_NOTIFY_SUBSCRIBE_PARAMETERSalready includesPDEVICE_NOTIFY_CALLBACK_ROUTINEas its callback field, which means the necessary callback type support is automatically generated when you request the struct.Remove line 94 entirely. The
MonitorFromWindowentry is correct and required for the taskbar logic.
🧹 Nitpick comments (1)
Flow.Launcher.Infrastructure/Win32Helper.cs (1)
1021-1055: Tidy up Taskbar helpers and call out multi‑monitor limitationThe core ShowTaskbar/HideTaskbar logic looks fine and matches the SmartTaskbar pattern, but a couple of cleanups would help:
ShowTaskbaris markedunsafebut doesn’t use any unsafe constructs; the modifier can be dropped.APPBARDATAis now unused after switching away fromABM_SETSTATE, so it can be removed to avoid confusion.- This implementation only targets the primary taskbar (
Shell_TrayWnd). That aligns with the current PR note ("may not work on dual‑monitor setups"), but if you later want multi‑monitor support you’ll likely need to also handleShell_SecondaryTrayWnd(and potentially call the same message per monitor).These are all non‑blocking, but worth tightening either in this PR or a follow‑up.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
Flow.Launcher.Infrastructure/NativeMethods.txtFlow.Launcher.Infrastructure/UserSettings/Settings.csFlow.Launcher.Infrastructure/Win32Helper.csFlow.Launcher/Languages/en.xamlFlow.Launcher/SettingPages/Views/SettingsPaneGeneral.xamlFlow.Launcher/ViewModel/MainViewModel.cs
🧰 Additional context used
🧠 Learnings (6)
📓 Common learnings
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher/App.xaml.cs:252-275
Timestamp: 2025-10-16T10:48:30.573Z
Learning: In Flow Launcher's App.xaml.cs, the plugin initialization block (lines 252-275) that includes PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, _mainVM.QueryResults(), and API.SaveAppAllSettings() does not require additional Task.Run wrappers or Dispatcher.InvokeAsync calls according to maintainer Jack251970, as the threading model is already safe as designed.
📚 Learning: 2025-10-16T10:48:30.573Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3854
File: Flow.Launcher/App.xaml.cs:252-275
Timestamp: 2025-10-16T10:48:30.573Z
Learning: In Flow Launcher's App.xaml.cs, the plugin initialization block (lines 252-275) that includes PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, _mainVM.QueryResults(), and API.SaveAppAllSettings() does not require additional Task.Run wrappers or Dispatcher.InvokeAsync calls according to maintainer Jack251970, as the threading model is already safe as designed.
Applied to files:
Flow.Launcher/ViewModel/MainViewModel.cs
📚 Learning: 2025-06-08T14:12:21.348Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3672
File: Flow.Launcher/MainWindow.xaml.cs:244-247
Timestamp: 2025-06-08T14:12:21.348Z
Learning: In Flow.Launcher, App.NotifyIcon is created before MainWindow creation, so null checks for App.NotifyIcon are not necessary when accessing it from MainWindow code.
Applied to files:
Flow.Launcher/ViewModel/MainViewModel.csFlow.Launcher.Infrastructure/NativeMethods.txtFlow.Launcher.Infrastructure/Win32Helper.cs
📚 Learning: 2025-06-08T14:12:12.842Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3672
File: Flow.Launcher/MainWindow.xaml.cs:318-318
Timestamp: 2025-06-08T14:12:12.842Z
Learning: In Flow.Launcher, the App.NotifyIcon static property is initialized in the App class before MainWindow creation, so null checks are not needed when accessing App.NotifyIcon in MainWindow lifecycle methods.
Applied to files:
Flow.Launcher/ViewModel/MainViewModel.csFlow.Launcher/Languages/en.xamlFlow.Launcher.Infrastructure/Win32Helper.cs
📚 Learning: 2025-09-05T11:56:27.267Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3593
File: Flow.Launcher/HotkeyControlDialog.xaml:6-6
Timestamp: 2025-09-05T11:56:27.267Z
Learning: In Flow.Launcher's migration to iNKORE.UI.WPF.Modern UI framework, dialog resource keys like PopuBGColor, PopupButtonAreaBGColor, PopupButtonAreaBorderColor, and PopupTextColor are provided by the iNKORE.UI.WPF.Modern framework itself, not defined locally in the codebase theme files.
Applied to files:
Flow.Launcher/Languages/en.xaml
📚 Learning: 2025-09-28T03:57:43.995Z
Learnt from: Jack251970
Repo: Flow-Launcher/Flow.Launcher PR: 3770
File: Flow.Launcher/Helper/HotKeyMapper.cs:0-0
Timestamp: 2025-09-28T03:57:43.995Z
Learning: In Flow.Launcher/Helper/HotKeyMapper.cs, the resource descriptions for arrow keys are intentionally swapped - Up/Down keys use "HotkeyLeftRightDesc" and Left/Right keys use "HotkeyUpDownDesc". This is documented with an inline comment and is intended behavior, not a bug.
Applied to files:
Flow.Launcher/Languages/en.xaml
🧬 Code graph analysis (2)
Flow.Launcher/ViewModel/MainViewModel.cs (2)
Flow.Launcher.Infrastructure/UserSettings/Settings.cs (1)
Settings(16-632)Flow.Launcher.Infrastructure/Win32Helper.cs (3)
Win32Helper(33-1058)ShowTaskbar(1023-1033)HideTaskbar(1035-1044)
Flow.Launcher.Infrastructure/Win32Helper.cs (1)
Flow.Launcher.Infrastructure/DialogJump/Models/WindowsExplorer.cs (1)
HWND(115-120)
🪛 GitHub Check: build
Flow.Launcher.Infrastructure/NativeMethods.txt
[warning] 94-94:
Method, type or constant "DeviceNotifyCallbackRoutine" not found
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (3)
Flow.Launcher/SettingPages/Views/SettingsPaneGeneral.xaml (1)
75-83: New “Show taskbar when opened” toggle wiring looks correctThe SettingsCard and ToggleSwitch binding to
Settings.ShowTaskbarWhenInvokedare consistent with existing patterns, and the resource keys (showTaskbarWhenOpened,showTaskbarWhenOpenedToolTip) line up with the language file. No issues here.Flow.Launcher.Infrastructure/UserSettings/Settings.cs (1)
484-485: Settings surface for taskbar option is consistent and safe
ShowTaskbarWhenInvokedas a simpleboolwith defaultfalsefits the existing settings pattern and keeps the new behavior opt‑in only. Placement near other window-visibility options also makes sense. No changes needed here.Flow.Launcher/Languages/en.xaml (1)
84-85: Localization for the new taskbar option is clear and accurateThe new
showTaskbarWhenOpenedand tooltip strings describe the behavior well and align with the settings UI and implementation. No further changes needed.
| // Show the taskbar if the setting is enabled | ||
| if (Settings.ShowTaskbarWhenInvoked) | ||
| { | ||
| Win32Helper.ShowTaskbar(); | ||
| } | ||
|
|
There was a problem hiding this comment.
Guard HideTaskbar() with state so show/hide stay balanced
Wiring the feature through Show()/Hide() is good, but right now HideTaskbar() is gated only by the current value of Settings.ShowTaskbarWhenInvoked. That means:
- If the setting is turned on while Flow is already open,
Show()won’t have calledShowTaskbar(), butHide()will callHideTaskbar(). - If the setting is turned off while Flow is open,
Show()will have calledShowTaskbar(), butHide()will skipHideTaskbar().
Given this uses an undocumented taskbar message, unbalanced calls risk leaving the taskbar in a different mode than the user expects.
Consider tracking a simple flag, e.g. bool _taskbarShownByFlow;, set true only when ShowTaskbar() is actually invoked in Show(), and use that flag to decide whether to call HideTaskbar() in Hide() (and reset it to false afterward). That keeps your interaction with the shell clearly symmetric regardless of when the setting is toggled.
Also applies to: 2211-2215
🤖 Prompt for AI Agents
In Flow.Launcher/ViewModel/MainViewModel.cs around lines 2100-2105 (and
similarly 2211-2215), the current logic checks only
Settings.ShowTaskbarWhenInvoked when hiding the taskbar which can lead to
unbalanced ShowTaskbar/HideTaskbar calls if the setting is toggled while Flow is
open; add a private bool field (e.g. _taskbarShownByFlow) to the viewmodel, set
it to true only when Show() actually calls Win32Helper.ShowTaskbar() (and only
when the setting is enabled), and in Hide() call Win32Helper.HideTaskbar() only
if _taskbarShownByFlow is true, then reset _taskbarShownByFlow to false after
hiding — do the same mirrored change for the other method block at 2211-2215 to
keep show/hide symmetric.
|
@Jack251970 do you have dual monitor setup to help test this? |
pr is not ready as the potential dual monitor issue and the issue addressed by code rabbit so I disable the auto merge now. |
Show taskbar when Flow is opened
Tested