-
-
Notifications
You must be signed in to change notification settings - Fork 327
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
Order search result by window title #3150
base: dev
Are you sure you want to change the base?
Order search result by window title #3150
Conversation
@check-spelling-bot Report🔴 Please reviewSee the 📂 files view, the 📜action log, or 📝 job summary for details.
See ❌ Event descriptions for more information. If the flagged items are 🤯 false positivesIf items relate to a ...
|
🥷 Code experts: no user matched threshold 10 See details
Knowledge based on git-blame:
Knowledge based on git-blame: To learn more about /:\ gitStream - Visit our Docs |
📝 WalkthroughWalkthroughThe pull request introduces enhancements to the Process Killer plugin in Flow Launcher, focusing on improving process information handling. A new Changes
Sequence DiagramsequenceDiagram
participant PH as ProcessHelper
participant Main as Main Plugin
participant User as User
User->>Main: Trigger Process Search
Main->>PH: GetProcessesWithNonEmptyWindowTitle()
PH-->>Main: Return Processes with Titles
Main->>Main: Create Results
Main-->>User: Display Processes
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (3)
Plugins/Flow.Launcher.Plugin.ProcessKiller/Main.cs (2)
68-70
: Consolidate dictionary usage
You're retrieving a dictionary of processes with non-empty window titles while also retrieving a broaderprocessList
. Consider whether this dictionary or an alternative data structure can more seamlessly integrate with the main list. This might streamline lookups and reduce repeated iteration.
78-90
: Avoid potential performance overhead in large loops
The approach of building a newResult
for each process is fine for modest lists, but in systems with many processes, enumerating them all might cause performance concerns. Periodically review if you need a paging mechanism or a more optimized approach for large process sets.Plugins/Flow.Launcher.Plugin.ProcessKiller/ProcessHelper.cs (1)
80-104
: Handle potential exceptions fromProcess.GetProcessById
If the process exits between the time of enumeration and retrieval, it may throw an exception. Consider wrapping it in a try-catch block to avoid runtime issues.Potential approach:
+try +{ + var process = Process.GetProcessById((int)processId); + if (!processDict.ContainsKey((int)processId)) + { + processDict.Add((int)processId, windowTitle.ToString()); + } +} +catch (ArgumentException) +{ + // Process no longer exists, skip +}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
Plugins/Flow.Launcher.Plugin.ProcessKiller/Main.cs
(3 hunks)Plugins/Flow.Launcher.Plugin.ProcessKiller/ProcessHelper.cs
(3 hunks)
🔇 Additional comments (11)
Plugins/Flow.Launcher.Plugin.ProcessKiller/Main.cs (4)
63-64
: Use a dedicated model for clarity
Defining a record for process data is a neat way to group and transport relevant info (ProcessName, MainWindowTitle). This improves maintainability and readability. Great approach!
71-71
: Consider user feedback for empty query
When processList.Any()
is false, you return null
. If someone types an invalid or empty query, returning null
means no results. Make sure this behavior aligns with desired user experience (e.g., we might want to show a “No matching processes” item).
101-104
: Sorting logic fits the use case
You’re correctly using OrderBy
to push processes with non-empty window titles to the top. The subsequent .ThenBy(x => x.Title)
helps group them by logical title ordering. This is straightforward and readable.
109-120
: Re-check concurrency or potential race conditions
Inserting a “Kill All” option is a solid UX improvement. However, calls to TryKill
for multiple processes could face concurrency or ephemeral process states. If a process closes just as the user selects “Kill All,” handle or log that possibility gracefully.
Would you like me to create a verification script to check for concurrency handling across all kill calls?
Plugins/Flow.Launcher.Plugin.ProcessKiller/ProcessHelper.cs (7)
1-1
: File header looks good
No issues found regarding the top-level using directives.
14-16
: Verify multi-platform considerations for EnumWindows
EnumWindows
is a Windows API function. Ensure that the plugin gracefully handles or skips this functionality on non-Windows platforms.
17-17
: Delegate for EnumWindowsProc
This delegate looks correctly declared for the callback.
22-23
: Checks for window visibility
Using IsWindowVisible
is a valid approach for filtering out hidden windows.
25-26
: GetWindowThreadProcessId
usage
Acquiring the process ID via GetWindowThreadProcessId
is standard practice and looks good here.
77-79
: Docstring clarity
The XML comment accurately describes the method’s purpose and return value.
19-20
:
Use a larger StringBuilder capacity
Calling new StringBuilder()
defaults to 16 as capacity. This may truncate window titles longer than 16 characters.
Consider specifying a larger capacity, for example:
-StringBuilder windowTitle = new StringBuilder();
+StringBuilder windowTitle = new StringBuilder(256);
Likely invalid or redundant comment.
make sense! Thanks. How do you think if we rank them by the z-index on the screen (I don't know whether it is possible though)? |
@@ -95,22 +98,25 @@ private List<Result> CreateResultsFromQuery(Query query) | |||
}); | |||
} | |||
|
|||
var sortedResults = results.OrderBy(x => x.Title).ToList(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to ask you to do a score bump instead of simply orderby.
Be a legend 🏆 by adding a before and after screenshot of the changes you made, especially if they are around UI/UX. |
When using the killer process feature, I often find it difficult to recall the exact name of the process I want to terminate. However, in most cases, I am trying to close a process associated with a visible window on my screen, rather than a background service or job.
To improve usability and speed, I propose sorting the search results to prioritize processes that have a non-empty MainWindowTitle, so that processes with visible windows appear first.