D13874: textplugin: Fix missing QTextStream include

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Not the maintainer, just did some commits recently :) Thanks for the patch. 
Seems this is needed with some newer version of Qt? Some >5.11.1?
  
  Can you commit yourself? Should go to Plasma/5.12 branch possibly, to make 
that one work as well with newer Qt.

REPOSITORY
  R112 Milou

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

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

D13874: textplugin: Fix missing QTextStream include

[Alistair Francis]

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

REVISION SUMMARY
  Signed-off-by: Alistair Francis 

REPOSITORY
  R112 Milou

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

AFFECTED FILES
  lib/previews/textplugin.cpp

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

D13745: Implement support for virtual desktops on Wayland

[Eike Hein]

hein added inline comments.

INLINE COMMENTS

> zzag wrote in taskfilterproxymodel.h:73
> Is it id or number?

It's id.

> zzag wrote in waylandtasksmodel.cpp:760
> How about `static_cast(data.size())`?

No strong opinion :). This code is based on the one in the X11 model, which is 
in turn from the original libtaskmanager.

REPOSITORY
  R120 Plasma Workspace

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

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

Re: Discussion for Virtual Desktops and Activities future

[Eike Hein]

On 07/04/2018 03:00 AM, Ivan Čukić wrote:
> Wondering where the original discussion happened where 'we' decided to
> merge two orthogonal concepts into one. Can you point me to the relevant
> thread on plasma-devel?

This is the relevant thread :-)

I think this is a fair recap so far:

* When Martin and I started talking about the Wayland protocol, we
  were keen to do work that would reusable for either use case. This
  resulted in a draft protocol by Martin which as far as window
  management goes is a superset of what X11 virtual desktops and
  Activities can do.
* We now have working code based on the above that's gearing up to
  make virtual desktops work on Wayland, with no work yet done on
  Activities in any way.
* At the Plasma 5.14 kickoff it was decided not to work on Activities
  for the 5.14 timeframe, so there's ample room for discussions and
  decision-making.
* Marco really wants to merge them.
* I'm indifferent because I don't use either.


I think it's a reality that we have users who use both together,
using seperate activities for silo'ing files and favorites, and
virtual desktops to partition window-space within them.

I think it's also a reality that we have users who avoid using
both because of the perception of multiplied complexity, and
miss out on Activities features because they stick to virtual
desktops for simplicty.

It's also reality that we have critics who complain the two are
redundant and it's all a big mess.


I don't think we have any clue what the percentages are, or what the
opportunity cost to having both really is.


It's not a surprise to me that the idea of merging them has come up,
and I can see the appeal of a more simplified system. It does mean
being willing to take some people's existing workflows away, though.


I also think merging has technical risks, e.g. if it increases the
latency of a "virtual desktop switch" it could make the perhaps
most-used aspect of the feature unergonomic.


I also think which of our options is more appealing is also up
to what UI we use to expose them in the end, e.g. the VDG's
mulled Activity overview/dashboard thingie.


Cheers,
Eike

D13745: Implement support for virtual desktops on Wayland

[Vlad Zagorodniy]

zzag added a comment.


  Oh, please ignore my comments about `reserve`.

REPOSITORY
  R120 Plasma Workspace

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

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

D13745: Implement support for virtual desktops on Wayland

[Vlad Zagorodniy]

zzag added inline comments.

INLINE COMMENTS

> taskfilterproxymodel.h:73
>   * @see setVirtualDesktop
>   * @returns the number of the virtual desktop used in filtering.
>   **/

Is it id or number?

> virtualdesktopinfo.cpp:126
>  {
> -return KWindowSystem::numberOfDesktops();
> +QVariantList ids;
> +

ids.reserve(KWindowSystem::numberOfDesktops());

> virtualdesktopinfo.cpp:304
> +
> +foreach (const QString , virtualDesktops) {
> +ids << id;

Call reserve method. Also, why not range based for loop?

> waylandtasksmodel.cpp:760
> +QByteArray data(mimeData->data(Private::groupMimeType()));
> +if ((unsigned int)data.size() < sizeof(int) + sizeof(quint32)) {
> +return ids;

How about `static_cast(data.size())`?

REPOSITORY
  R120 Plasma Workspace

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

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

Re: Raising windows on Wayland

[Martin Flöser]

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





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


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

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

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


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



There are two interesting questions:

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


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




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


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




---

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

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


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

Cheers
Martin

Re: Discussion for Virtual Desktops and Activities future

[Ivan Čukić]

 Just read the phab discussion. If I misunderstood the situation, please correct me. Wondering where the original discussion happened where 'we' decided to merge two orthogonal concepts into one. Can you point me to the relevant thread on plasma-devel?If this is about providing a unified implementation in kwin for both VDs and activities, I'm fine with that. If not, then continue reading. VDs are for managing windows - a solution for the 'I don't have a screen large enough for all these windows'.Activities are for managing work - a solution to the 'I don't want documents/files/etc. from separate projects to get jumbled up together'.Previously, we had problems when we tried to equate activities with any specific thing. As in, 'an activity is a group of Plasma widgets'. The same will happen if the activity becomes 'a group of windows'.This has been discussed quite a few times before. Has anyone collected the use-cases of activities before coming up with this idea?Cheers, Ivan Sent via the BlackBerry Hub for Android   From: mvourla...@gmail.comSent: 3 July 2018 5:36 pmTo: plasma-devel@kde.orgReply to: plasma-devel@kde.orgSubject: Discussion for Virtual Desktops and Activities future  A discussion started by me at: https://phabricator.kde.org/D13745 about concerns related to future Activities / Virtual Desktops merge (I will call it MERGE in the future). As proposed the discussion can be moved here.In my opinion having a concrete draft how things are going to work from a user point view it might bring design issues that can be solved earlier than later. My opinion in the matter can be found at: https://psifidotos.blogspot.com/2012/03/activities-and-workareas-draft.html1. I think that the previous draft can be used in order to identify any users workflow breakage from MERGE.2. A new draft describing MERGE from a user point of view should be created in order for everyone (plama team and VDG) to understand what they are trying to create.By reading comments I identified a internal decision in order for MERGE to be based more in Activites infrastructure  for Plasma product and to VDs infrastructure for KWin product. I would propose to forget the technical approach and focus more on the user point of view. This could help avoid the VDs/Activities debate that started in Plasma 4/5 era and it is still present at a smaller degree.I will start with one concern based on the comments I read even though it would be better for everyone to describe first what is expecting from the MERGE.Concern [A]If MERGE creates a new Activity each time the user needs more space for its windows, doesnt that break totally the VDs users workflow? Example: I am working on my current actitivity and I am writing a note in a plasma widget. I am creating a new Activity, should that Activity look the same as the previous one and if I change the note in the first should it look the same and in the second? (at this example a current VDs user would answer should be in sync and always the same, a current
Activity user would answer it doesnt matter, it is unrelated)

D13871: Make TestInProcess skip out-of-process tests if D-Bus service uninstalled

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Initial draft version of the patch for principal review.
  
  Blocks should be indented surely.
  
  Perhaps the test methods should be also separated each into in-orocess and 
out-of-process , so the out-of-process ones could get a QSKIP at the begin, for 
improved logging in the test result of the skipped test variants?

REPOSITORY
  R110 KScreen Library

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

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

D13871: Make TestInProcess skip out-of-process tests if D-Bus service uninstalled

[Friedrich W. H. Kossebau]

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

REVISION SUMMARY
  With the movement to support running unittests pre-installation and KDE CI
  having adapted to that for some build setups, this currently breaks tests
  which rely on subject-under-test D-Bus services being auto-started from
  D-Bus service files, given the D-Bus daemon does not see the uninstalled
  ones.
  
  One solution might be to catch that situation and do the start of the D-Bus
  service ourselves, but I failed to get this done quickly. So as intermediate
  solution, to at least have the in-process tests no longer being covered by
  the out-of-process ones failing, this patch will just skip the
  out-of-process tests if the D-Bus service could not be started.
  That follows the current behaviour of e.g. the KGlobalShortcutTest from
  KF5's kglobalaccel.

TEST PLAN
  TestInProcess no longer fails if the org.kde.KScreen D-Bus service cannot be
  autostarted.

REPOSITORY
  R110 KScreen Library

BRANCH
  makeTestSkipDBusTettsIfNotFound

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

AFFECTED FILES
  autotests/testinprocess.cpp

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

D13853: Fix setting primary connector if primary output changed

[David Edmundson]

davidedmundson requested changes to this revision.
davidedmundson added inline comments.
This revision now requires changes to proceed.

INLINE COMMENTS

> screenpool.cpp:108
>  }
>  Q_ASSERT(m_idForConnector.contains(primary));
>  

Either this is a valid case to be in, and this assert doesn't make sense.

Or we should never be in this case, and the patch doesn't make sense.

I don't fully understand the background of how we end up in this situation to 
say which it is.

REPOSITORY
  R120 Plasma Workspace

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

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

D13870: Correct Folder View sizing and representation switch behavior

[Michail Vourlakos]

mvourlakos added a comment.


  In D13870#286578 , @hein wrote:
  
  > Add back useful comment.
  
  
  I tested the patch and I couldnt reproduce the tiny popup window with plasma,
  I checked also the Latte parabolic effect and it was working.
  
  +1, Good work Eike!

REPOSITORY
  R119 Plasma Desktop

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

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

Re: Raising windows on Wayland

[David Edmundson]

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

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

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

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

There are two interesting questions:

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

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

---

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

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

Re: Raising windows on Wayland

[Martin Flöser]

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


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

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

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

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

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

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

https://phabricator.kde.org/T4448

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

our applications but with any.

Cheers
Martin


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


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


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


Cheers
Martin

Re: Raising windows on Wayland

[Aleix Pol]

On Tue, Jul 3, 2018 at 6:32 PM Martin Flöser  wrote:
>
> Am 2018-07-03 18:05, schrieb Aleix Pol:
> > On Tue, Jul 3, 2018 at 6:02 PM Martin Flöser 
> > wrote:
> >>
> >> Am 2018-07-03 14:45, schrieb Aleix Pol:
> >> > Dear kwiners,
> >> > Would it be possible to find a way to do so?
> >> >
> >> > I know we don't want windows to be positioning themselves willy-nilly
> >> > on the window stack, but we certainly need to figure out his use-case.
> >> >
> >> > What would need to happen to do this?
> >> >
> >> > If you need to, I can compile a list of use-cases.
> >>
> >> Hi Alex,
> >>
> >> this really depends on the use case. Instead of allowing general
> >> raising
> >> I would prefer to make the workflows work correctly. E.g. if you want
> >> that the polkit authentication dialog is above discover we can make
> >> this
> >> work right now without needing to implement window raising.
> >>
> >> Cheers
> >> Martin
> >
> > That's not the use-case.
> >
> > A use-case is I was using Discover, someone pressed
> > appstream://org.kde.kate and wants to install it. Discover changes but
> > doesn't go into the foreground.
> > Similarly, we want the web browser to raise after we've pressed a URL
> > on an app.
> > Another thing I keep hitting: I open telegram or konversation on
> > krunner, nothing happens. It's because it's open somewhere under my
> > current window.
>
> Ok, that's all the same pattern: we have an action in application A
> which should activate (and raise) application B.
>
> First of: KWin should prevent application B to activate. This is only
> working because we don't have focus stealing prevention for Wayland
> windows yet. If we had focus stealing prevention, it would kick in and
> prevent application B from activating.
>
> The solution to this is a mechanism to pass activation around through a
> side channel. Application A would need to create a token before
> activating B and pass the token to B. B would use this token towards the
> compositor and the compositor would be able to allow the request as it
> sees that application A passed the focus to application B. That kind of
> matches what startup notifications used to be on X11. This is basically
> https://phabricator.kde.org/T4448
>
> Ideally this needs to be standardized so that it does not only work with
> our applications but with any.
>
> Cheers
> Martin

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

Aleix

Re: Raising windows on Wayland

[Eike Hein]

The token approach sounds good. I also like the idea of generalizing it
to cover startup notifications and pursuing standardization for it.


Cheers,
Eike

Re: Raising windows on Wayland

[Martin Flöser]

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


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

Hi Alex,

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

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

work right now without needing to implement window raising.

Cheers
Martin


That's not the use-case.

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

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


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


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


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


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


Cheers
Martin

D13870: Correct Folder View sizing and representation switch behavior

[Eike Hein]

hein updated this revision to Diff 37115.
hein added a comment.


  Add back useful comment.

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13870?vs=37114=37115

BRANCH
  master

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

AFFECTED FILES
  containments/desktop/package/contents/ui/CompactRepresentation.qml
  containments/desktop/package/contents/ui/main.qml

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

D13870: Correct Folder View sizing and representation switch behavior

[Eike Hein]

hein updated this revision to Diff 37114.
hein added a comment.


  - Add the missing switch stuff.
  - Remove stray debug.

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13870?vs=37113=37114

BRANCH
  master

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

AFFECTED FILES
  containments/desktop/package/contents/ui/CompactRepresentation.qml
  containments/desktop/package/contents/ui/main.qml

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

D13870: Correct Folder View sizing and representation switch behavior

[Eike Hein]

hein planned changes to this revision.
hein added a comment.


  Whoops, I accidentally uploaded the wrong diff, hang on.

REPOSITORY
  R119 Plasma Desktop

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

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

D13870: Correct Folder View sizing and representation switch behavior

[Eike Hein]

hein created this revision.
hein added reviewers: mart, broulik, mvourlakos.
Restricted Application added a project: Plasma.
hein requested review of this revision.

REVISION SUMMARY
  - Resolve inherent layout hint conflicts between full and compact 
representations by setting them seperately. This fixes a recent regression 
causing tiny popups.
  
  BUG:395477
  
  - Correctly respect the panel icon size hint when scaling the compact 
representation, with the code and behavior now matching the Icon applet.
  - Only expand into the full representation in place on vertical panels. This 
is not a bugfix, and optional. But I think the expansion is useless on 
horizontal panels, and this means fewer users have to care about changing the 
panel icon size hint if they're using a really tall horizontal panel or Latte 
with parabolic zooming.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  master

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

AFFECTED FILES
  containments/desktop/package/contents/ui/CompactRepresentation.qml
  containments/desktop/package/contents/ui/main.qml

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

Re: Raising windows on Wayland

[Aleix Pol]

On Tue, Jul 3, 2018 at 6:02 PM Martin Flöser  wrote:
>
> Am 2018-07-03 14:45, schrieb Aleix Pol:
> > Dear kwiners,
> > Would it be possible to find a way to do so?
> >
> > I know we don't want windows to be positioning themselves willy-nilly
> > on the window stack, but we certainly need to figure out his use-case.
> >
> > What would need to happen to do this?
> >
> > If you need to, I can compile a list of use-cases.
>
> Hi Alex,
>
> this really depends on the use case. Instead of allowing general raising
> I would prefer to make the workflows work correctly. E.g. if you want
> that the polkit authentication dialog is above discover we can make this
> work right now without needing to implement window raising.
>
> Cheers
> Martin

That's not the use-case.

A use-case is I was using Discover, someone pressed
appstream://org.kde.kate and wants to install it. Discover changes but
doesn't go into the foreground.
Similarly, we want the web browser to raise after we've pressed a URL on an app.
Another thing I keep hitting: I open telegram or konversation on
krunner, nothing happens. It's because it's open somewhere under my
current window.

Aleix

Re: Raising windows on Wayland

[Martin Flöser]

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

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

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

What would need to happen to do this?

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


Hi Alex,

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


Cheers
Martin

D13745: Implement support for virtual desktops on Wayland

[Michail Vourlakos]

mvourlakos added a comment.


  In D13745#286544 , @hein wrote:
  
  > Can we discuss this somewhere else, e.g. on plasma-devel or in one of the 
Plasma monday meetings? This is a review thread for a libtaskmanager code patch.
  
  
  of course, done...
  I sent an e-mail to plasma mailing list with topic "Discussion for Virtual 
Desktops and Activities future"

REPOSITORY
  R120 Plasma Workspace

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

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

Discussion for Virtual Desktops and Activities future

[Michail Vourlakos]

A discussion started by me at: https://phabricator.kde.org/D13745 about
concerns related to future Activities / Virtual Desktops merge (I will call
it MERGE in the future). As proposed the discussion can be moved here.

In my opinion having a concrete draft how things are going to work from a
user point view it might bring design issues that can be solved earlier
than later. My opinion in the matter can be found at:
https://psifidotos.blogspot.com/2012/03/activities-and-workareas-draft.html

1. I think that the previous draft can be used in order to identify any
users workflow breakage from MERGE.
2. A new draft describing MERGE from a user point of view should be created
in order for everyone (plama team and VDG) to understand what they are
trying to create.


By reading comments I identified a internal decision in order for MERGE to
be based more in Activites infrastructure  for Plasma product and to VDs
infrastructure for KWin product. I would propose to forget the technical
approach and focus more on the user point of view. This could help avoid
the VDs/Activities debate that started in Plasma 4/5 era and it is still
present at a smaller degree.


I will start with one concern based on the comments I read even though it
would be better for everyone to describe first what is expecting from the
MERGE.


Concern [A]

If MERGE creates a new Activity each time the user needs more space for its
windows, doesnt that break totally the VDs users workflow?

Example: I am working on my current actitivity and I am writing a note in a
plasma widget. I am creating a new Activity, should that Activity look the
same as the previous one and if I change the note in the first should it
look the same and in the second? (at this example a current VDs user would
answer should be in sync and always the same, a current
Activity user would answer it doesnt matter, it is unrelated)

D13745: Implement support for virtual desktops on Wayland

[Nathaniel Graham]

ngraham added a comment.


  In D13745#286544 , @hein wrote:
  
  > Can we discuss this somewhere else, e.g. on plasma-devel or in one of the 
Plasma monday meetings? This is a review thread for a libtaskmanager code patch.
  
  
  +1, let's do that elsewhere.

REPOSITORY
  R120 Plasma Workspace

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

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

D13745: Implement support for virtual desktops on Wayland

[Andres Betts]

abetts added a comment.


  The dev team has been in talks with the VDG about this change. We are OK with 
the change. We understand that before we make any visual changes, we need to, 
at least, provide the same functionality that we have in X11 to what we want to 
have in Wayland. The VDG is currently working on devising the ways that this 
can work graphically.

REPOSITORY
  R120 Plasma Workspace

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

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

D13745: Implement support for virtual desktops on Wayland

[Eike Hein]

hein added a comment.


  Can we discuss this somewhere else, e.g. on plasma-devel or in one of the 
Plasma monday meetings? This is a review thread for a libtaskmanager code patch.

REPOSITORY
  R120 Plasma Workspace

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

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

D13864: [Splash Screen KCM] Fix "no thumbnail" icon for "None"

[Kai Uwe Broulik]

This revision was automatically updated to reflect the committed changes.
Closed by commit R119:50b1acf4016a: [Splash Screen KCM] Fix no 
thumbnail icon for None (authored by broulik).

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13864?vs=37092=37109

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

AFFECTED FILES
  kcms/ksplash/package/contents/ui/main.qml

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

D13745: Implement support for virtual desktops on Wayland

[Michail Vourlakos]

mvourlakos added a comment.


  In D13745#286501 , @hein wrote:
  
  > A lot of this is still up in the air, but here's the rough plan:
  >
  > 0. X11 will remain unchanged. The feature set of Activities will remain 
unchanged.
  >
  > 1. For 5.14, we want to have virtual desktops working on Wayland, with 
feature parity to X11. Activities will not yet work on Wayland. The new Wayland 
protocol allows windows to be on more than one desktop and it allows for 
multiple concurrently active desktops, but these abilities will not be used in 
5.14, they will only be present in the API (hence the API changes).
  > 2. For 5.15, we want to sync Activities to virtual desktops on Wayland, 
meaning adding/removing Activities is how you add/remove virtual desktops, and 
switching/activating VDs==switching/activating Activities.
  >
  >   That means on Wayland on 5.15+ (if this schedule holds) the default Task 
Manager would just hide all the virtual desktop UI, exposing only the 
activities UI.
  
  
  I see...
  
  The thing is that I can undestand the technical solution at some point but 
from user point of view I think that there will be issues.
  Personally I start from the user point of view how things will and should 
work and then I am focusing on the technical solution.
  
  If I understood correctly VDs in the future will be Activities but without 
the extra space that someone might need for its windows.
  That will break the workflow for the VDs users who are the majority of the 
linux desktop
  (take note that I am not :). I am Activities heavy user that always uses one 
VD)).
  
  If plasma devs agree on that roadmap then there are things that should be 
introduced in the future in order to make the VDs
  users life a bit easier.
  
  e.g. When a new Activity will be created shouldnt look exactly as the active 
one and be always in sync with it?
  e.g. I am working on my current actitivity and I am writing a note on the 
desktop. I am creating a new Activity,
  should that Activity look the same as the previous one and if I change the 
note in the first to look the same and in
  the second? (at this example a current VDs user would answer should be in 
sync and always the same, a current
  Activity user would answer it doesnt matter)
  
  I fear that if this isnt orchestrated correctly with VDG a new debate for VDs 
and Activities 
  will relaunch just like the plasma 4 and 5 debates for the matter.
  
  You can read my personal opinion for the matter at: 
https://psifidotos.blogspot.com/2012/03/activities-and-workareas-draft.html
  I dont object in any alternative solution but the solution should be designed 
from
  the user point of view first and then starting implementing.

REPOSITORY
  R120 Plasma Workspace

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

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

D13856: Fix crash on post-initial refresh()

[Eike Hein]

This revision was automatically updated to reflect the committed changes.
Closed by commit R119:e1252c6e40ac: Fix crash on post-initial refresh() 
(authored by hein).

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13856?vs=37105=37107

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

AFFECTED FILES
  applets/kicker/plugin/recentusagemodel.cpp
  applets/kicker/plugin/recentusagemodel.h

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

D13856: Fix crash on post-initial refresh()

[Eike Hein]

hein updated this revision to Diff 37105.
hein retitled this revision from "Work around KActivitiesStats' ResultsModel 
emitting wrong moves" to "Fix crash on post-initial refresh()".
hein edited the summary of this revision.
hein added a comment.


  Drop the hack.

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13856?vs=37077=37105

BRANCH
  master

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

AFFECTED FILES
  applets/kicker/plugin/recentusagemodel.cpp
  applets/kicker/plugin/recentusagemodel.h

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

D13745: Implement support for virtual desktops on Wayland

[Eike Hein]

hein added a comment.


  A lot of this is still up in the air, but here's the rough plan:
  
  0. X11 will remain unchanged. The feature set of Activities will remain 
unchanged.
  
  1. For 5.14, we want to have virtual desktops working on Wayland, with 
feature parity to X11. Activities will not yet work on Wayland. The new Wayland 
protocol allows windows to be on more than one desktop and it allows for 
multiple concurrently active desktops, but these abilities will not be used in 
5.14, they will only be present in the API (hence the API changes).
  
  2. For 5.15, we want to sync Activities to virtual desktops on Wayland, 
meaning adding/removing Activities is how you add/remove virtual desktops, and 
switching/activating VDs==switching/activating Activities.
  
  That means on Wayland on 5.15+ (if this schedule holds) the default Task 
Manager would just hide all the virtual desktop UI, exposing only the 
activities UI.

REPOSITORY
  R120 Plasma Workspace

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

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

D13745: Implement support for virtual desktops on Wayland

[Michail Vourlakos]

mvourlakos added a comment.


  In D13745#286491 , @hein wrote:
  
  > Michail: Please follow this review, as these API changes might impact Latte 
Dock, too. :)
  
  
  no prob... this will be a big change so it will break Latte.
  
  Latte v0.8 is a very heavy Activities user so only thing can done is when the 
VDs-Activities architecture lands  in Plasma to try to catch up until the 
official release with a secondary official release from Latte.
  
  If I have understood correctly:
  
  1. at some plasma point release (e.g. 5.x ) in the feature Activities will be 
merged with Virtual Desktops both for X11 and wayland?
  2. that will probably break Activties from (5.x-1) ?
  3. The idea is that Virtual Desktops will get some characteristics from 
Activities or vice versa?
  4. The features provided from kactivitymanagerd will be dropped? (files 
linked to Activities, Activity icon, etc...) OR Virtual Desktops in Plasma will 
be identified through kactivitymanagerd in the future?

REPOSITORY
  R120 Plasma Workspace

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

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

D13745: Implement support for virtual desktops on Wayland

[Eike Hein]

hein added a reviewer: mvourlakos.
hein added a comment.


  Michail: Please follow this review, as these API changes might impact Latte 
Dock, too. :)

REPOSITORY
  R120 Plasma Workspace

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

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

Raising windows on Wayland

[Aleix Pol]

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

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

What would need to happen to do this?

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

Aleix

D13868: [KdePlasma-Addons/POTD/NOAA] Fixed the web address and fetched the picture from new address

[Tagore Chandan Reddy]

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

REVISION SUMMARY
  The web address for NOAA is no longer valid. So, the new address had to be 
provided.
  
  Old address: http://www.nnvl.noaa.gov/imageoftheday.php
  new address: https://www.nesdis.noaa.gov/content/imagery-and-data
  
  'Image of the day' has a new landing page everyday. So the code had to 
slightly altered to fetch image from new address.

REPOSITORY
  R114 Plasma Addons

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

AFFECTED FILES
  dataengines/potd/noaaprovider.cpp
  dataengines/potd/noaaprovider.h

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

KDE CI: Plasma plasma-desktop kf5-qt5 SUSEQt5.10 - Build # 116 - Still unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Plasma%20plasma-desktop%20kf5-qt5%20SUSEQt5.10/116/
 Project:
Plasma plasma-desktop kf5-qt5 SUSEQt5.10
 Date of build:
Tue, 03 Jul 2018 11:06:16 +
 Build duration:
4 min 54 sec and counting
   JUnit Tests
  Name: (root) Failed: 1 test(s), Passed: 11 test(s), Skipped: 0 test(s), Total: 12 test(s)Failed: TestSuite.test_kio_fonts
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report13%
(10/79)11%
(44/383)11%
(44/383)10%
(3654/35887)8%
(1976/23802)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsapplets.kicker.plugin0%
(0/37)0%
(0/37)0%
(0/3225)0%
(0/2548)applets.kimpanel.backend.ibus0%
(0/1)0%
(0/1)0%
(0/30)0%
(0/10)applets.kimpanel.backend.ibus.ibus150%
(0/10)0%
(0/10)0%
(0/1088)0%
(0/606)applets.kimpanel.backend.scim0%
(0/1)0%
(0/1)0%
(0/663)0%
(0/395)applets.kimpanel.plugin0%
(0/2)0%
(0/2)0%
(0/43)0%
(0/26)applets.pager.plugin0%
(0/3)0%
(0/3)0%
(0/317)0%
(0/194)applets.taskmanager.plugin0%
(0/3)0%
(0/3)0%
(0/306)0%
(0/234)applets.taskmanager.plugin.smartlaunchers0%
(0/4)0%
(0/4)0%
(0/271)0%
(0/162)applets.trash.plugin0%
(0/5)0%
(0/5)0%
(0/111)0%
(0/54)attica-kde.kdeplugin0%
(0/1)0%
(0/1)0%
(0/124)0%
(0/108)containments.desktop.plugins.desktop0%
(0/2)0%
(0/2)0%
(0/48)0%
(0/18)containments.desktop.plugins.folder30%
(6/20)30%
(6/20)39%
(837/2149)27%
(381/1423)containments.desktop.plugins.folder.autotests100%
(4/4)100%
(4/4)100%
(536/536)60%
(219/364)dataengines.kimpanel0%
(0/7)0%
(0/7)0%
(0/328)0%
(0/131)imports.activitymanager0%
(0/3)0%
(0/3)0%
(0/373)0%
(0/224)kaccess0%
(0/3)0%
(0/3)0%
(0/579)0%
(0/281)kcms.access0%
(0/1)0%
(0/1)0%
(0/306)0%
(0/74)kcms.activities0%
(0/7)0%
 

D10040: Add serial number and EISA ID to OutputDevice interface

[Daniel Vrátil]

dvratil added a comment.


  In D10040#286064 , @davidedmundson 
wrote:
  
  > @dvratil want me to finish this?
  
  
  @davidedmundson  Yes, I'd appreciate it. I won't have time to look into this 
any time soon, sorry :(

REPOSITORY
  R127 KWayland

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

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

D13752: Build solidautoeject only on FreeBSD

[Kai Uwe Broulik]

broulik updated this revision to Diff 37098.
broulik retitled this revision from "Kill solidautoeject" to "Build 
solidautoeject only on FreeBSD".
broulik edited the summary of this revision.
broulik edited the test plan for this revision.
broulik added a comment.


  - Keep it around for FreeBSD

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13752?vs=36747=37098

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

AFFECTED FILES
  CMakeLists.txt

To: broulik, #plasma, #frameworks, adridg, davidedmundson, dfaure, fvogt, ervin
Cc: anthonyfieroni, mart, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol

D13752: Kill solidautoeject

[Adriaan de Groot]

adridg added a comment.


  - Start systemsettings; under *workspace*, *startup and shutdown*, find 
*background services*.
  - Untick the box for *Drive Ejector*; also check status is *not running*, 
click *stop* button if it is still running.
  - Insert CD, pick *open in file manager* from the device notifier popup
  - Check that it's mounted, from a konsole
  - Press button on CD drive: no result
  - Choose eject from device notifier:  CD is ejected

REPOSITORY
  R120 Plasma Workspace

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

To: broulik, #plasma, #frameworks, adridg, davidedmundson, dfaure, fvogt, ervin
Cc: anthonyfieroni, mart, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol

KDE CI: Plasma plasma-desktop kf5-qt5 SUSEQt5.10 - Build # 115 - Failure!

[CI System]

Error processing tokens: Error while parsing action 'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input position (line 1, pos 38):
${JELLY_SCRIPT,template="html_gmail"}
 ^

hudson.remoting.ChannelClosedException: Channel "unknown": Remote call on Docker Swarm-7e0a91e54865 failed. The channel is closing down or has closed down

D13863: Don't block startplasma sending DBus call to KSplash

[Kai Uwe Broulik]

This revision was automatically updated to reflect the committed changes.
Closed by commit R120:0470689f03de: Dont block startplasma sending DBus 
call to KSplash (authored by broulik).

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13863?vs=37091=37094

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

AFFECTED FILES
  startkde/startplasma.cmake

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

D13864: [Splash Screen KCM] Fix "no thumbnail" icon for "None"

[Kai Uwe Broulik]

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

REVISION SUMMARY
  In JavaScript `undefined` does not convert to empty string, so `undefined != 
""` is always `true`.
  The role isn't added to the `QStandardItemModel` for "None", so it is 
`undefined` (null `QVariant`) as far as QML is concerned.

TEST PLAN
  5.13
  "None" has the "no thumbnail available" icon now

REPOSITORY
  R119 Plasma Desktop

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

AFFECTED FILES
  kcms/ksplash/package/contents/ui/main.qml

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

D13863: Don't block startplasma sending DBus call to KSplash

[Kai Uwe Broulik]

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

REVISION SUMMARY
  Copy of D2910  for `startplasma`

TEST PLAN
  Logged into Wayland session, ksplash would still disappear normally

REPOSITORY
  R120 Plasma Workspace

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

AFFECTED FILES
  startkde/startplasma.cmake

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

D13852: [Device Automounter] Load kded module only if enabled

[Kai Uwe Broulik]

This revision was automatically updated to reflect the committed changes.
Closed by commit R119:2b9c762f9221: [Device Automounter] Load kded module only 
if enabled (authored by broulik).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D13852?vs=37070=37093#toc

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13852?vs=37070=37093

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

AFFECTED FILES
  solid-device-automounter/kcm/CMakeLists.txt
  solid-device-automounter/kcm/DeviceAutomounterKCM.cpp
  solid-device-automounter/kded/CMakeLists.txt
  solid-device-automounter/kded/DeviceAutomounter.cpp
  solid-device-automounter/kded/device_automounter.desktop

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

D10342: From 100% plasma cpu usage to normal when using vivaldi

[Anthony Fieroni]

anthonyfieroni added a comment.


  In D10342#286360 , @jtamate wrote:
  
  > Or perhaps is it better to try to create that cache in KServiceTypeTrader?
  
  
  That will be the right place, reading from disk is always costly, it will be 
better to make service parsing on file changes otherwise to read from cache.

REPOSITORY
  R120 Plasma Workspace

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

To: jtamate, #plasma_workspaces, hein
Cc: anthonyfieroni, mart, mwolff, broulik, plasma-devel, ragreen, Pitel, 
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol

D10342: From 100% plasma cpu usage to normal when using vivaldi

[Jaime Torres Amate]

jtamate added a comment.


  In D10342#286023 , @hein wrote:
  
  > This patch doesn't make any sense. It's setting up a cache for something 
computed from data that's subject to change, and it's never evicting it when 
that data changes.
  
  
  To make it right, should it also be wiped in 
XWindowTasksModel::Private::windowChanged?
  Or perhaps is it better to try to create that cache in KServiceTypeTrader?

REPOSITORY
  R120 Plasma Workspace

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

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