We animated from 1.0 to 0.0, however this does not take into account
that a previous effect may also have adjusted the opacity.
We should multiply accordingly.
We currently have "windows from current desktop" and "windows from
class" but not one combining both. This adds that mode along with a
(default empty) shortcut and border activation.
BUG: 413342
This fixes makes ExpoLayout independent of its position on a screen,
which in turn stops it from randomly reflowing while dragging a virtual
desktop across desktop grid. It also removes an unwanted animation at
the end of activation of desktop grid: desktops move in place and then
windows proceed to adjust themselves resulting in a double animation.
FIXED-IN: 5.25.5 5.26
Inheriting "active" state was meaningless, since "active" state binds
position to a ExpoCell which itself is in a disabled state.
FIXED-IN: 5.25.5 5.26
When no qml items manage the arrow key event, the root item will manage it looking to give focus to a view in the given direction derived from the arrow key
BUG:455783
This is most likely just an oversight/omission from the times when the
component was actively developed. There are five states total, including
one for realtime interactions; four others need to be transitioned to.
Due to nondeterministic nature of signal propagation in QML, changing
both targetScale and state depending on dragHandler's activity could
result in targetScale wrongly updating before the state change(and thus
applied property changes and subsequent animated transition).
This fixes a bug when a window dragged to the top (but not onto another
desktop) would animate its position back to its original position on a
heap, but the scale would remain constant until the end of animation
and only then rapidly jump back to a normally scaled state.
Otherwise this WindowHeap type is not usable without custom delegate.
/usr/lib/qml/org/kde/kwin/private/effects/WindowHeap.qml:111:23:
QML Component: Cannot create delegate
/usr/lib/qml/org/kde/kwin/private/effects/WindowHeapDelegate.qml:21:5:
Required property windowHeap was not initialized
This targetOpacity is nowhere to be found. This is a relic of past
development. Currently code that needs to alter opacity based on drag
state does so externally by setting opacity on a delegate as a whole.
Code such as "screenRect.bottom() - windowGeo.bottom()" assumes that
both screenRect and windowGeo have the same type. At the moment, it's
not the case, screenRect has QRect type and windowGeo has QRectF type,
so the calculated offset will be off by one.
This adds window filtering to the Overview effect. This satisfies both
Overview users' needs and the workflow of Windowview: When the user
starts typing, windows are filtered by default. If there is no matching
window, then the Milou UI is shown, including the option for opening a
new app is shown--the same one that currently gets shown when the user
starts typing. This leads to a very seamless experience, where the user
can type any app name and they will get it, no matter if it's already
opened or not.
Due to the wrong buffer format, the function failed with
GL_INVALID_OPERATION error, which was silently ignored by the effect.
It resulted in the constant phantom color being returned over and over
again.
Co-Authored-By: David Edmundson <kde@davidedmundson.co.uk>
BUG: 454974
FIXED-IN: 5.24.7, 5.25.4, 5.26
An effect that implements the "identify" functionality of
the screen configuration kcm. It displays a label on each
screen that identifies the screen.
Doing this as a kwin effect allows to correctly handle
the case when outputs are mirrored (on wayland) compared to
absolute positioning of windows which end up on top of each other.
If a DesktopView doesn't handle a keyboard navigation event it
propagates to main which then focusses the next desktop view and the
relevant window.
Empty desktops can also be selected.
BUG: 456068
In WindowHeap we currently always accept the keyboard event regardless
of whether the event was handled.
This will allow the event to propagate to other handlers
In WindowHeap we currently always accept the keyboard event regardless
of whether the event was handled.
This will allow the event to propagate to other handlers
Currently, the highlight effect is not very visible because it only
barely peeks out of the window thumbnail. We can make it bigger by
making it peek out a little bit more, and also by including the window
title and icon (when visible) within it.
BUG: 454842
In the desktop grid effect, dragging an empty area of a desktop to
another desktop swaps all windows on the two desktops. This change makes
sure that this matches only windows in the current activity.
Was earlier fixed in
1e0b0c881e
, but the bug was reintroduced by the QML rewrite.
BUG: 386769
With fractional scaling integer based logical geometry may not match
device pixels. Once we have a floating point base we can fix that. This
also is
important for our X11 scale override, with a scale of 2 we could
get logical sizes with halves.
We already have all input being floating point, this doubles down on it
for all remaining geometry.
- Outputs remain integer to ensure that any screen on the right remains
aligned.
- Placement also remains integer based for now.
- Repainting is untouched as we always expand outwards
(QRectF::toAdjustedRect().
- Decoration is untouched for now
- Rules are integer in the config, but floating in the adjusting/API
This should also be fine.
At some point we'll add a method to snap to the device pixel
grid. Effectively `round(value * dpr) / dpr` though right now things
mostly work.
This also gets rid of a lot of hacks for QRect right and bottom which
are very
confusing.
Parts to watch out in the port are:
QRectF::contains now includes edges
QRectF::right and bottom are now sane so previous hacks have to be
removed
QRectF(QPoint, QPoint) behaves differently for the same reason
QRectF::center too
In test results some adjusted values which are the result of
QRect.center because using QRectF's center should behave the same to the
user.
Sometimes windows on other desktops are higher in the stacking order,
which causes them to unexpectedly jump above windows from the current
desktop in the effect.
To fix that, the z index is adjusted to be higher for windows on the active
virtual desktop, and windows from other desktops get reduced opacity in the
beginning of the animation
The slide effect translates all windows as we switch desktop. In a multi
screen setup we don't want windows to enter a different screen during
this animation.
The current code masks everything to the current output. This is broken
for any window that spans across screens even slightly. It will not be
visible during the transform then appear on top at the end.
The new algorithm is, for each screen in each window we crop the painted
area to the intersection of the screen and the screen's translated
position.
ScreenPaintData provides a way to transform the painted screen, e.g.
scale or translate. From API point of view, it's great. It allows
fullscreen effects to transform the workspace in various ways.
On the other hand, such effects end up fighting the default scene
painting algorithm. For example, just have a look at the slide effect!
With fullscreen effects, it's better to leave to them the decision how
the screen should be painted. For example, such approach is taken in
some wayland compositors, e.g. wayfire, and our qtquick effects already
operate in similar fashion.
Given that, strip the ScreenPaintData of all available transforms. The
main motivation behind this change is to improve encapsulation of item
painting code and simplify model-view-projection code in kwin. It will
also make the job of extracting item code for sharing purposes easier.
These are proper nouns and should be capitalized. And let's consistently
use the term "Virtual Desktop", not just "Desktop" (which can be
confused for the desktop with the wallpaper).
This makes it so that the windowview/overview/desktopgrid effects
all use the middle mouse button to close windows.
The previous behavior of pinning window is now assigned to the
right mouse button.
BUG: 456144
effects->desktopCoords() returns the position of the desktop in pixels,
while we want the desktop grid coords, i.e. if the virtual desktop is in
the first row, second column, we want m_currentPosition to be (1, 0).
After the 5.25 update, one could not see which window was highlighted until one
manually unfocused the SearchField and then pressed any key to refresh the WindowHeap.
Also, the searchbar would (most of the time) "absorb" the arrow keys so one had to
also unfocus it to really be able to select windows with they keyboard.
With this change, there is always one window highlighted while filtering using the
search box. Also, one can select another window with the arrow keys without manually
unfocusing the searchbox. This heavily improves the keyboard functionality in this
effect that got lost with the 5.25 update of presentwindows to windowview and
resolves complaints about the keyboard navigation being buggy.
BUG: 455633
BUG: 455764
BUG: 455099
BUG: 455586
BUG: 455753
FIXED-IN: 5.25.2
This makes easier for individual effects to personalize it
without adding ad-hoc api in the main WindowHeap class.
WindowHeap and WindowHEapDelegate are still quite coupled and thing can probably still be improved, but the code should be more readable already
At the moment, the effect that animates the screen works as follows:
* render the screen before it's rotated in an offscreen texture
* after screen rotated, paint the offscreen texture in the first half of
the animation but not the screen contents after rotation and in the
second half of the animation, paint the live screen contents
This works but it doesn't take into account things such as blur (I can
see that the region around where the panel should be doesn't look as
expected).
This change makes the screen transform effect do proper cross-fading,
i.e. save the screen before it's rotated in an offscreen texture, render
the current screen in an offscreen texture, and produce the final result
by cross-fading between two offscreen textures in a shader.
Besides fixing the visuals of the effect, another motivation behind this
change is to reduce the number of ScreenPaintData transforms, which can
be very handy in simplifying item painting code.
The drag manager of a window now can take over from anything, so that
the events to initiate a drag are not stolen by the tap handlers
(fixes the drag starts only the second time is tried issue)
On wayland drag by touch was completely broken by the supportsclosewindows check,
now the touch drag handler is always active and the check of the property is done only
when the drag is over
BUG:455268
use a property of the effect itself to store the search text
so all the views will search for the same thing at the same time.
BUG: 455353
FIXED-IN: 5.25.1
At the moment, it's possible to activate a qtquick effect while another
qtquick effect is already active, we have code that prevents fullscreen
effects overriding each other, yet that still happens.
The reason for that behavior is that the gesture recognizer will mark
all gestures as started when user starts swiping on touchpad and cancel
gestures as more swiping occurs. This can mistrigger toggling logic in
the window view effect and the desktop grid effect, etc.
In order to make handling of gesture cancellation correct, we could
check whether user has swiped enough to deactivate window view, or
desktop grid. This change tries to implement exactly that.
As a side-effect, it also allows toggling the effect with the same
gesture. However, we should make cancellation gestures opposite of
activation gestures, i.e. if 4 swipe up gesture is used to activate an
effect, then 4 swipe down gesture should be used to deactivate the
effect.
Don't disable the main drag handler when canclosewindows is disabled,
that one is not used to close windows but to drag them on other desktops or screens
BUG: 455268
At the moment, blur shader code is barely readable because the code is
constructed at runtime.
Since ShaderManager handles opengl context profiles when loading shaders
from files, we can improve code readability by splitting shader code in
the corresponding files.
Note that ShaderManager adds "precision highp float;" for convenience
(whether using "highp" is okay is up for debate).
Redirect key events to search field so user can search for windows
without manually focusing the search field. It matches the behavior of
the overview effect.
BUG: 455100
If a window is added and then the current virtual desktop changes, we
can encounter the following situation:
* desktopChanged signal is emitted, and the slide effect starts
animation. SlideEffect::prepareSwitching() will setup windows; note
that the new window may be present in effects->stackingOrder()
* windowAdded signal is emitted, and slide effect tries to ref the
window again
In order to ensure that there's only one reference, maintain visibility
refs in a hashtable.
BUG: 455237
Originally, DeformEffect was meant to be used in effect that deform
windows, but its usage has become wider than anticipated. This change
renames the DeformEffect to OffscreenEffect to accommodate for that.
Allow dragging windows between screens, using a placeholder thumbnail item to
render part of the thumbnail on the other screen.
BUG: 283333
BUG: 453996
BUG: 448566
There are a few benefits to using smart pointers from the standard library:
- std::unique_ptr has move semantics. With move semantics, transfer of ownership
can be properly expressed
- std::shared_ptr is more efficient than QSharedPointer
- more developers are used to them, making contributions for newcomers easier
We're also already using a mix of both; because Qt shared pointers provide
no benefits, porting to standard smart pointers improves consistency in
the code base. Because of that, this commit ports most of the uses of QSharedPointer
to std::shared_ptr, and some uses of QScopedPointer to std::unique_ptr
When zoom factor is 1, the zoom effect will paint the scene in an
offscreen texture, but not actually paint the textures on the screen.
Zoom factor can be 1 when the effect has been just stopped.
BUG: 454407
When the effect closes, all the extra data attached to the window
(offToCornerId and apertureCorner properties) are not valid anymore
and need to be reset right after the animation end.
also manage the two edge cases where a window either appeared or
got minimized while the effect was running to either show it or not
BUG: 454280
On Wayland, screens are repainted independent of each other. If zooming
animation stops on one screen, other screens may still be stuck in the
zoomed state and therefore result in potential flickering. Issue a full
screen repaint when zooming stops to ensure that other screens are
repainted with "unscaled" contents.
BUG: 454407
Part-of: <https://invent.kde.org/plasma/kwin/-/merge_requests/2472>
Currently, if you want to use TimeLine, you need to track the last
presentation timestamp which boils down to carrying some boilerplate
code.
The current situation can be improved by making TimeLine work with
presentation timestamps.
Part-of: <https://invent.kde.org/plasma/kwin/-/merge_requests/2473>
The magnification filter was changed to GL_NEAREST with the reasoning
that "pixel granularity" would be more correct. Perhaps that was not a
bright idea. Change it back to GL_LINEAR.
BUG: 454408
Part-of: <https://invent.kde.org/plasma/kwin/-/merge_requests/2471>
The config group is formed as "Effect-" + plugin id, i.e. "desktopgrid"
Config migration from DesktopGrid to desktopgrid is already handled by
a kconf_update script.
BUG: 454102
Part-of: <https://invent.kde.org/plasma/kwin/-/merge_requests/2464>
This fixes integration of the zoom effect with the blur effect and qtquick
effects such as overview or window view.
The main con of the proposed solution is that offscreen rendering can be
a bit overkill. But on the other hand, it's the most robust way to
ensure that fullscreen effects integrate correctly with the zoom effect.
For example, without it, the quick scene effect would need to figure out
what screen views to paint for the given screen. There are also more
finicky cases, e.g. the screen transform effect.
BUG: 447002
BUG: 447670
BUG: 453467
Tested-by: Merge Service <https://invent.kde.org/plasma/kwin/-/merge_requests/2451>
Part-of: <https://invent.kde.org/plasma/kwin/-/merge_requests/2451>
The Blendchanges effect works by showing a snapshot of the current
screen for a few ms. Any other active full screen effect will look
broken, so it should take priority.
This is pre-empting an issue with a new Plasma feature that syncs
colours to wallpapers. Once we animate activity switches / have per
desktop wallpapers it'll glitch out.
As we don't provide any ability for the user to configure the gestures yet,
the gesture for the desktop grid should stay as it was in the last release.
This commit swaps the gestures for desktopgrid and overview to achieve that.
Overview is quite polished now, enough that we have a default touchpad
gesture that opens it by default. It's time to move it out of public
beta and enable it by default, and this commit does that.
BUG: 446753
FIXED-IN: 5.25
This makes it consistent with WindowView (and the panel window doesn't respond
to input anyways even if shown, which is misleading).
BUG: 444274
FIXED-IN: 5.24.6
This change makes the WindowItem track the opacity and schedule a
repaint. It further decouples the legacy scene from code window
abstractions.
It's an API breaking change. WindowPaintData no longer can make windows
more opaque. It only provides additional opacity factor.
This allows to toss a large amount of custom rendering code.
Furthermore, it removes the build-time dependency on Plasma Framework
for FrameSvg and Theme from KWin core as it's pulled in through QML
imports now.
It also cleans up the API and removes functions that are effectively
unused or no-op after this change.
For instance, effects often destroy their effect frames
in pre/postPaintScreen, which would now destroy an `OffscreenQuickView`,
which changes GL context. This is alleviated by delaying detruction
of the internal view.
Support for the features of text cross-fade and selection frame,
which are not used by any of the built-in effects, is dropped.
Signed-off-by: Eike Hein <eike.hein@mbition.io>
The lanczos filter depends on the effect system. It makes very difficult
changing painting code from SceneWindow to Item.
Given that the last big users of the laczos filter - present windows and
desktop grid effects were re-written in QML. The only remaining user of
the lanczos filter is the thumbnail aside effect. Given that it's a
really obscure usecase, switching to the linear filter won't be very
noticeable.
As a backup plan, one can reimplement the thumbnailaside effect using
QML. The lanczos filter is already implemented in plasma-framework.
since it has been replaced by windowview, and Desktop Grid
is ported as well, remove present windows which is effectively dead code
now
BUG:447001
BUG:362844
BUG:450487
BUG:453426
BUG:374481
BUG:185381
BUG:413342
BUG:451150
BUG:283333
BUG:315314
BUG:397500
BUG:321236
BUG:436572
BUG:335782
* give windowview the ability to show windows from current desktop, all
desktops or current class
* invokable from shortcuts screen edges or gestures
* add a search field to quickly filter
* current present windows effect still present but only internal as is used by desktop grid, which should eventually be ported as well
This can be done either from windowview or overview, tough note that some of the duplication from overview added in windowview is necessary regardless, as WindowHeap, the shared qml part needs some properties exposed from the c++ part.
Implementation wise I'm ok for it being in either place, but i think the functionality of present windows needs to be preserved, otherwise would be a completely unacceptable regression, namely:
* Behavior of what now are the ctrl+f7,f10 and f11 global shortcuts, showing windows of current app (invokable by shoortcut instead of having to use the pointer), windows of current desktop (the only thing overview does atm) or all desktops
* filter on typing, as opposed to invoking krunner. main use case of present windows is quickly switching, and filtering is the most helpful feature, some people do like krunner instead, but is completely out of place for my use case, and i suspect for many other users as well
* also clicking on a taskbar group should be possible to filter
* the view that opens by clicking on a taskbar group should follow the same layout strategy used elsewhere and currently being an effect used only there and not accessible form the list can't even be configured
With this, the WindowItem will know whether it's actually visible. As
the result, if a native wayland window has been minimized, kwin won't
try to schedule a new frame if just a frame callback has been committed.
EffectWindow::enablePainting() and EffectWindow::disablePainting() act
as a stone in the shoe. They have the final say whether the given window
is visible and they are invoked too late in the rendering process.
WindowItem needs to know whether the window is visible in advance,
before compositing starts.
This change replaces EffectWindow::enablePainting() and
EffectWindow::disablePainting() with EffectWindow::refVisible() and
EffectWindow::unrefVisible(). If an effect calls the refVisible()
function, the window will be kept visible regardless of its state. It
should be called when a window is minimized or closed, etc. If an effect
doesn't want to paint a window, it should not call effects->paintWindow().
EffectWindow::refVisible() doesn't replace EffectWindow::refWindow() but
supplements it. refVisible() only ensures that a window will be kept
visible while refWindow() ensures that the window won't be destroyed
until the effect is done with it.
If an effect is reloaded while it holds deleted references, it's
possible that the closed windows will get stuck in the "zombie" state.
This change introduces EffectWindowDeletedRef helper that can be
used to keep the closed window alive as long as the reference is valid.
If you lift fingers but not swipe them enough to switch to another
virtual desktop, the slide effect will play an animation to move from
the current position in the virtual desktop grid to the current desktop.
However, that animation doesn't feel right, there's something missing.
The slide effect uses a TimeLine to animate switching between virtual
desktops, it's great if the amount of sliding is constant.
This change makes the slide effect use the mass-spring-damper model to
simulate the motion of a spring in order to animate switching between
virtual desktops.
The mass-spring-damper equation is integrated using RK4. If the delta
interval is not multiple of the integration step precisely, the
SpringMotion will perform integration as many times as the integration
step fits into the delta. The leftover will be used for LERP between the
previous and the next integration results.
With the spring animation, the slide animation feels more natural when
you lift fingers. If you switch between virtual desktops without using a
gesture, the slide animation should look almost the same as if it were
implemented with the TimeLine.
If the animation reaches the end, desktop grid may render the screen
incorrectly. Make sure that PAINT_SCREEN_BACKGROUND_FIRST and flags as
such are set even if animation has reached the end.
Also, while on this, simplify the paintWindow() method by removing
redundant effect status checks.
effects can specify in their json file "X-KWin-Border-Activate":true
and will be listed in the edge menus.
Don't hardcode desktop grid and overview in the kcms
At the moment, if user switches between virtual desktops using a
gesture, panels will loose blurred background because WindowForceBlurRole
is not set.
This change refactors setup code so the slide effect always forces blur
and background contrast when sliding between virtual desktops using a
gesture or animation.
Possibility to implement realtime screenedges gestures in scripted effects,
implement it in the windowsaperture show desktop effect.
* Expose registerRealtimeScreenEdge to JavaScript, the callback will be
a JS function.
* Add the concept of freezeInTime() in the animation js bindings,
it will either create an animation frozen at a given time or freeze a running animation
that can be restored and ran to completition at any time
* add an edges property only for showdesktop as it's not directly on the effect configuration
This makes KWin switch to in-tree copy of KWaylandServer codebase.
KWaylandServer namespace has been left as is. It will be addressed later
by renaming classes in order to fit in the KWin namespace.
being naturalx something that needs to map to the actual geometry of the window which is in absolute coordinates but mapped to a view which geometry correspond to the one of one particular screen (plus the layout the thumbnail lives in has its own geometry in the scene)
Fixed a bunch of bugs and polished the slide effect.
Plugged the slide effect into the new VirtualDesktopManager interface desktopChanging() to allow for mac os style desktop switching.
BUG: 448419 BUG: 401479
The Window View effect is a companion effect for the task manager. It
provides the task manager a way to ask the user to pick a window among
windows identified by window ids passed to the activate() method.
The main motivation for adding this effect is to provide a QtQuick based
alternative for the present windows effect, which is needed to kill the
latter.
This change doesn't extend the overview effect to avoid repeating
mistakes of the past, i.e. adding too many (unrelated) features to the
present windows effect.
While the overview effect provides you a way to select windows, it's not
the only thing that it has. For example, it also allows changing virtual
desktops, etc.
On the other hand, the task manager doesn't need all of that. It only
needs to ask the user to pick a window among the specified windows, nothing
more.
As is, the window view effect is simply WindowHeap with a d-bus api slapped
on top of it.
GLRenderTarget doesn't provide a generic abstraction for framebuffer
objects, so let's call GLRenderTarget what it is - a framebuffer.
Renaming the GLRenderTarget class allows us to use the term "render
target" which abstracts fbos or shm images without creating confusion.
In the desktop grid effect, dragging an empty area of a desktop to
another desktop swaps all windows on the two desktops. This change makes
sure that this matches only windows in the current activity.
BUG: 386769
FIXED-IN: 5.24.5
- added option to remove the frametime graph
- added option to remove the "this is a benchmark" message
- location of the fps counter is now on the "active" monitor by default
- removed the hard-limit of 100 for the FPS counter
- added option to color the text based off the FPS value
When changing global settings like switching between light and dark
themes the result is currently quite messy. Apps update in a scattered
order and a jarring change.
The solution is heavily inspired from Gnome, we cache the window for X
milliseconds, then perform a crossfade between the cache and current
contents.
It does mean any video is paused for half a second, but pragmatically
it's not really bothersome.
On receipt of an explicit DBus method call we create a cache and start
animating. The explicit method call is needed so that we can guarantee
kwin has a fully copy before a client might change.
Use of an offscreen texture is used so that we include any window
decorations. The DeformEffect effect is repurposed as it has most the
relevnat logic if we remove the live updating.
* Makes the close button on thumbnails always visible: besides making it usable on touch, makes it more usable with mouse as well
* add a drag down gesture to close windows, moving opacity to zero while dragigng down to signal the window will be destroyed
* restore behavior animations: animate changes in thumbnails size or positions when not in drag mode or drag gesture to not make jarring sudden changes after closing a window or at end of drag mode
Swipe with three fingers
- left to switch to the previous virtual desktop
- right to switch to the next virtual desktop
- up and down to toggle the overview
CCBUG: 439925
The .clang-format file is based on the one in ECM except the following
style options:
- AlwaysBreakBeforeMultilineStrings
- BinPackArguments
- BinPackParameters
- ColumnLimit
- BreakBeforeBraces
- KeepEmptyLinesAtTheStartOfBlocks
support realtime activation for screenedges gestures, making it possible
for effects to show half-triggered states while dragging from
the edge with a finger, making them much more usable
They still aren't realtime animated, but by making them respond to the
realtimeGesture() call, they can use callbacks to determine if they should be shown
or not. This allows you to swipe up, have it trigger, then swipe down in the same
motion and get it to untrigger without ever having to release.
Fixed a bunch of bugs and polished the slide effect.
Plugged the slide effect into the new VirtualDesktopManager interface desktopChanging() to allow for mac os style desktop switching.
BUG: 448419 BUG: 401479
This reverts commit ca7fc44814.
Reverting work with no explanation is unacceptable, especially when
you've already been asked to stop multiple times.
CWG has already been contacted regarding this conduct, which is
starting to seem like vandalism of KDE's codebase. I am CCing sysadmins
and officially recommending an emergency recovation of commit access
for uhhadd@gmail.com to prevent further abusive behavior.
CCMAIL: uhhadd@gmail.com
CCMAIL: sysadmin@kde.org
This reverts commit 154528cdef.
This commit was reverted with no explanation, context, or discussion. In
the future, please discuss things like this before doing them. KWin is a
community project, not a personal playground.
CCMAIL: uhhadd@gmail.com
This fixes a bug introduced in https://invent.kde.org/plasma/kwin/-/merge_requests/2045 where it would no longer check if it should redraw the whole region unless the data clip intersected. This would lead to flickering in certain cases
BUG: 421135
Having blurRegion to identify if a decoration supports blur or not instead of the metadata-json way has the following benefits:
- decorations can now provide both blur or not based on user preference
- theme engines such as Aurorae do not have to enforce blur or not to their themes and they can support blur enabled and disabled themes at the same time if they want to
- blurRegion is empty by default so the Korners bug will be fixed for all solid aurorae themes. Breeze and Oxygen have set **blur:false** so nothing changes for them.
- all aurorae themes that do not require blur will free up system resources by default
This adds support for animating showing/hiding of the input method panel
to the sliding popup effect, if the input panel is of type "Toplevel".
This is mainly intended to animate showing the virtual keyboard and has
been primarily tested with Maliit. It replaces the client-side animation
that Maliit would do, instead doing the animation on the KWin side which
provides a significantly smoother experience.
This makes it easier to cross-compile KWin since it is no longer necessary
to have all the KWin dependencies on the host machine. This could be
partially addressed by moving the strip-effects-metadata.cpp into a
separate folder than can be built as a top-level project, thereby reducing
the dependencies to just QtCore. However, it still means we have to build
a native binary. Since all this script is doing is removing some JSON keys,
we could also use a python script and avoid the need to compile a
build-time helper program.
Notifications are really only useful in a setting with a full
shell environment where there is a notification center to display them.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
It is automatically called (and documented as such) by KCModule
after the constructor is run.
This avoids calling a virtual method from the constructor.
Signed-off-by: Eike Hein <eike.hein@mbition.io>
None of the features it adds ontop of `QComboBox` are used.
Allows to drop the dependency on KCompletion.
Signed-off-by: Eike Hein <eike.hein@mbition.io>
Currently, the blur effect will shrink an opaque region even if it
doesn't intersect m_currentBlur.
This ensures that the blur effect won't do a stupid thing such as
clipping the opaque region of the desktop window.
It's not guaranteed that there will be current render target in
postPaintScreen() as all painting have been completed. paintScreen() is
a much safer place to pick color.
It's not guaranteed that there will be current render target in
postPaintScreen() as all painting have been completed. Furthermore,
even the docs of the postPaintScreen() function indicate that no
painting should be done there, you can do only cleanup things, e.g.
schedule a repaint, etc. paintScreen() is a much safer place to
capture screenshot.
Whilst global shortcuts are blocked by grabbing the keyboard, user set
up manual scripts can still invoke a global action.
Given we already have code to deactivate when locking it makes sense to
also prevent activation.
BUG: 450331
qApp is defined differently depending on whether QCoreApplication,
QGuiApplication, or QApplication is included.
Use QGuiApplication::instance() to improve code readability.
CCBUG: 450359
qApp is defined differently depending on whether QCoreApplication,
QGuiApplication, or QApplication is included.
Use QGuiApplication::instance() to improve code readability.
CCBUG: 450359
If a window appears on the screen, the highlight window effect will try
to fast-forward animation to the target state by setting the animation
duration to 0. However, TimeLine doesn't like that because it will
eventually lead to division by zero.
This change makes the highlight window effect fast-forward the
transition to highlight or ghost state by using the complete() function.
BUG: 450323
Having a render loop in the Platform has always been awkward. Another
way to interpret the platform not supporting per screen rendering would
be that all outputs share the same render loop.
On X11, Scene::painted_screen is going to correspond to the primary
screen, we should not rely on this assumption though!
This allows us to make the GLRenderTarget a bit nicer when using it to
wrap the default fbo as we don't know what the color attachment texture
is besides its size.
This means that the responsibility of ensuring that the color attachment
outlives the fbo is now up to the caller. However, most of kwin code
has been written that way, so it's not an issue.
