-
-
Notifications
You must be signed in to change notification settings - Fork 393
Upgrade NuGet Dependencies & Package Lock Json Files #3846
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
Conversation
🥷 Code experts: no user but you matched threshold 10 Jack251970 has 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:
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:
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. |
📝 WalkthroughWalkthroughThis change upgrades multiple NuGet package dependencies across several projects, removes the dependency on Changes
Sequence Diagram(s)sequenceDiagram
participant OS as Windows OS
participant MainWindow
participant MonitorInfo
OS->>MainWindow: Sends WM_POWERBROADCAST (PBT_APMRESUMEAUTOMATIC)
MainWindow->>MainWindow: Calls InitSoundEffects()
Note over MainWindow,MonitorInfo: For monitor/screen operations
MainWindow->>MonitorInfo: GetCursorDisplayMonitor() / GetNearestDisplayMonitor(hwnd)
MonitorInfo-->>MainWindow: Returns MonitorInfo object
MainWindow->>MainWindow: Uses Bounds/WorkingArea for window positioning
Estimated code review effort🎯 4 (Complex) | ⏱️ ~90 minutes Possibly related PRs
Suggested reviewers
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 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)
✨ Finishing Touches🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 4
🧹 Nitpick comments (3)
Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj (1)
75-75
: Consider removing the redundant Microsoft.SourceLink.GitHub package.Based on previous learnings, SourceLink is included by default in .NET 8+. Since this project targets .NET 9.0, the explicit
Microsoft.SourceLink.GitHub
package reference may be redundant.Consider removing this package reference:
- <PackageReference Include="Microsoft.SourceLink.GitHub" Version="8.0.0" PrivateAssets="All" />
Flow.Launcher/packages.lock.json (2)
159-168
: API surface change:TaskScheduler
2.x replaces the forkThe custom
Jack251970.TaskScheduler
has been swapped out for upstreamTaskScheduler
2.12.2. The namespaces and a few enum names differ (Microsoft.Win32.TaskScheduler
vsTaskScheduler
). Any direct code references will now fail to compile.Double-check that every
using Jack251970.TaskScheduler
(or similar) was removed in the accompanying commits; otherwise build will break.
647-665
: Large set of legacySystem.* 4.3.0
packages indicate NETStandard 1.x fallbackNumerous
System.* 4.3.0
packages (System.Runtime
,System.IO
, …) are present; they get imported only when some transitive package still targets net45/netstandard1.x. These DLLs add ~6 MB to the deployment and occasionally clash with the inbox BCL on newer runtimes during single-file publish.If feasible, lift the remaining offenders (
Svg
,Fizzler
,HtmlAgilityPack 1.11.x
) to builds that target at least netstandard2.0 to drop the baggage.Also applies to: 690-809
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (17)
Flow.Launcher.Core/Flow.Launcher.Core.csproj
(1 hunks)Flow.Launcher.Core/packages.lock.json
(9 hunks)Flow.Launcher.Infrastructure/Flow.Launcher.Infrastructure.csproj
(2 hunks)Flow.Launcher.Infrastructure/Win32Helper.cs
(4 hunks)Flow.Launcher.Infrastructure/packages.lock.json
(7 hunks)Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj
(1 hunks)Flow.Launcher.Plugin/packages.lock.json
(3 hunks)Flow.Launcher.Test/Flow.Launcher.Test.csproj
(1 hunks)Flow.Launcher/Flow.Launcher.csproj
(2 hunks)Flow.Launcher/packages.lock.json
(16 hunks)Plugins/Flow.Launcher.Plugin.BrowserBookmark/Flow.Launcher.Plugin.BrowserBookmark.csproj
(1 hunks)Plugins/Flow.Launcher.Plugin.Explorer/Flow.Launcher.Plugin.Explorer.csproj
(1 hunks)Plugins/Flow.Launcher.Plugin.ProcessKiller/Flow.Launcher.Plugin.ProcessKiller.csproj
(1 hunks)Plugins/Flow.Launcher.Plugin.ProcessKiller/ProcessHelper.cs
(1 hunks)Plugins/Flow.Launcher.Plugin.Program/Flow.Launcher.Plugin.Program.csproj
(1 hunks)Plugins/Flow.Launcher.Plugin.Program/Programs/ShellLocalization.cs
(1 hunks)Plugins/Flow.Launcher.Plugin.Sys/Flow.Launcher.Plugin.Sys.csproj
(1 hunks)
🧰 Additional context used
🧠 Learnings (18)
📓 Common learnings
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Plugins/Flow.Launcher.Plugin.BrowserBookmark/Flow.Launcher.Plugin.BrowserBookmark.csproj (5)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-08-31T20:42:08.482Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Plugins/Flow.Launcher.Plugin.ProcessKiller/Flow.Launcher.Plugin.ProcessKiller.csproj (5)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-08-31T20:42:08.482Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Plugins/Flow.Launcher.Plugin.Sys/Flow.Launcher.Plugin.Sys.csproj (5)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-08-31T20:42:08.482Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Plugins/Flow.Launcher.Plugin.Program/Flow.Launcher.Plugin.Program.csproj (5)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-08-31T20:42:08.482Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Plugins/Flow.Launcher.Plugin.Explorer/Flow.Launcher.Plugin.Explorer.csproj (5)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-08-31T20:42:08.482Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Flow.Launcher.Core/Flow.Launcher.Core.csproj (3)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3561
File: Flow.Launcher/ViewModel/SelectBrowserViewModel.cs:53-58
Timestamp: 2025-05-21T10:37:07.696Z
Learning: When implementing collection item removal operations in Flow Launcher, always handle index boundaries carefully. After removing an item from a collection, ensure the updated index remains within valid bounds (>= 0 and < collection.Count) to prevent IndexOutOfRangeExceptions, especially when decrementing indexes.
Flow.Launcher.Test/Flow.Launcher.Test.csproj (2)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj (5)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-08-31T20:42:08.482Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Plugins/Flow.Launcher.Plugin.Program/Programs/ShellLocalization.cs (2)
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: Yusyuriv
PR: Flow-Launcher/Flow.Launcher#3057
File: Flow.Launcher.Core/Plugin/JsonRPCPluginSettings.cs:0-0
Timestamp: 2024-11-03T07:40:11.014Z
Learning: In Flow Launcher, when using Windows Forms dialogs (e.g., in `JsonRPCPluginSettings.cs`), path validation is enabled by default in `OpenFileDialog` and `FolderBrowserDialog`, preventing users from selecting invalid paths, but it's possible to opt out of this validation on individual dialogs.
Flow.Launcher/Flow.Launcher.csproj (7)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3561
File: Flow.Launcher/ViewModel/SelectBrowserViewModel.cs:53-58
Timestamp: 2025-05-21T10:37:07.696Z
Learning: When implementing collection item removal operations in Flow Launcher, always handle index boundaries carefully. After removing an item from a collection, ensure the updated index remains within valid bounds (>= 0 and < collection.Count) to prevent IndexOutOfRangeExceptions, especially when decrementing indexes.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#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.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-08-31T20:42:08.482Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Flow.Launcher.Infrastructure/Flow.Launcher.Infrastructure.csproj (5)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-08-31T20:42:08.482Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Plugins/Flow.Launcher.Plugin.ProcessKiller/ProcessHelper.cs (4)
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#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.
Flow.Launcher.Plugin/packages.lock.json (5)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-08-31T20:42:08.482Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Flow.Launcher.Infrastructure/Win32Helper.cs (3)
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#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.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#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.
Flow.Launcher.Core/packages.lock.json (2)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Flow.Launcher.Infrastructure/packages.lock.json (5)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-08-31T20:42:08.482Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Flow.Launcher/packages.lock.json (4)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2442
File: Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj:4-4
Timestamp: 2024-08-31T20:42:08.482Z
Learning: In .NET 8, SourceLink is included by default, eliminating the need for the `Microsoft.SourceLink.GitHub` package.
🪛 GitHub Check: Check Spelling
Flow.Launcher.Core/packages.lock.json
[warning] 177-177:
Newtonsoft
is not a recognized word. (unrecognized-spelling)
[warning] 234-234:
NLog
is not a recognized word. (unrecognized-spelling)
⏰ 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). (2)
- GitHub Check: gitStream.cm
- GitHub Check: build
🔇 Additional comments (35)
Flow.Launcher.Test/Flow.Launcher.Test.csproj (2)
51-51
: Moq 4.20.72 ships the SponsorLink telemetry analyzer – check legal / privacy policy
Starting from 4.20.0, Moq embeds SponsorLink which phones home during design-time builds. Some organisations forbid this.If this is a concern, pin to 4.18.4 or add
EnableSponsorLink="false"
viaDirectory.Build.props
.
53-57
: Confirm test-SDK / adapter compatibility
NUnit3TestAdapter 5.0.0 requires Microsoft.NET.Test.Sdk ≥ 17.6 – your bump to 17.14.1 satisfies that. Just ensure your CI/IDE uses VS 2022 17.9+ or the .NET 8/9 CLI so that discovery works.Plugins/Flow.Launcher.Plugin.BrowserBookmark/Flow.Launcher.Plugin.BrowserBookmark.csproj (1)
97-100
: No stale Sqlite references found—but please verify lock-file syncA repository-wide scan returned zero occurrences of
Version="9.0.3"
. However, none of the existingpackages.lock.json
files list either Microsoft.Data.Sqlite or SQLitePCLRaw.bundle_e_sqlite3, so it’s unclear whether the BrowserBookmark plugin’s lock-file (if enabled) has been regenerated.Please manually ensure:
- A
packages.lock.json
exists next toPlugins/Flow.Launcher.Plugin.BrowserBookmark/Flow.Launcher.Plugin.BrowserBookmark.csproj
.- It has been updated to include Microsoft.Data.Sqlite v 9.0.7 and SQLitePCLRaw.bundle_e_sqlite3 ≥ 2.2.1.
- No other project in the solution remains locked at v 9.0.3.
Plugins/Flow.Launcher.Plugin.ProcessKiller/Flow.Launcher.Plugin.ProcessKiller.csproj (1)
55-58
: CsWin32 0.3.183 ⇒ regenerateNativeMethods
or expect build-warnings0.3.183 ships new generators (VS 17.10) and emits
[GeneratedComInterface]
attributes.
Rundotnet build /t:Generate
(or just deleteGeneratedInterop.cs
so the source-generator reruns) before committing; otherwise stale interop code may linger and silently reference removed APIs.No action in code needed if you already did this; just flagging the gotcha.
Plugins/Flow.Launcher.Plugin.Sys/Flow.Launcher.Plugin.Sys.csproj (1)
62-65
: Keep CsWin32 package assets private in every consumerGood to see
PrivateAssets=all
retained – this prevents the transitive flood of thousands of Win32 projection types into plugin consumers.
No further concerns. 👍Flow.Launcher.Core/Flow.Launcher.Core.csproj (1)
58-64
: Large jump on core libs – run full regression & update binding redirectsMultiple foundational libs jumped patch/feature versions (FSharp.Core, StreamJsonRpc, Win32.Jobs).
Nothing obviously breaking, but these are deep in the call stack:• StreamJsonRpc 2.22 introduces new default timeouts.
• FSharp.Core 9.0.300 bumps language version baseline.Please schedule a smoke test covering plugin RPC traffic and F# helper utilities, and confirm that any explicit assembly binding redirects (app.config) are removed – .NET ≥ 8 doesn’t respect them for self-contained exe’s anyway.
Plugins/Flow.Launcher.Plugin.Explorer/Flow.Launcher.Plugin.Explorer.csproj (1)
50-51
: LGTM! Standard dependency upgrades.The package version upgrades for
System.Data.OleDb
(9.0.3 → 9.0.7) andSystem.Linq.Async
(6.0.1 → 6.0.3) are appropriate minor version bumps that likely include bug fixes and improvements.Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj (1)
71-71
: LGTM! Appropriate dependency upgrades.The version upgrades for
Fody
(6.5.5 → 6.9.2),Microsoft.Windows.CsWin32
(0.3.106 → 0.3.183), andPropertyChanged.Fody
(3.4.0 → 4.1.0) are reasonable updates that should provide bug fixes and improvements.Also applies to: 77-77, 81-81
Flow.Launcher.Infrastructure/Flow.Launcher.Infrastructure.csproj (1)
57-57
: LGTM! Comprehensive dependency upgrades.All package version upgrades are appropriate:
BitFaster.Caching
(2.5.3 → 2.5.4)Fody
(6.5.5 → 6.9.2)Microsoft.VisualStudio.Threading
(17.12.19 → 17.14.15)Microsoft.Windows.CsWin32
(0.3.106 → 0.3.183)PropertyChanged.Fody
(3.4.0 → 4.1.0)System.Drawing.Common
(7.0.0 → 9.0.7)These updates should provide bug fixes and improvements while maintaining compatibility.
Also applies to: 59-59, 64-64, 65-65, 70-70, 74-74
Flow.Launcher/Flow.Launcher.csproj (3)
99-100
: Verify compatibility with Microsoft.Extensions major version upgrade.The upgrade from Microsoft.Extensions 7.x to 9.0.7 is a major version jump that may introduce breaking changes. Ensure thorough testing of dependency injection and hosting functionality.
102-104
: Potential concern with ModernWpfUI v0.9.5 upgrade.The existing comment indicates that ModernWpfUI v0.9.5 introduced WinRT changes causing "Notification platform unavailable" errors on some machines. Upgrading to this version may reintroduce those issues.
Verify that the notification platform issues mentioned in the comment have been resolved or that the upgrade is intentional despite the known issues.
89-89
: LGTM! Standard dependency upgrades.The version upgrades for
Fody
(6.5.5 → 6.9.2),PropertyChanged.Fody
(3.4.0 → 4.1.0),TaskScheduler
(2.12.1 → 2.12.2), andVirtualizingWrapPanel
(2.1.1 → 2.3.0) are reasonable updates.Also applies to: 106-106, 110-111
Plugins/Flow.Launcher.Plugin.ProcessKiller/ProcessHelper.cs (2)
166-166
: LGTM! Correct handle comparison for CSWin32 upgrade.The change from
IntPtr.Zero
toHWND.Null
is the correct way to check for invalid handles with the upgraded CSWin32 package.
171-179
: LGTM! Improved code simplicity and type safety.The changes enhance the method:
- Explicit cast to
nint
provides better type safety- Simplified logic with direct buffer usage and single return path
- Proper error handling with immediate empty string return on failure
These changes align well with the CSWin32 package upgrade and improve code clarity.
Plugins/Flow.Launcher.Plugin.Program/Programs/ShellLocalization.cs (3)
22-22
: LGTM: Unsafe modifier correctly added for pointer operations.The
unsafe
modifier is properly added to enable the use of fixed pointers required by the updated CsWin32 package.
30-44
: LGTM: Proper pointer handling for Windows API calls.The changes correctly implement pointer handling for the upgraded CsWin32 package:
id
parameter is properly declared asint
and passed by pointer- Fixed pointers are used for string parameters in API calls
- Type safety is improved with explicit pointer usage
The logic and error handling remain unchanged, which is appropriate.
54-54
: LGTM: Buffer parameter adjustment for LoadString.The change to pass the buffer directly rather than as a pointer aligns with the updated API signature from the CsWin32 package upgrade.
Flow.Launcher.Infrastructure/Win32Helper.cs (3)
121-124
: LGTM: Proper type safety improvements for Windows API.The changes correctly implement:
unsafe
modifier for pointer operations- Explicit cast to
nint
for improved type safety- Alignment with the updated CsWin32 package API
The method logic remains unchanged, which is appropriate.
282-282
: LGTM: Improved null handle comparison.The change from comparing
hWndDesktop.Value
againstIntPtr.Zero
to directly comparinghWndDesktop
againstHWND.Null
is more idiomatic and type-safe with the updated CsWin32 package.
483-495
: LGTM: Proper parameter wrapping for PostMessage API.The changes correctly implement:
unsafe
modifier for the method- Proper wrapping of
_previousLayout.Value
inLPARAM
constructor- Type safety improvements with explicit casting
The method logic and functionality remain unchanged.
Flow.Launcher.Plugin/packages.lock.json (4)
7-9
: LGTM: Fody package upgrade.The upgrade from 6.5.4 to 6.9.2 brings the latest bug fixes and improvements.
19-25
: LGTM: Microsoft.SourceLink.GitHub upgrade.The upgrade from 1.1.1 to 8.0.0 along with its dependencies aligns with modern .NET tooling improvements.
29-36
: LGTM: Microsoft.Windows.CsWin32 upgrade.The upgrade from 0.3.106 to 0.3.183 includes the necessary metadata package updates and is consistent with the unsafe code changes in the source files.
40-45
: LGTM: PropertyChanged.Fody upgrade.The upgrade from 3.4.0 to 4.1.0 with updated Fody dependency maintains compatibility and brings improvements.
Flow.Launcher.Core/packages.lock.json (4)
16-18
: LGTM: F# Core upgrade.The upgrade from an earlier version to 9.0.300 brings the latest F# runtime improvements.
32-37
: LGTM: Addition of SemanticVersioning package.The new direct dependency on SemanticVersioning 3.0.0 suggests improved version handling capabilities.
51-62
: LGTM: StreamJsonRpc and related dependencies upgrade.The comprehensive upgrade of StreamJsonRpc to 2.22.11 along with its dependencies (MessagePack, Microsoft.VisualStudio.Threading, Nerdbank.Streams, Newtonsoft.Json) ensures compatibility and brings performance improvements.
187-191
: LGTM: Addition of SharpVectors.Wpf dependency.The addition of SharpVectors.Wpf 1.8.4.2 as a transitive dependency suggests enhanced SVG rendering capabilities.
Flow.Launcher.Infrastructure/packages.lock.json (6)
16-18
: LGTM: BitFaster.Caching upgrade.The upgrade from 2.5.3 to 2.5.4 brings the latest caching improvements.
28-30
: LGTM: Fody upgrade.The upgrade to 6.9.2 is consistent across all projects and brings the latest IL weaving improvements.
34-40
: LGTM: MemoryPack upgrade.The upgrade from 1.21.3 to 1.21.4 across core and generator packages ensures consistency and brings bug fixes.
44-52
: LGTM: Microsoft.VisualStudio.Threading upgrade.The comprehensive upgrade to 17.14.15 with the addition of Microsoft.VisualStudio.Threading.Only provides enhanced threading capabilities.
55-62
: LGTM: Microsoft.Windows.CsWin32 upgrade.The upgrade to 0.3.183 is consistent with the unsafe code changes and brings improved Windows API interop.
79-84
: LGTM: SharpVectors.Wpf addition.The addition of SharpVectors.Wpf 1.8.4.2 as a direct dependency enhances SVG rendering capabilities in the WPF infrastructure.
Flow.Launcher/packages.lock.json (1)
78-115
: Verify all projects target .NET 8+ before merging
I wasn’t able to confirm via automation that no.csproj
is still targeting net6.0 or net7.0. Please manually ensure every project has been bumped to net8.0 (or higher) to avoid CI breaks with Microsoft.Extensions 9.x.You can re-run these checks locally:
# Single-target projects rg --glob '*.csproj' -n '<TargetFramework>net[0-7]\.0' # Multi-target projects rg --glob '*.csproj' -n '<TargetFrameworks>.*net[0-7]\.0'If any hits appear, upgrade those TFMs or revert the 9.x package bump.
Plugins/Flow.Launcher.Plugin.Program/Flow.Launcher.Plugin.Program.csproj
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
🧹 Nitpick comments (3)
Flow.Launcher.Core/packages.lock.json (3)
131-138
: Threading libs 17.14.x – enable analyzers cautiously
Microsoft.VisualStudio.Threading.Analyzers
can surface hundreds of new warnings. Consider adding<AnalysisLevel>latest</AnalysisLevel>
tweaks or baseline suppression before turning CI red.
207-211
: System.Drawing.Common preview 9.0.7This is Windows-only. Confirm no cross-platform plugins use it; otherwise guard with
SupportedOSPlatform
attributes.
237-246
: Project dependency ranges left open-endedUsing
[x.y.z, )
turns everydotnet restore
with--no-lock
into an uncontrolled upgrade. Pinning exact versions in the csproj keeps reproducibility and reduces diff noise.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
Flow.Launcher.Core/packages.lock.json
(8 hunks)Flow.Launcher.Infrastructure/Flow.Launcher.Infrastructure.csproj
(2 hunks)Flow.Launcher.Infrastructure/packages.lock.json
(6 hunks)Flow.Launcher/packages.lock.json
(16 hunks)
✅ Files skipped from review due to trivial changes (2)
- Flow.Launcher.Infrastructure/packages.lock.json
- Flow.Launcher/packages.lock.json
🚧 Files skipped from review as they are similar to previous changes (1)
- Flow.Launcher.Infrastructure/Flow.Launcher.Infrastructure.csproj
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Flow.Launcher.Core/packages.lock.json (2)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
🪛 GitHub Check: Check Spelling
Flow.Launcher.Core/packages.lock.json
[warning] 192-192:
NLog
is not a recognized word. (unrecognized-spelling)
[warning] 187-187:
NLog
is not a recognized word. (unrecognized-spelling)
[warning] 182-182:
NLog
is not a recognized word. (unrecognized-spelling)
[warning] 177-177:
Newtonsoft
is not a recognized word. (unrecognized-spelling)
⏰ 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: gitStream.cm
🔇 Additional comments (14)
Flow.Launcher.Core/packages.lock.json (14)
16-19
: Confirm .NET 9-preview compatibility for FSharp.Core 9.0.300
9.0.300
targets the .NET 9 preview SDK. If CI/CD is still using an earlier SDK preview, restore will fail.
Make sure all build agents have matching preview bits or pin the project’sglobal.json
to the expected SDK version.
22-25
: LGTM – routine patch bump of Meziantou.Framework.Win32.Jobs
No breaking-change notes in the upstream changelog between 3.4.0 → 3.4.3.
32-37
: New direct dependencySemanticVersioning
– double-check license & necessityBefore merging, validate:
- License (MIT) is compatible with Flow Launcher’s distribution.
- The new DLL is actually referenced – accidental transient promotion can be removed from .csproj to keep the surface minimal.
51-60
: Mixed minor versions for Microsoft.VisualStudio.Threading.Only
StreamJsonRpc
lists17.13.61
, while the lock file resolves17.14.15
(lines 144-151). NuGet will unify to the higher version, which is fine, but please watch out for regressions – 17.14 introduced stricter analyzers that can break builds in “warnings-as-errors” pipelines.
72-75
: LGTM –BitFaster.Caching
2.5.4 brings only perf tweaks
No action required.
100-109
: Core / Generator versions kept in lock-step – good
112-118
: MessagePack runtime bumped to 2.5.192Heads-up: v2.5 drops implicit
EnumerableFormatter<T>
registration. If reflection-based resolvers are disabled, manualCompositeResolver.Register
is now required.
Confirm unit tests covering message-exchange still pass.
121-123
: Annotations package aligned – looks correct
140-151
: Version coherence verified – analyzers / only / runtime all on 17.14.15.
159-161
: SystemEvents 9.0.x is previewSame concern as FSharp.Core – ensure preview reference assemblies are present on build agents.
168-176
: Nerdbank.Streams 2.12.x bumps minimum .NET runtimeThis release removes netstandard2.0. Flow Launcher targets win7; verify runtime graph still selects a compatible TF.
187-194
: Addition ofNLog.OutputDebugString
– 👍 for easier debugging
No issues.
195-199
: SharpVectors.Wpf 1.8.4.2 – verify DPI scaling regression fixEarlier minor introduced a scaling regression on per-monitor DPI. Ensure SVG rendering tests on multi-DPI setups.
252-253
: JetBrains.Annotations 2024.3.0 – good to stay current
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
♻️ Duplicate comments (3)
Flow.Launcher.Core/packages.lock.json (3)
182-186
: Newtonsoft.Json 13.0.3 vulnerability reminder (same as prior review)Version 13.0.3 carries a moderate CVE; see earlier comment. Consider moving to 13.0.4-preview or a patched release.
96-108
: MemoryPack 1.21.x serializer format change (already flagged earlier)Persisted blobs written with < 1.20 will not round-trip. Ensure all plugins are rebuilt or supply a migration layer.
200-208
: NLog 6.0.1 default MaxArchiveFiles change (previously noted)If unlimited archives were expected, explicitly set
MaxArchiveFiles
in config.
🧹 Nitpick comments (1)
Flow.Launcher.Core/packages.lock.json (1)
149-156
: Two different Microsoft.VisualStudio.Threading. minor versions present*
StreamJsonRpc
pullsMicrosoft.VisualStudio.Threading.Only
17.13.61 while the top-level graph contains 17.14.15. Mixing patch versions usually works but can increase load time and package size. If possible, centralise to 17.14.15.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
Flow.Launcher.Core/packages.lock.json
(9 hunks)Flow.Launcher.Infrastructure/Flow.Launcher.Infrastructure.csproj
(1 hunks)Flow.Launcher.Infrastructure/Win32Helper.cs
(5 hunks)Flow.Launcher.Infrastructure/packages.lock.json
(6 hunks)Flow.Launcher/Flow.Launcher.csproj
(2 hunks)Flow.Launcher/packages.lock.json
(14 hunks)
✅ Files skipped from review due to trivial changes (2)
- Flow.Launcher.Infrastructure/Flow.Launcher.Infrastructure.csproj
- Flow.Launcher/packages.lock.json
🚧 Files skipped from review as they are similar to previous changes (3)
- Flow.Launcher/Flow.Launcher.csproj
- Flow.Launcher.Infrastructure/Win32Helper.cs
- Flow.Launcher.Infrastructure/packages.lock.json
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Flow.Launcher.Core/packages.lock.json (2)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
🪛 GitHub Check: Check Spelling
Flow.Launcher.Core/packages.lock.json
[warning] 197-197:
NHotkey
is not a recognized word. (unrecognized-spelling)
[warning] 192-192:
NHotkey
is not a recognized word. (unrecognized-spelling)
[warning] 182-182:
Newtonsoft
is not a recognized word. (unrecognized-spelling)
[warning] 261-261:
NHotkey
is not a recognized word. (unrecognized-spelling)
⏰ 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 (1)
Flow.Launcher.Core/packages.lock.json (1)
32-37
: MIT license confirmed for SemanticVersioning 3.0.0The package’s LICENSE file clearly uses the MIT license (permissive, compatible with Flow Launcher’s distribution). No further action is required here.
My concern is around memory usage with this PR, @Jack251970 thank you for testing it, please ensure there is a thorough confirmation on no memory impact. |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
Flow.Launcher.Infrastructure/MonitorInfo.cs
(6 hunks)Flow.Launcher.Infrastructure/NativeMethods.txt
(2 hunks)Flow.Launcher.Infrastructure/Win32Helper.cs
(5 hunks)Flow.Launcher/MainWindow.xaml.cs
(3 hunks)Flow.Launcher/Msg.xaml.cs
(1 hunks)Flow.Launcher/MsgWithButton.xaml.cs
(1 hunks)Flow.Launcher/SettingPages/ViewModels/SettingsPaneGeneralViewModel.cs
(2 hunks)Flow.Launcher/SettingWindow.xaml.cs
(3 hunks)
🧠 Learnings (6)
📓 Common learnings
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Flow.Launcher/Msg.xaml.cs (11)
Learnt from: Jack251970
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.
Learnt from: Jack251970
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.
Learnt from: Jack251970
PR: #3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: Yusyuriv
PR: #3057
File: Flow.Launcher.Core/Plugin/JsonRPCPluginSettings.cs:0-0
Timestamp: 2024-11-03T07:40:11.014Z
Learning: In Flow Launcher, when using Windows Forms dialogs (e.g., in JsonRPCPluginSettings.cs
), path validation is enabled by default in OpenFileDialog
and FolderBrowserDialog
, preventing users from selecting invalid paths, but it's possible to opt out of this validation on individual dialogs.
Learnt from: taooceros
PR: #2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the Flow.Launcher.csproj
file is dynamically updated during the CI/CD process.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:20:54.978Z
Learning: In WPF applications like Flow.Launcher, Border elements cannot directly display text content and require a child element like TextBlock to handle text rendering. This separation of concerns (Border for visual container styling, TextBlock for text display) follows WPF best practices and provides greater styling flexibility.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:20:54.978Z
Learning: In WPF applications like Flow.Launcher, Border elements cannot directly display text content and require a child element like TextBlock to handle text rendering. This separation of concerns (Border for visual container styling, TextBlock for text display) follows WPF best practices and provides greater styling flexibility.
Learnt from: Jack251970
PR: #3854
File: Flow.Launcher/App.xaml.cs:246-262
Timestamp: 2025-07-21T09:19:49.684Z
Learning: In Flow Launcher's App.xaml.cs, the asynchronous plugin initialization task (containing AbstractPluginEnvironment.PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, and AutoPluginUpdates) does not require additional try-catch error handling according to maintainer Jack251970, as these operations are designed to handle exceptions internally.
Learnt from: onesounds
PR: Flow-Launcher/Flow.Launcher#0
File: :0-0
Timestamp: 2025-04-23T15:14:49.986Z
Learning: In WPF applications like Flow.Launcher, font styling should be applied using implicit styles instead of setting the FontFamily property on individual controls. Define implicit styles in a ResourceDictionary using <Style TargetType="{x:Type Button}"> format and merge it into App.xaml, which automatically applies the font to all instances of the control type while still allowing explicit overrides where needed.
Learnt from: Jack251970
PR: #3279
File: Flow.Launcher/Helper/WallpaperPathRetrieval.cs:44-46
Timestamp: 2025-02-28T07:47:24.148Z
Learning: In Flow.Launcher's WallpaperPathRetrieval class, using a using
statement with MemoryStream when loading images with BitmapImage does not work properly, even when using BitmapCacheOption.OnLoad. The stream needs to remain open while the bitmap is in use.
Learnt from: Jack251970
PR: #3561
File: Flow.Launcher/ViewModel/SelectBrowserViewModel.cs:53-58
Timestamp: 2025-05-21T10:37:07.696Z
Learning: When implementing collection item removal operations in Flow Launcher, always handle index boundaries carefully. After removing an item from a collection, ensure the updated index remains within valid bounds (>= 0 and < collection.Count) to prevent IndexOutOfRangeExceptions, especially when decrementing indexes.
Flow.Launcher/SettingWindow.xaml.cs (11)
Learnt from: Jack251970
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.
Learnt from: Jack251970
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.
Learnt from: Jack251970
PR: #3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: Yusyuriv
PR: #3057
File: Flow.Launcher.Core/Plugin/JsonRPCPluginSettings.cs:0-0
Timestamp: 2024-11-03T07:40:11.014Z
Learning: In Flow Launcher, when using Windows Forms dialogs (e.g., in JsonRPCPluginSettings.cs
), path validation is enabled by default in OpenFileDialog
and FolderBrowserDialog
, preventing users from selecting invalid paths, but it's possible to opt out of this validation on individual dialogs.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:20:54.978Z
Learning: In WPF applications like Flow.Launcher, Border elements cannot directly display text content and require a child element like TextBlock to handle text rendering. This separation of concerns (Border for visual container styling, TextBlock for text display) follows WPF best practices and provides greater styling flexibility.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:20:54.978Z
Learning: In WPF applications like Flow.Launcher, Border elements cannot directly display text content and require a child element like TextBlock to handle text rendering. This separation of concerns (Border for visual container styling, TextBlock for text display) follows WPF best practices and provides greater styling flexibility.
Learnt from: onesounds
PR: Flow-Launcher/Flow.Launcher#0
File: :0-0
Timestamp: 2025-04-23T15:14:49.986Z
Learning: In WPF applications like Flow.Launcher, font styling should be applied using implicit styles instead of setting the FontFamily property on individual controls. Define implicit styles in a ResourceDictionary using <Style TargetType="{x:Type Button}"> format and merge it into App.xaml, which automatically applies the font to all instances of the control type while still allowing explicit overrides where needed.
Learnt from: Jack251970
PR: #3854
File: Flow.Launcher/App.xaml.cs:246-262
Timestamp: 2025-07-21T09:19:49.684Z
Learning: In Flow Launcher's App.xaml.cs, the asynchronous plugin initialization task (containing AbstractPluginEnvironment.PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, and AutoPluginUpdates) does not require additional try-catch error handling according to maintainer Jack251970, as these operations are designed to handle exceptions internally.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:12:13.386Z
Learning: In Flow.Launcher, hotkey styling is implemented with a two-component structure: a Border element with style ItemHotkeyBGStyle
that provides background and border styling, containing a TextBlock with style ItemHotkeyStyle
that handles the text styling.
Learnt from: Jack251970
PR: #3279
File: Flow.Launcher/Helper/WallpaperPathRetrieval.cs:44-46
Timestamp: 2025-02-28T07:47:24.148Z
Learning: In Flow.Launcher's WallpaperPathRetrieval class, using a using
statement with MemoryStream when loading images with BitmapImage does not work properly, even when using BitmapCacheOption.OnLoad. The stream needs to remain open while the bitmap is in use.
Learnt from: Jack251970
PR: #3573
File: Plugins/Flow.Launcher.Plugin.Explorer/ViewModels/SettingsViewModel.cs:491-493
Timestamp: 2025-06-18T13:55:09.190Z
Learning: When opening Windows settings (like indexing options), de-elevation is not needed since these operations cannot bring security risks, even when Flow Launcher is running as administrator.
Flow.Launcher/MsgWithButton.xaml.cs (12)
Learnt from: Jack251970
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.
Learnt from: Jack251970
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.
Learnt from: onesounds
PR: Flow-Launcher/Flow.Launcher#0
File: :0-0
Timestamp: 2025-04-23T15:14:49.986Z
Learning: In WPF applications like Flow.Launcher, font styling should be applied using implicit styles instead of setting the FontFamily property on individual controls. Define implicit styles in a ResourceDictionary using <Style TargetType="{x:Type Button}"> format and merge it into App.xaml, which automatically applies the font to all instances of the control type while still allowing explicit overrides where needed.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:20:54.978Z
Learning: In WPF applications like Flow.Launcher, Border elements cannot directly display text content and require a child element like TextBlock to handle text rendering. This separation of concerns (Border for visual container styling, TextBlock for text display) follows WPF best practices and provides greater styling flexibility.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:20:54.978Z
Learning: In WPF applications like Flow.Launcher, Border elements cannot directly display text content and require a child element like TextBlock to handle text rendering. This separation of concerns (Border for visual container styling, TextBlock for text display) follows WPF best practices and provides greater styling flexibility.
Learnt from: taooceros
PR: #2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the Flow.Launcher.csproj
file is dynamically updated during the CI/CD process.
Learnt from: Yusyuriv
PR: #3057
File: Flow.Launcher.Core/Plugin/JsonRPCPluginSettings.cs:0-0
Timestamp: 2024-11-03T07:40:11.014Z
Learning: In Flow Launcher, when using Windows Forms dialogs (e.g., in JsonRPCPluginSettings.cs
), path validation is enabled by default in OpenFileDialog
and FolderBrowserDialog
, preventing users from selecting invalid paths, but it's possible to opt out of this validation on individual dialogs.
Learnt from: Jack251970
PR: #3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:12:13.386Z
Learning: In Flow.Launcher, hotkey styling is implemented with a two-component structure: a Border element with style ItemHotkeyBGStyle
that provides background and border styling, containing a TextBlock with style ItemHotkeyStyle
that handles the text styling.
Learnt from: Jack251970
PR: #3854
File: Flow.Launcher/App.xaml.cs:246-262
Timestamp: 2025-07-21T09:19:49.684Z
Learning: In Flow Launcher's App.xaml.cs, the asynchronous plugin initialization task (containing AbstractPluginEnvironment.PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, and AutoPluginUpdates) does not require additional try-catch error handling according to maintainer Jack251970, as these operations are designed to handle exceptions internally.
Learnt from: Jack251970
PR: #3279
File: Flow.Launcher/Helper/WallpaperPathRetrieval.cs:44-46
Timestamp: 2025-02-28T07:47:24.148Z
Learning: In Flow.Launcher's WallpaperPathRetrieval class, using a using
statement with MemoryStream when loading images with BitmapImage does not work properly, even when using BitmapCacheOption.OnLoad. The stream needs to remain open while the bitmap is in use.
Learnt from: Jack251970
PR: #3561
File: Flow.Launcher/ViewModel/SelectBrowserViewModel.cs:53-58
Timestamp: 2025-05-21T10:37:07.696Z
Learning: When implementing collection item removal operations in Flow Launcher, always handle index boundaries carefully. After removing an item from a collection, ensure the updated index remains within valid bounds (>= 0 and < collection.Count) to prevent IndexOutOfRangeExceptions, especially when decrementing indexes.
Flow.Launcher/MainWindow.xaml.cs (9)
Learnt from: Jack251970
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.
Learnt from: Jack251970
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.
Learnt from: Jack251970
PR: #3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:12:13.386Z
Learning: In Flow.Launcher, hotkey styling is implemented with a two-component structure: a Border element with style ItemHotkeyBGStyle
that provides background and border styling, containing a TextBlock with style ItemHotkeyStyle
that handles the text styling.
Learnt from: onesounds
PR: Flow-Launcher/Flow.Launcher#0
File: :0-0
Timestamp: 2025-04-23T15:14:49.986Z
Learning: In WPF applications like Flow.Launcher, font styling should be applied using implicit styles instead of setting the FontFamily property on individual controls. Define implicit styles in a ResourceDictionary using <Style TargetType="{x:Type Button}"> format and merge it into App.xaml, which automatically applies the font to all instances of the control type while still allowing explicit overrides where needed.
Learnt from: Yusyuriv
PR: #3057
File: Flow.Launcher.Core/Plugin/JsonRPCPluginSettings.cs:0-0
Timestamp: 2024-11-03T07:40:11.014Z
Learning: In Flow Launcher, when using Windows Forms dialogs (e.g., in JsonRPCPluginSettings.cs
), path validation is enabled by default in OpenFileDialog
and FolderBrowserDialog
, preventing users from selecting invalid paths, but it's possible to opt out of this validation on individual dialogs.
Learnt from: Jack251970
PR: #3854
File: Flow.Launcher/App.xaml.cs:246-262
Timestamp: 2025-07-21T09:19:49.684Z
Learning: In Flow Launcher's App.xaml.cs, the asynchronous plugin initialization task (containing AbstractPluginEnvironment.PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, and AutoPluginUpdates) does not require additional try-catch error handling according to maintainer Jack251970, as these operations are designed to handle exceptions internally.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:20:54.978Z
Learning: In WPF applications like Flow.Launcher, Border elements cannot directly display text content and require a child element like TextBlock to handle text rendering. This separation of concerns (Border for visual container styling, TextBlock for text display) follows WPF best practices and provides greater styling flexibility.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:20:54.978Z
Learning: In WPF applications like Flow.Launcher, Border elements cannot directly display text content and require a child element like TextBlock to handle text rendering. This separation of concerns (Border for visual container styling, TextBlock for text display) follows WPF best practices and provides greater styling flexibility.
Flow.Launcher.Infrastructure/MonitorInfo.cs (3)
Learnt from: Jack251970
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.
Learnt from: Jack251970
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.
Learnt from: Jack251970
PR: #3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
🧬 Code Graph Analysis (3)
Flow.Launcher/Msg.xaml.cs (2)
Flow.Launcher.Infrastructure/MonitorInfo.cs (5)
MonitorInfo
(19-184)MonitorInfo
(49-70)MonitorInfo
(76-97)MonitorInfo
(103-128)MonitorInfo
(132-144)Flow.Launcher/MainWindow.xaml.cs (1)
MonitorInfo
(956-983)
Flow.Launcher/SettingWindow.xaml.cs (2)
Flow.Launcher.Infrastructure/MonitorInfo.cs (5)
MonitorInfo
(19-184)MonitorInfo
(49-70)MonitorInfo
(76-97)MonitorInfo
(103-128)MonitorInfo
(132-144)Flow.Launcher/MainWindow.xaml.cs (1)
MonitorInfo
(956-983)
Flow.Launcher/MsgWithButton.xaml.cs (1)
Flow.Launcher/MainWindow.xaml.cs (1)
MonitorInfo
(956-983)
🪛 GitHub Check: Check Spelling
Flow.Launcher.Infrastructure/MonitorInfo.cs
[failure] 168-168:
the the
matches a line_forbidden.patterns entry: \s([A-Z]{3,}|[A-Z][a-z]{2,}|[a-z]{3,})\s\g{-1}\s
. (forbidden-pattern)
🪛 GitHub Actions: Check Spelling
Flow.Launcher.Infrastructure/MonitorInfo.cs
[error] 168-168: Forbidden pattern detected: ' the the ' matches a line_forbidden.patterns entry. (forbidden-pattern)
✅ Files skipped from review due to trivial changes (1)
- Flow.Launcher.Infrastructure/NativeMethods.txt
🚧 Files skipped from review as they are similar to previous changes (1)
- Flow.Launcher.Infrastructure/Win32Helper.cs
🧰 Additional context used
🧠 Learnings (6)
📓 Common learnings
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Flow.Launcher/Msg.xaml.cs (11)
Learnt from: Jack251970
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.
Learnt from: Jack251970
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.
Learnt from: Jack251970
PR: #3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: Yusyuriv
PR: #3057
File: Flow.Launcher.Core/Plugin/JsonRPCPluginSettings.cs:0-0
Timestamp: 2024-11-03T07:40:11.014Z
Learning: In Flow Launcher, when using Windows Forms dialogs (e.g., in JsonRPCPluginSettings.cs
), path validation is enabled by default in OpenFileDialog
and FolderBrowserDialog
, preventing users from selecting invalid paths, but it's possible to opt out of this validation on individual dialogs.
Learnt from: taooceros
PR: #2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the Flow.Launcher.csproj
file is dynamically updated during the CI/CD process.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:20:54.978Z
Learning: In WPF applications like Flow.Launcher, Border elements cannot directly display text content and require a child element like TextBlock to handle text rendering. This separation of concerns (Border for visual container styling, TextBlock for text display) follows WPF best practices and provides greater styling flexibility.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:20:54.978Z
Learning: In WPF applications like Flow.Launcher, Border elements cannot directly display text content and require a child element like TextBlock to handle text rendering. This separation of concerns (Border for visual container styling, TextBlock for text display) follows WPF best practices and provides greater styling flexibility.
Learnt from: Jack251970
PR: #3854
File: Flow.Launcher/App.xaml.cs:246-262
Timestamp: 2025-07-21T09:19:49.684Z
Learning: In Flow Launcher's App.xaml.cs, the asynchronous plugin initialization task (containing AbstractPluginEnvironment.PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, and AutoPluginUpdates) does not require additional try-catch error handling according to maintainer Jack251970, as these operations are designed to handle exceptions internally.
Learnt from: onesounds
PR: Flow-Launcher/Flow.Launcher#0
File: :0-0
Timestamp: 2025-04-23T15:14:49.986Z
Learning: In WPF applications like Flow.Launcher, font styling should be applied using implicit styles instead of setting the FontFamily property on individual controls. Define implicit styles in a ResourceDictionary using <Style TargetType="{x:Type Button}"> format and merge it into App.xaml, which automatically applies the font to all instances of the control type while still allowing explicit overrides where needed.
Learnt from: Jack251970
PR: #3279
File: Flow.Launcher/Helper/WallpaperPathRetrieval.cs:44-46
Timestamp: 2025-02-28T07:47:24.148Z
Learning: In Flow.Launcher's WallpaperPathRetrieval class, using a using
statement with MemoryStream when loading images with BitmapImage does not work properly, even when using BitmapCacheOption.OnLoad. The stream needs to remain open while the bitmap is in use.
Learnt from: Jack251970
PR: #3561
File: Flow.Launcher/ViewModel/SelectBrowserViewModel.cs:53-58
Timestamp: 2025-05-21T10:37:07.696Z
Learning: When implementing collection item removal operations in Flow Launcher, always handle index boundaries carefully. After removing an item from a collection, ensure the updated index remains within valid bounds (>= 0 and < collection.Count) to prevent IndexOutOfRangeExceptions, especially when decrementing indexes.
Flow.Launcher/SettingWindow.xaml.cs (11)
Learnt from: Jack251970
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.
Learnt from: Jack251970
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.
Learnt from: Jack251970
PR: #3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: Yusyuriv
PR: #3057
File: Flow.Launcher.Core/Plugin/JsonRPCPluginSettings.cs:0-0
Timestamp: 2024-11-03T07:40:11.014Z
Learning: In Flow Launcher, when using Windows Forms dialogs (e.g., in JsonRPCPluginSettings.cs
), path validation is enabled by default in OpenFileDialog
and FolderBrowserDialog
, preventing users from selecting invalid paths, but it's possible to opt out of this validation on individual dialogs.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:20:54.978Z
Learning: In WPF applications like Flow.Launcher, Border elements cannot directly display text content and require a child element like TextBlock to handle text rendering. This separation of concerns (Border for visual container styling, TextBlock for text display) follows WPF best practices and provides greater styling flexibility.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:20:54.978Z
Learning: In WPF applications like Flow.Launcher, Border elements cannot directly display text content and require a child element like TextBlock to handle text rendering. This separation of concerns (Border for visual container styling, TextBlock for text display) follows WPF best practices and provides greater styling flexibility.
Learnt from: onesounds
PR: Flow-Launcher/Flow.Launcher#0
File: :0-0
Timestamp: 2025-04-23T15:14:49.986Z
Learning: In WPF applications like Flow.Launcher, font styling should be applied using implicit styles instead of setting the FontFamily property on individual controls. Define implicit styles in a ResourceDictionary using <Style TargetType="{x:Type Button}"> format and merge it into App.xaml, which automatically applies the font to all instances of the control type while still allowing explicit overrides where needed.
Learnt from: Jack251970
PR: #3854
File: Flow.Launcher/App.xaml.cs:246-262
Timestamp: 2025-07-21T09:19:49.684Z
Learning: In Flow Launcher's App.xaml.cs, the asynchronous plugin initialization task (containing AbstractPluginEnvironment.PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, and AutoPluginUpdates) does not require additional try-catch error handling according to maintainer Jack251970, as these operations are designed to handle exceptions internally.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:12:13.386Z
Learning: In Flow.Launcher, hotkey styling is implemented with a two-component structure: a Border element with style ItemHotkeyBGStyle
that provides background and border styling, containing a TextBlock with style ItemHotkeyStyle
that handles the text styling.
Learnt from: Jack251970
PR: #3279
File: Flow.Launcher/Helper/WallpaperPathRetrieval.cs:44-46
Timestamp: 2025-02-28T07:47:24.148Z
Learning: In Flow.Launcher's WallpaperPathRetrieval class, using a using
statement with MemoryStream when loading images with BitmapImage does not work properly, even when using BitmapCacheOption.OnLoad. The stream needs to remain open while the bitmap is in use.
Learnt from: Jack251970
PR: #3573
File: Plugins/Flow.Launcher.Plugin.Explorer/ViewModels/SettingsViewModel.cs:491-493
Timestamp: 2025-06-18T13:55:09.190Z
Learning: When opening Windows settings (like indexing options), de-elevation is not needed since these operations cannot bring security risks, even when Flow Launcher is running as administrator.
Flow.Launcher/MsgWithButton.xaml.cs (12)
Learnt from: Jack251970
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.
Learnt from: Jack251970
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.
Learnt from: onesounds
PR: Flow-Launcher/Flow.Launcher#0
File: :0-0
Timestamp: 2025-04-23T15:14:49.986Z
Learning: In WPF applications like Flow.Launcher, font styling should be applied using implicit styles instead of setting the FontFamily property on individual controls. Define implicit styles in a ResourceDictionary using <Style TargetType="{x:Type Button}"> format and merge it into App.xaml, which automatically applies the font to all instances of the control type while still allowing explicit overrides where needed.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:20:54.978Z
Learning: In WPF applications like Flow.Launcher, Border elements cannot directly display text content and require a child element like TextBlock to handle text rendering. This separation of concerns (Border for visual container styling, TextBlock for text display) follows WPF best practices and provides greater styling flexibility.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:20:54.978Z
Learning: In WPF applications like Flow.Launcher, Border elements cannot directly display text content and require a child element like TextBlock to handle text rendering. This separation of concerns (Border for visual container styling, TextBlock for text display) follows WPF best practices and provides greater styling flexibility.
Learnt from: taooceros
PR: #2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the Flow.Launcher.csproj
file is dynamically updated during the CI/CD process.
Learnt from: Yusyuriv
PR: #3057
File: Flow.Launcher.Core/Plugin/JsonRPCPluginSettings.cs:0-0
Timestamp: 2024-11-03T07:40:11.014Z
Learning: In Flow Launcher, when using Windows Forms dialogs (e.g., in JsonRPCPluginSettings.cs
), path validation is enabled by default in OpenFileDialog
and FolderBrowserDialog
, preventing users from selecting invalid paths, but it's possible to opt out of this validation on individual dialogs.
Learnt from: Jack251970
PR: #3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:12:13.386Z
Learning: In Flow.Launcher, hotkey styling is implemented with a two-component structure: a Border element with style ItemHotkeyBGStyle
that provides background and border styling, containing a TextBlock with style ItemHotkeyStyle
that handles the text styling.
Learnt from: Jack251970
PR: #3854
File: Flow.Launcher/App.xaml.cs:246-262
Timestamp: 2025-07-21T09:19:49.684Z
Learning: In Flow Launcher's App.xaml.cs, the asynchronous plugin initialization task (containing AbstractPluginEnvironment.PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, and AutoPluginUpdates) does not require additional try-catch error handling according to maintainer Jack251970, as these operations are designed to handle exceptions internally.
Learnt from: Jack251970
PR: #3279
File: Flow.Launcher/Helper/WallpaperPathRetrieval.cs:44-46
Timestamp: 2025-02-28T07:47:24.148Z
Learning: In Flow.Launcher's WallpaperPathRetrieval class, using a using
statement with MemoryStream when loading images with BitmapImage does not work properly, even when using BitmapCacheOption.OnLoad. The stream needs to remain open while the bitmap is in use.
Learnt from: Jack251970
PR: #3561
File: Flow.Launcher/ViewModel/SelectBrowserViewModel.cs:53-58
Timestamp: 2025-05-21T10:37:07.696Z
Learning: When implementing collection item removal operations in Flow Launcher, always handle index boundaries carefully. After removing an item from a collection, ensure the updated index remains within valid bounds (>= 0 and < collection.Count) to prevent IndexOutOfRangeExceptions, especially when decrementing indexes.
Flow.Launcher/MainWindow.xaml.cs (9)
Learnt from: Jack251970
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.
Learnt from: Jack251970
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.
Learnt from: Jack251970
PR: #3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:12:13.386Z
Learning: In Flow.Launcher, hotkey styling is implemented with a two-component structure: a Border element with style ItemHotkeyBGStyle
that provides background and border styling, containing a TextBlock with style ItemHotkeyStyle
that handles the text styling.
Learnt from: onesounds
PR: Flow-Launcher/Flow.Launcher#0
File: :0-0
Timestamp: 2025-04-23T15:14:49.986Z
Learning: In WPF applications like Flow.Launcher, font styling should be applied using implicit styles instead of setting the FontFamily property on individual controls. Define implicit styles in a ResourceDictionary using <Style TargetType="{x:Type Button}"> format and merge it into App.xaml, which automatically applies the font to all instances of the control type while still allowing explicit overrides where needed.
Learnt from: Yusyuriv
PR: #3057
File: Flow.Launcher.Core/Plugin/JsonRPCPluginSettings.cs:0-0
Timestamp: 2024-11-03T07:40:11.014Z
Learning: In Flow Launcher, when using Windows Forms dialogs (e.g., in JsonRPCPluginSettings.cs
), path validation is enabled by default in OpenFileDialog
and FolderBrowserDialog
, preventing users from selecting invalid paths, but it's possible to opt out of this validation on individual dialogs.
Learnt from: Jack251970
PR: #3854
File: Flow.Launcher/App.xaml.cs:246-262
Timestamp: 2025-07-21T09:19:49.684Z
Learning: In Flow Launcher's App.xaml.cs, the asynchronous plugin initialization task (containing AbstractPluginEnvironment.PreStartPluginExecutablePathUpdate, PluginManager.LoadPlugins, PluginManager.InitializePluginsAsync, and AutoPluginUpdates) does not require additional try-catch error handling according to maintainer Jack251970, as these operations are designed to handle exceptions internally.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:20:54.978Z
Learning: In WPF applications like Flow.Launcher, Border elements cannot directly display text content and require a child element like TextBlock to handle text rendering. This separation of concerns (Border for visual container styling, TextBlock for text display) follows WPF best practices and provides greater styling flexibility.
Learnt from: onesounds
PR: #3394
File: Flow.Launcher/Themes/Darker Glass.xaml:134-141
Timestamp: 2025-03-28T21:20:54.978Z
Learning: In WPF applications like Flow.Launcher, Border elements cannot directly display text content and require a child element like TextBlock to handle text rendering. This separation of concerns (Border for visual container styling, TextBlock for text display) follows WPF best practices and provides greater styling flexibility.
Flow.Launcher.Infrastructure/MonitorInfo.cs (3)
Learnt from: Jack251970
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.
Learnt from: Jack251970
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.
Learnt from: Jack251970
PR: #3791
File: Flow.Launcher.Core/Plugin/PluginManager.cs:293-295
Timestamp: 2025-07-01T05:46:13.251Z
Learning: In Flow.Launcher.Core/Plugin/PluginManager.cs, when checking if a plugin is modified within the PluginManager class itself, prefer using the internal static PluginModified(string id) method directly rather than going through API.PluginModified() for better performance and architectural design.
🧬 Code Graph Analysis (3)
Flow.Launcher/Msg.xaml.cs (2)
Flow.Launcher.Infrastructure/MonitorInfo.cs (5)
MonitorInfo
(19-184)MonitorInfo
(49-70)MonitorInfo
(76-97)MonitorInfo
(103-128)MonitorInfo
(132-144)Flow.Launcher/MainWindow.xaml.cs (1)
MonitorInfo
(956-983)
Flow.Launcher/SettingWindow.xaml.cs (2)
Flow.Launcher.Infrastructure/MonitorInfo.cs (5)
MonitorInfo
(19-184)MonitorInfo
(49-70)MonitorInfo
(76-97)MonitorInfo
(103-128)MonitorInfo
(132-144)Flow.Launcher/MainWindow.xaml.cs (1)
MonitorInfo
(956-983)
Flow.Launcher/MsgWithButton.xaml.cs (1)
Flow.Launcher/MainWindow.xaml.cs (1)
MonitorInfo
(956-983)
🪛 GitHub Check: Check Spelling
Flow.Launcher.Infrastructure/MonitorInfo.cs
[failure] 168-168:
the the
matches a line_forbidden.patterns entry: \s([A-Z]{3,}|[A-Z][a-z]{2,}|[a-z]{3,})\s\g{-1}\s
. (forbidden-pattern)
🪛 GitHub Actions: Check Spelling
Flow.Launcher.Infrastructure/MonitorInfo.cs
[error] 168-168: Forbidden pattern detected: ' the the ' matches a line_forbidden.patterns entry. (forbidden-pattern)
⏰ 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). (3)
- GitHub Check: gitStream.cm
- GitHub Check: gitStream.cm
- GitHub Check: build
🔇 Additional comments (16)
Flow.Launcher.Infrastructure/MonitorInfo.cs (8)
12-19
: LGTM! Good documentation and appropriate visibility change.The public visibility and XML documentation clearly explain the purpose of this class as a replacement for
System.Windows.Forms.Screen
to avoid platform exceptions.
29-33
: Simplified callback syntax looks good.The removal of explicit parameter types in the delegate improves readability without affecting functionality.
36-36
: Parameter simplification is appropriate.Removing the explicit cast
(RECT?)null
to justnull
is cleaner and functionally equivalent.
49-51
: Good use of nint for native handle parameter.The change from
HWND
tonint
provides better flexibility for callers while maintaining type safety for native window handles.
72-97
: GetPrimaryDisplayMonitor implementation looks correct.The method properly uses
MONITOR_DEFAULTTOPRIMARY
flag and follows the established enumeration pattern with appropriate error handling.
99-128
: GetCursorDisplayMonitor implementation is well-structured.The method properly handles cursor position retrieval with error checking and follows the established pattern for monitor enumeration.
134-142
: Property names are more descriptive and follow .NET conventions.The renaming from
RectMonitor
/RectWork
toBounds
/WorkingArea
improves code clarity.Also applies to: 157-165
173-173
: ToString() correctly updated to use new property names.The method now uses
Bounds
instead of the old property name, maintaining consistency.Flow.Launcher/Msg.xaml.cs (1)
18-18
: Correct migration to MonitorInfo API.The replacement of
Screen.FromPoint(System.Windows.Forms.Cursor.Position)
withMonitorInfo.GetCursorDisplayMonitor()
maintains the same functionality while removing the Windows Forms dependency.Flow.Launcher/MsgWithButton.xaml.cs (1)
18-18
: Consistent API migration.The replacement maintains the same functionality while removing the Windows Forms dependency, consistent with changes in other UI files.
Flow.Launcher/SettingPages/ViewModels/SettingsPaneGeneralViewModel.cs (1)
110-123
: Proper migration to MonitorInfo API with correct collection property.The change from
Screen.AllScreens
toMonitorInfo.GetDisplayMonitors()
is correct, and usingCount
instead ofLength
properly handles the IList return type.Flow.Launcher/SettingWindow.xaml.cs (2)
202-215
: Correct migration in position validation logic.The replacement of
Screen.AllScreens
withMonitorInfo.GetDisplayMonitors()
maintains the same validation logic while using the new API.
217-233
: Consistent API usage in window positioning methods.Both
WindowLeft()
andWindowTop()
methods correctly useMonitorInfo.GetCursorDisplayMonitor()
for window positioning calculations.Flow.Launcher/MainWindow.xaml.cs (3)
1-1
: LGTM: Clean removal of unused using directiveThe removal of
using System.Windows.Forms;
is appropriate since the code now usesMonitorInfo
instead ofSystem.Windows.Forms.Screen
. The remaining Windows Forms types (MouseButtons
,NotifyIcon
) are properly aliased with explicit using statements.
534-534
: LGTM: Proper API migrationThe replacement of
Screen.FromHandle()
withMonitorInfo.GetNearestDisplayMonitor()
maintains the same functionality while using the new abstraction layer.
985-1021
: LGTM: Consistent parameter type updatesAll helper methods have been updated to accept
MonitorInfo
parameters instead ofScreen
. The unchanged method bodies confirm thatMonitorInfo
provides compatible properties (WorkingArea
) maintaining the same functionality.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR upgrades NuGet dependencies to leverage .NET 9 capabilities and resolves compatibility issues. The main purpose is to modernize the dependency stack while maintaining functionality and fixing platform-specific exceptions.
- Upgrade NuGet dependencies across all projects to latest versions
- Replace System.Windows.Forms.Screen usage with custom MonitorInfo class to avoid platform exceptions
- Update CsWin32 package and adapt code to new API signatures
Reviewed Changes
Copilot reviewed 24 out of 24 changed files in this pull request and generated 2 comments.
Show a summary per file
File | Description |
---|---|
Multiple .csproj files | Upgraded package versions (CsWin32, Microsoft.Extensions, NLog, etc.) |
Multiple packages.lock.json files | Updated dependency versions to match upgraded packages |
ShellLocalization.cs | Updated PInvoke calls to use new CsWin32 API signatures with explicit string pointer handling |
ProcessHelper.cs | Modified process querying code to work with updated CsWin32 types |
MainWindow.xaml.cs | Replaced System.Windows.Forms.Screen with MonitorInfo class |
SettingWindow.xaml.cs | Replaced System.Windows.Forms.Screen with MonitorInfo class |
MonitorInfo.cs | Enhanced MonitorInfo class with additional methods and made it public |
Win32Helper.cs | Updated PInvoke calls for CsWin32 compatibility |
Comments suppressed due to low confidence (1)
This comment has been minimized.
This comment has been minimized.
I have updated test details in PR description. Please check. Generally, memory does not increase for non-Chinese users if they disable Search with Pinyin option. For users who enable Search with Pinyin option, memory will increase by 100MB for better Pinyin search experience. |
Thank you for the tests, it looks like the 100mb jump is happening when the settings window is opened? Am I reading it correctly? |
No, it jumps when you start to search something and memory usage differs when Search with Pinyin is enabled or disabled. I also open setting window for checking memory usage related to setting window. |
Are you finding any benefits with this upgrade? Is it worth the 100mb increase? |
Based on the NuGet package description, the main improvements seem to be faster loading times and better Pinyin support for more Chinese characters. Personally, I have not noticed much of a difference since most of my files and items are in English. However, I think these changes could be helpful for users who work more with Chinese content. |
I see. Ok let's go ahead with this upgrade then, but do we need to add a note in the option toggle tooltip that this will significantly increase memory consumption? 100mb increase is alot compared to the average memory consumption. |
Agree. Maybe we can update the description of Search with Pinyin option. Do you think this change is okay?
->
|
This comment has been minimized.
This comment has been minimized.
Yeah pretty much it, just make it more concise: |
This comment has been minimized.
This comment has been minimized.
@check-spelling-bot Report🔴 Please reviewSee the 📂 files view, the 📜action log, or 📝 job summary for details.
See ❌ Event descriptions for more information. Forbidden patterns 🙅 (1)In order to address this, you could change the content to not match the forbidden patterns (comments before forbidden patterns may help explain why they're forbidden), add patterns for acceptable instances, or adjust the forbidden patterns themselves. These forbidden patterns matched content: Reject duplicate words
If the flagged items are 🤯 false positivesIf items relate to a ...
|
…ency Upgrade NuGet Dependencies & Package Lock Json Files
Changes
Follow on with #3286. Since we have upgrade to .net9, we can upgrade many dependencies.
NLog.OutputDebugString.OutputDebugStringTarget
MonitorInfo
class andPInvoke
(CSWin32) to replaceSystem.Window.Forms.Screen
usage to avoid possible exception:MonitorInfo
class in Plugin project for other plugins to call to deprecate reference toSystem.Windows.Forms.Screen
Close #1835, #3845, #3858.
Test
Memory Test
When Pinyin & Double Pinyin are enabled, memory increases by 100MB
VM: Open App, Open App + Open Search Window, Open App + Open Search Window + Search Something + Open Setting Window
v1.20.2.13243: 70.4MB, 79.8MB, 146.3MB
v1.20.2.13243 (Upgraded): 73.6MB, 81.7MB, 220.7MB
PC:
v1.20.2.13243: 508.3MB, 584.2MB, 643.3MB
v1.20.2.13243 (Upgraded): 509.3MB, 583.1MB, 753.5MB
When Pinyin & Double Pinyin are disabled, memory does not not increase
v1.20.2.13243: 98.6MB
v1.20.2.13243 (Upgraded): 103.5MB