-
Notifications
You must be signed in to change notification settings - Fork 49
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
Desktop entries update #219
Conversation
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 noticed a search behavior change that seems odd. Searching for "test", I used to get the Blackmagic RAW Speed Test app I have installed on this system as the first result:
On this branch, it doesn't show up as a result at all when searching for that string:
Searching for something more specific does yield the result, so it's still being detected as an entry by the launcher:
Any idea why this update would cause fuzzy matches to have priority over an exact match? Not matching an exact term anymore seems like a regression.
Yes, I think i understand why this is the case. The old impl use
for matching while the new only use Having both
seems redundant. I will add the |
No rush, but just to make sure this isn't waiting on us again, I assume something will need to be done in this PR to bring pop-os/freedesktop-desktop-entry#23 in? Not sure if the |
I assume fde needs a new version |
@mmstick Can you make a crate release including pop-os/freedesktop-desktop-entry#23 so we can bump the version used in this PR to fix that regression? |
Sure |
Released as 0.6.2 |
@jacobgkau Sorry for the ping, i just making sure you aware that this pr is now ready for review again :) |
@wiiznokes I saw it this morning. There's some other work we're busy with at the moment, but I will review this again this week, hopefully within the next day or so. |
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.
On 4f281f7, the Blackmagic RAW Speed Test
app now shows up when searching test
. However, searching for settings
does not return the Settings app (a.k.a. GNOME Control Center) as a result. On this machine, it currently shows up as the second option when searching for that term on the released/master branch.
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.
The test
and settings
queries are both working as expected now.
Standard regression testing failed. GNOME Settings panels are not showing up in search anymore with this update. This can be tested with e.g. appearance
for the Appearance panel or wifi
for the Wi-Fi panel.
I suppose this is a popos only thing? Would you be able to provide an example of |
gnome-control-center desktop entries in the GNOME session should be searchable. |
Here's one, for the Appearance page:
It's installed to |
I see. Last commits should solve this issue. The current behavior seems odd to me. The launcher will search in desktop entries that set I'm not sure if applets should use the desktop enty spec here. It could potentially impact other DEs if i understand correctly. cc @mmstick |
The previous logic was based on the session. If you are in the GNOME session, then desktop entries which use |
Yes, i guess this is fine, even if the launcher could miss some useful entry of normal app (i don't have an example but an app not specific to a DE could use This means another launcher could choose to display this kind of entries, and then, all cosmic applets shows up. |
Yeah, we similarly want cosmic settings pages to appear in the launcher, but not in the app library. |
Yes, but my point was related to cosmic applets. AFAIU, cosmic applets are not meant to be presented in launchers or app library |
And the only things that prevent them to being displayed are |
It's what GNOME is doing, so we're working with behaviors that are already being relied upon. |
I see. The last 2 commits implements this behavior |
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.
Found another issue on 6ec06ef during standard regression testing. Searching for extensions
should only return one entry. Before:
With this branch, there are two results for that app:
This .desktop file comes from /usr/share/applications/org.gnome.Extensions.desktop
:
[Desktop Entry]
Type=Application
Name=Extensions
# Translators: Do NOT translate or transliterate this text (this is an icon file name)!
Icon=org.gnome.Extensions
Comment=Configure GNOME Shell Extensions
Exec=/usr/bin/gnome-extensions-app --gapplication-service
DBusActivatable=true
Categories=GNOME;GTK;Utility;
OnlyShowIn=GNOME;
X-Ubuntu-Gettext-Domain=gnome-shell
Damn, this will never end 😭 I don't really know why there is 2 Thanks |
Aha. I found this issue from just before this item was added to our QA checklist: pop-os/shell#293 In addition to the
I do want to point out that if existing behaviors are breaking the spec, we could probably consider following the spec if we fix those behaviors in their respective other components (i.e. patch the .desktop files in gnome-shell/gnome-control-center/etc). We just can't ship the update when it would break user-facing behaviors on the checklist. As for why this duplicate wasn't showing up before, I think it's because the exec line is set to false. If I change the exec line for e.g. LibreOffice Writer's .desktop file to false, it shows with this branch and doesn't show on master. So that's the regression we're looking at now. |
Yep, that must be it. I don't think this is in the spec but that's not surprising coming from Gnome |
Should be hopefully good now |
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.
The test
and settings
queries are still working as expected.
Standard regression testing passed:
- All windows on all workspaces appear on launch
- Choosing an app on another workspace moves workspaces and focus to that app
- Launching an application works
- Typing text and then removing it will re-show those windows
- Search works for applications and windows
- Search works for GNOME settings panels
- Search for "Extensions". There should be only one entry.
- The overlay hint correctly highlights the selected window
- Open windows are sorted above applications (e.g. "firefox")
- t: executes a command in a terminal
- : executes a command in sh
- = calculates an equation
- Search results are as expected:
cal
returns Calendar and Calculator before Colorpops
returns Popsicle firstshop
returns the Pop!_Shop first
I plan to start playing with the score now, for modifying to order of the result. I don't include it in this PR to keep things separate, but since the new matching function will match more things, currently, the search result are not as good as previously.see #217