FWIW, I've no idea against the principle, just please copy the .desktop approach from that spectacle patch.

Here's the patch in spectacle: D19310

We don't want more stuff using khotkeys, you've seen the spectacle discussion and the move to the new kglobalaccel code.

To give a context for people who haven't seen the prior conversation.

Does anyone know of other places that has the lsof functionality duplicated?

As long as it'd be an optional dependency, it should be fine, as I don't see it forbidden here: https://community.kde.org/Frameworks/Policies

There's a findByPath method on the list https://api.kde.org/frameworks/kio/html/classKMountPoint_1_1List.html#add38a82921d203856e1d1f9ddb9adbe6

This is definitely better. The part with the history saving is neat and that part is all good to go.

I don't get a crash and the patch itself is correct.

Sorry it's been taking so long, I've been having the hardest time getting virtualbox to work...

IMHO, if we have a patch that does software rotation (which I know you're working on) we should simplify the code and just remove all the hardware rotation.

The desktop is still essentially usable with them present, right?

Cool. Seems to work nicely, even with any weird edge cases I've thrown at it.
In general ++

Code still looks good. +1 from me

Ah, so the connect line is just a code tidy up not trying to be an important behavioural change. I misunderstood.

The rationale all makes sense.
Thanks for investigating this.

We don't use goto.

It means only spectacle fills memory, not doing work in gimp.

You're just going to burn through memory like crazy. We can't do this.
It also doesn't properly fix the klipper issue as it then breaks for anyone who has changed the setting.

At least that transient problem is fully understood. We have to solve that somewhere else as it affects the other KCMs.
Can you file a bug report (or phab task or whatever) copying the messages above so it doesn't get lost, and then lets get this shipped.

Seems sensible.

Sorry, I forgot about this. AFAIK Nate rewrote media frame to QQC2 anyway.

Gtk can easily check whether the window manager supports this property and if not do the same as this patch does.

I just read the title guessed you were talking about any server side decos.
You are correct. Sorry

GTK doesn't support xdg-decoration. :D

Good stuff! I'm hoping we see more of your commits in the future

Concept seems sensible.

Are GTK developers aware of this problem?

What's the reason for removing the linear gradient?

two window titles of different colours matching breeze.

hmm, those windows would need a flag saying it's un-maximizable?

Currently, xdg-shell protocol doesn't have any mechanism that a client could use to notify the compositor about its intent to map.

Visual indication on mouseover is generally a good thing ++

The calls to KGlobalaccel are still needed. Removing them from the updatescript caused the user specified shortcuts to be the default shortcuts.

Would it be better to set the sourceSize? If we're downscaling during rendering we're wasting memory

Maybe I should move this to a phab task, but I've done some looking:

kconfupdate is fine for migration. That code looks somewhat sensible.

[Wednesday, 27 February 2019] [16:40:39 GMT] <notmart> Android has actually 3 modes: resize the window, just tell the app of the area and shift the whole window up
[Wednesday, 27 February 2019] [16:40:49 GMT] <notmart> which is defined by the app

The original rationale of the time of having the black background was to hide the flickering blank framebuffer as we switch from SDDM to the login - and we're autologigng in we're coming from a black background too. From a tech POV I like that because loading a wallpaper is quite CPU consuming.

Add comment

I'm not sure changing the codec for all kauth stuff is the best