Skip to content

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

Merged
merged 19 commits into from
Jul 24, 2025
Merged

Conversation

Jack251970
Copy link
Member

@Jack251970 Jack251970 commented Jul 19, 2025

Changes

Follow on with #3286. Since we have upgrade to .net9, we can upgrade many dependencies.

  • Upgrade NuGet dependencies
  • Resolve compatibility issue with new version of CSWin32 package by editing codes
  • Restore package.json.lock files
  • Resolve compatibility issue with new version of NLog by introducing new package: NLog.OutputDebugString which is need for our project since we have used its class NLog.OutputDebugString.OutputDebugStringTarget
  • Upgrade ToolGood.Words.Pinyin to v3.1.0.4 since the problem that it results in high memory usage when search with pinyin is enabled is no longer a problem (Bump ToolGood.Words.Pinyin from 3.0.1.4 to 3.1.0 #1835)
  • Use MonitorInfo class and PInvoke (CSWin32) to replace System.Window.Forms.Screen usage to avoid possible exception:
System.PlatformNotSupportedException: SystemEvents is not supported on this platform.
   at Microsoft.Win32.SystemEvents.add_UserPreferenceChanged(UserPreferenceChangedEventHandler value)
   at System.Windows.Forms.Screen.get_DesktopChangedCount()
   at System.Windows.Forms.Screen.get_WorkingArea()
   at Flow.Launcher.MainWindow.HorizonCenter(Screen screen) in C:\projects\flow-launcher\Flow.Launcher\MainWindow.xaml.cs:line 988 ...
  • Add MonitorInfo class in Plugin project for other plugins to call to deprecate reference to System.Windows.Forms.Screen

Close #1835, #3845, #3858.

Test

  • Search Window Location can work
  • Memory usage is normal with new version of ToolGood.Words.Pinyin (Tested with VS, Debug configuration)

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

    • VM: Open App + Open Search Window + Search Something + Open Setting Window
      v1.20.2.13243: 98.6MB
      v1.20.2.13243 (Upgraded): 103.5MB

Copy link

gitstream-cm bot commented Jul 19, 2025

🥷 Code experts: no user but you matched threshold 10

Jack251970 has most 👩‍💻 activity in the files.
jjw24, Jack251970 have most 🧠 knowledge in the files.

See details

Flow.Launcher.Core/Flow.Launcher.Core.csproj

Activity based on git-commit:

Jack251970
JUL
JUN
MAY
APR
MAR
FEB

Knowledge based on git-blame:
jjw24: 14%

Flow.Launcher.Core/packages.lock.json

Activity based on git-commit:

Jack251970
JUL
JUN
MAY
APR
MAR
FEB

Knowledge based on git-blame:

Flow.Launcher.Infrastructure/Flow.Launcher.Infrastructure.csproj

Activity based on git-commit:

Jack251970
JUL 0 additions & 6 deletions
JUN
MAY
APR 4 additions & 1 deletions
MAR 0 additions & 1 deletions
FEB

Knowledge based on git-blame:
Jack251970: 16%
jjw24: 11%

Flow.Launcher.Infrastructure/Win32Helper.cs

Activity based on git-commit:

Jack251970
JUL 40 additions & 4 deletions
JUN 5 additions & 0 deletions
MAY 110 additions & 3 deletions
APR 202 additions & 33 deletions
MAR 581 additions & 226 deletions
FEB 13 additions & 16 deletions

Knowledge based on git-blame:
Jack251970: 95%

Flow.Launcher.Infrastructure/packages.lock.json

Activity based on git-commit:

Jack251970
JUL
JUN
MAY
APR
MAR
FEB

Knowledge based on git-blame:

Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj

Activity based on git-commit:

Jack251970
JUL 1 additions & 0 deletions
JUN
MAY
APR 3 additions & 1 deletions
MAR
FEB

Knowledge based on git-blame:
Jack251970: 15%
jjw24: 9%

Flow.Launcher.Plugin/packages.lock.json

Activity based on git-commit:

Jack251970
JUL
JUN
MAY
APR
MAR
FEB

Knowledge based on git-blame:

Flow.Launcher.Test/Flow.Launcher.Test.csproj

Activity based on git-commit:

Jack251970
JUL
JUN
MAY
APR
MAR
FEB

Knowledge based on git-blame:
jjw24: 22%

Flow.Launcher/Flow.Launcher.csproj

Activity based on git-commit:

Jack251970
JUL
JUN 5 additions & 0 deletions
MAY
APR 3 additions & 1 deletions
MAR 1 additions & 5 deletions
FEB 11 additions & 10 deletions

Knowledge based on git-blame:
jjw24: 12%
Jack251970: 9%

Flow.Launcher/packages.lock.json

Activity based on git-commit:

Jack251970
JUL
JUN
MAY
APR
MAR
FEB

Knowledge based on git-blame:

Plugins/Flow.Launcher.Plugin.BrowserBookmark/Flow.Launcher.Plugin.BrowserBookmark.csproj

Activity based on git-commit:

Jack251970
JUL
JUN 35 additions & 34 deletions
MAY
APR 2 additions & 2 deletions
MAR 35 additions & 35 deletions
FEB

Knowledge based on git-blame:
jjw24: 37%
Jack251970: 2%

Plugins/Flow.Launcher.Plugin.Explorer/Flow.Launcher.Plugin.Explorer.csproj

Activity based on git-commit:

Jack251970
JUL
JUN 1 additions & 1 deletions
MAY 1 additions & 2 deletions
APR 2 additions & 1 deletions
MAR 2 additions & 1 deletions
FEB

Knowledge based on git-blame:
jjw24: 72%
Jack251970: 5%

Plugins/Flow.Launcher.Plugin.ProcessKiller/Flow.Launcher.Plugin.ProcessKiller.csproj

Activity based on git-commit:

Jack251970
JUL
JUN
MAY
APR
MAR 1 additions & 1 deletions
FEB

Knowledge based on git-blame:
Jack251970: 12%
jjw24: 8%

Plugins/Flow.Launcher.Plugin.ProcessKiller/ProcessHelper.cs

Activity based on git-commit:

Jack251970
JUL
JUN
MAY
APR 35 additions & 12 deletions
MAR 76 additions & 69 deletions
FEB

Knowledge based on git-blame:
Jack251970: 54%

Plugins/Flow.Launcher.Plugin.Program/Flow.Launcher.Plugin.Program.csproj

Activity based on git-commit:

Jack251970
JUL
JUN
MAY
APR
MAR
FEB

Knowledge based on git-blame:
jjw24: 15%
Jack251970: 11%

Plugins/Flow.Launcher.Plugin.Program/Programs/ShellLocalization.cs

Activity based on git-commit:

Jack251970
JUL
JUN
MAY
APR
MAR
FEB

Knowledge based on git-blame:
Jack251970: 6%

Plugins/Flow.Launcher.Plugin.Sys/Flow.Launcher.Plugin.Sys.csproj

Activity based on git-commit:

Jack251970
JUL
JUN
MAY
APR
MAR
FEB

Knowledge based on git-blame:
jjw24: 13%
Jack251970: 10%

✨ Comment /gs review for LinearB AI review. Learn how to automate it here.

Copy link

gitstream-cm bot commented Jul 19, 2025

Be a legend 🏆 by adding a before and after screenshot of the changes you made, especially if they are around UI/UX.

@Jack251970 Jack251970 added bug Something isn't working dependencies Pull requests that update a dependency file .NET Pull requests that update .net code labels Jul 19, 2025
@Jack251970 Jack251970 added this to the 2.0.0 milestone Jul 19, 2025
Copy link
Contributor

coderabbitai bot commented Jul 19, 2025

📝 Walkthrough

Walkthrough

This change upgrades multiple NuGet package dependencies across several projects, removes the dependency on System.Windows.Forms.Screen for monitor handling, and introduces a new public MonitorInfo abstraction for display monitor operations. It also updates power event handling to use Windows messages and refactors related code accordingly.

Changes

File(s) Change Summary
Flow.Launcher.Core/Flow.Launcher.Core.csproj
Flow.Launcher.Infrastructure/Flow.Launcher.Infrastructure.csproj
Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj
Flow.Launcher.Test/Flow.Launcher.Test.csproj
Flow.Launcher/Flow.Launcher.csproj
Plugins/Flow.Launcher.Plugin.BrowserBookmark/Flow.Launcher.Plugin.BrowserBookmark.csproj
Plugins/Flow.Launcher.Plugin.Explorer/Flow.Launcher.Plugin.Explorer.csproj
Plugins/Flow.Launcher.Plugin.ProcessKiller/Flow.Launcher.Plugin.ProcessKiller.csproj
Plugins/Flow.Launcher.Plugin.Program/Flow.Launcher.Plugin.Program.csproj
Plugins/Flow.Launcher.Plugin.Sys/Flow.Launcher.Plugin.Sys.csproj
Upgraded NuGet package dependencies to newer versions in all project files.
Flow.Launcher.Core/packages.lock.json
Flow.Launcher.Infrastructure/packages.lock.json
Flow.Launcher.Plugin/packages.lock.json
Flow.Launcher/packages.lock.json
Updated lock files to reflect upgraded dependencies, added and removed some packages as required.
Flow.Launcher.Infrastructure/Win32Helper.cs
Plugins/Flow.Launcher.Plugin.ProcessKiller/ProcessHelper.cs
Plugins/Flow.Launcher.Plugin.Program/Programs/ShellLocalization.cs
Refactored interop and pointer handling for process and monitor APIs; improved type safety and pointer usage.
Flow.Launcher.Plugin/SharedModels/MonitorInfo.cs Changed MonitorInfo to public, moved to shared models, added static methods for monitor retrieval, improved property naming and interop consistency.
Flow.Launcher/MainWindow.xaml.cs
Flow.Launcher/Msg.xaml.cs
Flow.Launcher/MsgWithButton.xaml.cs
Flow.Launcher/SettingPages/ViewModels/SettingsPaneGeneralViewModel.cs
Flow.Launcher/SettingWindow.xaml.cs
Plugins/Flow.Launcher.Plugin.Explorer/Search/ResultManager.cs
Replaced all usage of System.Windows.Forms.Screen with MonitorInfo abstraction for monitor/screen handling.
Flow.Launcher.Infrastructure/NativeMethods.txt
Flow.Launcher.Plugin/NativeMethods.txt
Removed obsolete native method declarations from infrastructure, added monitor/cursor-related native methods to plugin.
Flow.Launcher/MainWindow.xaml.cs Replaced SystemEvents.PowerModeChanged event with direct handling of WM_POWERBROADCAST Windows message for system resume detection.
Flow.Launcher/Languages/en.xaml Updated tooltip text for Pinyin search setting to note increased memory usage.

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
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~90 minutes

Possibly related PRs

  • #3328: Both PRs modify the System.Data.OleDb package reference in the Explorer plugin, but in opposite directions and different versions.
  • #3349: Both PRs address Fody version upgrades; this PR includes a broader and later set of dependency updates.
  • #3532: Both PRs address sound effect reinitialization after system resume, but use different mechanisms for detecting the resume event.

Suggested reviewers

  • jjw24

Note

⚡️ Unit Test Generation is now available in beta!

Learn more here, or try it out under "Finishing Touches" below.


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c42f84f and 0564e58.

📒 Files selected for processing (1)
  • Flow.Launcher/Languages/en.xaml (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • Flow.Launcher/Languages/en.xaml
⏰ 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
✨ Finishing Touches
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch nuget_dependency

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.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need 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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai generate unit tests to generate unit tests for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a 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 fork

The custom Jack251970.TaskScheduler has been swapped out for upstream TaskScheduler 2.12.2. The namespaces and a few enum names differ (Microsoft.Win32.TaskScheduler vs TaskScheduler). 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 legacy System.* 4.3.0 packages indicate NETStandard 1.x fallback

Numerous 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

📥 Commits

Reviewing files that changed from the base of the PR and between d3824f2 and 7af3c5f.

📒 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" via Directory.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 sync

A repository-wide scan returned zero occurrences of Version="9.0.3". However, none of the existing packages.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 to Plugins/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 ⇒ regenerate NativeMethods or expect build-warnings

0.3.183 ships new generators (VS 17.10) and emits [GeneratedComInterface] attributes.
Run dotnet build /t:Generate (or just delete GeneratedInterop.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 consumer

Good 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 redirects

Multiple 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) and System.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), and PropertyChanged.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), and VirtualizingWrapPanel (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 to HWND.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 as int 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 against IntPtr.Zero to directly comparing hWndDesktop against HWND.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 in LPARAM 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.

Copy link
Contributor

@coderabbitai coderabbitai bot left a 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.7

This is Windows-only. Confirm no cross-platform plugins use it; otherwise guard with SupportedOSPlatform attributes.


237-246: Project dependency ranges left open-ended

Using [x.y.z, ) turns every dotnet 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

📥 Commits

Reviewing files that changed from the base of the PR and between 7af3c5f and 13cf433.

📒 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’s global.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 dependency SemanticVersioning – double-check license & necessity

Before merging, validate:

  1. License (MIT) is compatible with Flow Launcher’s distribution.
  2. 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 lists 17.13.61, while the lock file resolves 17.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.192

Heads-up: v2.5 drops implicit EnumerableFormatter<T> registration. If reflection-based resolvers are disabled, manual CompositeResolver.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 preview

Same concern as FSharp.Core – ensure preview reference assemblies are present on build agents.


168-176: Nerdbank.Streams 2.12.x bumps minimum .NET runtime

This release removes netstandard2.0. Flow Launcher targets win7; verify runtime graph still selects a compatible TF.


187-194: Addition of NLog.OutputDebugString – 👍 for easier debugging
No issues.


195-199: SharpVectors.Wpf 1.8.4.2 – verify DPI scaling regression fix

Earlier 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

@jjw24 jjw24 added the review in progress Indicates that a review is in progress for this PR label Jul 20, 2025
@Jack251970 Jack251970 changed the title Upgrade NuGet Dependencies Upgrade NuGet Dependencies & Package Lock Json Files Jul 20, 2025
Copy link
Contributor

@coderabbitai coderabbitai bot left a 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 pulls Microsoft.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

📥 Commits

Reviewing files that changed from the base of the PR and between 34cba65 and 55589f8.

📒 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.0

The package’s LICENSE file clearly uses the MIT license (permissive, compatible with Flow Launcher’s distribution). No further action is required here.

@jjw24
Copy link
Member

jjw24 commented Jul 23, 2025

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.

@coderabbitai coderabbitai bot added the enhancement New feature or request label Jul 23, 2025
Copy link
Contributor

@coderabbitai coderabbitai bot left a 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

📥 Commits

Reviewing files that changed from the base of the PR and between 8142ef1 and e1b01dc.

📒 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 just null is cleaner and functionally equivalent.


49-51: Good use of nint for native handle parameter.

The change from HWND to nint 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 to Bounds/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) with MonitorInfo.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 to MonitorInfo.GetDisplayMonitors() is correct, and using Count instead of Length 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 with MonitorInfo.GetDisplayMonitors() maintains the same validation logic while using the new API.


217-233: Consistent API usage in window positioning methods.

Both WindowLeft() and WindowTop() methods correctly use MonitorInfo.GetCursorDisplayMonitor() for window positioning calculations.

Flow.Launcher/MainWindow.xaml.cs (3)

1-1: LGTM: Clean removal of unused using directive

The removal of using System.Windows.Forms; is appropriate since the code now uses MonitorInfo instead of System.Windows.Forms.Screen. The remaining Windows Forms types (MouseButtons, NotifyIcon) are properly aliased with explicit using statements.


534-534: LGTM: Proper API migration

The replacement of Screen.FromHandle() with MonitorInfo.GetNearestDisplayMonitor() maintains the same functionality while using the new abstraction layer.


985-1021: LGTM: Consistent parameter type updates

All helper methods have been updated to accept MonitorInfo parameters instead of Screen. The unchanged method bodies confirm that MonitorInfo provides compatible properties (WorkingArea) maintaining the same functionality.

Copy link
Contributor

@Copilot Copilot AI left a 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)

Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>

This comment has been minimized.

@Jack251970
Copy link
Member Author

Jack251970 commented Jul 23, 2025

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.

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.

@jjw24
Copy link
Member

jjw24 commented Jul 23, 2025

Thank you for the tests, it looks like the 100mb jump is happening when the settings window is opened? Am I reading it correctly?

@Jack251970
Copy link
Member Author

Jack251970 commented Jul 23, 2025

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.

@jjw24
Copy link
Member

jjw24 commented Jul 23, 2025

Are you finding any benefits with this upgrade? Is it worth the 100mb increase?

@Jack251970
Copy link
Member Author

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.

@jjw24
Copy link
Member

jjw24 commented Jul 24, 2025

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.

@Jack251970
Copy link
Member Author

Jack251970 commented Jul 24, 2025

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?

Allows using Pinyin to search. Pinyin is the standard system of romanized spelling for translating Chinese.

->

Allows using Pinyin to search. Pinyin is the standard system of romanized spelling for translating Chinese. Enabling it can introduce more memory usage during searching.

This comment has been minimized.

@jjw24
Copy link
Member

jjw24 commented Jul 24, 2025

Yeah pretty much it, just make it more concise:
Pinyin is the standard system of romanized spelling for translating Chinese. Please note, enabling this can significantly increase memory usage during search.

This comment has been minimized.

@Jack251970
Copy link
Member Author

Pinyin is the standard system of romanized spelling for translating Chinese. Please note, enabling this can significantly increase memory usage during search.

Done.

image

@jjw24 jjw24 removed enhancement New feature or request review in progress Indicates that a review is in progress for this PR 5 min review labels Jul 24, 2025
Copy link

@check-spelling-bot Report

🔴 Please review

See the 📂 files view, the 📜action log, or 📝 job summary for details.

❌ Errors and Warnings Count
❌ forbidden-pattern 1
⚠️ noisy-file 2

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

\s([A-Z]{3,}|[A-Z][a-z]{2,}|[a-z]{3,})\s\g{-1}\s
If the flagged items are 🤯 false positives

If items relate to a ...

  • binary file (or some other file you wouldn't want to check at all).

    Please add a file path to the excludes.txt file matching the containing file.

    File paths are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your files.

    ^ refers to the file's path from the root of the repository, so ^README\.md$ would exclude README.md (on whichever branch you're using).

  • well-formed pattern.

    If you can write a pattern that would match it,
    try adding it to the patterns.txt file.

    Patterns are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your lines.

    Note that patterns can't match multiline strings.

@Jack251970 Jack251970 merged commit 65cfb29 into dev Jul 24, 2025
6 checks passed
@Jack251970 Jack251970 deleted the nuget_dependency branch July 24, 2025 10:52
TBM13 pushed a commit to TBM13/Flow.Launcher that referenced this pull request Jul 24, 2025
…ency

Upgrade NuGet Dependencies & Package Lock Json Files
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working dependencies Pull requests that update a dependency file .NET Pull requests that update .net code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants