[Differential] [Commented On] D3085: RFC: Use DBusMenu if available

[Martin Gräßlin]

graesslin added a comment.


  In https://phabricator.kde.org/D3085#57496, @broulik wrote:
  
  > To expose the menu id and object path as X/Wayland properties on the window 
I would need to implement QDBusMenuBar myself as I need to implement 
handleReparent as well as access m_objectPath which is private. I'll see how it 
goes.
  
  
  I think you can hack it without needing to implement. We know that it's 
exported on the DBusConnection and we know what the object is looking like. I'm 
sure we can get to it without needing to reimplement.

REPOSITORY
  rPLASMAINTEGRATION Integration for Qt applications in Plasma

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

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

Re: Breakout: UI and user vision for cloud services

[Martin Klapetek]

On Mon, Oct 17, 2016 at 12:54 PM, Jonathan Riddell  wrote:

>  * Services integration - I see more and more users who have
> data locked up in clouds (GDrive, etc.) and rely on accessing it
>  Gnome has GDrive integration, we need to do more on getting
> cloud filesystems into our software too, but we dropped the ball on
> KAccounts etc. for now
>

As the former KAccounts maintainer, I'd like to share some insights on this.

The tech is there. It's proven by real world usage in Ubuntu (incl. Phone),
Meego before that (iirc) and to some extent also Gnome, which has its own
fork of the same thing (I guess they just really don't like Qt anywhere).
Also
Elementary is using one of these, but I don't remember which. And if I'm
not mistaken, also Jolla in their phones.

So we have the tech, but what we're missing are two things, really.

1) Things actually using it. We've had KAccounts for a while but there was
nothing taking advantage of it, except KDE Telepathy, which migrated fully
to it. So it sort of became a synonym for KTp accounts config. On the other
hand, there was nothing much else that would actually need it. There was
an OwnCloud lib or Plasma thingy at some point where I pleaded to have the
account setup done through (K)Accounts to boost the adoption, but it never
happened. Related to that is...

2) Buy in from PIM. I mean, let's face it, the real accounts user in the
system
is PIM, with all the emails and calendars and contacts and what not. This
obviously requires quite some large effort to actually migrate everything to
it and sadly the PIM team is long time understaffed. Now with the new Sink
thing, this could have been a chance, but, again, after asking couple times
about the accounts plan, (K)Accounts was never in the picture. And that's
a problem.

And so now we have this system that nobody in/around KDE wants to use.
My take on it is that people (devs) don't really understand how that system
works and how to take advantage of it, which is partly my fault. It is
fairly
complex system on the inside with lots of points of possible breakages, but
also allows for great flexibility all around.

So, imho, in order to successfully follow literally every other desktop
these
days, it needs a proper full integration in all things using accounts. And
it really
shouldn't be just an afterthought. It needs to be put right at the core of
those
things and workflows should be redesigned to take that into account (heh).
It
needs to be a conscious community-wide effort, like Frameworks was.
Otherwise
KAccounts will stay exactly where it is now - a promising (egg-)shell that
has no
real use.

Unfortunately if the past two years are any indication, especially with
Sink,
the road ahead is not very bright.

I'm happy to try my best to answer any possible future questions about the
system
you might have. Friedrich Kossebau was also writing a tutorial about it at
some
point, but I'm not sure where it ended up (if at all; I also failed to
follow up on that).

Cheers
-- 
Martin Klapetek

Jenkins-kde-ci: plasma-workspace master kf5-qt5 » Linux,gcc - Build # 518 - Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-workspace%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/518/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 18 Oct 2016 22:16:37 +
Build duration: 16 min

CHANGE SET
Revision 68a490c9fd019820ac8ef76b7d5e8de46802ead1 by ivan.cukic: (Library 
support for per-activity pinned tasks)
  change: add libtaskmanager/launchertasksmodel_p.h
  change: edit libtaskmanager/launchertasksmodel.h
  change: edit libtaskmanager/tasksmodel.h
  change: edit libtaskmanager/tasksmodel.cpp
  change: edit libtaskmanager/launchertasksmodel.cpp
  change: edit libtaskmanager/autotests/launchertasksmodeltest.cpp
Revision a5e92b3ca11ce4c79da2d6450432bfe3e8d140df by ivan.cukic: (Filtering now 
checks for the null activity)
  change: edit libtaskmanager/taskfilterproxymodel.cpp
Revision 3de821de275660de55efd27db9d4121ff2bf68fb by ivan.cukic: (Exporting 
activities list through data member function)
  change: edit libtaskmanager/launchertasksmodel.cpp
  change: edit libtaskmanager/launchertasksmodel_p.h
Revision d20ad165142c6bd079002e996ebcba1f18d7e301 by ivan.cukic: (When a 
launcher is on all activities, the list is now empty)
  change: edit libtaskmanager/launchertasksmodel.cpp
Revision 060681d69479a260de06a19f74092e91d7e63f70 by ivan.cukic: (Relying on 
the filter model to do the filtering)
  change: edit libtaskmanager/launchertasksmodel.h
  change: edit libtaskmanager/autotests/launchertasksmodeltest.cpp
  change: edit libtaskmanager/launchertasksmodel.cpp
  change: edit libtaskmanager/tasksmodel.cpp
  change: edit libtaskmanager/tasksmodel.h
Revision ce5d187f4340320b47b89222fa5008cd5d87ec94 by ivan.cukic: (Removed 
debugging output)
  change: edit libtaskmanager/tasksmodel.cpp
  change: edit libtaskmanager/launchertasksmodel.cpp
  change: edit libtaskmanager/launchertasksmodel_p.h
Revision b4a8f6c6454c63ecfcb8339aaffe94016eeb5825 by ivan.cukic: (Validating 
the list of activities specified for a launcher)
  change: edit libtaskmanager/launchertasksmodel.cpp
Revision 8bb1058194a60420fb4f1df25d2da60470e4c538 by ivan.cukic: (Nicer 
handling of duplicate urls)
  change: edit libtaskmanager/launchertasksmodel.cpp
Revision 25cb8e18b520642b15b6bb98c86cc494775982bc by ivan.cukic: (Methods for 
adding and removing per-activity launchers)
  change: edit libtaskmanager/launchertasksmodel.cpp
  change: edit libtaskmanager/tasksmodel.cpp
  change: edit libtaskmanager/tasksmodel.h
  change: edit libtaskmanager/launchertasksmodel.h
Revision b08dea47c7fd0d698b549afd4bcdc6b8b117b4e1 by ivan.cukic: (Added 
function to return activities for a specified launcher)
  change: edit libtaskmanager/tasksmodel.cpp
  change: edit libtaskmanager/launchertasksmodel.h
  change: edit libtaskmanager/launchertasksmodel.cpp
  change: edit libtaskmanager/tasksmodel.h
Revision 9728508e90ab8c2e029b66ab2bfe63ae05d0d864 by ivan.cukic: (Fixed the 
shadowed variable error)
  change: edit libtaskmanager/launchertasksmodel.cpp
Revision f3b33315b90e0ef2f185f3c344208d6e90e927b8 by ivan.cukic: (Changed the 
launcher modification API)
  change: edit libtaskmanager/launchertasksmodel.h
  change: edit libtaskmanager/tasksmodel.h
  change: edit libtaskmanager/tasksmodel.cpp
  change: edit libtaskmanager/launchertasksmodel.cpp
Revision e6dca2f076ecbcc2797cbd076446bc41961480c5 by ivan.cukic: (When all 
activities are selected, select the #039;All activities#039; item)
  change: edit libtaskmanager/launchertasksmodel.cpp


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 9 test(s), Skipped: 0 test(s), Total: 
10 test(s)Failed: TestSuite.launchertasksmodeltest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 13/13 (100%)FILES 53/73 (73%)CLASSES 53/73 (73%)LINE 2102/5593 
(38%)CONDITIONAL 1444/5538 (26%)

By packages
  
drkonqi.parser
FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL 
478/616 (78%)
drkonqi.tests.backtraceparsertest
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL 
33/50 (66%)
kioslave.desktop
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 101/135 (75%)CONDITIONAL 
36/66 (55%)
kioslave.desktop.tests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 66/66 (100%)CONDITIONAL 
26/50 (52%)
klipper
FILES 12/13 (92%)CLASSES 12/13 (92%)LINE 256/384 
(67%)CONDITIONAL 109/210 (52%)
klipper.autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL 
377/820 (46%)
libtaskmanager
FILES 6/20 (30%)CLASSES 6/20 (30%)LINE 194/3245 (6%)CONDITIONAL 
119/3197 (4%)
libtaskmanager.autotests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 150/150 
(100%)CONDITIONAL 85/170 (50%)
runners.bookmarks
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 87/157 (55%)CONDITIONAL 
34/96 (35%)
runners.bookmarks.browsers
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 

[Differential] [Commented On] D3106: Replaced the launcher pinning action with a per-activity meny

[Ivan Čukić]

ivan added a comment.


  Preview:
  
  F369927: snap.png 

REPOSITORY
  rPLASMADESKTOP Plasma Desktop

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: ivan, #plasma, mart, hein
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Request, 86 lines] D3106: Replaced the launcher pinning action with a per-activity meny

[Ivan Čukić]

ivan created this revision.
ivan added reviewers: Plasma, mart, hein.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REPOSITORY
  rPLASMADESKTOP Plasma Desktop

BRANCH
  master

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

AFFECTED FILES
  applets/taskmanager/package/contents/ui/ContextMenu.qml

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: ivan, #plasma, mart, hein
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Closed] D3005: Library support for per-activity pinned tasks

[Ivan Čukić]

This revision was automatically updated to reflect the committed changes.
Closed by commit rPLASMAWORKSPACEb4a8f6c6454c: Validating the list of 
activities specified for a launcher (authored by ivan).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D3005?vs=7277=7524#toc

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3005?vs=7277=7524

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

AFFECTED FILES
  libtaskmanager/launchertasksmodel.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: ivan, hein, #plasma
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Closed] D3097: Changed the launcher modification API

[Ivan Čukić]

This revision was automatically updated to reflect the committed changes.
Closed by commit rPLASMAWORKSPACEe6dca2f076ec: When all activities are 
selected, select the 'All activities' item (authored by ivan).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D3097?vs=7505=7522#toc

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3097?vs=7505=7522

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

AFFECTED FILES
  libtaskmanager/launchertasksmodel.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: ivan, hein, #plasma
Cc: mart, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Closed] D3005: Library support for per-activity pinned tasks

[Ivan Čukić]

This revision was automatically updated to reflect the committed changes.
Closed by commit rPLASMAWORKSPACE8bb1058194a6: Nicer handling of duplicate urls 
(authored by ivan).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D3005?vs=7277=7523#toc

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3005?vs=7277=7524

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

AFFECTED FILES
  libtaskmanager/launchertasksmodel.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: ivan, hein, #plasma
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Commented On] D3097: Changed the launcher modification API

[Ivan Čukić]

ivan added a comment.


  > shouldn't cause problems changing api of libtaskmanager btw?
  
  This is changing API that I added in the patch (not released API) - not sure 
why arc made the last commit message to be the main one :)

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

BRANCH
  ivan/per-activity-launchers

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: ivan, hein, #plasma
Cc: mart, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

breakout: store and dependencies: to both plasma and other apps versions

[Łukasz Sawicki]

Hi,

>at first would try to install the thing with packagekit, if found, and that's
>probably the easy part (and where is i think realistic for 5.9) then the hard
>part is that it would need to search for stuff in the store as well.


Wait moment, why packagekit? I mean as far I remember the plan was to
specify dependencies only from KDE Store not from distro repositories.
https://bugs.kde.org/show_bug.cgi?id=367921

>at that point, would be needed something in attica to search for a particular
>appstream id, that may take a long time unfortunately as may need a change in
>the server as well to add new api (i wouldn't like to have to specify
>dependencies as numerical ids?)

Why appstream id? From what I see on KDE Store/opendesktop every file
already have an unique ID. Just an example.
Plasma theme MX Theme
https://dl.opendesktop.org/api/files/download/id/1475562141/

So why not just include that link or any other id used by Get Hot New
Stuff in the metadata file ?

X-KDE-Depends="http://dl.opendesktop.org/api/files/download/id/1475562141/;,
and so on.

Dependencies from the KDE store should be a top priority here imho. If
this is going to take more time I am fine with that.

Cheers
Łukasz

[Differential] [Closed] D3055: Small polishing changes to the lockscreen lookandfeel package

[subdiff (Roman Gilg)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rPLASMAWORKSPACEd0fc18e1831d: Lockscreen: Keyboard focus and 
commands, more animations (authored by subdiff).

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3055?vs=7399=7516

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

AFFECTED FILES
  lookandfeel/contents/lockscreen/LockScreenUi.qml
  lookandfeel/contents/lockscreen/MainBlock.qml

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: subdiff, davidedmundson
Cc: eliasp, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Accepted] D3097: Changed the launcher modification API

[hein (Eike Hein)]

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

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

BRANCH
  ivan/per-activity-launchers

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: ivan, hein, #plasma
Cc: mart, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Accepted] D3005: Library support for per-activity pinned tasks

[hein (Eike Hein)]

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

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

BRANCH
  ivan/per-activity-launchers

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: ivan, hein, #plasma
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

Re: Breakout: * multiscreen behaviour: how should Plasma exactly behave in different scenarios?

[David Edmundson]

On Tue, Oct 18, 2016 at 2:06 PM, Fredy Neeser  wrote:

> "Plasma-devel"  wrote on 18.10.2016
> 13:11:29:
>
> > From: Marco Martin 
> > To: plasma-devel@kde.org
> > Date: 18.10.2016 13:11
> > Subject: Re: Breakout: * multiscreen behaviour: how should Plasma
> > exactly behave in different scenarios?
> > Sent by: "Plasma-devel" 
> >
> > On Tuesday 18 October 2016, David Edmundson wrote:
> > >
> > > With regards to current Plasma behaviour that's not always true: I
> didn't
> > > mention if screen 2 was previously the primary screen or not.
> > >
> > > At which point the correct behaviour should be to show the containers
> that
> > > were previously on screen 2 on screen 1. Right?
> >
> > yes, that's the one case where the views get swapped to the other screen
> > in ShellCorona::primaryOutputChanged()
>
>
> Hi all
>
> I've been using KDE since about 15 years and I'm interested a lot
> in the recent multiscreen improvements and the present discussion.
> There is quite some complexity in changing multiscreen configs,
> and I liked Marco Martin's summary of how Containments
> (Desktop Containments or Panels) are linked to Screens etc.
>
> Already with <= 2 screens (say, LVDS and one external screen scr1)
> we can have 4 configurations (with * indicating the Primary Display),
> namely
>
>   c1 = [*lvds]
>   c2 = [*lvds][scr1]
>   c3 = [lvds][*scr1]
>   c4 = [*scr1]
>
> Based on the previous discussion, it seems that a Desktop Containment
> D is configurable on a per-config and per-screen basis, so we have
>
>   D = D(c,s)
>
> where c is a config in {c1,c2,c3,c4} and s is a screen in {lvds,scr1}.
> Moreover, a Panel P is apparently configurable on a per-config, per-screen
> and per-resolution basis, so we have
>
>   P = P(c,s,r,n)
>
> where c and s are as above, r is a resolution, and n would be a panel index
> (as there can be multiple panels per screen).
>
> Using the above definitions and assumptions, we can ask a couple
> of questions:
>
> Q1. Among the possible transitions
>-, c1 -> c2, c1 -> c3, c1 -> c4
> c2 -> c1,-, c2 -> c3, c2 -> c4
> c3 -> c1, c3 -> c2,-, c3 -> c4
> c4 -> c1, c4 -> c2, c4 -> c3,-
>
> from initial to final config, which ones are actually implemented
> as atomic transactions in kscreen control?  -- I'm asking because
> for example the transition  c1 -> c3 could be implemented
> atomically as
> [*lvds] -> [lvds][*scr1]
>
> or in two steps as
> [*lvds]   -> [*lvds][scr1]
> [*lvds][scr1] -> [lvds][*scr1]
> with possibly different outcomes.
>
> In general plasma shell never sees it as atomic. The underlying code in
QPlatform window will emit two signals. Plasma then sees and processes it
as two events.

But there's an added twist not mentioned. You can shutdown the computer in
the middle of any one of those transitions. That then is effectively an
atomic change, but also handled by a very different code path.

In terms of what currently Plasma does then:

Plasmashell then acheives the same thing but via a different code path; the
outputsname to output Id orders gets swapped round in the ScreenPool
constructor. Meaning that when we restore "0" may refer to lvds instead of
scr1.

However, there's a subtle behavioural difference. With a running primary
screen change we swap the new primary with the old primary ID. With a non
running screen change, we set the new primary to 0, and the old primary
becomes the first availableId.

With two outputs that will be the same, with n > 2, I'm not entirely
convinced.


> Q2. Marco stated that containments never migrate from one screen
> to another except when there is a "change of the primary screen".
> But which config changes actually qualify as "change of the primary
> screen"?
> I'd say
> [*lvds][scr1] -> [lvds][*scr1]
> is such a change, but how about
> [*lvds] -> [lvds][*scr1]
> ?
>
> That would be two events:
screen added:
primary screen changed

in that order

>
> Q3.  If I understand correctly, a "change of the primary screen"
> causes ShellCorona::primaryOutputChanged() to swap containments
> between the old primary screen and the new primary screen,
> so is it true that a config change
>
>   c1 = [*lvds][scr1] -> c3 = [lvds][*scr1]
>
> will always result in the swap operations
>   D(c3,scr1) := D(c1,lvds)
>   P(c3,scr1,r,n) := P(c1,lvds,r,n)
>   D(c3,lvds) := D(c1,scr1)
>   P(c3,lvds,r,n) := P(c1,scr1,r,n)
>
> regardless of whether c3 is created for the first time
> or recreated some time later?
>



>
> Q4.  For another example, if we consider the direct (atomic) transition
>   c1 = [*lvds] -> c3 = [lvds][*scr1]
> is this also handled by ShellCorona::primaryOutputChanged() ?
> Does it cause any containments to be migrated to another screen?
> (If not, one might end up with c3 having no panel
>  the first time it gets created).
>

In the current code the panel that was on 

[Differential] [Updated, 6 lines] D3079: Adapt Dashboard: Connect to new toggled signal instead of activated signal in order to initiate state change

[subdiff (Roman Gilg)]

subdiff updated this revision to Diff 7515.
subdiff added a comment.


  Implemented David's condition if variable exists.

REPOSITORY
  rPLASMADESKTOP Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3079?vs=7474=7515

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

AFFECTED FILES
  applets/kicker/package/contents/ui/main.qml
  applets/kickoff/package/contents/ui/Kickoff.qml

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

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

Re: Review Request 129204: Add toggle signal for applet de-/activation in order to fix non-closing launchers on Meta (and also on Active Screenedges)

[Roman Gilg]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129204/
---

(Updated Okt. 18, 2016, 7:20 nachm.)


Review request for Plasma and Martin Gräßlin.


Changes
---

Change variable name to `activationTogglesExpanded`.


Bugs: 367685
http://bugs.kde.org/show_bug.cgi?id=367685


Repository: plasma-framework


Description
---

# The new Meta-key support for launcher opening doesn't work for closing at the 
moment. My analysis of the problem was as follows:

- KWin calls Applet::activated() over DBus
- Applet::activated() is connected to AppletInterface::activated()
- AppletInterface::activated() is connected to setExpanded(true), which can 
only expand the launcher, but not the other way around

# Q: Why is Alt+F1 working though?
A: The launchers seem to inherit the reimplemented function 
Dialog::focusOutEvent(..). Atleast when you delete line 1094 in dialog.cpp, 
which sets the visibility to false, it's not working anymore. Alt+F1 triggers 
the focusOutEvent(..) as a global shortcut.

# Q: Why is it working with the Dashboard though?
A: The dashboard doesn't use the expanded feature of the plasmoid, but rather 
connects directly to the AppletInterface::activated() signal and shows/hides an 
independent widget when this signal gets triggered.

# Solution:
Create new toggled() signal chain in KWin, Applet, AppletInterface, which tests 
the current expanded state and sets it afterwards accordingly to the opposite. 
This diff here in plasma-framework is the first one, which the others depend 
on. The others are on Phabricator:

- kwin: https://phabricator.kde.org/D3077
- plasma-workspace: https://phabricator.kde.org/D3078
- plasma-desktop: https://phabricator.kde.org/D3079

# Need feedback regarding:

- Should we remove the activated() signal chain? Is it used somewhere else than 
KWin?
- Could a race condition occur if we deexpand the applet while at the same time 
setting the visibility to false through focusOutEvent()? My tests until now 
don't suggest it, but I haven't yet looked into it extensively.


Diffs (updated)
-

  src/plasmaquick/appletquickitem.h 943e227 
  src/plasmaquick/appletquickitem.cpp 2f100b8 
  src/plasmaquick/private/appletquickitem_p.h 1436935 
  src/scriptengines/qml/plasmoid/appletinterface.cpp 1cd6934 

Diff: https://git.reviewboard.kde.org/r/129204/diff/


Testing
---


Thanks,

Roman Gilg

[Differential] [Request, 32 lines] D3102: Do not ask for root permissions when it's unnecessary

[antlarr (Antonio Larrosa Jimenez)]

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

REVISION SUMMARY
  Only save values that were really changed
  
  This allows to change settings without being asked for the root password
  to save things that weren't modified by the user, so the
  request for the root password was unnecessary.
  
  Remove unneeded UncacheUser/CacheUser calls
  
  Modifying the Real Name of the user was requesting the root password
  because of the calls to UncacheUser/CacheUser, since modifying the Real
  Name doesn't in fact need extra permissions. Also, none of the other
  properties call UncacheUser/CacheUser when they're being modified, so
  I tried removing the calls and it works much better here.

TEST PLAN
  I tested changing avatar and Real Name and looking at /etc/passwd and ~/.face
  that they were correctly changed while not getting any polkit dialog
  requesting the root password.

REPOSITORY
  rUSERMANAGER User Manager

BRANCH
  master

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

AFFECTED FILES
  src/accountinfo.cpp
  src/lib/accountmodel.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: antlarr, #plasma
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Commented On] D3098: Update screen pool connector ID ordering before adjusting desktop containments

[mart (Marco Martin)]

mart added a comment.


  in general, it's OK.
  But as this is a bit delicate part, can you do one more test?
  
  have only the external screen enabled and primary, then detaching and 
reattaching the cable from the connector.
  this is a similar but not completely code path to swapping the primary screen.

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

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

[Differential] [Commented On] D3097: Changed the launcher modification API

[mart (Marco Martin)]

mart added a comment.


  +1
  
  shouldn't cause problems changing api of libtaskmanager btw? (here 
compatibility is not guaranteed)

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: ivan, #plasma, hein
Cc: mart, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Updated] D3097: Changed the launcher modification API

[mart (Marco Martin)]

mart added reviewers: Plasma, hein.

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: ivan, #plasma, hein
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Commented On] D3085: RFC: Use DBusMenu if available

[broulik (Kai Uwe Broulik)]

broulik added a comment.


  To expose the menu id and object path as X/Wayland properties on the window I 
would need to implement QDBusMenuBar myself as I need to implement 
handleReparent as well as access m_objectPath which is private. I'll see how it 
goes.

REPOSITORY
  rPLASMAINTEGRATION Integration for Qt applications in Plasma

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

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

[Differential] [Accepted] D3100: Expose GLRenderTarget::virtualScreenGeometry

[mart (Marco Martin)]

mart accepted this revision.
mart added a reviewer: mart.
This revision is now accepted and ready to land.

REPOSITORY
  rKWIN KWin

BRANCH
  render-target-virtual-screen-geometry

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #kwin, #plasma_on_wayland, mart
Cc: plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, 
abetts, sebas

[Differential] [Accepted] D3101: Adjust blur and contrast for multi-output rendering on Wayland

[mart (Marco Martin)]

mart accepted this revision.
mart added a reviewer: mart.
This revision is now accepted and ready to land.

REPOSITORY
  rKWIN KWin

BRANCH
  blur-wayland-multi-screen

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #kwin, #plasma_on_wayland, mart
Cc: plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, 
abetts, sebas

Re: Breakout: how to attract new contributors?

[Fredy Neeser]

> I am one of those new contributors that I would like to help... :)
>
> It might be a very good thing a "per distribution" way to build plasma's
> master branch and install it on a user's path (not global in order to
> not break the distribution's official packages)...

Very good idea.  In my case, this would hopefully allow me to debug
a new multiscreen issue ...

There are some recent HOWTOs at

[1] https://community.kde.org/Guidelines_and_HOWTOs
[2] https://community.kde.org/Guidelines_and_HOWTOs/Development
[3] https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source
[4]
https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Details
[5]
https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Plasma_5_on_Ubuntu_14.04_LTS

but I don't know yet how useful [3]-[5] really are.


> For example an analytic guide for some of the most used distributions,
> Ubuntu, Fedora, openSUSE etc.
>
> I am using openSUSE and I would love to have a walk through to follow
> for the first steps...

I'm using Fedora -- yes, a walk through for building Plasma (ideally with
distro-specific hints) would be greatly appreciated.


Cheers

Fredy Neeser
IBM Zurich Research

[Differential] [Updated] D3099: Fix viewport restore in GLRenderTarget::popRenderTarget

[Martin Gräßlin]

graesslin added a dependent revision: D3101: Adjust blur and contrast for 
multi-output rendering on Wayland.

REPOSITORY
  rKWIN KWin

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #kwin, #plasma_on_wayland
Cc: plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, 
abetts, sebas

[Differential] [Updated] D3101: Adjust blur and contrast for multi-output rendering on Wayland

[Martin Gräßlin]

graesslin added dependencies: D3100: Expose 
GLRenderTarget::virtualScreenGeometry, D3099: Fix viewport restore in 
GLRenderTarget::popRenderTarget.

REPOSITORY
  rKWIN KWin

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #kwin, #plasma_on_wayland
Cc: plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, 
abetts, sebas

[Differential] [Updated] D3100: Expose GLRenderTarget::virtualScreenGeometry

[Martin Gräßlin]

graesslin added a dependent revision: D3101: Adjust blur and contrast for 
multi-output rendering on Wayland.

REPOSITORY
  rKWIN KWin

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #kwin, #plasma_on_wayland
Cc: plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, 
abetts, sebas

[Differential] [Request, 17 lines] D3101: Adjust blur and contrast for multi-output rendering on Wayland

[Martin Gräßlin]

graesslin created this revision.
graesslin added reviewers: KWin, Plasma on Wayland.
Restricted Application added subscribers: kwin, plasma-devel.
Restricted Application added projects: Plasma on Wayland, KWin.

REVISION SUMMARY
  The glCopyTex(Sub)Image calls are adjusted to take the per output
  rendering into account. In addition contrast effect sets the model view
  projection matrix in each call to ensure it's on the correct screen.
  
  Blur probably needs more changes for the cached texture to work, but
  it's a start.

TEST PLAN
  Blur and Background contrast work on multi-screen wayland

REPOSITORY
  rKWIN KWin

BRANCH
  blur-wayland-multi-screen

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

AFFECTED FILES
  effects/backgroundcontrast/contrast.cpp
  effects/backgroundcontrast/contrast.h
  effects/blur/blur.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #kwin, #plasma_on_wayland
Cc: plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, 
abetts, sebas

[Differential] [Updated] D3100: Expose GLRenderTarget::virtualScreenGeometry

[Martin Gräßlin]

graesslin added a dependency: D3099: Fix viewport restore in 
GLRenderTarget::popRenderTarget.

REPOSITORY
  rKWIN KWin

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #kwin, #plasma_on_wayland
Cc: plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, 
abetts, sebas

[Differential] [Request, 11 lines] D3100: Expose GLRenderTarget::virtualScreenGeometry

[Martin Gräßlin]

graesslin created this revision.
graesslin added reviewers: KWin, Plasma on Wayland.
Restricted Application added subscribers: kwin, plasma-devel.
Restricted Application added projects: Plasma on Wayland, KWin.

REVISION SUMMARY
  A simple way to get the current per-output geometry. It's also needed by
  effects using render targets.

REPOSITORY
  rKWIN KWin

BRANCH
  render-target-virtual-screen-geometry

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

AFFECTED FILES
  libkwineffects/kwinglutils.h

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #kwin, #plasma_on_wayland
Cc: plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, 
abetts, sebas

[Differential] [Updated] D3099: Fix viewport restore in GLRenderTarget::popRenderTarget

[Martin Gräßlin]

graesslin added a dependent revision: D3100: Expose 
GLRenderTarget::virtualScreenGeometry.

REPOSITORY
  rKWIN KWin

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #kwin, #plasma_on_wayland
Cc: plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, 
abetts, sebas

[Differential] [Request, 3 lines] D3099: Fix viewport restore in GLRenderTarget::popRenderTarget

[Martin Gräßlin]

graesslin created this revision.
graesslin added reviewers: KWin, Plasma on Wayland.
Restricted Application added subscribers: kwin, plasma-devel.
Restricted Application added projects: Plasma on Wayland, KWin.

REVISION SUMMARY
  The viewport needs adjustment in the per-output rendering case. This
  change ensures the viewport is setup like in the platforms which do per
  output rendering. For the X11 case (multiple outputs in one render pass)
  the values are the same as previously.

REPOSITORY
  rKWIN KWin

BRANCH
  render-target-viewport

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

AFFECTED FILES
  libkwineffects/kwinglutils.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #kwin, #plasma_on_wayland
Cc: plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, 
abetts, sebas

Fw: Plasma 5.7.5 / 5.8.0 multiscreen: Menu and widgets react to mouse events with seconds of delay if Primary Display = external monitor

[Fredy Neeser]

Hi,

I'm looking for advice on how to narrow down this delay issue, which is
still present in 5.8.1. The delays make my desktop unusable
when I set Primary display = external monitor.

Could this be an unfortunate issue in the interaction between kwin
and XCB/X11 which occurs only if Primary display = external monitor,
or can you think of another potential culprit?

I would like to help debugging the issue -- if necessary, I can try
to build Plasma from sources, but I will likely need some guidance.

Thank you

Fredy Neeser
IBM Zurich Research Laboratory


"Plasma-bugs"  wrote on 06.10.2016 14:27:05:

> From: "Fredy Neeser" 
> To: plasma-b...@kde.org
> Date: 06.10.2016 14:27
> Subject: Plasma 5.7.5 / 5.8.0 multiscreen: Menu and widgets react to
> mouse events with seconds of delay if Primary Display = external monitor
> Sent by: "Plasma-bugs" 
>
> Hello list
>
> After upgrading from Fedora 22 (Plasma 5.5.5) to Fedora 24 (Plasma
> 5.7.5 and now 5.8.0), I experience a new, multiscreen - related
> mouse-event handling problem, which was not present in Plasma 5.5.5.
> B.t.w., I read about the multiscreen related improvements being
> worked on in 5.7 and 5.8, which I do appreciate.
>
> I'm using a dual-screen setup (LVDS + external monitor), where I
> usually set Primary Display = external monitor. Moreover, I place
> the KDE Panel also on the external monitor. When I do that and try
> to navigate through the Application Menu (launcher with cascading
> popup menus) or when I click / move over a desktop widget, the
> following happens:
>
> - After a mouse left click on the KDE menu icon (left hand side of
> KDE Panel), the menu pops up only after a delay of >= 1 second
> - When the mouse pointer is moved to another item in a popup menu,
> the focus visibly jumps from item to item, and a delay of at least 1
> second is added on every intermediate item.
> - When I click / move over a desktop widget, the desktop reacts with
> a delay of >= 1 second
>
> Note that the delay occurs only for the panel and widgets on the
> external monitor; if I add a second panel and move it manually to
> the laptop screen, the menu on this second panel does NOT have a
> delay problem.
>
> The delay problem on the menu consistently disappears when I set
> Primary display = Laptop Screen, even when the KDE Panel is moved
> manually (via Screen Edge) to the external monitor.
>
> B.t.w., after the recent design changes for multiscreen, it's
> unclear to me in which case a Panel is supposed to move along with
> the Primary display as opposed to being "pinned" to a specific
> display. Could someone please clarify the behavior intended for
> Plasma versions >= 5.7 ? Thanks!
>
> Also, the delay problem typically reappears when I go back to
> Primary display = external monitor. Only in two out of perhaps a
> dozen logout-login cycles, I observed that the delay problem was
> gone, despite the fact that I had Primary display = external
> monitor. This may indicate some kind of race condition at login.
>
>
> Since this was an upgrade from an earlier Plasma version, I also
> tried the following:
> - Remove the contents of ~/.cache
> - Temporarily remove ~/.config, ~/.local and ~/.kde and login to KDE
> - Login to KDE as another user
> but the delay problem behaved the same.
>
>
> The delay problem is exactly the same for Plasma 5.7.5 and 5.8.0:
>
> Plasma 5.7.5 package versions:
> kscreen-5.7.5-1.fc24.x86_64
> kwin-5.7.5-1.fc24.x86_64
> plasma-desktop-5.7.5-1.fc24.x86_64
> plasma-systemsettings-5.7.5-1.fc24.x86_64
> plasma-workspace-5.7.5-2.fc24.x86_64
> plasma-workspace-libs-5.7.5-2.fc24.x86_64
> qt5-qtbase-5.6.1-3.fc24.x86_64
> Plasma 5.8.0 package versions:
> kscreen-5.8.0-0.1.fc24.x86_64
> kwin-5.8.0-0.1.fc24.x86_64
> plasma-workspace-5.8.0-0.1.fc24.x86_64
> plasma-workspace-libs-5.8.0-0.1.fc24.x86_64
> qt5-qtbase-5.6.1-3.fc24.x86_64
>
>
> Please advise on how to best narrow down this issue -- I'd be happy
> to do some testing / debugging!
>
> I tried a KDE Neon Live Image yesterday, but the external monitor,
> although shown by the kscreen control module, turns black after a
> quick initial KDE logo splash at login.
>
> I wish some KDE debug messages could be seen in ~/.xsession-errors
> (I enabled the debug messages using kdebugsettings), but I don't see
> any of the familiar messages - maybe something is broken with the
> KDE debug messages as well.
This problem is now resolved -- debug messages appear in the system log.

> Also, let me know if plasma-bugs is not the right list for this problem.
>
> Thank you!

Re: Plasma 5.8.2 is out

[Jonathan Riddell]

yes well spotted, fixed

On Tue, Oct 18, 2016 at 03:40:16PM +0200, tsdg...@yahoo.es wrote:
> Is the date on kde.org and announcement wrong? 11 vs 18?
> 
> Enviat des del meu telèfon intel·ligent BlackBerry 10.
>   Missatge original  
> De: Jonathan Riddell
> Enviat: dimarts 18 d’octubre de 2016 15.28
> Per a: KDE release coordination; plasma-devel@kde.org
> Respon a: KDE release coordination
> Tema: Plasma 5.8.2 is out
> 
> Plasma 5.8.2 is out
> 
> https://www.kde.org/announcements/plasma-5.8.2.php

Re: Plasma 5.8.2 is out

[tsdgeos]

Is the date on kde.org and announcement wrong? 11 vs 18?

Enviat des del meu telèfon intel·ligent BlackBerry 10.
  Missatge original  
De: Jonathan Riddell
Enviat: dimarts 18 d’octubre de 2016 15.28
Per a: KDE release coordination; plasma-devel@kde.org
Respon a: KDE release coordination
Tema: Plasma 5.8.2 is out

Plasma 5.8.2 is out

https://www.kde.org/announcements/plasma-5.8.2.php

[Breeze] [Bug 371116] New: BANDUNI@COM TExas ∭18*44-41*44*868∭New York QUICKBOOKS SUPPORT NUMBER Nebraska Lincoln Omaha, Lincoln, Bellevue, Grand Island, Kearney

[ronald via KDE Bugzilla]

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

Bug ID: 371116
   Summary: BANDUNI@COM TExas ∭18*44-41*44*868∭New York QUICKBOOKS
SUPPORT NUMBER Nebraska Lincoln Omaha, Lincoln,
Bellevue, Grand Island, Kearney
   Product: Breeze
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: plasma-devel@kde.org
  Reporter: 81smith.john...@gmail.com

BANDUNI@COM TExas ∭18*44-41*44*868∭New York QUICKBOOKS SUPPORT NUMBER Nebraska
Lincoln Omaha, Lincoln, Bellevue, Grand Island, Kearney
BANDUNI@COM TExas ∭18*44-41*44*868∭New York QUICKBOOKS SUPPORT NUMBER Nebraska
Lincoln Omaha, Lincoln, Bellevue, Grand Island, KearneyBANDUNI@COM TExas
∭18*44-41*44*868∭New York QUICKBOOKS SUPPORT NUMBER Nebraska Lincoln Omaha,
Lincoln, Bellevue, Grand Island, KearneyBANDUNI@COM TExas ∭18*44-41*44*868∭New
York QUICKBOOKS SUPPORT NUMBER Nebraska Lincoln Omaha, Lincoln, Bellevue, Grand
Island, KearneyBANDUNI@COM TExas ∭18*44-41*44*868∭New York QUICKBOOKS SUPPORT
NUMBER Nebraska Lincoln Omaha, Lincoln, Bellevue, Grand Island,
KearneyBANDUNI@COM TExas ∭18*44-41*44*868∭New York QUICKBOOKS SUPPORT NUMBER
Nebraska Lincoln Omaha, Lincoln, Bellevue, Grand Island, KearneyBANDUNI@COM
TExas ∭18*44-41*44*868∭New York QUICKBOOKS SUPPORT NUMBER Nebraska Lincoln
Omaha, Lincoln, Bellevue, Grand Island, KearneyBANDUNI@COM TExas
∭18*44-41*44*868∭New York QUICKBOOKS SUPPORT NUMBER Nebraska Lincoln Omaha,
Lincoln, Bellevue, Grand Island, Kearney

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

Plasma 5.8.2 is out

[Jonathan Riddell]

Plasma 5.8.2 is out

https://www.kde.org/announcements/plasma-5.8.2.php

Re: Breakout: how to attract new contributors?

[Michail Vourlakos]

Hello,

I am one of those new contributors that I would like to help... :)

It might be a very good thing a "per distribution" way to build plasma's 
master branch and install it on a user's path (not global in order to 
not break the distribution's official packages)...


For example an analytic guide for some of the most used distributions, 
Ubuntu, Fedora, openSUSE etc.


I am using openSUSE and I would love to have a walk through to follow 
for the first steps...



regards,

michail




On 18/10/2016 12:24 μμ, Marco Martin wrote:

On Monday 17 October 2016, Jonathan Riddell wrote:

  we need more contributors, junior jobs are best way to get
started  the most critical thing we can do for developer recruitment
 is change the way we publish/blog
 our blogs are mostly work notes aimed at users, we need to
write more blog posts that engineers like to read
 mgraesslin: the interesting thing is that among the best and
brightest fresh young open source contributors, we have quite a few
users - e.g. in the Rust community quite a few use Plasma, because C++
is the next best thing - but we don't publish anything they like to
read so we don't convert

it's kind of a pipe dream, but indeed, great documentation would be one of the
most effective things

Re: Breakout: * multiscreen behaviour: how should Plasma exactly behave in different scenarios?

[Fredy Neeser]

"Plasma-devel"  wrote on 18.10.2016 13:11:29:

> From: Marco Martin 
> To: plasma-devel@kde.org
> Date: 18.10.2016 13:11
> Subject: Re: Breakout: * multiscreen behaviour: how should Plasma
> exactly behave in different scenarios?
> Sent by: "Plasma-devel" 
>
> On Tuesday 18 October 2016, David Edmundson wrote:
> >
> > With regards to current Plasma behaviour that's not always true: I
didn't
> > mention if screen 2 was previously the primary screen or not.
> >
> > At which point the correct behaviour should be to show the containers
that
> > were previously on screen 2 on screen 1. Right?
>
> yes, that's the one case where the views get swapped to the other screen
> in ShellCorona::primaryOutputChanged()


Hi all

I've been using KDE since about 15 years and I'm interested a lot
in the recent multiscreen improvements and the present discussion.
There is quite some complexity in changing multiscreen configs,
and I liked Marco Martin's summary of how Containments
(Desktop Containments or Panels) are linked to Screens etc.

Already with <= 2 screens (say, LVDS and one external screen scr1)
we can have 4 configurations (with * indicating the Primary Display),
namely

  c1 = [*lvds]
  c2 = [*lvds][scr1]
  c3 = [lvds][*scr1]
  c4 = [*scr1]

Based on the previous discussion, it seems that a Desktop Containment
D is configurable on a per-config and per-screen basis, so we have

  D = D(c,s)

where c is a config in {c1,c2,c3,c4} and s is a screen in {lvds,scr1}.
Moreover, a Panel P is apparently configurable on a per-config, per-screen
and per-resolution basis, so we have

  P = P(c,s,r,n)

where c and s are as above, r is a resolution, and n would be a panel index
(as there can be multiple panels per screen).

Using the above definitions and assumptions, we can ask a couple
of questions:

Q1. Among the possible transitions
   -, c1 -> c2, c1 -> c3, c1 -> c4
c2 -> c1,-, c2 -> c3, c2 -> c4
c3 -> c1, c3 -> c2,-, c3 -> c4
c4 -> c1, c4 -> c2, c4 -> c3,-

from initial to final config, which ones are actually implemented
as atomic transactions in kscreen control?  -- I'm asking because
for example the transition  c1 -> c3 could be implemented
atomically as
[*lvds] -> [lvds][*scr1]

or in two steps as
[*lvds]   -> [*lvds][scr1]
[*lvds][scr1] -> [lvds][*scr1]
with possibly different outcomes.


Q2. Marco stated that containments never migrate from one screen
to another except when there is a "change of the primary screen".
But which config changes actually qualify as "change of the primary
screen"?
I'd say
[*lvds][scr1] -> [lvds][*scr1]
is such a change, but how about
[*lvds] -> [lvds][*scr1]
?


Q3.  If I understand correctly, a "change of the primary screen"
causes ShellCorona::primaryOutputChanged() to swap containments
between the old primary screen and the new primary screen,
so is it true that a config change

  c1 = [*lvds][scr1] -> c3 = [lvds][*scr1]

will always result in the swap operations
  D(c3,scr1) := D(c1,lvds)
  P(c3,scr1,r,n) := P(c1,lvds,r,n)
  D(c3,lvds) := D(c1,scr1)
  P(c3,lvds,r,n) := P(c1,scr1,r,n)

regardless of whether c3 is created for the first time
or recreated some time later?


Q4.  For another example, if we consider the direct (atomic) transition
  c1 = [*lvds] -> c3 = [lvds][*scr1]
is this also handled by ShellCorona::primaryOutputChanged() ?
Does it cause any containments to be migrated to another screen?
(If not, one might end up with c3 having no panel
 the first time it gets created).


Thanks and regards,

---
Fredy Neeser
IBM Zurich Research Laboratory

Re: Breakout: * multiscreen behaviour: how should Plasma exactly behave in different scenarios?

[Marco Martin]

On Tuesday 18 October 2016, Marco Martin wrote:
> b) if it's not the first time, restore whatever was created for it in the
> past, the desktop and any eventual panels, in the exact same positions
> (panel geometries as usual have a config per screen resolution, so if you
> go from an high resolution screen to a low resolution projector they are
> managed separatedly, so one doesn't screw with the other too much)
 
forgot another managed case:

when two or more screens have an overlapping geometry, only one (the bigger, 
ideally) of those screens is considered, no desktops or panels should be 
created for the other overlapping screens, as the other screens will show all 
or part of the main screen, including desktops and panels, achieving what's 
usually called "clone mode"


-- 
Marco Martin

Re: Breakout: * multiscreen behaviour: how should Plasma exactly behave in different scenarios?

[Marco Martin]

On Tuesday 18 October 2016, Martin Klapetek wrote:
> On Mon, Oct 17, 2016 at 12:59 PM, Jonathan Riddell  wrote:
> >  biggest pain point from bugzilla is mostly still
> > 
> > multiscreen. I'm not sure we have a solid plan of what /should/ happen
> > in each situation.
> > 
> >  panel gets added to screen 1 and 2, you disconnect screen
> > 
> > 2. How many panels do you have on screen 1
> 
> (speaking from being in a work environment where I regularly switch
> between various screens/tvs and screen setups multiple times a day)

hey Martin, nice to see you =)

> Ideally containments are tied to screens as a whole and no "merge"
> of panels is happening. So in the case above, one panel. (I don't
> remember if panels are part of the containments, but I'll assume it is)

yes, panels are containments with their own view window, just like the 
desktops (so, assigned to a screen by their own)

> Ie: [laptop] [*screen1] --unplug screen--> [*laptop]
> 
> That primary setting should also be remembered by a screen I think,
> because if I'm plugging to a projector or big room TV, I don't think I want
> all my laptop screen suddenly jumping to the other screen for everyone
> to see. In other words, I never set that TV or projector as primary and
> therefore plasma shouldn't automatically assume "any external screen
> equals move primary screen".

that would need I guess some special treating in kscreen like
"when you encounter that particular screen (edid? manifacturer/model?) do not 
set it as primary"
or even stricter, set as primary only when you encounter that particular 
screen that is the one you have sitting on your desk, and not any new unknown 
one


-- 
Marco Martin

[Differential] [Request, 3 lines] D3098: Update screen pool connector ID ordering before adjusting desktop containments

[davidedmundson (David Edmundson)]

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

REVISION SUMMARY
  Setting the screenpool primary screen changes the mapping of ID ->
  connector. We need this to be done before the
  DesktopView::setScreenToFollow is called because otherwise it will save
  lastScreen with the wrong ID.
  
  BUG: 370711 (?)

TEST PLAN
  Hot swapped primary, both things swapped.
  Restarted Plasma
  Things restored as I think they should be.

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

BRANCH
  master

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

AFFECTED FILES
  shell/shellcorona.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: davidedmundson, #plasma
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

Re: Breakout: * multiscreen behaviour: how should Plasma exactly behave in different scenarios?

[Marco Martin]

On Tuesday 18 October 2016, David Edmundson wrote:
> 
> With regards to current Plasma behaviour that's not always true: I didn't
> mention if screen 2 was previously the primary screen or not.
> 
> At which point the correct behaviour should be to show the containers that
> were previously on screen 2 on screen 1. Right?

yes, that's the one case where the views get swapped to the other screen
in ShellCorona::primaryOutputChanged()

-- 
Marco Martin

Re: Breakout: * multiscreen behaviour: how should Plasma exactly behave in different scenarios?

[David Edmundson]

On Tue, Oct 18, 2016 at 10:07 AM, Marco Martin  wrote:

> On Monday 17 October 2016, Jonathan Riddell wrote:
> >  biggest pain point from bugzilla is mostly still
> > multiscreen. I'm not sure we have a solid plan of what /should/ happen
> > in each situation.
>
> there are now 18 bugs marked as multiscreen, which a good part of them i'm
> almost sure they should be fixed by 5.8.1/5.8.2, waiting for confirmation
> on
> them tough
>

Common case may be better, edge cases are definitely not.


> >  panel gets added to screen 1 and 2, you disconnect screen
> > 2. How many panels do you have on screen 1
>
> on screen 1 you should have the panel you added on screen 1, nothing of
> what
> you added on the screen 2
>
>
With regards to current Plasma behaviour that's not always true: I didn't
mention if screen 2 was previously the primary screen or not.

At which point the correct behaviour should be to show the containers that
were previously on screen 2 on screen 1. Right?

David

[Differential] [Updated, 146 lines] D3097: Changed the launcher modification API

[Ivan Čukić]

ivan updated this revision to Diff 7505.
ivan added a comment.


  - When all activities are selected, select the 'All activities' item

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3097?vs=7502=7505

BRANCH
  ivan/per-activity-launchers

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

AFFECTED FILES
  libtaskmanager/launchertasksmodel.cpp
  libtaskmanager/launchertasksmodel.h
  libtaskmanager/tasksmodel.cpp
  libtaskmanager/tasksmodel.h

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: ivan
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

Re: Breakout: * multiscreen behaviour: how should Plasma exactly behave in different scenarios?

[Marco Martin]

On Tuesday 18 October 2016, Martin Graesslin wrote:
> Both issues are unfixable with X11. And even on Wayland we kind of would
> need to know what the user wants. Which  is hardly possible.

c'mon just implement focus follows mind already :p


-- 
Marco Martin

Re: Breakout: * multiscreen behaviour: how should Plasma exactly behave in different scenarios?

[Martin Graesslin]

On Monday, October 17, 2016 5:59:05 PM CEST Jonathan Riddell wrote:
>  biggest pain point from bugzilla is mostly still
> multiscreen. I'm not sure we have a solid plan of what /should/ happen
> in each situation.
>  panel gets added to screen 1 and 2, you disconnect screen
> 2. How many panels do you have on screen 1

Adding something we see regularly in KWin: windows should store their position 
in relation to the screen they are on. E.g. you have window A on screen 1, 
then you add and move it to screen 2, unplug screen 2, kwin will put it on 
screen 1 and it's not where it was last on screen 1.

Other issues we regularly get reported is windows not opening on the screen 
the user expects them to open. Mostly a problem, because on X11 almost every 
application provides a positioning hint which kwin honors.

Both issues are unfixable with X11. And even on Wayland we kind of would need 
to know what the user wants. Which  is hardly possible.

With my window manager hat on, I'm nowadays convinced that there are two/three 
different usage strategies:
1: static setup with two screens. System should ideally have virtual desktop 
per screen, window management super important
2: notebook with docking station: like 1, but dynamic
3a: notebook with external extended projector: no window should ever go to the 
external screen except the ones added there
3b: static system with an external (off) TV: only used for kodi/vlc. No window 
should ever go there

Of course this is all highly dynamic. A system like 2 might turn into 3a at 
any time.

Taking the panel question from above: it depends on the usage pattern we are 
in. In 1 and 2 it should only be one panel, in 3a it should be 2, in 3b I have 
no idea.

And of course the question related to window management also depends on the 
usage strategy.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.

[Differential] [Closed] D3096: [kstyle] Implement window moving on Wayland

[Martin Gräßlin]

This revision was automatically updated to reflect the committed changes.
Closed by commit rOXYGEN0a4be7bdc1dd: [kstyle] Implement window moving on 
Wayland (authored by graesslin).

REPOSITORY
  rOXYGEN Oxygen Theme

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3096?vs=7501=7503

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

AFFECTED FILES
  kstyle/oxygenwindowmanager.cpp
  kstyle/oxygenwindowmanager.h

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #plasma, hpereiradacosta
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Request, 112 lines] D3097: Changed the launcher modification API

[Ivan Čukić]

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

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

BRANCH
  ivan/per-activity-launchers

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

AFFECTED FILES
  libtaskmanager/launchertasksmodel.cpp
  libtaskmanager/launchertasksmodel.h
  libtaskmanager/tasksmodel.cpp
  libtaskmanager/tasksmodel.h

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: ivan
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

Re: Breakout: how to attract new contributors?

[Marco Martin]

On Monday 17 October 2016, Jonathan Riddell wrote:
>  we need more contributors, junior jobs are best way to get
> started  the most critical thing we can do for developer recruitment
>  is change the way we publish/blog
>  our blogs are mostly work notes aimed at users, we need to
> write more blog posts that engineers like to read
>  mgraesslin: the interesting thing is that among the best and
> brightest fresh young open source contributors, we have quite a few
> users - e.g. in the Rust community quite a few use Plasma, because C++
> is the next best thing - but we don't publish anything they like to
> read so we don't convert

it's kind of a pipe dream, but indeed, great documentation would be one of the 
most effective things


-- 
Marco Martin

Re: Breakout: * multiscreen behaviour: how should Plasma exactly behave in different scenarios?

[Marco Martin]

On Monday 17 October 2016, Jonathan Riddell wrote:
>  biggest pain point from bugzilla is mostly still
> multiscreen. I'm not sure we have a solid plan of what /should/ happen
> in each situation.

there are now 18 bugs marked as multiscreen, which a good part of them i'm 
almost sure they should be fixed by 5.8.1/5.8.2, waiting for confirmation on 
them tough

>  panel gets added to screen 1 and 2, you disconnect screen
> 2. How many panels do you have on screen 1

on screen 1 you should have the panel you added on screen 1, nothing of what 
you added on the screen 2

>  btw, this is meta, but I feel the amount of feedback we get
> on multiscreen is really telling about our audience - many people who
> use KDE have multiple screens it seems, and only certain kinds of
> people and usage scenarios involve multiple screens (enthusiast home
> users, office professionals ..)
>  Multiscreen is also connecting to a projector for
> a movie, not only multiple displazs on the desk
>  d_ed: multiscreen on sddm on X11 is something I reported,
> it doesn't work terribly well as in: you get overlapping sddms if you
> have overlapping screens etc.

this is what is supposed to happen in plasmashell 5.8 right now (and in tests 
so far right now it happens, if not, s a bug):

* the way in which screen are identified is connector names, is the most 
unique way to identify whatever is connected to a particular port (that may 
change a lot of times, while the connector doesn't)
* every desktop containment is linked to a particular screen and stays forever 
with it, exept a single case [1]
* every panel  is linked to a particular screen and stays forever with it, 
exept a single case [1]
* so every screen has a set of panels and a desktop that are forever linked 
with each oter
* when you remove a screen, its desktop/panels must become unreachable (and 
their views destroyed), panels are *not* moved to the visible screens (if it 
happens in 5.8, please show me how to reproduce, because would be a bug)
* when you add a screen there may be 2 cases:
a) it's the first time, so create a new desktop containment for it, and no 
panels
b) if it's not the first time, restore whatever was created for it in the 
past, the desktop and any eventual panels, in the exact same positions (panel 
geometries as usual have a config per screen resolution, so if you go from an 
high resolution screen to a low resolution projector they are managed 
separatedly, so one doesn't screw with the other too much)

[1] now, the one and only case when the association connector-
>containment/panels set changes: change of the primary screen.
* when you change the primary screen, the containment/panels set gets swapped 
between the new primary screen and the one that used to be the primary screen: 
that seems the behavior that was expected by users
*slightly special case, when the system is configured to have one and only 
enabled primary screen and in the same transaction the old one is disabled and 
the new one enabled, in that case all the existing views are simply moved on 
the new screen (this happens when laptop users configure only the external 
monitor enabled upon connection with the internal display automatically 
reenabling when pulling the cable, quite popular setup and works surprisingly 
well after 5.8.1)

-- 
Marco Martin

[Differential] [Accepted] D3096: [kstyle] Implement window moving on Wayland

[hpereiradacosta (Hugo Pereira Da Costa)]

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


  Thanks !

REPOSITORY
  rOXYGEN Oxygen Theme

BRANCH
  ksytle-move-window

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #plasma, hpereiradacosta
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Request, 209 lines] D3096: [kstyle] Implement window moving on Wayland

[Martin Gräßlin]

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

REVISION SUMMARY
  So far oxygen hard disabled the window moving on Wayland. With this
  change the required functionality gets added.
  
  For that Oxygen creates an additional Seat and a Pointer on it to track
  all pointer button events on the window. That way the kstyle gets the
  latest serial which needs to be passed to the move requests. This is not
  available through QtWayland's native interface, thus Oxygen needs to
  interact with Wayland directly.
  
  When the move is triggered Oxygen gets the ShellSurface for the window
  and triggers the move on the own Seat object with the tracked serial.

TEST PLAN
  Tested with KWin/Wayland

REPOSITORY
  rOXYGEN Oxygen Theme

BRANCH
  ksytle-move-window

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

AFFECTED FILES
  kstyle/oxygenwindowmanager.cpp
  kstyle/oxygenwindowmanager.h

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #plasma, hpereiradacosta
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

Re: breakout: store and dependencies: to both plasma and other apps versions

[Marco Martin]

On Monday 17 October 2016, Jonathan Riddell wrote:
>  llucas`: on one hand, we need to figure out the dependency
> system on KPackage, then we can look whether anything is needed on the
> discover side, which shouldn't be needed
>  apol what about   * store and dependencies: to both
> plasma and other apps versions (for i.e. simplemenu, Dolphin service
> menus) and to other store items (i.e. look packages)  and
> integration with discover?
>  About KDE Store: I noticed that i.e. Dolphin Service
> Menus doesn't display KDE Store contents. The previous domains point
> to store.kde.org now but the new contents on KDE Store are not aleays
> displayed like in Dolphin
>  Riddell: I need basic version dependency handling - if I
> put Simple Menu on the Store today, say, it won't work for anyone
> because it needs 5.9 stuff

so, what i was thinking of doing is:
having this managed mostly on the client side, kpackage supporting 
dependencies defined as appdata ids in its metadata file. (so would still need 
to download the apckage anyways)
a key may be
X-KDE-Depends=org.kde.plasmashell:5.9,org.someone.beautifulicons

at first would try to install the thing with packagekit, if found, and that's 
probably the easy part (and where is i think realistic for 5.9) then the hard 
part is that it would need to search for stuff in the store as well.

at that point, would be needed something in attica to search for a particular 
appstream id, that may take a long time unfortunately as may need a change in 
the server as well to add new api (i wouldn't like to have to specify 
dependencies as numerical ids?)


-- 
Marco Martin

[Differential] [Closed] D3019: [kstyle] Implement window moving on Wayland

[Martin Gräßlin]

This revision was automatically updated to reflect the committed changes.
Closed by commit rBREEZE85f0e93ee82c: [kstyle] Implement window moving on 
Wayland (authored by graesslin).

REPOSITORY
  rBREEZE Breeze

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3019?vs=7443=7500

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

AFFECTED FILES
  kstyle/breezewindowmanager.cpp
  kstyle/breezewindowmanager.h

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #plasma_on_wayland, hpereiradacosta
Cc: sebas, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts

[Differential] [Commented On] D3079: Adapt Dashboard: Connect to new toggled signal instead of activated signal in order to initiate state change

[davidedmundson (David Edmundson)]

davidedmundson added inline comments.

INLINE COMMENTS

> main.qml:47
>  
> +Plasmoid.shrinkOnReactivation: !isDash
> +

If you want this to be in Plasma/5.8.x we can't rely on this being available.

Plasma 5.8.x *has* to still work with frameworks 5.26.

You can either go master only

or do the following:

Component.onCompleted: {
if (Plasmoid.hasOwnProperty("shrinkOnReactivation")) {

  shrinkOnReactivation = !isDash

}
}

REPOSITORY
  rPLASMADESKTOP Plasma Desktop

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

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

[Differential] [Request, 30 lines] D3095: Implement cursor shape tracking on Wayland

[Martin Gräßlin]

graesslin created this revision.
graesslin added reviewers: KWin, Plasma on Wayland.
Restricted Application added subscribers: kwin, plasma-devel.
Restricted Application added projects: Plasma on Wayland, KWin.

REVISION SUMMARY
  So far the tracking for cursor shape was done incorrectly on Wayland by
  only listening to X11 cursor changes. That's from a time when
  KWin/Wayland was still run on top of an X server.
  
  Nowadays the Platform tracks cursor shape changes and emits changes to
  it. Xwayland cursor changes go through the normal Wayland way so it's
  just one way to get it on Wayland.
  
  This change adds the required connect and changes the signal signature
  in Cursor by dropping the serial argument. No user of the signal uses
  the argument and on Wayland we don't have a serial for the cursor. So it
  can be dropped.

TEST PLAN
  Zoom effect updates cursor shape correctly on Wayland

REPOSITORY
  rKWIN KWin

BRANCH
  cursor-tracking-wayland

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

AFFECTED FILES
  cursor.cpp
  cursor.h

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #kwin, #plasma_on_wayland
Cc: plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, 
abetts, sebas

[Differential] [Commented On] D3019: [kstyle] Implement window moving on Wayland

[Martin Gräßlin]

graesslin added a comment.


  > Any plan for including the same to oxygen ?
  
  Yes, will do the same change for Oxygen now.

REPOSITORY
  rBREEZE Breeze

BRANCH
  kstyle-move-wayland

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #plasma_on_wayland, hpereiradacosta
Cc: sebas, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts

[Differential] [Accepted] D3019: [kstyle] Implement window moving on Wayland

[hpereiradacosta (Hugo Pereira Da Costa)]

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


  Thanks for changing the deltas. I find it much more readible now. 
  For me the is good to go. I could not test it though (no working wayland 
setup yet ... sorry)
  Any plan for including the same to oxygen ?
  
  (at some point I guess we could move all this common code to a common 
library, such as framework-integration/kstyle. My only worry with this is all 
the BIC, and API stability guaranty that come with it ... )

REPOSITORY
  rBREEZE Breeze

BRANCH
  kstyle-move-wayland

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #plasma_on_wayland, hpereiradacosta
Cc: sebas, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts

[Differential] [Request, 121 lines] D3093: Add a PlatformCursorImage to Platform and EffectsHandler

[Martin Gräßlin]

graesslin created this revision.
graesslin added reviewers: KWin, Plasma on Wayland.
Restricted Application added subscribers: kwin, plasma-devel.
Restricted Application added projects: Plasma on Wayland, KWin.

REVISION SUMMARY
  There are several effects (screenshot, zoom) which need access to the
  cursor image and cursor hotspot. So far these effects used X11
  unconditionally to get the cursor which obviously does not work on
  Wayland.
  
  This change adds a new class PlatformCursorImage to kwinglobals which
  wraps what a cursor is (image and hotspot) and adds a new virtual method
  to Platform to provide such a PlatformCursorImage. By default it's the
  cursor image the Platform tracks. On X11/standalone platform this new
  virtual method is overriden and provides a PlatformCursorImage from X11
  using the code previously used in screenshot effect.
  
  Screenshot effect and zoom are adjusted to use the new API instead of
  X11.

TEST PLAN
  Zoom effect tested on Wayland, now gets the proper cursor icon.
  X11 functionality not yet tested.

REPOSITORY
  rKWIN KWin

BRANCH
  platform-cursor-image

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

AFFECTED FILES
  autotests/mock_effectshandler.h
  effects.cpp
  effects.h
  effects/screenshot/screenshot.cpp
  effects/zoom/zoom.cpp
  libkwineffects/CMakeLists.txt
  libkwineffects/kwineffects.h
  libkwineffects/kwinglobals.h
  platform.cpp
  platform.h
  plugins/platforms/x11/standalone/x11_platform.cpp
  plugins/platforms/x11/standalone/x11_platform.h

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #kwin, #plasma_on_wayland
Cc: plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, 
abetts, sebas

[Differential] [Closed] D3084: [shell] Support autohide panel on wayland

[bshah (Bhushan Shah)]

This revision was automatically updated to reflect the committed changes.
bshah marked an inline comment as done.
Closed by commit rPLASMAWORKSPACEd0df5725d9ca: [shell] Support autohide panel 
on wayland (authored by bshah).

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3084?vs=7460=7490

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

AFFECTED FILES
  shell/panelview.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: bshah, graesslin, #plasma
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Closed] D3036: Support forceActiveWindow for Panels

[Martin Gräßlin]

This revision was automatically updated to reflect the committed changes.
Closed by commit rKWAYLANDINTEGRATION571072cccba5: Support forceActiveWindow 
for Panels (authored by graesslin).

REPOSITORY
  rKWAYLANDINTEGRATION Frameworks integration plugin using KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3036?vs=7345=7488

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

AFFECTED FILES
  src/windowsystem/windowsystem.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #plasma_on_wayland, sebas
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Commented On] D3084: [shell] Support autohide panel on wayland

[Martin Gräßlin]

graesslin added a comment.


  When pushing please add bug 369386

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

BRANCH
  panel-autohide

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: bshah, graesslin, #plasma
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Closed] D3037: Support docks which take input

[Martin Gräßlin]

This revision was automatically updated to reflect the committed changes.
Closed by commit rKWIN03d706150ab4: Support docks which take input (authored by 
graesslin).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D3037?vs=7346=7485#toc

REPOSITORY
  rKWIN KWin

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3037?vs=7346=7485

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

AFFECTED FILES
  abstract_client.cpp
  abstract_client.h
  activation.cpp
  autotests/integration/plasma_surface_test.cpp
  shell_client.cpp
  shell_client.h

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #kwin, #plasma_on_wayland, sebas
Cc: luebking, plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, 
jensreuterberg, abetts, sebas

[Differential] [Closed] D3080: Panel auto hide support for Wayland panels

[Martin Gräßlin]

This revision was automatically updated to reflect the committed changes.
Closed by commit rKWIN01667cacea85: Panel auto hide support for Wayland panels 
(authored by graesslin).

REPOSITORY
  rKWIN KWin

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3080?vs=7452=7484

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

AFFECTED FILES
  shell_client.cpp
  shell_client.h
  tests/CMakeLists.txt
  tests/screenedgeshowtest.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, bshah, #plasma_on_wayland, #kwin
Cc: plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, 
abetts, sebas

[Differential] [Closed] D3038: [krunner] Make KRunner on Wayland a Panel

[Martin Gräßlin]

This revision was automatically updated to reflect the committed changes.
Closed by commit rPLASMAWORKSPACE9abb81021288: [krunner] Make KRunner on 
Wayland a Panel (authored by graesslin).

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3038?vs=7347=7483

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

AFFECTED FILES
  krunner/view.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

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