So far it was bound to whether we build for GLES. But this is
semantically wrong. It might be possible that even on desktop gl
epoxy is built without GLX support, thus we need to reflect this.
This change ensures that epoxy/glx.h is only included if available,
that relevant code is bound to it and that checks are in place to
enforce EGL if not build with glx support.
In addtion the glxbackend.cpp is now only included in the build set
if available.
Only those which truly are different are kept as compile time checks.
In addition the index buffer is made available to GLES as in principle
all required functionality is available on gles.
REVIEW: 125865
So far we manually updated the toggled state depending on the button
type and the corresponding client property. This had an error sneaked
in for onAllDesktops: it was bound to desktop change instead of on all
desktop change causing the button to not reflect the state correctly.
To prevent such errors it's now setup to a property binding to the
client's state directly.
BUG: 354702
FIXED-IN: 5.4.3
REVIEW: 125917
A check for whether the button is the maximize/restore button was still
for the old syntax causing always the maximize button and never the
restore to show.
BUG: 354702
FIXED-IN: 5.4.3
If a rule minus the title match matches,
the captionChanged signal is bound to re-evaluate
the rules for that client, ie. the tracking overhead
only exists for those clients where title matching
is relevant and costs rematching all rules when such
client changes its title (yes, the partial matching
rules could be stored for faster re-check, but that
would make the patch bigger and is probably not worth
it; just some string comparisms)
additional tracking of wm_class or wm_role
(what is iirc a netwm violation anyway) would require
to monitor the resp. property for changes (not done atm.)
BUG: 220227
FIXED-IN: 5.5
REVIEW: 125427
While the main plasma desktop containment does one
desktop per screen, that does not necessarily hold
for other containments, let alone other desktop shells
To indicate that the window is "active" ie. can
be dragged or activated (like in present windows)
There was either a bug or a forum post complaining
about the inability to activate windows from DG
They're only traversed and QHash is unordered - so
the worst container. Also we have complete control
over the maintained class, so we can just keep the
mapped EffectWindow there
esp. the list-remove icon looks like "delete" and
can cause worries about what happens to the windows
as a bonus, the buttons now follow the DPI. are a
little smaller (presently might fit touch devices? but
is way to huge on "normal" desktops with ordinary DPI)
and the buttons have nice visible animations on pressing
BUG: 354131
FIXED-IN: 5.5
Heavily inspired by how the glxbackend works: present happens on
rendering start and not on end frame. In addition present needs to
check whether there is something to show to not block incorrectly.
This is needed as present might also be called from going to idle.
With this change the Nexus5 has a decend refresh rate shown in the
totally accurate fps effect. Before it was capped at around 30 fps
which indicates that the refresh rate was halfed.
On the tearfing front the change seems to not have any negative
impact.
allow to minimize some kind of windows, all those that don't
have a plasmashell surface and those that have and have Normal
as role (to be sure to not minimize panel, desktop, etc)
REVIEW:125842
We already unset QT_DEVICE_PIXEL_RATIO to ensure to keep out of
high dpi scaling. Now with Qt 5.6 we also need to set the attribute.
Without we crash on startup as we don't have a screen that early and
well Qt doesn't check whether it's null.
...and use PATH_VARS to make the config file work with absolute paths.
Two reasons to do this:
- DBUS_INTERFACES_INSTALL_DIR is marked deprecated
- Not hard-coding the packackage prefix is helpful on a multiarch
layout where the prefix is /usr/${host} but arch-independent files
should still be installed to /usr/share (i.e a level below the
prefix).
REVIEW: 125843
Similar to X11 world: we send a sync request on each size change and
block till we get the next damage with the proper size.
Testing seems to show a very smooth resize experience. We automatically
sync to the resize speed of the client.
Maybe we need a timeout in case the client isn't able to resize to the
requested size.
Properly handle the mouse press/release events in InputRedirection
while we move windows. If it's the last mouse release event we end
the move resize of the window. For that we reuse the code written
in Client.
The button state was not represented correctly which was very visible
when using the MouseClickEffect. Now MouseClickEffect on Wayland works
as expected.
Methods are no longer virtual. The only x11 specific usage in these
methods (resizeInc) is replaced by a virtual method. Default resize
increments is QSize(1,1) for AbstractClient.
Don't emit both geometryShapeChanged and geometryChanged: the one
is set up to call the other.
Also adjust tests because maximize changes triggers too many geometry
changed signals.
Method no longer virtual and only implemented in AbstractClient.
The implementaton works in a generic way nowadyas.
Added an autotest for the basic packTo behavior for packing against
a screen border. Packing towards other clients still needs adjustments
in the Placement code.
The signals operate on AbstractClient nowadays, so we can have one
implementation for both Client and ShellClient.
Only X specific connections are only done for Client.
So far only moving through useractions menu is possible and only through
cursor control (mouse events are lost).
A basic first autotest is added to validate the moving of Windows.
Sync related code is split out into dedicated virtual methods so that
Client can provide the X11 specific implementation. General handling,
though is completely in AbstractClient.
Implementation is moved to abstract_client.cpp as so far events.cpp
does not have any code from AbstractClient.
This includes moving the electricMaximizingDelay from Client to
AbstractClient.
The implementation of positionGeometryTip is X specific, we need to
figure out whether that one makes sense for Wayland. Given that, let's
have it virtual to ease the transition of code which calls it.
