Sorry, it doesn't work for me either. I didn't relog before testing and I guess it was still using the qdbus commands. KLauncher gets the right arguments I think:

Shortcuts work for me. For testing make sure to install to /usr since we link our .desktop from KDE_INSTALL_FULL_APPDIR to the kglobalaccel one.

In D25273#561847, @ngraham wrote:

Also, the combobox's model appears to have duplicates for Breeze, Breeze Dark, and Breeze Light, which (correctly) don't show up in the colors KCM for me:

I think I know what's happening. Do you have Breeze installed into the same prefix as cuttlefish in addition to system breeze? After doing so I also see the duplicate color. (The same happens in Kate)

Load initial color scheme name from the respective .colors file

In D25273#561845, @ngraham wrote:

Nice, it's good to get rid of so much boilerplate.

However when I change the system's own color scheme from Breeze to anything else and start Cuttlefish, the app itself uses that color scheme as expected, but the combobox's text is blank:

I see what's happening. I copied that code form Kate and it reads the current color scheme name from kdeglobals but there can be a difference between the stored name and the user visible name. Especially when it includes a space or hyphen. So it works correctly for Breeze or Oxygen but not Breeze Dark or Oxygen cold.

Was a typo

I somehow broke it before uploading

Seems to work

QLatin1String

In fact in the first diff you linked you are set correctly as the author in the commit but not the second one.

That's probably because @drosca committed those for you and didn't set you as the author.

Use real file

Rebase

update application for migration based on the one I did for spectacle

Konsole still uses khotkeys (updatescript can be adapted from D19310 and D25086 since it writes itself into the kmenuedit group)

In D25086#559109, @mlaurent wrote:

For me it seems ok

Did you finish it ? is it work ? or still in progress ?

Shortcut setting and displaying works so far in my testing.
I still need to do the migration of existing shortcuts otherwise if user had set a shortcut though kmenuedit before it wouldn't be displayed in kmenuedit (although it would be functional).

Or maybe some things could be dropped if there is an equivalent feature in the standard.

• const
• System services

In D25144#558670, @ngraham wrote:

Hmm, I think that would be confusing. "Session" isn't the name of any user-facing applications. That stuff is really a part of Plasma, both technically speaking, and also in terms of the user expectation. Is there any way we could force it to live in the Plasma/System Services section?

In D25144#558665, @ngraham wrote:

In D25144#558663, @davidre wrote:

In D25144#558630, @ngraham wrote:

However I see a problem with changing "Application Launchers" to "Applications": It implies that the items in that category will give you access to change all the shortcuts for those applications, which it does not do. If we want to make this change, I think we'd need to actually put all of each app's shortcuts into its item in that list, assuming that's possible.

I don't think that's implied when the Settings page is titled "Global Shortcuts". The category is about about global shortcuts that relate to Application.

All right, I suppose that makes sense.

Also note that it will be an improvement when eventually more shortcuts are moved to desktop files. For example the "Lock Session" shortcut would end up in "Application Launchers" with D24877.

Under which entry? That seems odd.

The user facing name which would be Session. As I wrote the current code only looks if the component name ends with .desktop so you would have "Session" inside "Application Launchers".

In D25144#558630, @ngraham wrote:

However I see a problem with changing "Application Launchers" to "Applications": It implies that the items in that category will give you access to change all the shortcuts for those applications, which it does not do. If we want to make this change, I think we'd need to actually put all of each app's shortcuts into its item in that list, assuming that's possible.

I don't think that's implied when the Settings page is titled "Global Shortcuts". The category is about about global shortcuts that relate to Application.
Also note that it will be an improvement when eventually more shortcuts are moved to desktop files. For example the "Lock Session" shortcut would end up in "Application Launchers" with D24877.

Thanks for spotting!

I don't know how Discover works but to me looks the wrong fix. Does every third party wallpaper then also need to have a name with plasma in it?
In my opinion ServiceType Plasma/Wallpaper should be enough for a Service as add-on and not having plasma in it's name.

• comments

• Don't delete disabled
• Remove guards

One place where we still use khotkeys in plasma is in kmenuedit but that should be easily ported to GlobalAccel

As mentioned in T11567, we probably don't want to port khotkeys

Count me in!

Will arrival and depature be at 22 and 24 or before/after?

I think this is fine. Imo we can address the comments on master

Ping

To clarify my comment refers to

The logic is fine but if we start with 0 wallpapers and then add 20 newones we don't shuffle anything.

For the other cases shuffling the added images is probably the right thing

Are you sure? Shouldn't we be hitting this case:
https://cgit.kde.org/plasma-workspace.git/tree/wallpapers/image/image.cpp#n773 ?

For reference here is the relevant part in the kcm
https://cgit.kde.org/plasma-desktop.git/tree/kcms/keys/kglobalshortcutseditor.cpp#n176

I think you have also to check the the kcm as i also saw some nodisplay there.
Also it seems kglobalaccel uses nodisplay when a component is disabled. https://cgit.kde.org/kglobalaccel.git/tree/src/runtime/kserviceactioncomponent.cpp#n144

We would need some way to hide the default _launch entry

I don't think that is a problem. I think we could wrap https://cgit.kde.org/kglobalaccel.git/tree/src/runtime/kserviceactioncomponent.cpp#n119 in an if and only register _launch if the [Desktop Entry] has an Exec line?

report Unknown

In T7622#205454, @The-Feren-OS-Dev wrote:

Started working on a patch for the Latte Dock layout specifying part at least. Is there a DBus Signal I can use for cleanly quitting Latte so that Look & Feels can also specify to not have Latte running at all?

I started rewriting the KCM because I was annoyed at the inconsistency of the list representation (even though I fixed that in the meantime). I am going for the backend model in C++ with a Qml frontend approach.
What works:

• Displaying the components, actions and shortcuts
• Global filtering: Hiding of components that don't match the entered query and don't have actions or shortcuts that do either

To Do:

• Setting shortcuts
• the whole scheme thing
• Performance: My hacked together qml seems to do be a bit slow sometimes (but maybe only because of debugging or having gammaray attached?)

Build the new order only after setting the source model.
In invalidate just shuffling is enough.

Like this?
I also changed the condition in image.cpp otherwise the order wouldn't have been random on the first run with these changes.

Whitespace

• Make helper a qquickitem instead

Simplify the logic. In configmode we don't need the random order. We just
use the order of the underlying model.

Need rebuild here, rowCount could have changed

Is there an alternative API for listing installed icon themes? I added functionality to Cuttlefish that uses this and the KCM may use it?

add comment

In D24453#544251, @ngraham wrote:

+1. Can you do the same thing for the similar header that's seen in System Settings' icon view?

In D24508#544318, @ngraham wrote:

This works, though I'll admit that the custom event filter makes me a bit queasy. Feels kind of like hacking around something that wasn't implemented the right way in the first place (i.e. using a QDialog and QDialogButtonBox). Is porting away from that stuff even worse?

I tried making it a QWidget but then no button was reacting to enter and we would lose close-on-esc which we would then have to implement ourselves. Hey it's, not *that* bad ;). It's an only an handler and not a filter for another widget.
Maybe someone with more experience has another idea? Or we concede that no button can be activated with Enter only with Space.

Also is there a reason why we can't use only PushButtons in the main window? I was surprised to discover that half of them were ToolButtons when I went digging into the code, because they all *look* like PushButtons.

I didn't wrote the code but the obvious reason would be that one can assign actions to ToolButtons. Here it is used with KStandardActions and I use it for the screenshot button to switch easily between states.