- User Since
- Mar 3 2016, 9:43 PM (193 w, 4 d)
May 10 2019
I'll try to reason that out, because I think there's some confusion about the development of the topic.
Quick reminder: the constantly brought argument for this was that it would allow mass closing of windows, what's outright silly, because the window layout would change w/ every closed window - not necessarily in a predictable way (not only because of the re-layout but attempting to close a window might instead add a dialog - in worst case not a transient one)
Aug 15 2018
The functional justification for translucent moving/resizing windows has always been to control its geometry in relation to windows lower in the stack ("what and how much will be covered", "where's a free area")
There may also have been references to early WMs when windows were just hinted by an outline during geometry transitions (though typically not unmapping the actual window), simply because displaying them while resizing them is resource intense (what's more of a concern when you're short on resources) - those WMs would often have presented an outline to allow controlling the initial position for the window before actually mapping it.
May 9 2018
iirc the set rules are used by kstart
Jan 20 2018
I'd assume the const casting avoids deep copies of the QList - at least that's the only explanation I could come up without a deeper investigation.
Did you compare that to a profile with the updated cast?
This makes little sense and a simplified testcase doesn't measure significant differences in casting times on the wall clock time. And certainly not factor 22.
Jan 14 2018
I'm not actually smiling ...
Why was that a problem?
(Or how can I see the previous patch in this messy review tool which draws an entire core when typing...)
On a general note, UI-wise: if there's no way to ever enable an item it should not be shown anyway.
Jan 6 2018
The original implementation based the fullscreen status on the stack position of the window (ie. whenever a window would rise above the plain stack position of the FS window, it would loose the FS status, ie. top layer)
The result was iirc that random notifications would not only show up but also de-fullscreen the window and also virtual desktop switches would constantly kill the FS state.
Jan 2 2018
Should the lock screen not be guarded by a black layer in the compositor?
As of the effect, maybe this should rather fade in a black layer than fade out everything else?
Dec 13 2017
requestToolTip(QString) and treat an empty string reasonably?
Nov 13 2017
Ignore the request as "probably temporary" and just freeze rendering?
Nov 7 2017
Oct 5 2017
Why should it? The stack remains the same, just one window changes its visibility.
Aug 25 2017
There's a major pitfall to inter-process modality:
In case of a persistent transient (used by several clients), the leader may loose the focus access "forever" (because the modal window remains)
Probably to handle internal WhatsThis online help (ie. you click the maximize button of a deco and get the information that this is a maximize button) but I don't know either.
Apparently even Lubos was already unsure what this was about.
Aug 23 2017
I take there's no such support announcement on native wayland at all?
Pretty uninformed consideration:
When dealing with X11/wayland hybrids, won't one end up with two property indexes which are hard -if not impossible- to align (because one will be assigned by kwin internally and the other by the casual xwayland server)?
Might the xwayland property even change over the runtime of kwin (is the xwayland server conditionally removed)?
Aug 20 2017
Unless things changed for the worse, clients (through this function) still send a client message (on _NET_ACTIVE_WINDOW) - the difference between the regular call and the force version is the source indication being "2" ("i'm a pager/taskbar and know what i'm doing so please do") - but the actual property is still set by the WM after receiving (and honoring) such message.
There's no technical advantage in a local static, only a design one. You prevent it from future mis-use beyond its limited purpose, because m_activeWindow isn't actually a "property" of RootInfo.
If you however at some point need several instances, that's no longer an option (resp. you'd need a local hash which is but even uglier than the "false" member)
David has some point though - m_activeWindow *can* get out of sync (server error, mal... stupid client - and will be temporarily due to the async setup) and must not be used directly to query the active window.
Aug 15 2017
2¢ - you don't have to expose the cursor position for those effects, just a signal that the cursor position changed and the ability to "do some" at the "current" cursor position (which is then resolved by the core)
Jul 15 2017
Jul 14 2017
Jun 19 2017
Jun 18 2017
Jun 9 2017
What about lldb and in case this is meant as security measure(?): this only checks a tail, ie. ~/mysuperspytool/trick_kwin/gdb would work just as well - check the binary to be UID0 at least?
I think what David has in mind is a shadow constellation like
Jun 6 2017
Jun 4 2017
Just saw this because of a bug report.
Why was this patch approved at all?
May 6 2017
Matter of semantics only (if you would want to use the XCB_CURRENT_TIME symbol wrt backend abstraction matters and readability - the invalidity isn't implicitly explained, maybe read as bool "if (timestamp && ...") but I'm out of position for an informed comment on this.
0L is XCB_CURRENT_TIME iow "kinda invalid", so it's sane to block that in setX11Time()
May 4 2017
The desktop grid seeems more suited to handle the windows VD.
There're PW modes where this feature is pointless (because you only see the current VD anyway) and for the other ones there's (as mentioned) no feedback nor oversight on the status quo. Nor is there even visibility of the feature.
A merge between PW and DG (aka "Mission Control"; what you seem to be after?) would imo require a sane re-draft of such effect/tool.
KWin *has* global shortcuts for minimizing and stickyness. Those should either be forwarded or picked up from KGlobalAccel, rather than adding some randonmly hardcoded strings where the user might have entirely different expectation on what they do.
May 3 2017
Another problem related to timestamp handling is KWin getting broken by wrong timestamps sent by applications. A prominent example is clusterssh
This should also mitigate the "idiotic client confused X11 time with epoch" condition (iirc some ssh per script?), yesno?
Apr 26 2017
According to the bug kwin_wayland receives a SIGINT, not a SIGSEGV?
This boils down to the question why the process is still lingering around. If the only parent/child link is actually the socket, then it's more likely to zombie around on a bad socket.
In this case you can fire as many signals as you want - they'll never be handled (the process isn't interruptable)
If the child survives the parent that normally means it's forked at some point and the fork will clear the flag - anyway:
Kai says the process knocks out gdb - is it a zombie process (indicated by "D", cannot be stopped or killed, let alone being terminated) and/or is the socket actually closed or still around?
Mar 29 2017
ftr, not sure about --transform correctnes, but metamodes ViewportIn/ViewportOut work flawless on at least the nvidia blob.
In case you'd rather not want to introduce a git history wall:
-Wno-inconsistent-missing-override -Wno-inconsistent-missing-destructor-override -Wno-initializer-overrides
Mar 27 2017
Mar 24 2017
To keep the delay, one would have to wire the call through a secure dispatcher which guarantees (by searching the list of all windows) the effectwindow still points valid memory before passing the function call on (or use a guarded pointer)
Feb 22 2017
Jan 20 2017
"On Wayland that kded has no real access to the layouts and cannot
properly implement switching. Given that it's better to integrate the
SNI directly in KWin."
Jan 17 2017
Jan 13 2017
The entire parsing is totally not safe against JoeReddiot murking around in the config file, I wonder what happens if we pass "-1" and what is " " cast as...
Jan 8 2017
xcb_randr, gamma ramps. yes.
Look at the inversion implementation in kwin and/or simply the xgamma/xcalib code =)
I'm no longer sufficiently in touch with the code, but one could probably "abuse" the (unstyled) effectframe for the matter (ie. generalize it and make the current frame a special case reg. color, roundness and opacity) - or introduce a similar class for such purposes.
Wouldn't it make more sense to leave the windows alone and trail the screen paint with a black rectangle, in doubt by adding a black window?
Dec 25 2016
Dec 14 2016
Dec 6 2016
Featurewise, there's iirc a config item to wrap around virtual desktops - maybe this should be invoked here? (Although that link is currently not made clear by the config dialog)
Nov 25 2016
On a general note: this terribly looks like doubling all (or a lot of) the core logics reg. tabs - which we had in initial KDE 4 tabbing and which made tabbing *incredibly* buggy.
I'd suggest to forward the cores tab logics and not keep local states, counters etc. around, you'll easily get out of sync.
Oct 24 2016
Oct 23 2016
Oct 16 2016
Oct 12 2016
Errrr... this does not allow the dock to control input, ie. the dock can or can not take focus but you want focus if eg. clicking into a lineedit while do certainly not want it when clicking a button that will activate a window (FSP trouble)
Oct 6 2016
Oct 4 2016
Sep 24 2016
This looks like editing the rule while the activity daemon does not respond (in time) is prone to alter the setting?
Maybe disable the combo until there's response from the activity dameon and ensure to not write back the setting until it's enabled?
Sep 19 2016
The statement is legal, this is either a problem in Qt (API break) or the compiler (resolving function signatures, maybe related to "explicit" or template usage)
Sep 15 2016
Sounds reasonable enough, but seems to point out an issue in wayland:
This is BC, but undocumented.