- User Since
- Apr 17 2015, 10:32 PM (157 w, 4 d)
A better version
I have a plan for a kconf_update v2 which would resolve the problem above nicely
Probably means this would be 5.14.
Please add the "." that cfeck said, then ship it
marking as request changes based on my comments
We have lots of KJob API patterns when *making* an async call to something else.
I can't think of any async-ly handling somethign else (except for maybe slavebase) , so we are in a fairly unique position here.
Thanks for merging my other patches! What does it mean when one is accepted, but not merged though? Do I need to rebase this one?
As this is clearly more readable:
y = sg.height() - (r.y() - sg.y() + r.height())
I read your comments.
Mon, Apr 23
setting sourceWidth/height so that it resizes before the texture upload
I think so.
why ignore aspect ratio?
Sun, Apr 22
In the sense that they both involve scaling, yes. But otherwise not really. See my patch that first fixed it. But as you say this is very unrelated. Blur doesn't even use this function.
On X kwin doesn't do any scaling s_virtualScreenScale will always be 1.
This line was modded with 9cafbb117984f746d4b71213effc3d27e1435f36
That also claimed to be a bug fix that fixing things, and that one was tested with vertically stacked multiscreens.
It's a bit cheeky, but it's the only soltuion that doesn't require an invasive patch inverting the way input is eventFiltered.
You can, but given it's intended audience and how hidden it now is, it really isn't worth putting a lot of time into.
Hide in systemsettings whilst keeping in krunner
Just to clarify somethig, even though we need this for fractional scaling (which is quite a bit in the future) it's also needed to fix an xwayland fullscreen bug at regular 2x.
So I want this for 5.13 if possible
Sat, Apr 21
I can't imagine this working. It didn't when I've tried the same thing.
Docs say QT_SCREEN_SCALE_FACTORS doesn't affect the logical DPI. which means you have a 1x scale on one screen 2x on another..they both have the same font size which will just be really wrong.
Fri, Apr 20
We have two settings:
The first, when the X selection owner gets cleared, replaces the clipboard with the top entry
This one when the X selection owner gets cleared, deletes the top entry in the UI.
Right, but pressing control+v again won't paste the item after clearing which I assumed was the intended goal
Aren't you just duplicating the existing "prevent empty clipboard" option ?
Thu, Apr 19
Kinda makes sense, though the weston code also set the resolution and bpp.
That "fixes" it for those who accidentally have it enabled but don't want it
but breaks it for those who deliberately went and enabled it (possibly with the GUI, possibly manually)
Surely this is now two cases of ints in booleans instead of one...but if the compiler prefers this one, sure.
Wed, Apr 18
It's looking a trillion times better than the early screenshots.
This revision was not accepted when it landed; it landed in state Changes Planned.Wed, Apr 18, 8:54 PM
So much red!
1 minor change.
There's ColorButton (https://api.kde.org/frameworks/kdeclarative/html/classColorButton.html) inside kquickcontrols
Personally I sort of, well, hate this and it was a very conscious design decision to make the menu widths uniform, so I'd like some more VDG opinions to convince me otherwise first.
Probably fine, but can you attach a screenshot
I don't think we have the same sort of window decorations on a mobile
Tue, Apr 17
Not too fond of this "Current"
Mon, Apr 16
Some minor fixes