D6186: Implement software cursor in OpenGL backend

[Thomas Lübking]

luebking added inline comments.

INLINE COMMENTS

> scene_opengl.cpp:713
> +// handle shape update on case cursor image changed
> +connect(Cursor::self(), ::cursorChanged, this, 
> updateCursorTexture);
> +}

You still update the cursor texture with every paint() - there should be no 
need to hook this signal.
Actually, the patch got much worse:

a) you're fetching the image and reset the texture with each! paint()
b) you're creating a nerw connection to cursorChanged() with each! paint()

REPOSITORY
  R108 KWin

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

To: Kanedias, graesslin, davidedmundson
Cc: luebking, plasma-devel, kwin, #kwin, ZrenBot, spstarr, progwolff, 
lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, eliasp, sebas, 
apol, mart, hein, lukas

D6257: Fix switch desktop through edge when moving window

[Martin Flöser]

graesslin added a dependent revision: D6264: Fix switch desktop on screenedge 
while resizing a Wayland window.

REPOSITORY
  R108 KWin

BRANCH
  fix-screenedge-window-move-5.10

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

To: graesslin, #kwin, #plasma, broulik
Cc: plasma-devel, kwin, ZrenBot, spstarr, progwolff, lesliezhai, ali-mohamed, 
hardening, jensreuterberg, abetts, sebas, apol, mart, lukas

D6264: Fix switch desktop on screenedge while resizing a Wayland window

[Martin Flöser]

graesslin added a dependency: D6257: Fix switch desktop through edge when 
moving window.

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

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

D6264: Fix switch desktop on screenedge while resizing a Wayland window

[Martin Flöser]

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

REVISION SUMMARY
  Screenedges only allows to switch desktop while moving window, not
  while resizing. There was a special branch which only checked this for
  X11 windows but not for Wayland windows.
  
  This change removes a no longer needed cast from AbstractClient to Client
  so that the check whether a window is getting resized works for both
  X11 and Wayland clients. The cast was introduced in a time when
  AbstractClient did not yet support the isResize method.

BRANCH
  fix-screenedge-wayland-window-resize-5.10

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

AFFECTED FILES
  screenedge.cpp

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

[Breeze] [Bug 381288] Breeze could use higher-contrast text by default (tweaked color scheme attached)

[Jens Reuterberg]

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

--- Comment #7 from Jens Reuterberg  ---
You do have a good point. Perfect black on light-light grey is the preferred 
one... (although as a print-monkey I need to say "Bright Yellow on Dark Grey" 
or the other print monkeys may get angry ;) ) I worry about the inverted 
colour scheme though and icon effects.

I propose this - lets create a secondary theme and then try to do some proper 
testing. I mean the tricky bit is tying up the bag as it where (because we 
don't want #00 background for breeze dark) as the colour scheme is such a 
huge chunk of the identity in so many other areas (from mascots to print 
material, webpages etc) - will the gain from swapping to #00 in 
readability justify eventual issues there? Or am I just bikeshedding?

We also need to see if we are creating a huge problem for the developers in 
the future... so we would need to have a dev in on it to supervise so we don't 
create a mess

Sebas (et al) can we sort of hold off on this while we drag poor Nate into the 
VDG room for a chat?

On Sunday, 18 June 2017 15.42.54 CEST Nate Graham wrote:
> https://bugs.kde.org/show_bug.cgi?id=381288
> 
> Nate Graham  changed:
> 
>What|Removed |Added
> 
> Status|RESOLVED|UNCONFIRMED
>  Resolution|WONTFIX |---
> 
> --- Comment #6 from Nate Graham  ---
> Thanks for the comments, everyone.
> 
> I have to disagree that this is a matter of subjectivity or taste--this is
> just my preference and other people might not like it. There are objective,
> scientifically derived principles governing things like eyestrain and
> readability:
> 
> https://www.nngroup.com/articles/low-contrast/
> http://www.tinhat.com/usability/color.html
> http://contrastrebellion.com/
> http://universalusability.com/access_by_design/text/contrast.html
> 
> From the above articles, you can see that the *most* readable, usable text
> is 100% black on a not-quite-100%-white background, since pure white can be
> blinding on bright screens. Breeze is *so close* with the pleasant light
> gray backgrounds, but the text itself needs to be a bit bolder to reap the
> rewards of maximum readability. This will not present a "harsh" contrast;
> on the contrary, it will make the text *more attractive*, not less. Again,
> this is not my personal preference, but rather the result of decades of
> hard-earned usability investigation. I encourage you to read those
> articles.

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

Re: [Breeze] [Bug 381288] Breeze could use higher-contrast text by default (tweaked color scheme attached)

[Jens Reuterberg]

You do have a good point. Perfect black on light-light grey is the preferred 
one... (although as a print-monkey I need to say "Bright Yellow on Dark Grey" 
or the other print monkeys may get angry ;) ) I worry about the inverted 
colour scheme though and icon effects.

I propose this - lets create a secondary theme and then try to do some proper 
testing. I mean the tricky bit is tying up the bag as it where (because we 
don't want #00 background for breeze dark) as the colour scheme is such a 
huge chunk of the identity in so many other areas (from mascots to print 
material, webpages etc) - will the gain from swapping to #00 in 
readability justify eventual issues there? Or am I just bikeshedding?

We also need to see if we are creating a huge problem for the developers in 
the future... so we would need to have a dev in on it to supervise so we don't 
create a mess

Sebas (et al) can we sort of hold off on this while we drag poor Nate into the 
VDG room for a chat?

On Sunday, 18 June 2017 15.42.54 CEST Nate Graham wrote:
> https://bugs.kde.org/show_bug.cgi?id=381288
> 
> Nate Graham  changed:
> 
>What|Removed |Added
> 
> Status|RESOLVED|UNCONFIRMED
>  Resolution|WONTFIX |---
> 
> --- Comment #6 from Nate Graham  ---
> Thanks for the comments, everyone.
> 
> I have to disagree that this is a matter of subjectivity or taste--this is
> just my preference and other people might not like it. There are objective,
> scientifically derived principles governing things like eyestrain and
> readability:
> 
> https://www.nngroup.com/articles/low-contrast/
> http://www.tinhat.com/usability/color.html
> http://contrastrebellion.com/
> http://universalusability.com/access_by_design/text/contrast.html
> 
> From the above articles, you can see that the *most* readable, usable text
> is 100% black on a not-quite-100%-white background, since pure white can be
> blinding on bright screens. Breeze is *so close* with the pleasant light
> gray backgrounds, but the text itself needs to be a bit bolder to reap the
> rewards of maximum readability. This will not present a "harsh" contrast;
> on the contrary, it will make the text *more attractive*, not less. Again,
> this is not my personal preference, but rather the result of decades of
> hard-earned usability investigation. I encourage you to read those
> articles.

D6186: Implement software cursor in OpenGL backend

[Oleg Chernovskiy]

Kanedias marked 3 inline comments as done.
Kanedias added a comment.


  Fixed lazy-init

REPOSITORY
  R108 KWin

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

To: Kanedias, graesslin, davidedmundson
Cc: luebking, plasma-devel, kwin, #kwin, ZrenBot, spstarr, progwolff, 
lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, eliasp, sebas, 
apol, mart, hein, lukas

D6186: Implement software cursor in OpenGL backend

[Oleg Chernovskiy]

Kanedias updated this revision to Diff 1.
Kanedias added a comment.


  Whoops, wrong patch

REPOSITORY
  R108 KWin

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D6186?vs=15554=1

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

AFFECTED FILES
  scene_opengl.cpp
  scene_opengl.h

To: Kanedias, graesslin, davidedmundson
Cc: luebking, plasma-devel, kwin, #kwin, ZrenBot, spstarr, progwolff, 
lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, eliasp, sebas, 
apol, mart, hein, lukas

D6186: Implement software cursor in OpenGL backend

[Oleg Chernovskiy]

Kanedias updated this revision to Diff 15554.
Kanedias added a comment.


  Fixes for lazy-init (thanks T.L.)

REPOSITORY
  R108 KWin

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D6186?vs=15397=15554

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

AFFECTED FILES
  autotests/client/CMakeLists.txt
  autotests/client/test_remote_access.cpp
  src/client/CMakeLists.txt
  src/client/fakeinput.cpp
  src/client/fakeinput.h
  src/client/protocols/fake-input.xml
  src/client/protocols/remote-access.xml
  src/client/registry.cpp
  src/client/registry.h
  src/client/remote_access.cpp
  src/client/remote_access.h
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/fakeinput_interface.cpp
  src/server/fakeinput_interface.h
  src/server/remote_access_interface.cpp
  src/server/remote_access_interface.h
  src/server/remote_access_interface_p.h
  src/tools/mapping.txt
  src/tools/testserver/testserver.cpp

To: Kanedias, graesslin, davidedmundson
Cc: luebking, plasma-devel, kwin, #kwin, ZrenBot, spstarr, progwolff, 
lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, eliasp, sebas, 
apol, mart, hein, lukas

D6186: Implement software cursor in OpenGL backend

[Thomas Lübking]

luebking added inline comments.

INLINE COMMENTS

> Kanedias wrote in scene_opengl.cpp:734
> You mean, to check whether BLEND was enabled prior to calling this func?

You might have to - and in addition possibly reset the actual blend function 
from before. Please wait for Martins comment on this, idk which assumptions can 
be safely made here.

REPOSITORY
  R108 KWin

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

To: Kanedias, graesslin, davidedmundson
Cc: luebking, plasma-devel, kwin, #kwin, ZrenBot, spstarr, progwolff, 
lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, eliasp, sebas, 
apol, mart, hein, lukas

D6186: Implement software cursor in OpenGL backend

[Oleg Chernovskiy]

Kanedias added inline comments.

INLINE COMMENTS

> luebking wrote in scene_opengl.cpp:699
> The entire head should probably be in some init function, not in every paint 
> call.
> If you go for a lazy init, you should seekt to prevent double connects (but I 
> don't know whether Qt::UniqueConnection works with functors), but I'd 
> discourage that approach, because it prevents shortcutting the function if 
> there's no cursor image (ie. "!m_cursorTexture")

Will fix that

> luebking wrote in scene_opengl.cpp:734
> This needs a comment from Martin, but you might have to glGet with 
> GL_BLEND_SRC and GL_BLEND_DST as well as glIsEnabled(GL_BLEND)

You mean, to check whether BLEND was enabled prior to calling this func?

REPOSITORY
  R108 KWin

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

To: Kanedias, graesslin, davidedmundson
Cc: luebking, plasma-devel, kwin, #kwin, ZrenBot, spstarr, progwolff, 
lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, eliasp, sebas, 
apol, mart, hein, lukas

D1231: Add Remote Access interface to KWayland

[Oleg Chernovskiy]

Kanedias updated this revision to Diff 15553.
Kanedias added a comment.


  Fixed KWAYLAND -> Kwayland in CmakeLists.txt

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D1231?vs=15125=15553

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

AFFECTED FILES
  autotests/client/CMakeLists.txt
  autotests/client/test_remote_access.cpp
  src/client/CMakeLists.txt
  src/client/fakeinput.cpp
  src/client/fakeinput.h
  src/client/protocols/fake-input.xml
  src/client/protocols/remote-access.xml
  src/client/registry.cpp
  src/client/registry.h
  src/client/remote_access.cpp
  src/client/remote_access.h
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/fakeinput_interface.cpp
  src/server/fakeinput_interface.h
  src/server/remote_access_interface.cpp
  src/server/remote_access_interface.h
  src/server/remote_access_interface_p.h
  src/tools/mapping.txt
  src/tools/testserver/testserver.cpp

To: Kanedias, graesslin, davidedmundson
Cc: #frameworks, davidedmundson, plasma-devel, ZrenBot, spstarr, progwolff, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, eliasp, sebas, apol, mart, 
hein, lukas

D1231: Add Remote Access interface to KWayland

[Oleg Chernovskiy]

Kanedias added a comment.


  @davidedmundson , do we really have nativeResourceForScreen call? AFAIK KWin 
uses its own QPA, which implements only bits of functionality. We need to have 
nativeResourceForScreen to be able to pass wl_output, should I patch QPA also, 
or is there better way?

REPOSITORY
  R127 KWayland

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

To: Kanedias, graesslin, davidedmundson
Cc: #frameworks, davidedmundson, plasma-devel, ZrenBot, spstarr, progwolff, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, eliasp, sebas, apol, mart, 
hein, lukas

D6186: Implement software cursor in OpenGL backend

[Thomas Lübking]

luebking added inline comments.

INLINE COMMENTS

> scene_opengl.cpp:699
> +// don't paint if no image for cursor is set
> +const QImage img = kwinApp()->platform()->softwareCursor();
> +if (img.isNull()) {

The entire head should probably be in some init function, not in every paint 
call.
If you go for a lazy init, you should seekt to prevent double connects (but I 
don't know whether Qt::UniqueConnection works with functors), but I'd 
discourage that approach, because it prevents shortcutting the function if 
there's no cursor image (ie. "!m_cursorTexture")

> scene_opengl.cpp:709
> +// handle shape update in case cursor image changed
> +connect(Cursor::self(), ::cursorChanged, this, [this] {
> +const QImage img = kwinApp()->platform()->softwareCursor();

At this time, this seems superfluous, because you fetch the current image with 
every paint call anyway.

> scene_opengl.cpp:711
> +const QImage img = kwinApp()->platform()->softwareCursor();
> +m_cursorTexture.reset(new GLTexture(img));
> +});

There's no .isNull() test here - in contrast to the assignment some lines above

> scene_opengl.cpp:734
> +
> +glDisable(GL_BLEND);
> +}

This needs a comment from Martin, but you might have to glGet with GL_BLEND_SRC 
and GL_BLEND_DST as well as glIsEnabled(GL_BLEND)

REPOSITORY
  R108 KWin

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

To: Kanedias, graesslin, davidedmundson
Cc: luebking, plasma-devel, kwin, #kwin, ZrenBot, spstarr, progwolff, 
lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, eliasp, sebas, 
apol, mart, hein, lukas

D6186: Implement software cursor in OpenGL backend

[Oleg Chernovskiy]

Kanedias marked an inline comment as done.
Kanedias added a comment.


  @graesslin , are you here? Can you look at this submission please if you have 
time?

REPOSITORY
  R108 KWin

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

To: Kanedias, graesslin, davidedmundson
Cc: plasma-devel, kwin, #kwin, ZrenBot, spstarr, progwolff, lesliezhai, 
ali-mohamed, hardening, jensreuterberg, abetts, eliasp, sebas, apol, mart, 
hein, lukas

D6258: Workaround Qt regression of no longer delivering events for the root window

[Martin Flöser]

graesslin added a comment.


  In https://phabricator.kde.org/D6258#117243, @fvogt wrote:
  
  > What about the 5.8 branch? I'm not aware of any distros that use it with Qt 
5.9, but IMO it needs to be fixed there as well.
  
  
  I think it is not reasonable for a distribution to keep Plasma on LTS but 
update Qt to the latest. If a distro really wants they can backport the patch.

REPOSITORY
  R108 KWin

BRANCH
  fix-grab-root-window-5.10

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

To: graesslin, #kwin, #plasma, broulik
Cc: fvogt, broulik, plasma-devel, kwin, ZrenBot, spstarr, progwolff, 
lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart, 
lukas

D6260: Better handle cases when the xkb keymap fails to be created

[Martin Flöser]

graesslin created this revision.
Restricted Application added a project: KWin.
Restricted Application added subscribers: kwin, plasma-devel.

REVISION SUMMARY
  If the keymap cannot be created a few pointers in Xkb are null.
  We should make sure to not call any xkbcommon functions on those
  null pointers and instead use proper fallbacks.
  
  This change introduces fixes for a few usages, but it's not unlikely
  that there are more cases.
  
  BUG: 381210
  FIXED-IN: 5.10.3

TEST PLAN
  Autotest added for the condition of the bug, which does
  not crash any more. Just starting the test found a few more crash
  cases.

REPOSITORY
  R108 KWin

BRANCH
  safety-checks-xkbcommon-5.10

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

AFFECTED FILES
  autotests/integration/CMakeLists.txt
  autotests/integration/keymap_creation_failure_test.cpp
  xkb.cpp

To: graesslin, #kwin, #plasma
Cc: plasma-devel, kwin, ZrenBot, spstarr, progwolff, lesliezhai, ali-mohamed, 
hardening, jensreuterberg, abetts, sebas, apol, mart, lukas

D6247: Fix clicking outside of preview popups to dismiss them corrupting mouse state

[Kai Uwe Broulik]

broulik added inline comments.

INLINE COMMENTS

> FolderItemDelegate.qml:119
>  } else if (!hovered) {
>  if (popupDialog != null) {
> +closePopup();

This check is now superfluous as it's also done in `closePopup()`

REPOSITORY
  R119 Plasma Desktop

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

To: hein, #plasma
Cc: broulik, plasma-devel, ZrenBot, spstarr, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D6258: Workaround Qt regression of no longer delivering events for the root window

[Fabian Vogt]

fvogt added a comment.


  What about the 5.8 branch? I'm not aware of any distros that use it with Qt 
5.9, but IMO it needs to be fixed there as well.

REPOSITORY
  R108 KWin

BRANCH
  fix-grab-root-window-5.10

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

To: graesslin, #kwin, #plasma, broulik
Cc: fvogt, broulik, plasma-devel, kwin, ZrenBot, spstarr, progwolff, 
lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart, 
lukas

[Powerdevil] [Bug 352497] laptop back light not coming back on after long period of lcd being in dpms power save mode.

[Sebastian Kügler]

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

Sebastian Kügler  changed:

   What|Removed |Added

   Assignee|plasma-devel@kde.org|plasma-b...@kde.org

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

[Breeze] [Bug 381288] Breeze could use higher-contrast text by default (tweaked color scheme attached)

[Nate Graham]

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

Nate Graham  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |---

--- Comment #6 from Nate Graham  ---
Thanks for the comments, everyone.

I have to disagree that this is a matter of subjectivity or taste--this is just
my preference and other people might not like it. There are objective,
scientifically derived principles governing things like eyestrain and
readability:

https://www.nngroup.com/articles/low-contrast/
http://www.tinhat.com/usability/color.html
http://contrastrebellion.com/
http://universalusability.com/access_by_design/text/contrast.html

>From the above articles, you can see that the *most* readable, usable text is
100% black on a not-quite-100%-white background, since pure white can be
blinding on bright screens. Breeze is *so close* with the pleasant light gray
backgrounds, but the text itself needs to be a bit bolder to reap the rewards
of maximum readability. This will not present a "harsh" contrast; on the
contrary, it will make the text *more attractive*, not less. Again, this is not
my personal preference, but rather the result of decades of hard-earned
usability investigation. I encourage you to read those articles.

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

D6257: Fix switch desktop through edge when moving window

[Kai Uwe Broulik]

broulik accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R108 KWin

BRANCH
  fix-screenedge-window-move-5.10

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

To: graesslin, #kwin, #plasma, broulik
Cc: plasma-devel, kwin, ZrenBot, spstarr, progwolff, lesliezhai, ali-mohamed, 
hardening, jensreuterberg, abetts, sebas, apol, mart, lukas

D6258: Workaround Qt regression of no longer delivering events for the root window

[Kai Uwe Broulik]

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


  Fixes keyboard nav in present windows for me

REPOSITORY
  R108 KWin

BRANCH
  fix-grab-root-window-5.10

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

To: graesslin, #kwin, #plasma, broulik
Cc: broulik, plasma-devel, kwin, ZrenBot, spstarr, progwolff, lesliezhai, 
ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart, lukas

D6258: Workaround Qt regression of no longer delivering events for the root window

[Martin Flöser]

graesslin created this revision.
Restricted Application added a project: KWin.
Restricted Application added subscribers: kwin, plasma-devel.

REVISION SUMMARY
  With qtbase 2b34aefcf02f09253473b096eb4faffd3e62b5f4 we do no longer get
  events reported for the X11 root window. Our keyboard handling in effects
  like PresentWindows and DesktopGrid relied on that.
  
  This change works around the regression by calling winId() on
  qApp->desktop() as suggested in the change. This is a short term solution
  for the 5.10 branch.
  
  This needs to be addressed properly by no longer relying on Qt in this
  area. KWin already does not rely on Qt for Wayland in that area and is
  able to compose the QKeyEvents. This should also be done on X11. It just
  needs some more hook up code for xkb, but that's needed anyway to improve
  modifier only shortcuts and friends.
  
  BUG: 360841
  FIXED-IN: 5.10.3

REPOSITORY
  R108 KWin

BRANCH
  fix-grab-root-window-5.10

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

AFFECTED FILES
  effects.cpp

To: graesslin, #kwin, #plasma
Cc: plasma-devel, kwin, ZrenBot, spstarr, progwolff, lesliezhai, ali-mohamed, 
hardening, jensreuterberg, abetts, sebas, apol, mart, lukas

D6257: Fix switch desktop through edge when moving window

[Martin Flöser]

graesslin created this revision.
Restricted Application added a project: KWin.
Restricted Application added subscribers: kwin, plasma-devel.

REVISION SUMMARY
  There was a regression introduced in ScreenEdges when introducing the
  activatesForPointer method. It considered the switch desktop on edge,
  but not the special case of switch desktop when moving windows. Due to
  that the edges did not activate when moving the window.
  
  This change addresses the regression and extends the autotest to ensure
  it's properly covered.
  
  BUG: 380440
  FIXED-IN: 5.10.3

TEST PLAN
  Manual testing and extended auto test

REPOSITORY
  R108 KWin

BRANCH
  fix-screenedge-window-move-5.10

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

AFFECTED FILES
  autotests/mock_abstract_client.cpp
  autotests/mock_abstract_client.h
  autotests/mock_client.cpp
  autotests/mock_client.h
  autotests/test_screen_edges.cpp
  screenedge.cpp

To: graesslin, #kwin, #plasma
Cc: plasma-devel, kwin, ZrenBot, spstarr, progwolff, lesliezhai, ali-mohamed, 
hardening, jensreuterberg, abetts, sebas, apol, mart, lukas

Re: [Breeze] [Bug 381288] Breeze could use higher-contrast text by default (tweaked color scheme attached)

[Jens Reuterberg]

I have to agree with Sebas here: the choice is a "damned if you do, damned if 
you don't level" - the harsh contrasts would make many users feel as if the 
experience is worse... 

I am not trying to wave you away of course - you are more than right there are 
many users who find the theme too vague but as there is a contrast colour 
scheme of Breeze Dark it feels as if its kinda covered. 

On Friday, 16 June 2017 17.46.16 CEST Nate Graham wrote:
> https://bugs.kde.org/show_bug.cgi?id=381288
> 
> Nate Graham  changed:
> 
>What|Removed |Added
> 
> CC||pointedst...@zoho.com
> 
> --- Comment #3 from Nate Graham  ---
> It's worth mentioning that reviewers have noted Breeze's lack of sufficient
> text contrast. For example:
> http://www.ocsmag.com/2017/02/17/the-state-of-plasma/

Re: Plasma Vision v 2.0

[Jens Reuterberg]

Yes that was a worry of mine too - that certain people in the community would 
use the vision as a club against developers but then I thought that the issue 
there isn't so much the vision - its the person using it as a club.

Any vision can be used as a club, every statement of intent, even now where we 
don't have one certain people are using it on reddit to harass, harangue or 
simply misuse it as their idea of an "argument". It can't be avoided. 
Some people are simply going to take whatever ammunition they can use and at 
the same time ignore the realities of developers ("no I can't make it 
controllable through telepathy, even if that is your workflow!")

If someone uses the vision (or ANYTHING) to harass our developers I think we 
as a community must be more vocal. Its a lacking of ours to not step up and 
just set that person right. Simply going "well the realities of programming is 
that even though your idea is something the developer would LOVE to include 
its not feasible right now" - or if its actually more on the harassing side 
speak up in that channel and clearly put yourself between developer and 
harasser. 

This is a very very relevant topic but one where the key aspect of it is 
1) us being able to tell users and actual commentators that "Well that feature 
is a good idea but currently there is no way to do it, help out though!" or 
"Hmm that would make the rest of the application worse - do you have a 
suggestion on making your idea fit more gracefully?"
2) us being able to tell trolls and harassers to bugger off more quickly. We 
loose developers when we don't step up and give the only argument some of 
these people deserve: "No, go away"

(sry this is a sore topic of mine and something that kinda pisses me off more 
than I thought it would :) )

As for the vision: I think that as a statement of intent its good, toning it 
down may hurt it to the point its more a Mission Statement or Strategy 
Document - we want the vision to be a flag in the distance to aim for as well. 


On Thursday, 15 June 2017 21.11.34 CEST Martin Flöser wrote:
> Am 2017-06-09 09:40, schrieb Jens Reuterberg:
> > Time to get back to the vision.
> > 
> >  Plasma Vision 2 
> > Plasma never dictates the user's needs, it only strives to solve them.
> > Plasma
> > never defines what the user should be allowed to do, it only ensures
> > that she
> > can.
> 
> I'm not too happy with this part as it can be interpreted by the user
> that we must support his/her weird workflow. I can already see how users
> bring up the old "you must support this, because you are all about
> customization" now backed with the vision.
> 
> Cheers
> Martin

[Breeze] [Bug 381288] Breeze could use higher-contrast text by default (tweaked color scheme attached)

[Sebastian Kügler]

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

Sebastian Kügler  changed:

   What|Removed |Added

 CC||se...@kde.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #4 from Sebastian Kügler  ---
Thanks Nate, for the thoughful bug report!

We have chosen these colors very thoroughly. The grey tints instead of black
and white were chosen so these contrasts don't look too hard on the eye.

In the end, this boils down to a matter of taste, and that's ultimately the
reason why changing color schemes in Plasma is so easy, one person's perfect
color scheme isn't necessary everybody else's, and it also depends on the
display hardware used.

What you could do is create a cloned color scheme and use that, you can even
upload it to store.kde.org to make it easily available to others.

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

Re: Plasma Vision v 2.0

[Jens Reuterberg]

I will add all these as notes on Phabricator task as well - keep the ideas 
coming everyone its golden so far! 

On Friday, 16 June 2017 01.27.42 CEST Aleix Pol wrote:
> On Thu, Jun 15, 2017 at 9:16 PM, Martin Flöser  wrote:
> > Am 2017-06-12 01:19, schrieb Aleix Pol:
> >> On Sun, Jun 11, 2017 at 11:13 PM, Jonathan Riddell 
> >> 
> >> wrote:
> >>> Yay, I like it.
> >>> 
> >>> Across different operating systems? We don't do anything on Windows or
> >>> Mac.
> >>> 
> >>> Jonathan
> >>> 
> >>> On Fri, Jun 09, 2017 at 09:40:28AM +0200, Jens Reuterberg wrote:
>  Time to get back to the vision.
>  
>   Plasma Vision 2 
>  
>  Plasma Desktop is a cross device work environment where total trust is
>  put on
>  the user's capacity to best define her own workflow and preferences.
>  
>  Plasma is simple by default, a clean work area for real world usage
>  which
>  intends to stay out of your way.
>  Plasma is powerful when needed, enabling the user to create the
>  workflows that
>  make her more effective to complete her tasks.
>  
>  Plasma never dictates the user's needs, it only strives to solve them.
>  Plasma
>  never defines what the user should be allowed to do, it only ensures
>  that she
>  can.
>  
>  Our motivation is that we enable actual work to happen, across devices,
>  across
>  different operating systems, using any application needed.
>  
>  We build to be durable, we create to be usable, we design to be
>  interesting.
>  
>  
>  
>  Reasoning behind the vision:
>  The key aspects of it is that Plasma is "Cross Device" - we state that
>  as
>  clearly as possible. "Simple by default, powerful when needed" has to
>  be
>  repeated within it to hammer that in as that is, in many ways a
>  communicative
>  tool we really want associated with Plasma.
>  
>  Removed Desktop Environment after last one as that was seen as too much
>  "computer" and too little "Mobile" etc.
>  
>  The focus is "work" and "tasks", IRL stuff focusing on a user that
>  needs
>  to
>  solve an actual problem instead of an attempt to create further ones
>  through
>  complexity. At the same time we want to ensure that we never strip the
>  user of
>  options (this is one of the weak points in the vision - more on that
>  below)
>  
>  Finally its the poetic vitruvian line at the end: Firmitas, Utilitas,
>  Venustatis. That something is "well built" or "durable", that something
>  is
>  "usable" (from a users perspective easy to use) and finally "beautiful"
>  or
>  interesting to use - inspiring usage. Build/Create/Design is intended
>  not as
>  work roles ("designer" etc) but something we all do ("designing the
>  system"
>  for example).
>  
>  
>  
>  Feedback, spellchecking, grammar checking and just "yay" or "neigh"
>  wanted.
>  
>  /Jens
> >> 
> >> Plasma Desktop doesn't work on Windows/OS X, but we know our users
> >> will be using different systems on different machines: maybe Android
> >> or iOS on the phone, maybe OS X or Windows at work or at home.
> >> When developing Plasma we need to keep that in mind and leverage it.
> > 
> > Nevertheless we shouldn't give users hope of having Plasma available on
> > Windows, OSX or iOS. Even for Android it does not look like any part of
> > Plasma could be available anytime soon.
> > 
> > Given that I'm also very uneasy with the formulation of operating systems.
> > Personally I would like to not see operating systems mentioned in the
> > vision. Personally - as most know - I wouldn't mind if we would only
> > support Linux (and maybe, maybe the BSDs). Given that at least for me
> > this part of the vision is not fitting and nothing I strive for with my
> > work.
> 
> As I said above:
> > Plasma Desktop doesn't work on Windows/OS X, but we know our users
> > will be using different systems on different machines: maybe Android
> > or iOS on the phone, maybe OS X or Windows at work or at home.
> > When developing Plasma we need to keep that in mind and leverage it.
> 
> This doesn't mean that the vision text is okay, it means that we need
> to tune it so that it communicates properly.
> 
> Aleix