D22418: WIP [wayland] make automatic backend selection truly automatic

[Martin Flöser]

graesslin added a comment.


  I'm not convinced that removing the ifdef is the solution to the problem. 
What you basically want is being able to do an out-of-tree build of a backend. 
Ideally you would want to install all the variants next to each other and be 
able to pick the correct one.
  
  So what about the following idea: The plugins provide the command line 
arguments themselves (e.g. a static method that's queried) and specify the 
checks themselves. Thus we would externalize the resolution to the plugin.

REPOSITORY
  R108 KWin

REVISION DETAIL
  https://phabricator.kde.org/D22418

To: alexeymin, romangg, #kwin
Cc: PureTryOut, graesslin, kwin, plasma-devel, LeGast00n, fmonteiro, sbergeron, 
jraleigh, fbampaloukas, GB_2, mkulinski, ragreen, jackyalcine, Pitel, iodelay, 
crozbo, bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
hardening, jensreuterberg, abetts, sebas, apol, mart

D22418: wayland: make automatic backend selection truly automatic

[Martin Flöser]

graesslin added a comment.


  Is there a real world situation where KWin is getting compiled twice with 
different settings? When adding the ifdefs this was based on feedback from 
distributions

REPOSITORY
  R108 KWin

REVISION DETAIL
  https://phabricator.kde.org/D22418

To: alexeymin, romangg, zzag
Cc: graesslin, kwin, plasma-devel, LeGast00n, sbergeron, jraleigh, 
fbampaloukas, GB_2, mkulinski, ragreen, jackyalcine, Pitel, iodelay, crozbo, 
bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
hardening, jensreuterberg, abetts, sebas, apol, mart

Re: RFC: Running clang-format across all Plasma (and more?) repos

[Martin Flöser]

Am 2019-07-11 16:18, schrieb David Edmundson:

One topic discussed at the recent Plasma sprint was that we should run
a code formatting tool (clang-format) over all our repos to ease all
future review comments about whitespace.

All new contributions simply have to run the same tool and we get
consistent code without having to comment on every minor thing in a
review individually.

I've written up a wall of text outlining steps, challenges etc.
https://phabricator.kde.org/T11214

Does anyone have any thoughts / objections?


As someone being guilty of only focusing on whitespace changes I'm very 
much in favor of this idea.


Cheers
Martin

Re: Proposal: passing user idle time to systemd-logind

[Martin Flöser]

Am 2019-05-24 21:51, schrieb Aleix Pol:

On Wed, May 22, 2019 at 6:13 PM Germano Massullo
 wrote:


Hello, I am writing to you to propose the following reasoning, hoping
that it can help making easier (just a bit) third parties development
work on Linux.
I am currently developing BOINC client user idle time detection on
Linux systems (both graphical or tty sessions)
After some studies I started writing a little piece of code that that
is able to print on standard output the user idle time by retrieving
it from systemd-logind IdleSinceHint property (that is exposed on
DBus). By the way I found out that this value was always 0 [1], so I
asked why [2]. I have been told that logind relies on the desktop
environment to pass this information.
Many d.e. expose user idle time to their own DBus path, (i.e.
org.gnome.Mutter.IdleMonitor), so I will be forced to write code that
depends on the specific desktop environment. Since:
1) systemd-logind is just ready for exposing user idle time;
2) for a developer writing code for Linux it would be much easier to
retrieve user idle time from a unique place rather than having to deal
with all various desktop environments;
I would like to ask you what do you think about passing the user idle
time to logind [3] [4] ?

Best regards

[1]: you can try with system console command
$ sleep 2 && gdbus introspect --system --dest org.freedesktop.login1
--object-path /org/freedesktop/login1 | grep IdleSinceHint
[2]: 
https://lists.freedesktop.org/archives/systemd-devel/2019-May/042726.html
[3]: 
https://www.freedesktop.org/wiki/Software/systemd/writing-desktop-environments/
[4]: 
https://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/


We are using the kidletime framework to do that on our applications:
https://api.kde.org/frameworks/kidletime/html/index.html

IIRC, In X11 it happens through mere X11 observation, in wayland
there's a protocol for that,
It could make sense to expose this data to logind and even consume it
like that from applications. Why not.


When implementing kidletime support for Wayland I also looked at the 
logind property and came to the conclusion that it's totally useless. 
The property provides the idle time. But that is not what anybody is 
interested in. What one needs are notifications (to the application) 
like idle for five minutes. That's exactly what kidletime provides.


The problem with the idle time in logind is that it keeps 3 applications 
busy:
* the Wayland compositor needs to update the time, although it's 
currently sleeping
* applications need to actively poll the logind property to check how 
much has passed
* logind is kept busy due to the polling of the applications and due to 
the compositor updating the property.


I'm all for having something standardized, ideally working on both X11 
and Wayland, but the logind interface is unfortunately not the solution.


We can add support for logind but it would be very cross. E.g. only 
providing idle for one minute, idle for five minutes, 10 minutes, 15 
minutes, 30 minutes, one hour. Everything else just causes too much 
stress on the sleeping KWin (I like KWin best when it's sleeping ;-) ).


Cheers
Martin

D18564: Remove support for KWin's QPA plugin for KWindowSystem

[Martin Flöser]

graesslin created this revision.
graesslin added reviewers: KWin, Plasma.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
graesslin requested review of this revision.

REVISION SUMMARY
  KWin added a plugin for itself, thus it's no longer needed.
  
  See: 02a0561016c22be906350bca68973f2818b727d7 
 in 
kwin.git

REPOSITORY
  R130 Frameworks integration plugin using KWayland

BRANCH
  no-kwin

REVISION DETAIL
  https://phabricator.kde.org/D18564

AFFECTED FILES
  src/windowsystem/wayland.json

To: graesslin, #kwin, #plasma
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D16945: Fix fallback to built-in ui

[Martin Flöser]

This revision was automatically updated to reflect the committed changes.
Closed by commit R133:dfd02160746b: Fix fallback to built-in ui (authored by 
graesslin).

REPOSITORY
  R133 KScreenLocker

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D16945?vs=45744=49330

REVISION DETAIL
  https://phabricator.kde.org/D16945

AFFECTED FILES
  greeter/greeterapp.cpp

To: graesslin, #plasma, davidedmundson
Cc: davidedmundson, plasma-devel, kvanton, jraleigh, GB_2, ragreen, Pitel, 
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D16943: Disable kcrash in greeter in same way as in KWin

[Martin Flöser]

This revision was automatically updated to reflect the committed changes.
Closed by commit R133:552932c8baab: Disable kcrash in greeter in same way as in 
KWin (authored by graesslin).

REPOSITORY
  R133 KScreenLocker

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D16943?vs=45629=49329

REVISION DETAIL
  https://phabricator.kde.org/D16943

AFFECTED FILES
  greeter/greeterapp.cpp

To: graesslin, #plasma, #kwin, bshah, davidedmundson
Cc: plasma-devel, kvanton, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17659: Set parent window for dialogs

[Martin Flöser]

graesslin added a comment.


  In D17659#389728 , @volkov wrote:
  
  > I mean this plugin: https://cgit.kde.org/kwin.git/tree/plugins/qpa
  
  
  That is KWin's own plugin. No binary except KWin can use it.

REPOSITORY
  R838 Flatpak Support: KDE Portal for XDG Desktop

REVISION DETAIL
  https://phabricator.kde.org/D17659

To: volkov, jgrulich, apol
Cc: graesslin, broulik, apol, plasma-devel, kvanton, jraleigh, GB_2, ragreen, 
Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, mart

D17706: Fix lock screen focus

[Martin Flöser]

graesslin added inline comments.

INLINE COMMENTS

> greeterapp.cpp:460
>  // w->setFocus(Qt::OtherFocusReason); // FIXME
> +w->setFlags(w->flags() | Qt::X11BypassWindowManagerHint);
>  }

David already said it: we cannot do this. Changing the 
X11BypassWindowManagerHint flag after the window is created is not supported by 
X11 protocol! We really, really cannot do this.

REPOSITORY
  R133 KScreenLocker

REVISION DETAIL
  https://phabricator.kde.org/D17706

To: andreyby, davidedmundson
Cc: graesslin, abetts, davidedmundson, plasma-devel, kvanton, jraleigh, GB_2, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, 
mart

D17659: Set parent window for dialogs

[Martin Flöser]

graesslin added a comment.


  In D17659#379912 , @volkov wrote:
  
  > Is it possible to implement support for foreign windows in KWin QPA plugin?
  
  
  There is no such thing as a KWin QPA.

REPOSITORY
  R838 Flatpak Support: KDE Portal for XDG Desktop

REVISION DETAIL
  https://phabricator.kde.org/D17659

To: volkov, jgrulich, apol
Cc: graesslin, broulik, apol, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, mart

D17758: Disable KDE ServerDecoration on Qt > 5.12

[Martin Flöser]

graesslin accepted this revision.
graesslin added a comment.
This revision is now accepted and ready to land.


  I still have Qt 5.11, so I'll try to compile the change and give it a try.

INLINE COMMENTS

> kwaylandintegration.cpp:127
> +
> +if (QLibraryInfo::version() >= QVersionNumber(5, 12, 0))
> +{

PlasmaIntegration is compile time bound, right?

REPOSITORY
  R135 Integration for Qt applications in Plasma

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D17758

To: davidedmundson, #kwin, #plasma, graesslin
Cc: graesslin, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17659: Set parent window for dialogs

[Martin Flöser]

graesslin added a comment.


  In D17659#379007 , @apol wrote:
  
  > LGTM, I also missed this!
  >
  > Maybe it would make sense to add a TODO about implementing it for Wayland?
  
  
  Even better would be to just implement it for Wayland. 
https://api.kde.org/frameworks/kwayland/html/classKWayland_1_1Client_1_1XdgExporter.html
 and 
https://api.kde.org/frameworks/kwayland/html/classKWayland_1_1Client_1_1XdgImporter.html
 are the relevant classes.

REPOSITORY
  R838 Flatpak Support: KDE Portal for XDG Desktop

BRANCH
  Plasma/5.14

REVISION DETAIL
  https://phabricator.kde.org/D17659

To: volkov, jgrulich, apol
Cc: graesslin, broulik, apol, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, mart

D17217: Implement free memory notifier

[Martin Flöser]

graesslin added a comment.


  I don't think that this is useful - sorry. I run out of memory about once 
every five years, so polling every five seconds is way too often and a waste of 
resources. On the other hand the time when it happens polling 5 sec is way too 
low as then we are already dead. This can only happen if an application eats 
memory and then it's going fast.

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D17217

To: McPain, broulik, #vdg
Cc: graesslin, abetts, ngraham, plasma-devel, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart

D16945: Fix fallback to built-in ui

[Martin Flöser]

graesslin updated this revision to Diff 45744.
graesslin added a comment.


  Adjust in the way David suggested.

REPOSITORY
  R133 KScreenLocker

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D16945?vs=45633=45744

BRANCH
  fix-fallback

REVISION DETAIL
  https://phabricator.kde.org/D16945

AFFECTED FILES
  greeter/greeterapp.cpp

To: graesslin, #plasma
Cc: davidedmundson, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D16945: Fix fallback to built-in ui

[Martin Flöser]

graesslin created this revision.
graesslin added a reviewer: Plasma.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
graesslin requested review of this revision.

REVISION SUMMARY
  If the lock screen package is not available m_mainQmlPath is an empty
  URL. Thus view->setSource won't do anything and the status won't change
  to Error. Due to that the fallback was not activated when the lnf
  package is missing.
  
  This change also checks whether said variable is empty.

TEST PLAN
  run kscreenlocker_greet in testing mode with manipulated XDG_DATA_DIRS

REPOSITORY
  R133 KScreenLocker

BRANCH
  fix-fallback

REVISION DETAIL
  https://phabricator.kde.org/D16945

AFFECTED FILES
  greeter/greeterapp.cpp

To: graesslin, #plasma
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D16943: Disable kcrash in greeter in same way as in KWin

[Martin Flöser]

graesslin created this revision.
graesslin added reviewers: Plasma, KWin.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
graesslin requested review of this revision.

REVISION SUMMARY
  When running KWin's lock screen test I saw:
  
  KCrash: crashing... crashRecursionCounter = 2
  KCrash: Application Name = kscreenlocker_greet path = 
/usr/lib/x86_64-linux-gnu/libexec pid = 20795
  KCrash: Arguments: /usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet 
--immediateLock --graceTime 5000 --ksldfd 85
  
  This should not be as kcrash is supposed to be disabled. Comparing with
  kwin showed a difference. This change brings in the same change as in
  KWin.

TEST PLAN
  KWin's lockscreen test no longer shows the kcrash debug

REPOSITORY
  R133 KScreenLocker

BRANCH
  disable-kcrash

REVISION DETAIL
  https://phabricator.kde.org/D16943

AFFECTED FILES
  greeter/greeterapp.cpp

To: graesslin, #plasma, #kwin
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D16897: Allow windows to be closed from the window switchers

[Martin Flöser]

graesslin added a comment.


  In D16897#359912 , @ngraham wrote:
  
  > In D16897#359911 , @graesslin 
wrote:
  >
  > > In D16897#359900 , @ngraham 
wrote:
  > >
  > > > Good point, guys. I'll start with `StandardKey.Close` for now and see 
about making the KWin changes later (I'll admit I'm a bit intimidated by KWin's 
codebase!).
  > >
  > >
  > > I would prefer if the standardKey.Close is not used. This is an 
in-application shortcut used by Qt, but not necessarily by GTK or other 
toolkits. It is not used by the window manager. Please don't mix in-application 
shortcuts and global shortcuts. It would be confusing to users.
  >
  >
  > Isn't the in-application shortcut for window closing exactly what the user 
would expect? From another perspective, the implementation of this feature in 
other window managers and other platforms (macOS, GNOME) uses the same 
window-closing shortcut in the switcher, so it seems that this is what is 
expected and common.
  
  
  And how do you know the in-application shortcut of a window? What's for 
example the in application close window shortcut of Konsole or xterm? There 
simply is no universal shortcut. Also our default shortcut for Qt application 
is ctrl+q which simply is impossible to press in an alt+tab session.

REPOSITORY
  R114 Plasma Addons

REVISION DETAIL
  https://phabricator.kde.org/D16897

To: ngraham, #plasma, #vdg, davidedmundson
Cc: graesslin, davidedmundson, abetts, Zren, plasma-devel, ragreen, Pitel, 
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart

D16897: Allow windows to be closed from the window switchers

[Martin Flöser]

graesslin added a comment.


  In D16897#359900 , @ngraham wrote:
  
  > Good point, guys. I'll start with `StandardKey.Close` for now and see about 
making the KWin changes later (I'll admit I'm a bit intimidated by KWin's 
codebase!).
  
  
  I would prefer if the standardKey.Close is not used. This is an 
in-application shortcut used by Qt, but not necessarily by GTK or other 
toolkits. It is not used by the window manager. Please don't mix in-application 
shortcuts and global shortcuts. It would be confusing to users.

REPOSITORY
  R114 Plasma Addons

REVISION DETAIL
  https://phabricator.kde.org/D16897

To: ngraham, #plasma, #vdg, davidedmundson
Cc: graesslin, davidedmundson, abetts, Zren, plasma-devel, ragreen, Pitel, 
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart

D16897: Allow windows to be closed from the window switchers

[Martin Flöser]

graesslin added a comment.


  I agree with David: please don't hardcode the key. Please don't use "W" - it 
has no meaning in a window manager, it's just the shortcut in some 
applications, others use Ctrl+Q and localized it could be something completely 
different.
  
  I suggest to implement this in KWin and intercept the shortcut hold by kwin - 
if it matches close the window.

REPOSITORY
  R114 Plasma Addons

REVISION DETAIL
  https://phabricator.kde.org/D16897

To: ngraham, #plasma, #vdg, davidedmundson
Cc: graesslin, davidedmundson, abetts, Zren, plasma-devel, ragreen, Pitel, 
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart

D15512: [startplasmacompositor] Add Wayland socket argument

[Martin Flöser]

graesslin added a comment.


  In D15512#359253 , @fvogt wrote:
  
  > > KWin doesn't need this functionality and shouldn't have this 
functionality and it would be difficult to implement.
  >
  > Why? That goes entirely against what I and probably many others expect from 
a kwin_wayland call without explicit socket argument.
  
  
  This was a deliberate design decision when writing the code. One reason is 
that code performing the check and then trying to create the socket is racy. 
Such a race does not belong into KWin.
  
  Also for me the reason "it was like that in X" is not valid. The only valid 
question is: what makes sense from a KWin perspective.
  
  > kwin_wayland already checks whether a socket is used, it can't be that hard 
to extend that to iterate a few socket names.
  
  No kwin_wayland does not check whether a socket is used.
  
  > If you suggest to implement that in a layer higher than kwin, that's not 
possible as kwin has to create the .lock file itself.
  
  The lock file is not created by KWin, but by the wayland library. That is a 
layer higher than KWin. If such functionality should exist it should be in 
libwayland-server and from there available to all compositors. I refuse to 
accept that every compositor has to implement racy code.
  
  > I'd be fine with this change if it were more generic and allowed to add 
arbitrary arguments to kwin_wayland.
  
  No other option makes sense to pass to kwin from startplasmacompositor.

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D15512

To: romangg, #kwin, #plasma
Cc: graesslin, fvogt, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D15512: [startplasmacompositor] Add Wayland socket argument

[Martin Flöser]

graesslin added a comment.


  KWin does not have functionality to generate the socket. KWin doesn't need 
this functionality and shouldn't have this functionality and it would be 
difficult to implement. Given that I fully support this change.

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D15512

To: romangg, #kwin, #plasma
Cc: graesslin, fvogt, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D12997: Add new api to support window tabs

[Martin Flöser]

graesslin added a comment.


  In D12997#354190 , @zzag wrote:
  
  > Ping?
  
  
  The code doesn't work yet, the API is still lacking some functionality

REPOSITORY
  R129 Window Decoration Library

REVISION DETAIL
  https://phabricator.kde.org/D12997

To: graesslin, #kwin, #plasma
Cc: zzag, ngraham, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D16425: Added new Suspend then Hibernate option

[Martin Flöser]

graesslin added a comment.


  I would suggest to turn "suspend then hibernate" into the new suspend. And 
one just can specify in the ui how long it takes till hibernate (which could 
also be endless).

REPOSITORY
  R122 Powerdevil

REVISION DETAIL
  https://phabricator.kde.org/D16425

To: avaldes, broulik
Cc: graesslin, ngraham, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D14949: Add option for whether to show the volume change OSD

[Martin Flöser]

graesslin added a comment.


  It's not about that there are only complaints on Reddit. It's about the user 
group: do we want to deaign so that the small Reddit community is happy or do 
we want to design for the rest? Do we want to make the product more complicated 
(yes that's the result of a config option) to please some people on Reddit 
while at the same time we already have a mechanism to achieve the same?

REVISION DETAIL
  https://phabricator.kde.org/D14949

To: anonym, #vdg
Cc: graesslin, svenmauch, ngraham, romangg, mart, broulik, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol

Re: My ksmserver plans

[Martin Flöser]

Sounds good!

Cheers
Martin

Am 1. Oktober 2018 13:46:56 MESZ schrieb David Edmundson 
:
>I was making a few ksmserver patches, I thought I should document what
>my
>long term plans are so the patches make sense.
>
>https://phabricator.kde.org/T9779
>
>It's not an urgent task, so might spread over the next 2 releases.
>
>David

D14949: Add option for whether to show the volume change OSD

[Martin Flöser]

graesslin added a comment.


  Please don't introduce options based on what's unpopular on Reddit.

REVISION DETAIL
  https://phabricator.kde.org/D14949

To: anonym, #vdg
Cc: graesslin, svenmauch, ngraham, romangg, mart, broulik, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol

D15410: Handle clients which change window metadata during early startup

[Martin Flöser]

graesslin added a comment.


  I just want to point out that such applications are not ICCCM compliant: This 
property must be present when the window leaves the Withdrawn state and may be 
changed only while the window is in the Withdrawn state. Window managers may 
examine the property only when they start up and when the window leaves the 
Withdrawn state, but there should be no need for a client to change its state 
dynamically.
  
  KWin doesn't support updates to wm_class and e.g. window rules are broken.

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D15410

To: hein, davidedmundson, broulik, ngraham
Cc: graesslin, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D14923: Supress paste in screen locker

[Martin Flöser]

graesslin added a comment.


  In D14923#311845 , @davidedmundson 
wrote:
  
  > > . As a matter of fact the default options of Klipper are also fine. Only 
if the not default prevent empty clipboard option is used this breaks.
  >
  > Code says otherwise.
  >
  > klipper.kcfg:
  >  klipper.kcfg-  Prevent empty clipboard
  >  klipper.kcfg-  true
  
  
  wow, sorry. I was sure it's the default. Must have been my two years on 
Wayland without klipper ;-)

REPOSITORY
  R133 KScreenLocker

REVISION DETAIL
  https://phabricator.kde.org/D14923

To: davidedmundson, #plasma
Cc: rkflx, graesslin, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D14924: Prevent paste in screen locker (alternative approach)

[Martin Flöser]

graesslin added a comment.


  I like the other solution better as it doesn't depend on Klipper specific 
behavior.

REPOSITORY
  R133 KScreenLocker

REVISION DETAIL
  https://phabricator.kde.org/D14924

To: davidedmundson, #plasma
Cc: graesslin, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D14923: Supress paste in screen locker

[Martin Flöser]

graesslin added a comment.


  I like this solution. As a matter of fact the default options of Klipper are 
also fine. Only if the not default prevent empty clipboard option is used this 
breaks.

REPOSITORY
  R133 KScreenLocker

REVISION DETAIL
  https://phabricator.kde.org/D14923

To: davidedmundson, #plasma
Cc: graesslin, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

Re: KWin tests on FreeBSD all timing out

[Martin Flöser]

Am 2018-08-03 12:04, schrieb Ben Cooksley:

Hi all,

Sometime recently there was a change in the KWin / FreeBSD world which
means all KWin tests now fail on FreeBSD, and instead of exiting
nicely simply fail with a timeout on the CI system.

As a consequence this means KWin builds now tie up builders for around
11 hours per run.

Could someone please take a look into this?


This is something the FreeBSD devs need to look into.

Cheers
Martin

Re: Akademy BOF Topics

[Martin Flöser]

Am 2018-08-01 17:01, schrieb David Edmundson:

We currently have a bunch of slots booked as general "Plasma".

We should split them up into relevant topics people actually want to
discuss so people know when to turn up to what.


In case there is something you want me to remote participate: I can 
remote join starting at 16:00 CEST, but I need to know before.


Cheers
Martin

Re: KDE Connect clipboard integration doesn't work on Wayland

[Martin Flöser]

Am 2018-08-01 17:43, schrieb Aleix Pol:

Hey,
One of the most useful features in KDE Connect is the clipboard
integration, this is not working currently. I'm guessing it's a
privileges issue, I was wondering if it would maybe be possible to fix
it by doing something like we're doing for fake input:


the reason why it's not working is the same for why klipper is not 
working: clipboard is not a shared medium anymore, but the compositor 
grants applications to write to the clipboard and to read from the 
clipboard. Both is strictly tied to having (keyboard) focus.


For kdeconnect this means it's not possible to write to the clipboard 
nor to read from the clipboard as it doesn't have a gui which could gain 
focus (obviously having a gui would not really be a solution here).


The ideas I had was to have a kind of clipboard manager which is always 
informed when clipboard content changes and is also allowed to write 
clipboard. I had a draft protocol, but I never got it to work properly 
for the klipper case as it tried to sync into both directions. But for 
the kdeconnect case the approach could work. Basically what we need is a 
protocol which allows to always set the data source and to get data 
offers. This would probably make sense to have in wayland-protocols as 
it's a rather generic problem (e.g. also virtual machines need this 
feature).


Cheers
Martin

D14264: Disconnect decoration button requestHover tooltip on decoration destuction

[Martin Flöser]

graesslin added a comment.


  What's really strange is that requestShowTooltip comes from the event loop. 
But nothing in kdecoration or in KWin goes through a queued event to 
KWin::Decoration::DecoratedClientImpl::requestShowToolTip.
  
  Could it be a decoration plugin causing this?

REPOSITORY
  R129 Window Decoration Library

REVISION DETAIL
  https://phabricator.kde.org/D14264

To: davidedmundson, #kwin
Cc: graesslin, zzag, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D14264: Disconnect decoration button requestHover tooltip on decoration destuction

[Martin Flöser]

graesslin added a comment.


  The hovered state cannot change if there is no decoration. Hover is from an 
event handler from Decoration. I doubt that this change here can fix the crash. 
Also that's the explanation for the update slot not checking: no hover change 
if there's no decoration.
  
  The crash is weird: we did have a crash related to tooltips, but it's fixed.

REPOSITORY
  R129 Window Decoration Library

REVISION DETAIL
  https://phabricator.kde.org/D14264

To: davidedmundson, #kwin
Cc: graesslin, zzag, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

Re: Discussion for Virtual Desktops and Activities future

[Martin Flöser]

Hi all,

just chiming in to give some KWin perspective.

Activities are weird and we (Thomas and I) never knew what they are and 
how we should integrate them in KWin. The existing code is just a bad 
copy of virtual desktops (bad because it copied the code 1:1 without 
understanding what it does including the things which just don't make 
sense). It's one of the few areas in KWin which are truly unmaintained. 
From KWin perspective the only useful element is that it allows to have 
a window on multiple "virtual whatever".


On the other hand everything around activities makes KWin code way more 
complex. We have from user perspective two menus offering more or less 
the same. We have duplicated code all over the place. E.g. every effect 
needs to be desktop and activity aware. This results in strange bugs 
like desktop grid switching activities when you click empty space.


The ideas we had when activity support was integrated into KWin just 
never emerged. Things like sub-sessions, windows being truly activity 
aware, applications using the information all just never happened.


On the other hand the interaction with kamd has caused problems several 
times. That is due to the nature of having a side channel related to 
window management. We just are in a tricky situation if KWin asks kamd 
about information it should get from KWin.


So from KWin perspective I would prefer:
 * virtual desktops gain support for windows on multiple desktops
 * activity support gets removed from KWin
 * any mapping from activity to virtual desktop happens outside of KWin 
(e.g. in kamd)


Following the discussing I think that goes into the direction David 
suggested.


What I think would be a disservice to KWin (and thus also Plasma) would 
be to build up any changes on top of the existing activity support in 
KWin. It needs to be kicked out, it's in a bad state.


Cheers
Martin

Re: Raising windows on Wayland

[Martin Flöser]

Am 2018-07-03 18:58, schrieb David Edmundson:





Ideally this needs to be standardized so that it does not only work
with our applications but with any.


Even within just KDE apps, we have code like QDesktopServices spawning
links in code we can't manipulate. Anything non standard, simply isn't
worth merging.

But I don't think standardising anything would be too hard.

Effectively we want something like xdg-foreign which exists. The
difference is that it lasts temporarily and it's not manipulating
parents.


xdg-foreign is pretty much the "token" idea :-)



There are two interesting questions:

Do we want/need to support wayland window sending activating an
xwayland window?


short term: yes, long term: no. Ideally would be a mapping to the 
startup notifications used on X11.




Would we need a serial of the user event (xdg_popup style)? It would
which kinda matches the X event timestamps?
 It's trickier as you'd need a protocol to generate a UUID for both
that and the surface to sidechannel, but it's not impossible.


I don't think that the serial is needed as the compositor would only 
pass on focus if the app which generated the token has currently the 
focus. Given that the serial does not provide any additional advantage. 
And I don't like just using the serial as that could be guessed.




---

The other potential solution that I was wondering about, that's waaay
simpler, definitely waaay crappier, but possibly simple enough to just
work without really having issues.

Could client A just release focus (somehow) when spawning an app? If
nothing has focus and toplevel B appears, it seems sensible that kwin
would focus it.


Won't work for the "discover already running" usecase.

Cheers
Martin

Re: Raising windows on Wayland

[Martin Flöser]

Am 2018-07-03 18:41, schrieb Aleix Pol:
On Tue, Jul 3, 2018 at 6:32 PM Martin Flöser  
wrote:


Am 2018-07-03 18:05, schrieb Aleix Pol:
> On Tue, Jul 3, 2018 at 6:02 PM Martin Flöser 
> wrote:
>>
>> Am 2018-07-03 14:45, schrieb Aleix Pol:
>> > Dear kwiners,
>> > Would it be possible to find a way to do so?
>> >
>> > I know we don't want windows to be positioning themselves willy-nilly
>> > on the window stack, but we certainly need to figure out his use-case.
>> >
>> > What would need to happen to do this?
>> >
>> > If you need to, I can compile a list of use-cases.
>>
>> Hi Alex,
>>
>> this really depends on the use case. Instead of allowing general
>> raising
>> I would prefer to make the workflows work correctly. E.g. if you want
>> that the polkit authentication dialog is above discover we can make
>> this
>> work right now without needing to implement window raising.
>>
>> Cheers
>> Martin
>
> That's not the use-case.
>
> A use-case is I was using Discover, someone pressed
> appstream://org.kde.kate and wants to install it. Discover changes but
> doesn't go into the foreground.
> Similarly, we want the web browser to raise after we've pressed a URL
> on an app.
> Another thing I keep hitting: I open telegram or konversation on
> krunner, nothing happens. It's because it's open somewhere under my
> current window.

Ok, that's all the same pattern: we have an action in application A
which should activate (and raise) application B.

First of: KWin should prevent application B to activate. This is only
working because we don't have focus stealing prevention for Wayland
windows yet. If we had focus stealing prevention, it would kick in and
prevent application B from activating.

The solution to this is a mechanism to pass activation around through 
a

side channel. Application A would need to create a token before
activating B and pass the token to B. B would use this token towards 
the

compositor and the compositor would be able to allow the request as it
sees that application A passed the focus to application B. That kind 
of
matches what startup notifications used to be on X11. This is 
basically

https://phabricator.kde.org/T4448

Ideally this needs to be standardized so that it does not only work 
with

our applications but with any.

Cheers
Martin


I'm not sure how viable this is though. xdg-open doesn't know who's
the caller, and so doesn't just calling "konversation" from bash.


xdg-open could get the token through side channel and pass it on just 
like any other application.


Calling konversation from bash is a corner case which is also not 
supported on X11 (KWin needs the startup notification and that's only 
generated by KLauncher, not from bash).


Cheers
Martin

Re: Raising windows on Wayland

[Martin Flöser]

Am 2018-07-03 18:05, schrieb Aleix Pol:
On Tue, Jul 3, 2018 at 6:02 PM Martin Flöser  
wrote:


Am 2018-07-03 14:45, schrieb Aleix Pol:
> Dear kwiners,
> Would it be possible to find a way to do so?
>
> I know we don't want windows to be positioning themselves willy-nilly
> on the window stack, but we certainly need to figure out his use-case.
>
> What would need to happen to do this?
>
> If you need to, I can compile a list of use-cases.

Hi Alex,

this really depends on the use case. Instead of allowing general 
raising

I would prefer to make the workflows work correctly. E.g. if you want
that the polkit authentication dialog is above discover we can make 
this

work right now without needing to implement window raising.

Cheers
Martin


That's not the use-case.

A use-case is I was using Discover, someone pressed
appstream://org.kde.kate and wants to install it. Discover changes but
doesn't go into the foreground.
Similarly, we want the web browser to raise after we've pressed a URL 
on an app.

Another thing I keep hitting: I open telegram or konversation on
krunner, nothing happens. It's because it's open somewhere under my
current window.


Ok, that's all the same pattern: we have an action in application A 
which should activate (and raise) application B.


First of: KWin should prevent application B to activate. This is only 
working because we don't have focus stealing prevention for Wayland 
windows yet. If we had focus stealing prevention, it would kick in and 
prevent application B from activating.


The solution to this is a mechanism to pass activation around through a 
side channel. Application A would need to create a token before 
activating B and pass the token to B. B would use this token towards the 
compositor and the compositor would be able to allow the request as it 
sees that application A passed the focus to application B. That kind of 
matches what startup notifications used to be on X11. This is basically 
https://phabricator.kde.org/T4448


Ideally this needs to be standardized so that it does not only work with 
our applications but with any.


Cheers
Martin

Re: Raising windows on Wayland

[Martin Flöser]

Am 2018-07-03 14:45, schrieb Aleix Pol:

Dear kwiners,
Would it be possible to find a way to do so?

I know we don't want windows to be positioning themselves willy-nilly
on the window stack, but we certainly need to figure out his use-case.

What would need to happen to do this?

If you need to, I can compile a list of use-cases.


Hi Alex,

this really depends on the use case. Instead of allowing general raising 
I would prefer to make the workflows work correctly. E.g. if you want 
that the polkit authentication dialog is above discover we can make this 
work right now without needing to implement window raising.


Cheers
Martin

D13481: Recommend window border size "None"

[Martin Flöser]

graesslin added a comment.


  Nate, I cannot believe what I read here. Every week you do a blog post about 
usability. In other reviews you draw the usability card so often that it annoys 
me. And here you want to break user setups and break with "form follows 
function". This is absolutely unbelievable to me.
  
  Do what you want!

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: hein, januz, ngraham, davidedmundson, graesslin, abetts, mart, 
plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
sebas, apol

D13481: Recommend window border size "None"

[Martin Flöser]

graesslin added a comment.


  In D13481#282653 , @mart wrote:
  
  > In D13481#280767 , @romangg 
wrote:
  >
  > > What I thought of as a solution back when it happened was to check if 
it's a single click on the dead zone without mouse movement, then activate the 
window below. Since if you want to use the virtual border, you would move the 
mouse after press to drag. Not sure if it's worth it since as said, never 
disturbed my work flow afterwards again.
  >
  >
  > how difficult is to implement? would just bring the window forward, or 
actually pass the click? (ie, if there is a button under that dead zone, it 
should be clicked)
  
  
  Completely different code paths on X11 and on Wayland. We don't have any 
click handlers, only pressed and released. So it's not a was this a click 
thing, we need to learn what a click is.
  
  Given that it requires different implementation for X11 and Wayland and this 
clearly would be a new feature the X11 Feature freeze rule would kick in and 
then we have different solutions for X11 and Wayland. So overall I would rather 
say: too difficult and too breakage risky.
  
  I think we should go back to the drawing board and think about what really is 
wanted and needed. I want to remind that the original idea was to still have 
round corners. As I said a few times: this is not the change vdg wants. So 
let's not try to make something work which the vdg doesn't want. Let's provide 
them the solution for their actual needs instead.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: januz, ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Martin Flöser]

graesslin added a comment.


  Please don't play with the users. I would have never pushed a change to test 
how things work. They are not our testbed. That it worked on other platforms 
doesn't mean a thing. Maybe that other platform cannot even run into the dead 
zone situation.
  
  My point is: this is a behavior change which affects users and thus is not 
for the VDG to decide on. This is something so far the VDG declined. I'm not in 
a position anymore to block it, but as maintainer I would have blocked this 
change for the dead zone effect. That's just an unacceptable behavior chnage.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: januz, ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Martin Flöser]

graesslin added a comment.


  To everyone here: you are extremely experienced developers and software 
users, partially working in the window manager area. Of course you understand 
why the dead zone happens and of course you are able to adapt to it. But please 
think of your users. I fear they won't understand it. Also with click the dead 
zone might be obvious. With just mouse hover it might not. Please try not to 
argument for this strong behavior change with anecdotal evidence like "I use 
this for years".
  
  In the end it comes down to form follows function. I think that this is a 
case where the impact of functionality change is large and thus form needs to 
follow. Futhermore I have to say that my proposals I did in the task are also 
not going to solve it. After thinking more and more about it I see mainly an 
issue with resize outside the window and the impacts it has. My ideas there 
also tried to use it and thus are not a solution.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: januz, ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Martin Flöser]

graesslin added a comment.


  In D13481#280754 , @ngraham wrote:
  
  > Right. That's not a workflow I think I've ever seen anyone do with a 
windowed game.
  
  
  Did you read my comment? Let me quote: "please don't tell me that nobody 
would use a fps in windowed mode. This is an example for problems with the dead 
zone"

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: januz, ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Martin Flöser]

graesslin added a comment.


  In D13481#279575 , @davidedmundson 
wrote:
  
  > There are two visual hints when the mouse is inside the deadzone.
  >
  >   You would still get the different cursor
  >   The client gets the mouse left event and would not show any hover effect 
on whatever control might be there.
  
  
  Which might already be problematic. E.g. for things like first person 
shooters (please don't tell me that nobody would use a fps in windowed mode. 
This is an example for problems with the dead zone). Basically we break the 
complete idea of window snapping.
  
  I don't like this change. I fear it will create much harm for questionable 
visual improvements. I recommend against this.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, ragreen, 
Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Martin Flöser]

graesslin added a comment.


  I realized that there's yet another problem with the approach: if two windows 
border and the window with pointer focus is lower in the stacking order this 
would create a dead zone in the window. With compositing disabled this would be 
worse as there's not even a visual hint.
  
  I really need to urge vdg to rethink all of that. I have a really bad feeling 
about turning no borders on by default. Please reconsider.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: graesslin, abetts, mart, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, sebas, apol

Re: Stepping down as maintainer

[Martin Flöser]

Am 2018-06-02 13:43, schrieb Eike Hein:

To establish the full extent of the range opinions here: Personally I
think the VDG has been working very well lately, and I want to thank
its members for being some of the most hard-working and motivated
contributors to Plasma today. They've made my work better many times.

I also disagree that this has lead to sacrificing "product work at the
altar of usability".


our experiences seem to differ here.


I believe the solution to any remaining woes lies in engagement, not
in throwing hands up in the air and complaining. It's normal for
coding and design teams to have some push-and-pull between them,
that's how they complement and course-correct each other. It's also
worth keeping in mind how frustrating it must be for design
contributors if code contributors let them constantly feel that they
are the final arbiters and gate-keepers, and resort to arguments from
authority constantly. This is not what "common ownership" in the
Manifesto is about. I urge code contributors to be aware of this
harmful messaging, which sets us back on our quest to grow our talent
mix, which has been paying dividends. This goes doubly so for
maintainers, whose primary function is to enable the work of other -
any - contributors. Let's keep in mind onboarding is one of our chosen
community goals.


What I considered as my most important job as maintainer was saying 
"no". If a change is wrong or against the product vision one needs to be 
able to say no. And there is nothing bad about that. It's the job of the 
maintainer to ensure the product is in good shape and goes into the 
right direction. If I as maintainer see that there could be a better 
solution or a proposed solution has side effects the author cannot know 
about it's my duty to say no. No matter whether it's a new contributor, 
the VDG or a dev having been around for 20 years.


What a maintainer should not say no to are ideas. In fact the maintainer 
should help moving ideas into the right direction, so that they could be 
added to the product. In that sense I think it is important to have the 
maintainer a gate keeper for the code side, but not for the idea side.


If we work like that I think this would be satisfying for all sides. To 
take the example of the no border change. I don't mind the VDG to want 
to improve the area. If they present the idea on "we want Kirigami apps 
look great", we can work on that. If instead a change is presented which 
is flipping a default on the code side, which doesn't make sense from 
the product perspective, my job as the gate keeper kicks in and I need 
to say no. For the overall product KWin I think this change is wrong. I 
think there are solutions which can result in satisfying both, Roman's 
patch is a step into that direction for example.


So the problem I see here is not that design and code teams clash. The 
problem is in my opinion that the design team presented technical 
solutions without consulting the experts.


Personally my opinion is that the VDG does not even want to change the 
borders. It's a hack around the problem. Kirigami apps seam not to be 
designed with decorations around them. That's fine, but changing the 
default as a hack is the wrong solution. Like what Hugo said we need to 
fix Kirigami instead of changing the default. There are multiple ways to 
do that. One option would certainly be client side decorations. And 
that's also fine. If that's what the VDG wants it could be implemented 
in a sane and working way. What I think is that they did not even 
consider that option. But that's where the expertise of the maintainer 
comes in. He is the one with the best technical understanding of the 
problem and the solution.




Finally, I want to say that I think it's not in good form to have
started this discussion in this thread. Putting an entire set of
contributors on trial under the mantle of someone's disgruntled exit
announcement, biasing the burden of proof from the get-go? What are we
doing here?


Sorry about that. Maybe it's not the place to discuss that. I only 
wanted to explain why I lost motivation.


Cheers
Martin

Re: Stepping down as maintainer

[Martin Flöser]

Am 2018-06-02 16:15, schrieb David Edmundson:

Fair enough.

On the day to day side.

ZZag's and Anemeth have both been doing an amazing job lately on the
effects.

I'll continue on anything wrt rendering + wayland, hopefully Roman can
tackle anything on input and DRM.

Hopefully Thomas L will still be around as the relevant X wizz as
that's a domain I don't think anyone else wants to touch.

Collectively, we're all going to have to chip in on kwin bug triage,
that's an area where Martin has been doing an excellent job fo years.


For the time being I try to continue to go through the bugs.



I'm sure we'll be able to keep kwin awesome for the forseeable future.


I'm sure as well :-)

Cheers
Martin

Re: Stepping down as maintainer

[Martin Flöser]

Am 2018-06-02 10:59, schrieb Roman Gilg:

Hi Martin,

first of all thank you! KWin is an amazing piece of software and we
owe this to a huge part to you.

Regarding your decision to step down as maintainer I hope you
reconsider though.


No, that decision is final. It's not that I decided yesterday, but it's 
something I have been thinking about more and more often over the last 
year. Especially over the last months I got more and more frustrated and 
not motivated when going through reviews. In too many reviews I said no. 
I don't want to be the one guy who is against everything. In such a 
situation it's better to step down as maintainer and enjoy coding.



While it's true that you are currently not as
active as in the past, we still very much need your knowledge and
expertise on everything KWin/KWayland and X/Wayland related. This
holds definitely for bigger changes to KWin or KWayland like my
current output class restructuring in KWin or how there are at the
moment numerous new interfaces in the process of being added to
KWayland by different people.


I'm still around. Just ping me or add me to the review. I'll try to get 
phabricator notifications working for me by removing myself from the 
groups.




When I saw there was a problem with stacking up reviews in the last
few weeks my secret plan was to still have you as maintainer of KWin
for the foreseeable future because of your immense knowledge about the
project, but at some point have David and/or me added as co-maintainer
to help with the legwork. Would this be an option for you?


As said the decision to not be maintainer any more is final. I'll be 
around to help and give advice, also to code, but not to maintain.


Cheers
Martin

Stepping down as maintainer

[Martin Flöser]

Hi all,

After long consideration I decided that I am no longer in a position to 
be a maintainer. I currently do not follow up on reviews and hardly 
contribute any code. Given that I think it's time to pass on the torch. 
KWin is currently in a good position we have new developers working on 
various areas of KWin and my suggestion would be to split the task of 
maintainership on many shoulders, specialized for various areas.


My lack of work lately was not just the lack of time, but to a larger 
degree a lack of motivation. I searched a lot for the reasons for the 
lack of motivation and I think I identified two core areas where KDE is 
currently heading to and where I just disagree with these directions. 
Please don't take my explanation personal, you are doing awesome work, 
it's just that I don't approve these directions. Lately I had a feeling 
of doing fundamental opposition to changes the community wants to do. 
Granted I think these changes are wrong, but I don't want to stand in 
the way, if that's what the people doing the work want.


What I identified as the core issues is the way the VDG currently acts 
and the usability project.


With the VDG I currently see the following problems:
 * tendency to do changes and reverting them again
 * taking easy solutions like flipping defaults without looking at the 
big picture

 * tries to dictate much more than just visual or design
 * does not consult domain experts
 * presents final solution and disallows discussion as you were not part 
of the telegram discussion


As examples I take the discussion around the change of lock screen 
wallpaper and the window decoration no border setting. In both cases the 
VDG identified a problem, which is great. But also presented the 
solution. In both cases the technical solution is bad and results in 
losing functionality. It takes a hard fight to convince the VDG that 
their solution is wrong and that something better is required. In the 
case of the lockscreen we succeeded. The new implementation is awesome, 
a clear improvement over the blue background and also over the one we 
had before. But if we would have taken the approach the VDG did without 
opposing and fighting we would have ended with a solution worse to the 
one we had before the blue background. To me this is a dangerous 
development. I don't want to have to fight for good solutions. That 
costs a lot of power and is not healthy for the community. My wish to 
the VDG would be to take a step back again and not trying to find the 
technical solution to the problems you identify. Please approach the 
developer community with "hey, we think this area is bad, we want to 
have these improvements, how can we achieve it?" What I also think is 
important is that you realize that changing a default is a technical 
solution. It's not just design. Ask the experts whether that is the 
right solution to your problem and don't dismiss their opinion based on 
"it's just design".


Similar the no border discussion highlights some of these problems. 
While it sounds like a minor thing, it is not. We see the fundamental 
problems: domain experts are not consulted, if they chime in they are 
told that they have no saying in it as they were not part of the 
discussion. Changing the default has more consequences than just a 
visual one. I told that and nobody is listening. We are going the easy 
road of flipping defaults without thinking of the big picture or finding 
good solutions. This is not what we used to strive for in KDE. We used 
to operate on highest technical level trying to bring the best 
solutions. This is clearly not form follows function. We are removing 
function in the sake of form. A dangerous development. To get one thing 
clear: I don't care about whether no border or normal is the default, 
I'm not personal attached to this. What I care about is that we get the 
best solution for the users. And I am sure that changing this default 
will have negative impact. And that is sad.


The second area where I really dislike the development KDE is taking is 
the usability project. I have a feeling currently everything is done in 
the sake of usability. We are losing the big picture, we are no longer 
doing product development. We don't try to improve the product and take 
it to the next level instead a thousand of minor things are added in the 
sake of usability. We ignore that every checkbox or option added 
decreases the usability for everybody else, we ignore the costs to 
maintain the code due to the changes. I remember that people like Björn, 
Kevin and Thomas told us that we should strive for satisfying 90 % of 
the userbase and not everyone. Currently we try to satisfy everyone. 
This is a road to failure in my opinion. We are on the road to KDE 3's 
configuration nightmare and creating an unmaintainable monster. We are 
working against plans we set for ourselves during the start of Plasma 5 
development such as focus on the core features and 

D13062: Don't manipulate foreign windows

[Martin Flöser]

graesslin accepted this revision.
graesslin added a comment.


  Please as bugfix to 5.12 branch.

REPOSITORY
  R135 Integration for Qt applications in Plasma

REVISION DETAIL
  https://phabricator.kde.org/D13062

To: broulik, #plasma, davidedmundson, graesslin
Cc: graesslin, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D7038: [server] Respect input region of sub-surfaces on pointer surface focus

[Martin Flöser]

graesslin added a comment.
Restricted Application added a subscriber: kde-frameworks-devel.


  any update on this?

REPOSITORY
  R127 KWayland

REVISION DETAIL
  https://phabricator.kde.org/D7038

To: romangg, #frameworks, graesslin
Cc: kde-frameworks-devel, graesslin, plasma-devel, ragreen, Pitel, schernikov, 
michaelh, ZrenBot, ngraham, bruns, alexeymin, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, eliasp, sebas, apol, mart, hein

D12997: Add new api to support window tabs

[Martin Flöser]

graesslin created this revision.
graesslin added reviewers: KWin, Plasma.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
graesslin requested review of this revision.

REVISION SUMMARY
  The new API basically just provides a vector of DecoratedClient
  referring to the window tabs. This was the idea on how to implement
  window tabs I had back when starting the implementation of KDecoration2.
  There are a few more requests to close a specific tab and to activate a
  tab.
  
  On the private side a new subclass is added, which KWin can implement to
  provide window tab support.

TEST PLAN
  Early review and KWin doesn't use the new API yet, so completely
  untested. Will not merge prior to using the API in KWin.

REPOSITORY
  R129 Window Decoration Library

BRANCH
  window-tab-api

REVISION DETAIL
  https://phabricator.kde.org/D12997

AFFECTED FILES
  src/decoration.cpp
  src/decoration.h
  src/private/decoratedclientprivate.cpp
  src/private/decoratedclientprivate.h

To: graesslin, #kwin, #plasma
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

Re: When kwin_wayland crashes

[Martin Flöser]

Am 2018-05-17 16:32, schrieb Aleix Pol:

Hey,
Here's an issue I've seen and I'm pretty sure you've seen too. For any
reason kwin crashes. SDDM kills the whole session and jumps back to
the login UI

Tue 2018-05-15 15:22:30 CEST669  1000  1000  11 truncated
/home/apol/devel/kde5/bin/kwin_wayland
Tue 2018-05-15 15:22:32 CEST  11004  1000  1000   6 present
/home/apol/devel/kde5/lib64/libexec/drkonqi
Tue 2018-05-15 15:22:32 CEST  11003  1000  1000   6 present
/home/apol/devel/kde5/lib64/libexec/org_kde_powerdevil
Tue 2018-05-15 15:22:32 CEST   1139  1000  1000   6 present
/usr/lib/chromium/chromium
Tue 2018-05-15 15:22:32 CEST811  1000  1000   6 present
/home/apol/devel/kde5/lib64/libexec/org_kde_powerdevil


As you can see here, kwin crashes into a "truncated" state that
doesn't allow us to get a backtrace. My guess there is that it's SDDM
rushing to have it killed but I'm not sure that's actually the case.

Can anyone point me at what is actually happening on the SDDM side? I
was thinking that ideally when the session is open again we'd see a
kcrash dialog with the backtrace and the opportunity to report. Or at
the very least, we need to be able to successfully query coredumpd.


KWin_Wayland doesn't support kcrash. When KWin_Wayland crashes the 
windowing system dies. Thus DrKonqi cannot connect to a windowing system 
and doesn't work. Due to that it's disabled in kwin_wayland binary.


If you want to get a backtrace the best bet is coredumpctl, but I had no 
real luck with it. I tend to try to reproduce crashes in a nested setup 
which I run directly through gdb.


Cheers
Martin

Re: Cursor sizes on wayland

[Martin Flöser]

Am 2018-05-09 12:08, schrieb Aleix Pol:
On Tue, May 8, 2018 at 8:57 PM, Martin Flöser <mgraess...@kde.org> 
wrote:



Am 8. Mai 2018 17:05:57 MESZ schrieb Aleix Pol <aleix...@kde.org>:

Hi,
I've been looking into getting a consistent cursor look on wayland,
which is specially daunting because of scaling.

I'd like to look into fixing it for xwayland clients. Would somebody
be able to shed some light into the issue so I can understand it and
fix it?

Xwayland clients use the normal X11 API to set cursors. Xwayland just 
forwards them through the Wayland protocol. The env variable for 
cursor size is the same on Wayland and X11, so there should not be any 
difference.


I'm not sure what exactly you want to look into. Personally I had the 
feeling that apps started to act crazy concerning cursor sizes - on 
Wayland and on X11. Normally there just should not be any difference. 
There's one env variable controlling it and if all apps would just use 
it and not do crazy stuff instead it would just work.


Well, setting the cursor size isn't any useful if you have two
monitors. I have it configured at resolution-dependent at the moment
and sometimes I lose my cursor on my high dpi screen.
If I use something bigger, when I move it to my external monitor I get
a monstrosity.

David mentioned at the sprint that we maybe should be correcting its
scale on the kwin size, if it's not being scaled yet.


This might be part of the solution. This needs a more general solution 
and might require changes to Wayland protocols and each toolkit and 
KWin.


For "normal" windows we use the wl_surface::enter to inform on which 
output they are. Thus they can adjust for different dpi. Similar there 
is the scale information on a wl_surface.


For a cursor wl_surface KWin neither emits the output information nor 
uses the scale information. Both would be relative easy to implement. 
But only makes sense if toolkits support it. Last time I looked at Qt 
code, Qt did not (but that's some time ago).


So to get this properly working, I would suggest to add the output 
enter/leave information to cursor surfaces and honor scale in KWin. Then 
add the same to QtWayland if it doesn't exist already.


Cheers
Martin

Re: Cursor sizes on wayland

[Martin Flöser]

Am 8. Mai 2018 17:05:57 MESZ schrieb Aleix Pol :
>Hi,
>I've been looking into getting a consistent cursor look on wayland,
>which is specially daunting because of scaling.
>
>I'd like to look into fixing it for xwayland clients. Would somebody
>be able to shed some light into the issue so I can understand it and
>fix it?
>
Xwayland clients use the normal X11 API to set cursors. Xwayland just forwards 
them through the Wayland protocol. The env variable for cursor size is the same 
on Wayland and X11, so there should not be any difference.

I'm not sure what exactly you want to look into. Personally I had the feeling 
that apps started to act crazy concerning cursor sizes - on Wayland and on X11. 
Normally there just should not be any difference. There's one env variable 
controlling it and if all apps would just use it and not do crazy stuff instead 
it would just work.

Cheers
Martin

Re: Late API change to KWayland for upcoming Frameworks release

[Martin Flöser]

Am 2018-05-02 06:19, schrieb Roman Gilg:

I have the following patch to KWayland adding a property for per
OutputDevcie color correction via color curve adjustment:
https://phabricator.kde.org/D12388

The problem is that Frameworks tag is on Saturday, but if the patch
does not get in with next Frameworks release, I'm blocked on multiple
other patches for KWin and Plasma that otherwise could land in 5.13.

There seems to be an unwritten rule against API changes to Frameworks
in the last week before tagging, but since KWayland is an independent
framework only relevant to the fast-moving Wayland session and the
additional code paths will only become relevant in practice with the
upcoming changes to Plasma in 5.13 I would like to make an exception
to this unwritten rule. Because of the unwritten rule I want to hear
other opinions on this decision first though.

Regarding the API changes one other question: I have not increased the
Wayland protocol version numbers of the affected protocol extensions
in the patch, because they are only used internally and KScreen as
well as KWin will just ignore the additional property functioning as
before as long as no support has been added to them with a future
Plasma release. Is this alright?


No, we need to be compatible and should follow the common Wayland way. 
If we add requests, we increase the version. I just pointed that out in 
the review.


What's worse is that you added the events/requests in between which is 
not API compatible.


Like what David said in the phab request: don't rush. In the worst case 
everything is delayed, in the half-worst case you need compile time 
checks in kwin and remove them once we branched 5.13.


Cheers
Martin

D12539: Klipper: Do not insert secret data into history

[Martin Flöser]

graesslin added a comment.


  In D12539#254330 , @broulik wrote:
  
  > > And it's probably something we also want to add to KWallet and maybe 
every password field we have.
  >
  > Since when can you Copy from password fields?
  
  
  I just locked my screen on X11 (I need the wacom), enabled echo mode, copied 
the content of the password field, unlocked and pasted and yes it worked.

REPOSITORY
  R120 Plasma Workspace

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D12539

To: hoffmannrobert, davidedmundson
Cc: broulik, graesslin, davidedmundson, plasma-devel, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D12539: Klipper: Do not insert secret data into history

[Martin Flöser]

graesslin added a comment.


  And it's probably something we also want to add to KWallet and maybe every 
password field we have.

REPOSITORY
  R120 Plasma Workspace

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D12539

To: hoffmannrobert, davidedmundson
Cc: graesslin, davidedmundson, plasma-devel, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D12405: [WIP] Per-screen scale factors on X11 using QT_SCREEN_SCALE_FACTORS

[Martin Flöser]

graesslin added a comment.


  I'm pointing out that I'm in general against any risky changes on X11. If 
users want to use this features: Wayland is there. KWin is feature frozen on 
X11 and I highly suggest to the Plasma community to decide the same at the 
sprint. We will have less maintenance issues due to it.
  
  I can promise you that this feature will create bug reports, it comes with a 
cost to add this on X11. While we have a almost finished Wayland solution which 
is hold back by among other developers still working on X11.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D12405

To: fvogt, #plasma
Cc: ngraham, graesslin, davidedmundson, plasma-devel, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D12069: Implement a keyboard selector plasmoid

[Martin Flöser]

graesslin added a comment.


  I don't think that there's any reason to discard this. It's a start and 
improvement over the current situation and a fallback is needed anyway. So we 
start with the fallback instead of adding it later on.

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D12069

To: apol, #plasma
Cc: hein, graesslin, broulik, davidedmundson, plasma-devel, ragreen, Pitel, 
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D12373: Klipper: Remove first history item on clipboard clear

[Martin Flöser]

graesslin added a comment.


  Sorry, but I'm against this. The options keepass provides are just bullshit 
(sorry to be that direct). That cannot work and will not work. One cannot 
remove anything from the clipboard, trying to do so is insane. What would make 
most sense for things like clipboard is setting a mimetime like text/password. 
This could be used by Klipper to never add it to history. That would be a 
useful feature. But anything that just tries to support keepass's utterly 
broken workflow from an X11/Wayland and security point of view doesn't make any 
sense.

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D12373

To: hoffmannrobert
Cc: graesslin, broulik, davidedmundson, plasma-devel, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D12405: [WIP] Per-screen scale factors on X11 using QT_SCREEN_SCALE_FACTORS

[Martin Flöser]

graesslin added a comment.


  I also cannot imagine this to work due to the fact how X11 works. There is 
just no mapping from window to screen. No window can know on which screen it 
is. Not even KWin knows that as the window manager (screen is not a constant 
property, but evaluated every time it is accessed, it's based on the distance 
to closest screen). Especially for overlapping windows it's very difficult to 
try to get to which screen it belongs. It gets even more complicated when 
things like panning and overlapping screens get into it. So I wouldn't trust 
this thing in Qt to work due to the pain we have in KWin especially with these 
problems.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D12405

To: fvogt, #plasma
Cc: graesslin, davidedmundson, plasma-devel, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D12069: Implement a keyboard selector plasmoid

[Martin Flöser]

graesslin added inline comments.

INLINE COMMENTS

> davidedmundson wrote in main.qml:42
> "apl" and "mao" are 3 letters.
> No idea what either of those mean, it's just in the list.

I'm not sure whether a substring is the correct solution anyhow. On Wayland we 
get a proper name like German, but that doesn't match the short name which 
would be de.

That's also the reason why the sni doesn't support flags: I didn't find a 
trivial solution to map to iso codes.

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D12069

To: apol, #plasma
Cc: graesslin, broulik, davidedmundson, plasma-devel, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

Re: Keyboard Layout notification on Wayland

[Martin Flöser]

Am 6. April 2018 18:15:47 MESZ schrieb Aleix Pol :
>Hey,
>Since I moved to wayland instead of seeing an item on the tray with
>the layout I see a keyboard. The behavior is right but the fact that I
>just see a keyboard that doesn't tell me much pushed me to see if we
>could gain back the behavior we have on X11.
>
>I saw that this code moved to kwin, my first instinct was to port the
>logic from the kded module we have nowadays, but the algorithm we have
>to render text on the status notifier is horrid and thought we could
>do something else, like a plasmoid.
>
>TLDR:
>kwin maintainers, how would you feel about dropping the status
>notifier item and creating an ad-hoc plasmoid for org.kde.keyboard
>/Layouts dbus service?
>
>Aleix

As David says it came up before and I would be very pleased to see a nice 
plasmoid replacing the sni. 

Cheers
Martin

D10836: Ensure _NET_CURRENT_DESKTOP is set on startup

[Martin Flöser]

This revision was automatically updated to reflect the committed changes.
Closed by commit R108:420549603372: Ensure _NET_CURRENT_DESKTOP is set on 
startup (authored by graesslin).

REPOSITORY
  R108 KWin

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10836?vs=28039=30856

REVISION DETAIL
  https://phabricator.kde.org/D10836

AFFECTED FILES
  autotests/integration/virtual_desktop_test.cpp
  workspace.cpp

To: graesslin, #kwin, #plasma, romangg
Cc: broulik, plasma-devel, kwin, ragreen, iodelay, zzag, bwowk, ZrenBot, 
lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart

D11722: If GL context creation fails fall back to the software renderer

[Martin Flöser]

graesslin added a comment.


  An env variable would not work for things like lock screen as the process 
starting the lock screen is started before Plasmashell.
  
  Given that I think persistent storage makes more sense. But a way to get back 
would be cool. Maybe we could create a test app to see whether OpenGL Scene 
Graph works? Something like mapping a transparent rectangle?

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D11722

To: davidedmundson, #plasma
Cc: broulik, graesslin, plasma-devel, ragreen, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11722: If GL context creation fails fall back to the software renderer

[Martin Flöser]

graesslin added a comment.


  I like this change

INLINE COMMENTS

> desktopview.cpp:63
>  [this, corona]() {
> +qDebug() << QQuickWindow::sceneGraphBackend();
>  // check whether the GL Context supports OpenGL

This looks like too much debug or like a need of qcdebug

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D11722

To: davidedmundson, #plasma
Cc: graesslin, plasma-devel, ragreen, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D10816: Add platform detection to KWorkspace library to adjust QT_QPA_PLATFORM

[Martin Flöser]

graesslin added a comment.


  In D10816#233128 , @fvogt wrote:
  
  > In D10816#233088 , @graesslin 
wrote:
  >
  > > In D10816#233074 , @fvogt 
wrote:
  > >
  > > > `XDG_SESSION_TYPE` is not set if you run `startplasmacompositor` from a 
tty - so should this also check for `WAYLAND_DISPLAY` or 
`startplasmacompositor` set `XDG_SESSION_TYPE=wayland`?
  > >
  > >
  > > [...] from developers we can expect to set this variable.
  >
  >
  > Any reason not to set it in `startplasmacompositor` then?
  
  
  It's not the task of startplasmacompositor to set it.

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D10816

To: graesslin, #plasma, romangg
Cc: fvogt, davidedmundson, romangg, broulik, plasma-devel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D10816: Add platform detection to KWorkspace library to adjust QT_QPA_PLATFORM

[Martin Flöser]

graesslin added a comment.


  In D10816#233074 , @fvogt wrote:
  
  > `XDG_SESSION_TYPE` is not set if you run `startplasmacompositor` from a tty 
- so should this also check for `WAYLAND_DISPLAY` or `startplasmacompositor` 
set `XDG_SESSION_TYPE=wayland`?
  
  
  No, I think that's a cornercase. Running from a tty is not the way users 
interact with the system and from developers we can expect to set this variable.
  
  Basing the change on the availability of WAYLAND_DISPLAY or DISPLAY has 
disadvantages including that we don't know what the door is. We could have 
both: Wayland on top of X of X on top of Wayland.

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D10816

To: graesslin, #plasma, romangg
Cc: fvogt, davidedmundson, romangg, broulik, plasma-devel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

Re: KDE CI: Frameworks kwindowsystem kf5-qt5 FreeBSDQt5.9 - Build # 15 - Failure!

[Martin Flöser]

Hi Ben,

I pushed a possible fix. No guarnatees as this code obviously compiled 
on my system.


Could the compiler settings please be adjusted so that we have warnings 
be warnings on all ci systems and not fail on randomly? This was rather 
unexpected for me and makes it quite difficult to properly test before 
hand. The firefighting afterwards is something I don't like as mails 
with "fix this as soon as possible" are difficult if you don't have much 
time.


Cheers
Martin

Am 2018-03-24 11:25, schrieb Ben Cooksley:

Hi Martin,

Please see below. Could you please fix this as soon as possible?

This is blocking all FreeBSD Dependency builds meaning any change to
the binary compatibility state of the FreeBSD platform will break the
whole CI system on FreeBSD.

Cheers,
Ben

On Wed, Mar 21, 2018 at 6:51 PM, CI System  wrote:


BUILD FAILURE

Build URL


https://build.kde.org/job/Frameworks%20kwindowsystem%20kf5-qt5%20FreeBSDQt5.9/15/

[1]

Project:
Frameworks kwindowsystem kf5-qt5 FreeBSDQt5.9

Date of build:
Wed, 21 Mar 2018 05:50:19 +

Build duration:
1 min 31 sec and counting

CONSOLE OUTPUT

[...truncated 92.62 KB...]

[ 10%] Building CXX object


src/CMakeFiles/KF5WindowSystem.dir/ECMQmLoader-kwindowsystem5_qt.cpp.o


[ 11%] Building CXX object


src/CMakeFiles/KF5WindowSystem.dir/platforms/xcb/kselectionowner.cpp.o


[ 12%] Building CXX object


src/CMakeFiles/KF5WindowSystem.dir/platforms/xcb/kselectionwatcher.cpp.o


[ 12%] Building CXX object


src/CMakeFiles/KF5WindowSystem.dir/platforms/xcb/kxerrorhandler.cpp.o


[ 13%] Building CXX object
src/CMakeFiles/KF5WindowSystem.dir/platforms/xcb/kxutils.cpp.o

/usr/home/jenkins/workspace/Frameworks kwindowsystem kf5-qt5
FreeBSDQt5.9/src/platforms/xcb/kxerrorhandler.cpp:145:10: warning:
unused variable 'num' [-Wunused-variable]

char num[ 256 ];

^

1 warning generated.

[ 14%] Building CXX object
src/CMakeFiles/KF5WindowSystem.dir/platforms/xcb/kkeyserver.cpp.o

[ 15%] Building CXX object
src/CMakeFiles/KF5WindowSystem.dir/platforms/xcb/kxmessages.cpp.o

[ 16%] Building CXX object
src/CMakeFiles/KF5WindowSystem.dir/platforms/xcb/netwm.cpp.o

/usr/home/jenkins/workspace/Frameworks kwindowsystem kf5-qt5
FreeBSDQt5.9/src/platforms/xcb/kkeyserver.cpp:524:27: warning:
'XKeycodeToKeysym' is deprecated [-Wdeprecated-declarations]

keySymX = XKeycodeToKeysym(QX11Info::display(),
xmk->modifiermap[xmk->max_keypermod * i + j], k);

^

/usr/local/include/X11/Xlib.h:1687:15: note: 'XKeycodeToKeysym'
has been explicitly marked deprecated here

extern KeySym XKeycodeToKeysym(

^

/usr/home/jenkins/workspace/Frameworks kwindowsystem kf5-qt5
FreeBSDQt5.9/src/platforms/xcb/kkeyserver.cpp:719:20: warning:
'XKeycodeToKeysym' is deprecated [-Wdeprecated-declarations]

if (sym == XKeycodeToKeysym(QX11Info::display(), code, 0))

^

/usr/local/include/X11/Xlib.h:1687:15: note: 'XKeycodeToKeysym'
has been explicitly marked deprecated here

extern KeySym XKeycodeToKeysym(

^

/usr/home/jenkins/workspace/Frameworks kwindowsystem kf5-qt5
FreeBSDQt5.9/src/platforms/xcb/kkeyserver.cpp:721:25: warning:
'XKeycodeToKeysym' is deprecated [-Wdeprecated-declarations]

else if (sym == XKeycodeToKeysym(QX11Info::display(), code, 1)) {

^

/usr/local/include/X11/Xlib.h:1687:15: note: 'XKeycodeToKeysym'
has been explicitly marked deprecated here

extern KeySym XKeycodeToKeysym(

^

/usr/home/jenkins/workspace/Frameworks kwindowsystem kf5-qt5
FreeBSDQt5.9/src/platforms/xcb/kkeyserver.cpp:723:27: warning:
'XKeycodeToKeysym' is deprecated [-Wdeprecated-declarations]

} else if (sym == XKeycodeToKeysym(QX11Info::display(), code, 2))
{

^

/usr/local/include/X11/Xlib.h:1687:15: note: 'XKeycodeToKeysym'
has been explicitly marked deprecated here

extern KeySym XKeycodeToKeysym(

^

/usr/home/jenkins/workspace/Frameworks kwindowsystem kf5-qt5
FreeBSDQt5.9/src/platforms/xcb/kkeyserver.cpp:725:27: warning:
'XKeycodeToKeysym' is deprecated [-Wdeprecated-declarations]

} else if (sym == XKeycodeToKeysym(QX11Info::display(), code, 3))
{

^

/usr/local/include/X11/Xlib.h:1687:15: note: 'XKeycodeToKeysym'
has been explicitly marked deprecated here

extern KeySym XKeycodeToKeysym(

^

/usr/home/jenkins/workspace/Frameworks kwindowsystem kf5-qt5
FreeBSDQt5.9/src/platforms/xcb/kkeyserver.cpp:917:20: warning:
'XKeycodeToKeysym' is deprecated [-Wdeprecated-declarations]

uint sym = XKeycodeToKeysym(QX11Info::display(), keyCodeX, 0);

^

/usr/local/include/X11/Xlib.h:1687:15: note: 'XKeycodeToKeysym'
has been explicitly marked deprecated here

extern KeySym XKeycodeToKeysym(

^

[ 16%] Building CXX object


src/CMakeFiles/KF5WindowSystem.dir/KF5WindowSystem_autogen/mocs_compilation.cpp.o


6 warnings generated.

/usr/home/jenkins/workspace/Frameworks kwindowsystem kf5-qt5
FreeBSDQt5.9/src/platforms/xcb/netwm.cpp:2762:25: warning: cast from
'unsigned char *' to 'uint32_t *' (aka 'unsigned int *') increases
required alignment from 1 to 4 [-Wcast-align]

uint32_t *d32 = (uint32_t *) 

Re: Experience on wayland regressed

[Martin Flöser]

Am 22. März 2018 20:36:38 MEZ schrieb David Edmundson 
:
>>At the moment it seems that kded is being ran as xcb so
>the per-screen scaling isn't being set u
>
>All scaling will be half-broken since that change anyway.
>Running clients in xwayland means we lose all client high DPI support.
>
>​>. Also system settings shows
>the behavior for xcb instead of the one for wayland also with the
>per-display UX broken.
>
>Systemsettings knows what backend the kscreen daemon is using, which is
>sensible behaviour. It should be fixed by the kded change.
>
>
>
>We might have a big problem. Even though 5.11 now has fallback support
>I'm
>not convinced that changing the default
>QT_QPA_DEFAULT_PLATFORM_NAME is going to happen for 5.11.  That will be
>a
>big problem.

Maybe we could get a change in to use the XDG_SESSION_TYPE environment variable 
to pick the default platform?

Re: Experience on wayland regressed

[Martin Flöser]

Am 2018-03-22 19:13, schrieb Martin Flöser:

Am 22. März 2018 15:54:22 MEZ schrieb Aleix Pol <aleix...@kde.org>:

Hi,
Since the recent removal of QT_QPA_PLATFORM=wayland, we lost some
functionality. At the moment it seems that kded is being ran as xcb so
the per-screen scaling isn't being set up. Also system settings shows
the behavior for xcb instead of the one for wayland also with the
per-display UX broken.


Uh kded was an oversight on my side as it's not part of workspace - I
checked what workspace has as binaries and adjusted those. I'll have a
look.


-> https://phabricator.kde.org/D11583

sorry about the inconvenience. If there are any other processes you 
notice, please report a bug and put me on CC.


Cheers
Martin

Re: Experience on wayland regressed

[Martin Flöser]

Am 22. März 2018 15:54:22 MEZ schrieb Aleix Pol :
>Hi,
>Since the recent removal of QT_QPA_PLATFORM=wayland, we lost some
>functionality. At the moment it seems that kded is being ran as xcb so
>the per-screen scaling isn't being set up. Also system settings shows
>the behavior for xcb instead of the one for wayland also with the
>per-display UX broken.

Uh kded was an oversight on my side as it's not part of workspace - I checked 
what workspace has as binaries and adjusted those. I'll have a look.

Systemsettings is adjusted and works fine.

>
>I also see that Spectacle is now even more broken as it's trying to
>ask xcb for the screenshots.

Well it should not do that. Even on X11 spectacle should use the dbus protocol. 
That should be easy to adjust without needing to check the platform in 
spectacle.

Cheers
Martin

D11573: Use QPlatformWindow::startSystemMove() with Qt 5.11

[Martin Flöser]

graesslin added a comment.


  In general I like the idea and that should be extended to Wayland as well, 
but private API is a no-no for breeze. That has huge runtime breakage potential.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D11573

To: volkov, #breeze
Cc: graesslin, davidedmundson, broulik, plasma-devel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11567: Fix use of assert/crash when removing global shortcut

[Martin Flöser]

graesslin accepted this revision.
graesslin added a comment.
This revision is now accepted and ready to land.


  Or just remove the assert.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D11567

To: davidedmundson, #plasma, graesslin
Cc: graesslin, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D11447: No longer export QT_QPA_PLATFORM env variable to the session

[Martin Flöser]

This revision was automatically updated to reflect the committed changes.
Closed by commit R120:c4a0d6925ec6: No longer export QT_QPA_PLATFORM env 
variable to the session (authored by graesslin).

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11447?vs=29816=30086

REVISION DETAIL
  https://phabricator.kde.org/D11447

AFFECTED FILES
  krunner/main.cpp
  shell/main.cpp
  startkde/startplasmacompositor.cmake

To: graesslin, #plasma, davidedmundson, romangg
Cc: romangg, fvogt, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D11446: Use platform detection from KWorkspace in Powerdevil

[Martin Flöser]

This revision was automatically updated to reflect the committed changes.
Closed by commit R122:8ba04f890e15: Use platform detection from KWorkspace in 
Powerdevil (authored by graesslin).

REPOSITORY
  R122 Powerdevil

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11446?vs=29811=30085

REVISION DETAIL
  https://phabricator.kde.org/D11446

AFFECTED FILES
  CMakeLists.txt
  daemon/CMakeLists.txt
  daemon/powerdevilapp.cpp

To: graesslin, #plasma, davidedmundson, broulik
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D11445: Use platform detection in SystemSettings

[Martin Flöser]

This revision was automatically updated to reflect the committed changes.
Closed by commit R124:2d8296904bb4: Use platform detection in SystemSettings 
(authored by graesslin).

REPOSITORY
  R124 System Settings

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11445?vs=29810=30084

REVISION DETAIL
  https://phabricator.kde.org/D11445

AFFECTED FILES
  CMakeLists.txt
  app/CMakeLists.txt
  app/main.cpp

To: graesslin, #plasma, davidedmundson
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

Re: no OSK in Plasma Mobile

[Martin Flöser]

Am 2018-03-19 21:25, schrieb Heather Ellsworth:

On 03/17/2018 02:41 PM, Martin Flöser wrote:



Am 17. März 2018 02:01:24 MEZ schrieb Heather Ellsworth 
<heather.ellswo...@puri.sm>:

On 03/15/2018 09:10 PM, Bhushan Shah wrote:

Hello Heather,

On Thu, Mar 15, 2018 at 06:57:27PM -0600, Heather Ellsworth wrote:

I've been running Plasma Mobile on my iMX6 dev board (precursor to

the

dev kit for the Librem 5) and I've notices there's no onscreen

keyboard.

Is it there and I'm just not initializing it? Or what is the story

with

the OSK in Plasma Mobile?


For OSK, you just need to install qtvirtualkeyboard-plugin package,

it

should give you working on-screen-keyboard for the Qt applications.

It

is however possible that QtVirtualKeyboard is disabled by default if

you
have keyboard attached. In that case you can enable it by clicking 
on

virtualkeyboard icon in top drawer.

You can also "export QT_VIRTUALKEYBOARD_STYLE=Plasma" for better

theming

integration with Plasma Mobile.


After installing qtvirtualkeyboard-plugin and exporting
QT_VIRTUALKEYBOARD_STYLE, we still do not see a keyboard icon in the
top
left of the Plasma Mobile desktop.

Similarly, we do not see the icon after manually enabling the 
keyboard

with:

$ qdbus org.kde.KWin /VirtualKeyboard
org.kde.kwin.VirtualKeyboard.enable

However, after enabling the keyboard with the above qdbus command, we
see the keyboard pop up when a text field is clicked (like the search
bar, kwrite, konsole) but then the keyboard immediately goes away.

Also in the lock screen, I see the virtual keyboard icon in the 
bottom

left. When I click it, the virtual keyboard appears and does not
disappear. Then I can type in the password (using Ctrl+Super to guide
my
mouse) to log back in.

So the virtual keyboard works, but when in the desktop session the
keyboard goes away right after it appears. Any troubleshooting advice
you have would be helpful.



It might sound stupid, but just unplug the physical keyboard. Then it 
should work best. If the keyboard still hides, run the apps with 
WAYLAND_DEBUG=1 then we can see what's going on and why it hides. It 
should only hide if the application requests it and that's something 
we can see in the debug output.




Thank you for the suggestion. It turns out that the issue was actually
setting the QT_IM_MODULE:

$ export QT_IM_MODULE=qtvirtualkeyboard

With this variable set, I see the keyboard come up and then disappear
when a text field is clicked. I was testing with this variable on
Friday. However with this variable unset, the keyboard seems to _stay
around_ and be usable when a text field is clicked. So the trick is to
not set this :)


Yes, that makes sense. If the env variable is set, Qt creates a window 
in the process. If the env variable is not set the wayland protocol is 
used and KWin can provide the virtual keyboard.


I think I also understand why it closed directly: when the window opens 
KWin passes it keyboard focus. Thus the text field which triggered the 
keyboard loses keyboard focus and closes the keyboard again.


Cheers
Martin

D11447: No longer export QT_QPA_PLATFORM env variable to the session

[Martin Flöser]

graesslin added a comment.


  In D11447#229522 , @graesslin 
wrote:
  
  > There's another solution which might be cleaner and which KWin uses for 
that problem: modifying the process environment. I'll give a try whether this 
could work here.
  
  
  Doesn't work for our case. KWin calls QProcess::setProcessEnvironment on 
every QProcess it starts. It's a clean solution but unsuited for KRunner and 
Plasmashell.

REPOSITORY
  R120 Plasma Workspace

BRANCH
  unset-qt-qpa-platform

REVISION DETAIL
  https://phabricator.kde.org/D11447

To: graesslin, #plasma, davidedmundson, romangg
Cc: romangg, fvogt, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D11447: No longer export QT_QPA_PLATFORM env variable to the session

[Martin Flöser]

graesslin added a comment.


  In D11447#229478 , @romangg wrote:
  
  > Could we use a wrapper for QApplication being called by
  >
  >   QApplication app = KWorkSpace::createPlattformAwareQApplication(argc, 
argv);
  >
  >
  > and that sets and unsets the env variable in the wrapper call? With above 
code there might be a copy involved though.
  
  
  I don't think Qt allows this, the copy and move ctor should be deleted.
  
  There's another solution which might be cleaner and which KWin uses for that 
problem: modifying the process environment. I'll give a try whether this could 
work here.
  
  Btw it was a surprise to me that this unsetting is needed at all.

REPOSITORY
  R120 Plasma Workspace

BRANCH
  unset-qt-qpa-platform

REVISION DETAIL
  https://phabricator.kde.org/D11447

To: graesslin, #plasma, davidedmundson, romangg
Cc: romangg, fvogt, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D11447: No longer export QT_QPA_PLATFORM env variable to the session

[Martin Flöser]

graesslin added a comment.


  In D11447#229337 , @fvogt wrote:
  
  > In D11447#229334 , @graesslin 
wrote:
  >
  > > In D11447#229128 , @fvogt 
wrote:
  > >
  > > > If `KWorkSpace::detectPlatform(argc, argv);` were changed to edit 
`argc` and `argv` to pass `-platform foo` instead of setting `QT_QPA_PLATFORM`, 
the `qunsetenv` calls would become unnecessary.
  > >
  > >
  > > but that sounds rather dangerous. I don't want to mess with the command 
line arguments
  >
  >
  > Why is that more dangerous than environment variables?
  >  If argc and argv are passed to `QApplication`, you already know how it'll 
be parsed.
  
  
  Because I don't see how I could add something to argv without leaking memory 
and potentially crash. I consider it as dangerous to modify the argv array and 
adding elements to it. It's something I do not dare.

REPOSITORY
  R120 Plasma Workspace

BRANCH
  unset-qt-qpa-platform

REVISION DETAIL
  https://phabricator.kde.org/D11447

To: graesslin, #plasma, davidedmundson
Cc: romangg, fvogt, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D11447: No longer export QT_QPA_PLATFORM env variable to the session

[Martin Flöser]

graesslin added a comment.


  In D11447#229128 , @fvogt wrote:
  
  > If `KWorkSpace::detectPlatform(argc, argv);` were changed to edit `argc` 
and `argv` to pass `-platform foo` instead of setting `QT_QPA_PLATFORM`, the 
`qunsetenv` calls would become unnecessary.
  
  
  but that sounds rather dangerous. I don't want to mess with the command line 
arguments

REPOSITORY
  R120 Plasma Workspace

BRANCH
  unset-qt-qpa-platform

REVISION DETAIL
  https://phabricator.kde.org/D11447

To: graesslin, #plasma, davidedmundson
Cc: fvogt, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D11447: No longer export QT_QPA_PLATFORM env variable to the session

[Martin Flöser]

graesslin created this revision.
graesslin added a reviewer: Plasma.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
graesslin requested review of this revision.

REVISION SUMMARY
  As discussed the env variables are no longer exported. Thus Qt
  applications follow the default qpa platform they are compiled with and
  thus still function if they are packaged with a Qt without QtWayland.
  Plasma's internal processes pick the qpa platform depending on the
  session type as well as our flatpak apps.
  
  KRunner and Plasmashell are adjusted to not leak the env variable they
  set for themselves.

TEST PLAN
  Started a wayland session, verified with KWin's debug console
  that plasmashell and krunner are wayland. Launched kwrite from both plasma
  and krunner and verified that it's xcb

REPOSITORY
  R120 Plasma Workspace

BRANCH
  unset-qt-qpa-platform

REVISION DETAIL
  https://phabricator.kde.org/D11447

AFFECTED FILES
  krunner/main.cpp
  shell/main.cpp
  startkde/startplasmacompositor.cmake

To: graesslin, #plasma
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D11446: Use platform detection from KWorkspace in Powerdevil

[Martin Flöser]

graesslin created this revision.
graesslin added a reviewer: Plasma.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
graesslin requested review of this revision.

REVISION SUMMARY
  On a wayland session powerdevil needs to use Wayland platform.

TEST PLAN
  Only compile tested, changes are identical to the tested
  systemsettings patch.

REPOSITORY
  R122 Powerdevil

BRANCH
  platform-detection

REVISION DETAIL
  https://phabricator.kde.org/D11446

AFFECTED FILES
  CMakeLists.txt
  daemon/CMakeLists.txt
  daemon/powerdevilapp.cpp

To: graesslin, #plasma
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D11445: Use platform detection in SystemSettings

[Martin Flöser]

graesslin created this revision.
graesslin added a reviewer: Plasma.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
graesslin requested review of this revision.

REVISION SUMMARY
  SystemSettings needs to run on Wayland in a Wayland session and on X11
  in an X11 session.

TEST PLAN
  unset QT_QPA_PLATFORM and XDG_SESSION_TYPE -> x11 window,
  reset XDG_SESSION_TYPE to wayland -> wayland window

REPOSITORY
  R124 System Settings

BRANCH
  platform-detection

REVISION DETAIL
  https://phabricator.kde.org/D11445

AFFECTED FILES
  CMakeLists.txt
  app/CMakeLists.txt
  app/main.cpp

To: graesslin, #plasma
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D10816: Add platform detection to KWorkspace library to adjust QT_QPA_PLATFORM

[Martin Flöser]

This revision was automatically updated to reflect the committed changes.
Closed by commit R120:b5c326996309: Add platform detection to KWorkspace 
library to adjust QT_QPA_PLATFORM (authored by graesslin).

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10816?vs=28556=29809

REVISION DETAIL
  https://phabricator.kde.org/D10816

AFFECTED FILES
  krunner/CMakeLists.txt
  krunner/main.cpp
  ksmserver/logout-greeter/main.cpp
  ksmserver/switchuser-greeter/main.cpp
  ksplash/ksplashqml/CMakeLists.txt
  ksplash/ksplashqml/main.cpp
  kuiserver/CMakeLists.txt
  kuiserver/main.cpp
  libkworkspace/CMakeLists.txt
  libkworkspace/autotests/CMakeLists.txt
  libkworkspace/autotests/testPlatformDetection.cpp
  libkworkspace/kworkspace.cpp
  libkworkspace/kworkspace.h
  shell/CMakeLists.txt
  shell/main.cpp
  startkde/kcminit/CMakeLists.txt
  startkde/kcminit/main.cpp
  systemmonitor/CMakeLists.txt
  systemmonitor/main.cpp

To: graesslin, #plasma, romangg
Cc: davidedmundson, romangg, broulik, plasma-devel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

Re: no OSK in Plasma Mobile

[Martin Flöser]

Am 17. März 2018 02:01:24 MEZ schrieb Heather Ellsworth 
:
>On 03/15/2018 09:10 PM, Bhushan Shah wrote:
>> Hello Heather,
>> 
>> On Thu, Mar 15, 2018 at 06:57:27PM -0600, Heather Ellsworth wrote:
>>> I've been running Plasma Mobile on my iMX6 dev board (precursor to
>the
>>> dev kit for the Librem 5) and I've notices there's no onscreen
>keyboard.
>>> Is it there and I'm just not initializing it? Or what is the story
>with
>>> the OSK in Plasma Mobile?
>> 
>> For OSK, you just need to install qtvirtualkeyboard-plugin package,
>it
>> should give you working on-screen-keyboard for the Qt applications.
>It
>> is however possible that QtVirtualKeyboard is disabled by default if
>you
>> have keyboard attached. In that case you can enable it by clicking on
>> virtualkeyboard icon in top drawer.
>> 
>> You can also "export QT_VIRTUALKEYBOARD_STYLE=Plasma" for better
>theming
>> integration with Plasma Mobile.
>
>After installing qtvirtualkeyboard-plugin and exporting
>QT_VIRTUALKEYBOARD_STYLE, we still do not see a keyboard icon in the
>top
>left of the Plasma Mobile desktop.
>
>Similarly, we do not see the icon after manually enabling the keyboard
>with:
>
>$ qdbus org.kde.KWin /VirtualKeyboard
>org.kde.kwin.VirtualKeyboard.enable
>
>However, after enabling the keyboard with the above qdbus command, we
>see the keyboard pop up when a text field is clicked (like the search
>bar, kwrite, konsole) but then the keyboard immediately goes away.
>
>Also in the lock screen, I see the virtual keyboard icon in the bottom
>left. When I click it, the virtual keyboard appears and does not
>disappear. Then I can type in the password (using Ctrl+Super to guide
>my
>mouse) to log back in.
>
>So the virtual keyboard works, but when in the desktop session the
>keyboard goes away right after it appears. Any troubleshooting advice
>you have would be helpful.
>

It might sound stupid, but just unplug the physical keyboard. Then it should 
work best. If the keyboard still hides, run the apps with WAYLAND_DEBUG=1 then 
we can see what's going on and why it hides. It should only hide if the 
application requests it and that's something we can see in the debug output.

[Breeze] [Bug 369676] White lockscreen text's readability depends on background

[Martin Flöser]

https://bugs.kde.org/show_bug.cgi?id=369676

--- Comment #24 from Martin Flöser <mgraess...@kde.org> ---
I really like the idea presented by Marco to use a slideshow and then
transition to our "existing" lock screen. I see this as a clear evolution over
the current state without losing why we did the current existing lock screen in
the first place.

What I would like to be considered is the impact on the environment when doing
a slideshow. If a system is locked, it's most likely because nobody is in front
of the system. That means we show an animation nobody sees, which of course has
a negative impact on the climate. We shouldn't downplay this factor as this
change will hopefully affect millions of systems.

But I think it's possible to get a compromise here:
 * stop the animation as soon as the screen goes into power saving (for this we
might need a hook from powerdevil) and restart on user interaction
 * increase the time between every transition (e.g. fibonacci style, so the
longer nobody interacting with the system, the longer it takes for an animation
to be shown).

For those wondering why an animation is a big deal: in the locked case we have
KWin (Wayland compositor) pretty much sleeping, the system can go into the
lowest power mode. But animations mean that the compositor is woken up and the
system needs to go into a higher power state. The transition between wallpapers
is animated so our system is at least woken up 60 times per second for the
duration of the transition.

-- 
You are receiving this mail because:
You are the assignee for the bug.

D11308: Use the default Plasma wallpaper on the lock screen

[Martin Flöser]

graesslin added a comment.


  In D11308#227359 , @ngraham wrote:
  
  > In D11308#227358 , @graesslin 
wrote:
  >
  > > In D11308#227332 , @ngraham 
wrote:
  > >
  > > > In D11308#227330 , 
@graesslin wrote:
  > > >
  > > > > @ngraham Let's try to not work against our distros. Yes we could 
change that because we are upstream, we set the default. The result would be 
distros swapping the wallpaper and we have unreadable text. This is something 
which will happen, I have been too long in this business to not expect 
otherwise. We want to provide a good experience for everyone. And that means 
this change just cannot go in, sorry about that.
  > > > >
  > > > > Sorry, we just cannot do a change which renders the text possibly 
unreadable on most systems.
  > > >
  > > >
  > > > Do we know that the distros you mentioned currently do use wallpapers 
that will make white text unreadable, or is this a worry about the future?
  > >
  > >
  > > I do not know how the situation is as I don't have tested all distros. 
But I also think that this is irrelevant. We have a technical problem here and 
that needs to be fixed.
  >
  >
  > I very much agree that there is a technical problem in need of fixing. As 
you can see in https://bugs.kde.org/show_bug.cgi?id=369676, we're starting to 
scope out that work. The question is, does that work need to be done before 
this change can land? We can ensure that our upstream image looks good, and we 
can alert distros to the change and help them ensure that theirs do too. Plasma 
5.13 isn't being released for several more months, which gives us time to work 
with rolling release distros to ensure that they're not shipping a lock screen 
background that's unreadable. We have even more time for the fixed release 
distros like Debian, Ubuntu, Fedora, and openSUSE Leap.  In particular it will 
be years before Debian stable gets Plasma 5.13.
  >
  > I volunteer to lead the distro outreach effort to ensure that distros don't 
ship with lockscreen backgrounds that make the text unreadable.
  >
  > And medium-term, we will fix the lock screen's UI in 
https://bugs.kde.org/show_bug.cgi?id=369676 to eliminate the issue entirely.
  >
  > Does this sound like a sensible path forward, Martin?
  
  
  Sorry but no. I want to see it addressed before flipping it. We have shipped 
half finished things too often - especially on the look screen. Sorry but 
sometimes I wonder what you want to achieve: improve the situation for all of 
change for the sake of change. If you ignore that most users won't get the 
wallpaper you think of then it's unfortunately the latter.

REPOSITORY
  R133 KScreenLocker

REVISION DETAIL
  https://phabricator.kde.org/D11308

To: ngraham, #plasma, #vdg, graesslin, abetts
Cc: Fuchs, broulik, davidedmundson, zzag, Pitel, progwolff, abetts, hein, mart, 
graesslin, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
sebas, apol

D11308: Use the default Plasma wallpaper on the lock screen

[Martin Flöser]

graesslin added a comment.


  In D11308#227357 , @ngraham wrote:
  
  > In D11308#227356 , @graesslin 
wrote:
  >
  > > In D11308#227334 , @ngraham 
wrote:
  > >
  > > > Also, Martin, this isn't about re-using the desktop wallpaper on the 
lock screen. It's about using the current Plasma wallpaper on the lock screen. 
Distros can and do override the desktop wallpaper but to my knowledge most 
don't currently override the lockscreen background, right?
  > >
  > >
  > > At least on Debian our default wallpaper is not installed and replaced by 
Debian's default wallpaper. This change is so deep that it even overrides my 
local plasma installation.
  >
  >
  >
  >
  > 1. That seems like a downstream bug; they should be adding wallpapers and 
overriding defaults using config files, not replacing our defaults (with 
potentially invasive code changes?). Can you engage with the Debian folks to 
get that fixed?
  
  
  I'm certainly not going to play don Quixote against Debian packaging 
policies. I currently don't even have time to review KWin changes...
  
  > 2. Does the wallpaper they chose make the white lock screen text unreadable?
  
  Debian tends to change the wallpaper late in the cycle. I cannot tell you how 
the wallpaper will look like together with this change. I can tell you that 
Debian will ship it broken and their policies will make it impossible to change 
once the freeze is in place. And I can tell you that Debian will certainly not 
adjust the lnf package. Nobody looks at the big picture - there's a team doing 
keep packaging and a team doing wallpapers. Expecting them to work together 
seems unreasonable. Apparently the ice team does not even have influence on 
what's getting installed in a default ice install, because that's another team.
  
  Welcome to the reality of distros. And in many other distros it doesn't look 
different. Most distros are understaffed and only do packaging. Nobody will 
notice if this breaks till it's too late. And then we will get the blame for 
doing such  a change. And we cannot say we didn't know.

REPOSITORY
  R133 KScreenLocker

REVISION DETAIL
  https://phabricator.kde.org/D11308

To: ngraham, #plasma, #vdg, graesslin, abetts
Cc: Fuchs, broulik, davidedmundson, zzag, Pitel, progwolff, abetts, hein, mart, 
graesslin, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
sebas, apol

D11308: Use the default Plasma wallpaper on the lock screen

[Martin Flöser]

graesslin added a comment.


  In D11308#227332 , @ngraham wrote:
  
  > In D11308#227330 , @graesslin 
wrote:
  >
  > > @ngraham Let's try to not work against our distros. Yes we could change 
that because we are upstream, we set the default. The result would be distros 
swapping the wallpaper and we have unreadable text. This is something which 
will happen, I have been too long in this business to not expect otherwise. We 
want to provide a good experience for everyone. And that means this change just 
cannot go in, sorry about that.
  > >
  > > Sorry, we just cannot do a change which renders the text possibly 
unreadable on most systems.
  >
  >
  > Do we know that the distros you mentioned currently do use wallpapers that 
will make white text unreadable, or is this a worry about the future?
  
  
  I do not know how the situation is as I don't have tested all distros. But I 
also think that this is irrelevant. We have a technical problem here and that 
needs to be fixed.
  
  > And would you accept this chance if we fixed the login screen to eliminate 
the issue of bad contrast on light backgrounds? 
(https://bugs.kde.org/show_bug.cgi?id=369676)
  
  I asked for addressing this issue, if it's addressed then it's fine for me. 
Personally I would recommend you against the change due to the history, but 
design decisions are up to the vdg and won't be blocked by me.

REPOSITORY
  R133 KScreenLocker

REVISION DETAIL
  https://phabricator.kde.org/D11308

To: ngraham, #plasma, #vdg, graesslin, abetts
Cc: Fuchs, broulik, davidedmundson, zzag, Pitel, progwolff, abetts, hein, mart, 
graesslin, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
sebas, apol

D11308: Use the default Plasma wallpaper on the lock screen

[Martin Flöser]

graesslin added a comment.


  In D11308#227334 , @ngraham wrote:
  
  > Also, Martin, this isn't about re-using the desktop wallpaper on the lock 
screen. It's about using the current Plasma wallpaper on the lock screen. 
Distros can and do override the desktop wallpaper but to my knowledge most 
don't currently override the lockscreen background, right?
  
  
  At least on Debian our default wallpaper is not installed and replaced by 
Debian's default wallpaper. This change is so deep that it even overrides my 
local plasma installation.

REPOSITORY
  R133 KScreenLocker

REVISION DETAIL
  https://phabricator.kde.org/D11308

To: ngraham, #plasma, #vdg, graesslin, abetts
Cc: Fuchs, broulik, davidedmundson, zzag, Pitel, progwolff, abetts, hein, mart, 
graesslin, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
sebas, apol

D11308: Use the default Plasma wallpaper on the lock screen

[Martin Flöser]

graesslin added a comment.


  @ngraham Let's try to not work against our distros. Yes we could change that 
because we are upstream, we set the default. The result would be distros 
swapping the wallpaper and we have unreadable text. This is something which 
will happen, I have been too long in this business to not expect otherwise. We 
want to provide a good experience for everyone. And that means this change just 
cannot go in, sorry about that.
  
  I understand that you want to improve the situation, but we need to think in 
the big picture. And that is all distros change wallpapers. Debian does, 
openSUSE does, Fedora does. The only distro I know which does not exchange the 
default wallpaper is Kubuntu. Sorry, we just cannot do a change which renders 
the text possibly unreadable on most systems.

REPOSITORY
  R133 KScreenLocker

REVISION DETAIL
  https://phabricator.kde.org/D11308

To: ngraham, #plasma, #vdg, graesslin, abetts
Cc: broulik, davidedmundson, zzag, Pitel, progwolff, abetts, hein, mart, 
graesslin, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
sebas, apol

D11308: Use the default Plasma wallpaper on the lock screen

[Martin Flöser]

graesslin added a comment.


  In D11308#226836 , @ngraham wrote:
  
  > @graesslin, those are good comments for @mart's ideas for the other 
approach. Do you have any remaining concerns with this one that I can work on?
  
  
  As long as the lnf theme is not changed to provide sensible background 
contrast I'm against this change. We don't have control over the default 
background, this is done by distros. We cannot change in ways that it would 
break for them.

REPOSITORY
  R133 KScreenLocker

REVISION DETAIL
  https://phabricator.kde.org/D11308

To: ngraham, #plasma, #vdg, graesslin, abetts
Cc: davidedmundson, zzag, Pitel, progwolff, abetts, hein, mart, graesslin, 
plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D11308: Use the default Plasma wallpaper on the lock screen

[Martin Flöser]

graesslin added a comment.


  In D11308#226803 , @ngraham wrote:
  
  > Thanks @mart. I think using an animated slideshow by default will be really 
popular, especially if we do some work to add more nice images by default and 
polish up the slideshow plugin's UI a bit. I'm glad to hear that the memory 
issue is or should be resolved soon.
  >
  > @graesslin, have we satisfactorily resolved your objections yet? It not, 
what more needs to be done here?
  
  
  Please be aware of two things:
  
  - Most distros only install one wallpaper by default. If we go this route we 
must reach out to distros before and check whether they are able to install 
more default wallpapers
  - If you talk about this please never, never,ever call it a screen saver. We 
don't have to save screens, we don't have crts anymore. We removed the screen 
saver support because of that and because of the energy saving. Call it 
animations or transitions, but not screen saver.
  
  Personally I dislike animations on the lock screen by default due to the 
environment impact. We burn CPU and GPU cycles to show animations nobody will 
see (if the screen is locked the reason is mostly that the user went away). In 
times of global warming we should consider the impact of enabling animations 
for maybe millions of systems.
  
  My suggestion is to:
  
  - Decrease the default power saving time
  - Ensure those animations stop when screen is power saved
  - Increase the time between wallpaper transitions in e.g. Fibonacci time.

REPOSITORY
  R133 KScreenLocker

REVISION DETAIL
  https://phabricator.kde.org/D11308

To: ngraham, #plasma, #vdg, graesslin, abetts
Cc: davidedmundson, zzag, Pitel, progwolff, abetts, hein, mart, graesslin, 
plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D11308: Use the default Plasma wallpaper on the lock screen

[Martin Flöser]

graesslin requested changes to this revision.
graesslin added a comment.
This revision now requires changes to proceed.


  I think we first need to bring back some background for the UI elements. 
Otherwise it's too difficult to read.
  
  Personally I'm very confused as it was the vdg's wish to have it blue. I hope 
our users don't take this negative. I would take it negative to see such a 
forward and backward.

REPOSITORY
  R133 KScreenLocker

REVISION DETAIL
  https://phabricator.kde.org/D11308

To: ngraham, #plasma, #vdg, graesslin
Cc: graesslin, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D10816: Add platform detection to KWorkspace library to adjust QT_QPA_PLATFORM

[Martin Flöser]

graesslin added a comment.


  In D10816#221084 , @romangg wrote:
  
  > Hmm, what about application distributed as distro packages? Anyways,if you 
think this is a non-issue, feel free to push.
  
  
  Let's be realistic. Many applications we ship don't even have the desktop 
file name fixed for Wayland. I doubt we would see adjustments for this prior to 
distros shipping Qt 5.11.

REPOSITORY
  R120 Plasma Workspace

BRANCH
  platform-detection

REVISION DETAIL
  https://phabricator.kde.org/D10816

To: graesslin, #plasma, romangg
Cc: romangg, broulik, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart