Re: some feedback from a mobile application development team

[Dirk Hohndel]

Hi Thomas

On Wed, Jan 06, 2016 at 02:56:09AM +0100, Thomas Pfeiffer wrote:

You clearly have interesting working hours... just like Sebastian

> There is a difference between edge swipe and regular horizontal swipes. All 
> stock Android apps that have a left drawer use an edge swipe to open it (in 
> addition to the button), but still happily use horizontal swipes to navigate 
> e.g. between emails without conflict.

Wow. I did not realize that. Just tried it and indeed, you are right.
No conflict, no issue. Cool.

I learned something new today :-)

> > What do you think about this solution instead:
> > - on Android, draw the two hard to reach corner menu buttons
> > - on any OS, show the FAB with the arrows
> 
> We could do that, yes.

I think that would really help. Especially in the beginning - until Plasma
Mobile takes over the world and everyone is used to this behavior and is
wondering why there are apps that don't use the Action Button in the lower
center...

Just promise that you don't go BMW iDrive on us and allow eight different
directions for the Action Button :-)

> > AND
> > 
> > Support a "first start" mode for Plasma Mobile Components based apps that
> > demonstrates to the user how things get used. So it shows a see through
> > finger that taps and holds (the pulsing circles around the touch area) the
> > FAB and moves it and the menus show up, and then shows that you could also
> > tap the menu buttons when on Android. It would be nice to have this "first
> > start" mode supported by the tool kit so that not every single app has to
> > implement something along those lines.
> 
> You caught us here: Actually, this was our idea all along, we just haven't 
> gotten around to design and implement them, yet. My usability tests so far 
> also clearly show that this interaction needs a quick introduction. Once I 
> showed users how it worked, they found it easy to interact with, so yes, we 
> need those tutorials and will provide them.

Cool

> And I also agree that this should be provided by the framework. In Plasma 
> Mobile, the tutorial would come up directly on the first start of a new 
> device. 
> On Android, it should ideally be shown only the first time that any 
> application 
> using our components is used.

Not sure how that could be handled on Android, but I'll burn that bridge
when I get there.

> > > So, what do you think?
> > 
> > I tried to show my thinking above. In summary I'm supportive of introducing
> > the FAB as an easy to reach way to get to the drawers, as long as it's in
> > addition to the  traditional ways to do so.
> 
> This might indeed be a good compromise indeed.

Great.

> > I'm not a fan of side swiping for the drawers because that prohibits what
> > I find more intuitive and more useful application of the side swipe gesture.
> 
> I'd really like you to try out whether edge swipes for drawers and regular 
> horizontal swipes for switching between dives can coexist in Subsurface as 
> well as it can coexist in stock Android apps (see e.g. GMail or Photos), and 
> if problems come up, I'd like to know what causes them and whether we can fix 
> them.

I think you are right. I poked Sebastian to help us get a first
implementation of that in place so our testers can play with it. But based
on spending two minutes with GMail on my Nexus 6p I'm convinced now that
this will work

(btw: I didn't notice an action button in GMail - what am I missing?)

> > Either way, I'd love to stay engaged with you and the Plasma Mobile
> > developers to create the best possible user experience for our users.
> 
> Definitely! We need feedback from people who use our components in the real 
> world. Design must not happen in an ivory tower, which is why I am eternally 
> grateful that you are using our components even in their very early stage and 
> are happy to provide feedback so we can continuously improve them. We really 
> need that!

For Subsurface the huge advantage is that we are getting two things we are
dearly missing: a) help with figuring out the user interaction design
(YAY!) and b) help with the QML implementation (since it is becoming very
clear to me that I still have a HUGE learning curve ahead of me there...)

So this is mutually benefitial :-)

/D
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: some feedback from a mobile application development team

[Thomas Pfeiffer]

On Dienstag, 5. Januar 2016 16:58:10 CET Dirk Hohndel wrote:
> Hi Thomas,
> 
> > On Jan 5, 2016, at 3:22 PM, Thomas Pfeiffer 
> > wrote: as the person in charge of the KDE Mobile HIG (and therefore also
> > responsible for the usability of the Plasma Components), I'm very happy
> > to get feedback from users of an actual working application using our
> > components!
> 
> Awesome - a designer who wants to hear feedback from users... I cannot tell
> you how refreshing that is :-)

I'm foremost a human-centered design specialist, so incorporating user 
feedback into design is integral to my design work.

> > First of all: It's fully understandable that Android testers like UIs the
> > way that stock Android UIs are. That's what they're used to, that's what
> > their muscle memory has learned.
> 
> Which, based on the principle of least surprise, to me was an important
> part of the equation. I went through the Gnome 2->3 disaster, err, migration
> and had endless discussions with designers who did NOT want to hear
> feedback from users... and clearly did not understand the principle of
> least surprise.

Conformity with expectations is one of the key principles of HCI, so I will 
always try to innovate while breaking with expectations as little as possible.
 
> > Given that, the context menu button in the top-right corner is almost in
> > the worst possible place to reach (for left-handed people, it is
> > literally in the worst possible place). Try reaching that button with
> > your thumb when holding a 5"+ phone with one hand, without changing the
> > position of the device in your hand. Really, it's no fun.
> 
> So I have two 6" devices (Nexus 6p and iPhone 6+) and use both of them
> single handed and have no problem reaching either corner (happy to provide
> video evidence), but I will admit that I have really big hands and that I'm
> well aware that this is a big problem for most people, so this is a very
> valid point .

Okay, fair enough. But I'm glad you still consider my point valid for people 
with smaller hands than yours.

> Side note: I am not a huge friend of the side swipes being used for the
> drawers. I find swipes a great way to do navigation. There are a bunch of
> email applications where swiping left and right you can move to the
> previous / next item in your mailbox - something that I was hoping to adapt
> on Subsurface-mobile: if you look at the details of a dive, swiping
> sideways will get you to the previous / next dive in your dive list.

There is a difference between edge swipe and regular horizontal swipes. All 
stock Android apps that have a left drawer use an edge swipe to open it (in 
addition to the button), but still happily use horizontal swipes to navigate 
e.g. between emails without conflict.
Edge swipes are really only from outside of the screen in, whereas regular 
horizontal swipes start from any other point on the screen.

The usability tests I've conducted so far showed no conflict between edge 
swipes and regular horizontal swipes (which we use heavily for back and 
forward navigation). Users only on very rare occasions accidentally opened a 
drawer while using horizontal swipes for navigation.

> > So, dragging the Action Button is not "a solution looking for a problem",
> > but in fact it is the answer to the problem that screen corners are hard
> > to reach when you hold a bigger phone (which are becoming more and more
> > common) in one hand.
> 
> OK, maybe that wasn't a nice way to phrase this :-/ -- my apologies.
> But fact is that we had pretty unanimous feedback that people had not the
> slightest idea what that button was there for. We had two different users
> assume that this button was to move to the previous / next dive :-)
> But the user interaction "to open a menu, move this button sideways"
> seemed utterly perplexing to everyone.

> > Therefore what I'd like to see is that when our components are used within
> > Android, they draw the buttons in the top bar (where they are - and that
> > is a research-supported fact - hard to reach, but consistent with other
> > Android applications) but leave edge-swiping as an easier-to-reach
> > alternative for _both_ drawers (stock Android apps do it only for the
> > left drawer, which is really nonsensical if you think about it). When the
> > same application is run on Plasma Mobile, where people have learned how
> > to use the Action Button-dragging from other applications, it should use
> > that one.
> 
> See my comment above on the edge swiping...

...and see my reply ;)

> What do you think about this solution instead:
> - on Android, draw the two hard to reach corner menu buttons
> - on any OS, show the FAB with the arrows

We could do that, yes.

> - allow the application to override the edge swipe functionality

See above.

> AND
> 
> Support a "first start" mode for Plasma Mobile Components based apps that
> demonstrates to the user how things get used. So it shows a see through
> finger that taps and 

Re: some feedback from a mobile application development team

[Dirk Hohndel]

Hi Thomas,

> On Jan 5, 2016, at 3:22 PM, Thomas Pfeiffer  wrote:
> as the person in charge of the KDE Mobile HIG (and therefore also responsible 
> for the usability of the Plasma Components), I'm very happy to get feedback 
> from users of an actual working application using our components!

Awesome - a designer who wants to hear feedback from users... I cannot tell
you how refreshing that is :-)

> Since I am not a developer, I can only discuss our design choices, our 
> developers are better suited to discuss the technical problems you 
> encountered. 
> 
> So here goes my comment on the user feedback. Please bear with me, as I'll 
> have to expand a bit on the reasoning behind the interaction with the action 
> button:

Not at all - that's very useful to understand

> First of all: It's fully understandable that Android testers like UIs the way 
> that stock Android UIs are. That's what they're used to, that's what their 
> muscle memory has learned.

Which, based on the principle of least surprise, to me was an important
part of the equation. I went through the Gnome 2->3 disaster, err, migration
and had endless discussions with designers who did NOT want to hear
feedback from users... and clearly did not understand the principle of least
surprise.

> Let me explain to you, then, why we diverged from the default Android 
> behavior.
> As a start, here are the relevant section from my blog post laying out the 
> basic assumptions behind our design choices [1]:
> ---
> Users prefer to interact with the center of the screen
> As research [2] shows, smartphones are predominantly held upright (portrait 
> mode) and in one hand, simply because that is the most convenient way to use 
> it and it leaves one hand free e.g. to hold onto something while standing in 
> a 
> bus.
> 
> If we want an application to be used conveniently with one hand, we have to 
> make sure that everything that is needed often can be reached with that 
> hand’s 
> thumb without having to reposition the hand (although the aforementioned 
> research also shows that people do switch how they hold their phone whenever 
> needed).
> 
> Regardless of the way users hold their phone, research [3] shows they 
> generally are more precise in interacting with – and prefer to interact with 
> – 
> the center of the screen.
> 
> Based on these findings, the HIG recommends interaction patterns which do not 
> require users to reach for the far ends of the screen (mostly the top), but 
> give them on-demand controls near the center of the screen.
> ---
> 
> Given that, the context menu button in the top-right corner is almost in the 
> worst possible place to reach (for left-handed people, it is literally in the 
> worst possible place). Try reaching that button with your thumb when holding 
> a 
> 5"+ phone with one hand, without changing the position of the device in your 
> hand. Really, it's no fun.

So I have two 6" devices (Nexus 6p and iPhone 6+) and use both of them
single handed and have no problem reaching either corner (happy to provide
video evidence), but I will admit that I have really big hands and that I'm well
aware that this is a big problem for most people, so this is a very valid point.

> What makes it even worse is that this button is the _only_ way to open the 
> context menu on Android.
> Therefore, the first and very obvious idea was to allow users to open the 
> context drawer by swiping in from the right edge of the screen (since they do 
> not have to reach to a corner for that).
> However, we also know that not all users are comfortable with edge-swiping, 
> which is why we looked for an alternative means to open the drawers (the 
> primary way is still edge-swiping) for those people which are not.
> 
> That's where the Action Button comes into play. With Material Design, the 
> "Floating Action Button" (FAB) has become an integral part of most stock 
> Android applications (Mail, Hangouts, 
> G+, Calendar, Maps, Photos, the thing is pretty much everywhere). There, it's 
> used to execute a "main action" within an application (often creating a new 
> object, but in Maps it's navigation and in Photos it's searching).
> 
> And, interestingly enough, the Material Design guidelines place that FAB in a 
> position where it's easy to reach. So we thought "Hey, why not re-use the FAB 
> as an alternative to edge-swipes for opening the drawers?".
> And this is how this idea was born: We have a button in an easy-to-reach 
> position which doubles as a main action button and an alternative to open 
> drawers, mostly for those who can't use edge-swipe well.

Side note: I am not a huge friend of the side swipes being used for the drawers.
I find swipes a great way to do navigation. There are a bunch of email 
applications
where swiping left and right you can move to the previous / next item in your
mailbox - something that I was hoping to adapt on Subsurface-mobile: if you 
look 
at the details of a dive, swiping sideways will ge

Re: Review Request 126647: [Task Manager] Provide media controls in tooltips

[Kai Uwe Broulik]

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

(Updated Jan. 5, 2016, 11:40 nachm.)


Review request for Plasma, KDE Usability and Eike Hein.


Changes
---

Fix tooltip height for launchers


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


Repository: plasma-desktop


Description
---

This adds media player controls to the tooltip of a media player, using the 
already existing mpris dataengine this was pretty straightforward to implement.

When album art is available, no window thumbnails will be shown, instead the 
album art. There will be a close button on the album art closing the first 
window. Multiple windows for a player is uncommon and you can still access them 
all by clicking the task manager entry.

Interestingly enough, Amarok does not expose its album art through MPris. Also, 
if it wouldn't crash whilst doing so, you could control Amarok when it's main 
window is closed if you have a launcher pinned to your task manager, basically 
rendering its tray icon obsolete.


Diffs (updated)
-

  applets/taskmanager/package/contents/ui/Task.qml 2a6 
  applets/taskmanager/package/contents/ui/ToolTipDelegate.qml 972dd62 
  applets/taskmanager/package/contents/ui/ToolTipWindowMouseArea.qml 
PRE-CREATION 

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


Testing
---

Works with VLC and Audacious, does not work with Dragon as the player announces 
itself as "dragonplayer" while its Desktop file says "dragon"


File Attachments


VLC with album art
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/3058dacb-1dfd-464d-a1ec-be90bc9e58a8__mpristaskmanagerreview1.png
Amarok without album art
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/6799d6f6-d505-4f56-9531-3013a3e34ae6__mpristaskmanagerreview2.png


Thanks,

Kai Uwe Broulik

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: some feedback from a mobile application development team

[Thomas Pfeiffer]

On Dienstag, 5. Januar 2016 08:16:38 CET Dirk Hohndel wrote:
> Hi there,

Hi Dirk,
as the person in charge of the KDE Mobile HIG (and therefore also responsible 
for the usability of the Plasma Components), I'm very happy to get feedback 
from users of an actual working application using our components!

Since I am not a developer, I can only discuss our design choices, our 
developers are better suited to discuss the technical problems you 
encountered. 

So here goes my comment on the user feedback. Please bear with me, as I'll 
have to expand a bit on the reasoning behind the interaction with the action 
button:

> c) the user feedback (about 25 alpha testers on about 30 Android devices,
> we haven't gotten the iOS build to work, yet, as some of our dependency
> libraries are causing us trouble) is very negative on the action button.
> People find it very unintuitive and a solution looking for a problem.
> In my latest builds I have hacked our copy of the MobileComponents to
> simply disable the action button and instead added traditional three
> bar / three dot menus to the top bar - this was very well received with
> the testers. The context menu button (three vertical dots in the top
> right corner) only shows up when there is a contextDrawer. Tapping on
> either of the buttons opens the coresponding drawer.
> The Subsurface team would love to see an option to cleanly disable the
> action button in the MobileComponents.

First of all: It's fully understandable that Android testers like UIs the way 
that stock Android UIs are. That's what they're used to, that's what their 
muscle memory has learned.
Let me explain to you, then, why we diverged from the default Android 
behavior.
As a start, here are the relevant section from my blog post laying out the 
basic assumptions behind our design choices [1]:
---
Users prefer to interact with the center of the screen
As research [2] shows, smartphones are predominantly held upright (portrait 
mode) and in one hand, simply because that is the most convenient way to use 
it and it leaves one hand free e.g. to hold onto something while standing in a 
bus.

If we want an application to be used conveniently with one hand, we have to 
make sure that everything that is needed often can be reached with that hand’s 
thumb without having to reposition the hand (although the aforementioned 
research also shows that people do switch how they hold their phone whenever 
needed).

Regardless of the way users hold their phone, research [3] shows they 
generally are more precise in interacting with – and prefer to interact with – 
the center of the screen.

Based on these findings, the HIG recommends interaction patterns which do not 
require users to reach for the far ends of the screen (mostly the top), but 
give them on-demand controls near the center of the screen.
---

Given that, the context menu button in the top-right corner is almost in the 
worst possible place to reach (for left-handed people, it is literally in the 
worst possible place). Try reaching that button with your thumb when holding a 
5"+ phone with one hand, without changing the position of the device in your 
hand. Really, it's no fun.

What makes it even worse is that this button is the _only_ way to open the 
context menu on Android.
Therefore, the first and very obvious idea was to allow users to open the 
context drawer by swiping in from the right edge of the screen (since they do 
not have to reach to a corner for that).
However, we also know that not all users are comfortable with edge-swiping, 
which is why we looked for an alternative means to open the drawers (the 
primary way is still edge-swiping) for those people which are not.

That's where the Action Button comes into play. With Material Design, the 
"Floating Action Button" (FAB) has become an integral part of most stock 
Android applications (Mail, Hangouts, 
G+, Calendar, Maps, Photos, the thing is pretty much everywhere). There, it's 
used to execute a "main action" within an application (often creating a new 
object, but in Maps it's navigation and in Photos it's searching).

And, interestingly enough, the Material Design guidelines place that FAB in a 
position where it's easy to reach. So we thought "Hey, why not re-use the FAB 
as an alternative to edge-swipes for opening the drawers?".
And this is how this idea was born: We have a button in an easy-to-reach 
position which doubles as a main action button and an alternative to open 
drawers, mostly for those who can't use edge-swipe well.

So, dragging the Action Button is not "a solution looking for a problem", but 
in fact it is the answer to the problem that screen corners are hard to reach 
when you hold a bigger phone (which are becoming more and more common) in one 
hand.

I do agree with you, however - and this is also what I suggested within our 
team before - that on Android, people are not used to being able to drag the 
FAB, as it's inconsistent with what they expect 

Re: Review Request 126647: [Task Manager] Provide media controls in tooltips

[Kai Uwe Broulik]

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

(Updated Jan. 5, 2016, 11:21 nachm.)


Review request for Plasma, KDE Usability and Eike Hein.


Changes
---

Unbreak hit area for multiple windows


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


Repository: plasma-desktop


Description
---

This adds media player controls to the tooltip of a media player, using the 
already existing mpris dataengine this was pretty straightforward to implement.

When album art is available, no window thumbnails will be shown, instead the 
album art. There will be a close button on the album art closing the first 
window. Multiple windows for a player is uncommon and you can still access them 
all by clicking the task manager entry.

Interestingly enough, Amarok does not expose its album art through MPris. Also, 
if it wouldn't crash whilst doing so, you could control Amarok when it's main 
window is closed if you have a launcher pinned to your task manager, basically 
rendering its tray icon obsolete.


Diffs (updated)
-

  applets/taskmanager/package/contents/ui/Task.qml 2a6 
  applets/taskmanager/package/contents/ui/ToolTipDelegate.qml 972dd62 
  applets/taskmanager/package/contents/ui/ToolTipWindowMouseArea.qml 
PRE-CREATION 

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


Testing
---

Works with VLC and Audacious, does not work with Dragon as the player announces 
itself as "dragonplayer" while its Desktop file says "dragon"


File Attachments


VLC with album art
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/3058dacb-1dfd-464d-a1ec-be90bc9e58a8__mpristaskmanagerreview1.png
Amarok without album art
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/6799d6f6-d505-4f56-9531-3013a3e34ae6__mpristaskmanagerreview2.png


Thanks,

Kai Uwe Broulik

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126647: [Task Manager] Provide media controls in tooltips

[Kai Uwe Broulik]

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

(Updated Jan. 5, 2016, 11:15 nachm.)


Review request for Plasma, KDE Usability and Eike Hein.


Changes
---

* Show album art, if any
* Improve layout, show track title and artist
* While at it, I also simplified the close button to be larger
* Also split the mouse area for the tooltip delegate into a separate file
* I also changed the dialog sizing code a bit while keeping sizes as they were


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


Repository: plasma-desktop


Description (updated)
---

This adds media player controls to the tooltip of a media player, using the 
already existing mpris dataengine this was pretty straightforward to implement.

When album art is available, no window thumbnails will be shown, instead the 
album art. There will be a close button on the album art closing the first 
window. Multiple windows for a player is uncommon and you can still access them 
all by clicking the task manager entry.

Interestingly enough, Amarok does not expose its album art through MPris. Also, 
if it wouldn't crash whilst doing so, you could control Amarok when it's main 
window is closed if you have a launcher pinned to your task manager, basically 
rendering its tray icon obsolete.


Diffs (updated)
-

  applets/taskmanager/package/contents/ui/Task.qml 2a6 
  applets/taskmanager/package/contents/ui/ToolTipDelegate.qml 972dd62 
  applets/taskmanager/package/contents/ui/ToolTipWindowMouseArea.qml 
PRE-CREATION 

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


Testing
---

Works with VLC and Audacious, does not work with Dragon as the player announces 
itself as "dragonplayer" while its Desktop file says "dragon"


File Attachments (updated)


VLC with album art
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/3058dacb-1dfd-464d-a1ec-be90bc9e58a8__mpristaskmanagerreview1.png
Amarok without album art
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/6799d6f6-d505-4f56-9531-3013a3e34ae6__mpristaskmanagerreview2.png


Thanks,

Kai Uwe Broulik

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126647: [Task Manager] Provide media controls in tooltips

[Eike Hein]

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


I agree with the album art suggestion - or we could build on your composition 
approach and superimpose the album art on top with a soft shadow halo around, 
maybe.


applets/taskmanager/package/contents/ui/Task.qml (line 192)


Semicolae;



applets/taskmanager/package/contents/ui/ToolTipDelegate.qml (line 209)


Wondering how this compares to GraphicalEffects' LinearGradient



applets/taskmanager/package/contents/ui/ToolTipDelegate.qml (line 211)


I think a little bit higher in the buttons would look nicer



applets/taskmanager/package/contents/ui/ToolTipDelegate.qml (line 243)


Was wondering if this should be an icon size + margins, then again choosing 
numbers proportional to the thumbnail rect size might make more sense


- Eike Hein


On Jan. 5, 2016, 8:45 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126647/
> ---
> 
> (Updated Jan. 5, 2016, 8:45 p.m.)
> 
> 
> Review request for Plasma, KDE Usability and Eike Hein.
> 
> 
> Bugs: 352126
> https://bugs.kde.org/show_bug.cgi?id=352126
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This adds media player controls to the tooltip of a media player, using the 
> already existing mpris dataengine this was pretty straightforward to 
> implement.
> 
> In order not to change the tooltip dialog size, the controls are placed ontop 
> of the thumbnail with a little fade effect at the bottom to improve contrast.
> 
> There could be multiple grouped windows of a given player, unlikely though, 
> but it doesn't look too bad with that either.
> 
> The app in the screenshot is just for demo purposes, the buttons are disabled 
> in the screenshot, they're a darker black usually.
> The button reflects play/pause state, forward/back are disabled if not 
> possible and the controls, obviously, are only shown for tasks with an 
> associated mpris interface.
> 
> 
> Diffs
> -
> 
>   applets/taskmanager/package/contents/ui/Task.qml 2a6 
>   applets/taskmanager/package/contents/ui/ToolTipDelegate.qml 972dd62 
> 
> Diff: https://git.reviewboard.kde.org/r/126647/diff/
> 
> 
> Testing
> ---
> 
> Works with VLC and Audacious, does not work with Dragon as the player 
> announces itself as "dragonplayer" while its Desktop file says "dragon"
> 
> 
> File Attachments
> 
> 
> Tooltip with media controls
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/79c94b3c-5d64-4eb2-8cc6-1541abf28e5f__mpristaskfade.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126647: [Task Manager] Provide media controls in tooltips

[Thomas Pfeiffer]

> On Jan. 5, 2016, 9:28 p.m., Martin Klapetek wrote:
> > One idea I was thinking about for this case - why not replace
> > the audio player window thumbnail with the album cover art?
> > 
> > The window of the player is not really useful in the thumbnail;
> > it's mostly just a window with some listviews and controls anyway,
> > nothing interesting or useful. But we do have more interesting
> > data for it - showing the album art instead (if available on the
> > mpris). That would at least give some useful/nice info. Plus the
> > music players are usually minimized anyway (breaking the thumbnails).
> > 
> > Thoughts?

You know what? Kai and I were thinking the exact same thing (though with a 
bigger scope than only media players, because other applications could make 
much better use of the space than a regular thumbnail, too), so yes, it would 
be much better to show the album cover there!


- Thomas


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


On Jan. 5, 2016, 8:45 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126647/
> ---
> 
> (Updated Jan. 5, 2016, 8:45 p.m.)
> 
> 
> Review request for Plasma, KDE Usability and Eike Hein.
> 
> 
> Bugs: 352126
> https://bugs.kde.org/show_bug.cgi?id=352126
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This adds media player controls to the tooltip of a media player, using the 
> already existing mpris dataengine this was pretty straightforward to 
> implement.
> 
> In order not to change the tooltip dialog size, the controls are placed ontop 
> of the thumbnail with a little fade effect at the bottom to improve contrast.
> 
> There could be multiple grouped windows of a given player, unlikely though, 
> but it doesn't look too bad with that either.
> 
> The app in the screenshot is just for demo purposes, the buttons are disabled 
> in the screenshot, they're a darker black usually.
> The button reflects play/pause state, forward/back are disabled if not 
> possible and the controls, obviously, are only shown for tasks with an 
> associated mpris interface.
> 
> 
> Diffs
> -
> 
>   applets/taskmanager/package/contents/ui/Task.qml 2a6 
>   applets/taskmanager/package/contents/ui/ToolTipDelegate.qml 972dd62 
> 
> Diff: https://git.reviewboard.kde.org/r/126647/diff/
> 
> 
> Testing
> ---
> 
> Works with VLC and Audacious, does not work with Dragon as the player 
> announces itself as "dragonplayer" while its Desktop file says "dragon"
> 
> 
> File Attachments
> 
> 
> Tooltip with media controls
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/79c94b3c-5d64-4eb2-8cc6-1541abf28e5f__mpristaskfade.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: robots.txt in quickgit.kde.org

[Ben Cooksley]

On Wed, Jan 6, 2016 at 3:17 AM, Kevin Funk  wrote:
> On Wednesday, December 30, 2015 12:57:23 PM Ben Cooksley wrote:
>> On Tue, Dec 29, 2015 at 11:16 PM, Kevin Funk  wrote:
>> > On Tuesday, December 29, 2015 10:39:01 PM Ben Cooksley wrote:
>> >> On Tue, Dec 29, 2015 at 7:59 AM, Lydia Pintscher  wrote:
>> >> > On Sun, Dec 27, 2015 at 12:35 PM, Ben Cooksley 
> wrote:
>> >> >>> Is there some place where search engines can easily index our source
>> >> >>> code or are we shooting ourselves in the foot here?
>> >> >>
>> >> >> We could probably make it available by publishing the source trees
>> >> >> used by LXR / EBN.
>> >> >> This would only have the main branches obviously rather than
>> >> >> everything
>> >> >> though.
>> >> >>
>> >> >> I haven't checked, but LXR may already make it's copy of the code
>> >> >> accessible...>
>> >> >
>> >> > I think making our sourcecode available to search engines is pretty
>> >> > important for the reasons already mentioned by others. Do you need
>> >> > help for it? If you write down what's needed I can help find someone
>> >> > to do it.
>> >>
>> >> I've now provisioned https://sources.kde.org/
>> >
>> > I'm not sure this is super useful, to be honest (as mentioned in #kde-
>> > sysadmins already).
>> >
>> > This is really just plain file serving, with no cross-references to either
>> > LXR (or apidocs). This is basically a dead-end when you follow a result
>> > on Google.
>> >
>> > Wouldn't it be possible to let robots index https://lxr.kde.org/source/
>> >
>> >  instead? We have the infrastructure...
>>
>> We'll give it a shot.
>
> Just to stress again this would be *really* useful to have.



>
> I answered a post on SO:
>   http://stackoverflow.com/a/34612692/592636
>
> Tried to link kwallet's FindGpgpme.cmake into the answer; and there's *no*
> easy way quickly get a link to KDE infrastructure serving the file via Google
> (not even api.kde.org).
>
> Try googling for "kwallet findgpgme.cmake" (very specific search after all):
>   https://www.google.de/search?q=kwallet+findgpgme.cmake
>
> -> First result: Github..., rest: mildly interesting
>
>
> Different issue I just noticed: There's no way to get the plain-text (raw)
> representation of a given file on LXR, is there? Would be useful as well.

There isn't a link in our templates, but my Google fu (and subsequent
tests confirm) that adding the parameter "_raw=1" to a LXR source view
URL will return the file without any HTML around it.

>
> Cheers,
> Kevin

Regards,
Ben

>
>> > Of course we need to blacklist all the pages allowing to actively *search*
>> > LXR for robots, in order to avoid abuse.
>>
>> Note that despite robots.txt, many spiders (including Google, Yahoo
>> and Bing) will actively disregard the instructions in there.
>> While they may not return the results - or omit snippets of the page
>> content - they have all been guilty (at least in the past) of
>> disregarding our restrictions, resulting in downtime (which have in
>> some cases necessitated full host reboots to fix) for numerous KDE.org
>> subsites in the past.
>>
>> This is why QuickGit and WebSVN have extremely restrictive robots.txt
>> policies, in addition to blacklist rules within our web server
>> configurations.
>>
>> > Cheers,
>> > Kevin
>>
>> Regards,
>> Ben
>>
>> >> > Cheers
>> >> > Lydia
>> >>
>> >> Regards,
>> >> Ben
>> >>
>> >> > --
>> >> > Lydia Pintscher - http://about.me/lydia.pintscher
>> >> > KDE e.V. Board of Directors / KDE Community Working Group
>> >> > http://kde.org - http://open-advice.org
>> >> >
>> >> >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
>> >> >>> unsubscribe <<>>
>> >> >>
>> >> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
>> >> >> unsubscribe
>> >> >> <<
>> >
>> > --
>> > Kevin Funk | kf...@kde.org | http://kfunk.org
>
> --
> Kevin Funk | kf...@kde.org | http://kfunk.org
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126647: [Task Manager] Provide media controls in tooltips

[Martin Klapetek]

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


One idea I was thinking about for this case - why not replace
the audio player window thumbnail with the album cover art?

The window of the player is not really useful in the thumbnail;
it's mostly just a window with some listviews and controls anyway,
nothing interesting or useful. But we do have more interesting
data for it - showing the album art instead (if available on the
mpris). That would at least give some useful/nice info. Plus the
music players are usually minimized anyway (breaking the thumbnails).

Thoughts?

- Martin Klapetek


On Jan. 5, 2016, 9:45 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126647/
> ---
> 
> (Updated Jan. 5, 2016, 9:45 p.m.)
> 
> 
> Review request for Plasma, KDE Usability and Eike Hein.
> 
> 
> Bugs: 352126
> https://bugs.kde.org/show_bug.cgi?id=352126
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This adds media player controls to the tooltip of a media player, using the 
> already existing mpris dataengine this was pretty straightforward to 
> implement.
> 
> In order not to change the tooltip dialog size, the controls are placed ontop 
> of the thumbnail with a little fade effect at the bottom to improve contrast.
> 
> There could be multiple grouped windows of a given player, unlikely though, 
> but it doesn't look too bad with that either.
> 
> The app in the screenshot is just for demo purposes, the buttons are disabled 
> in the screenshot, they're a darker black usually.
> The button reflects play/pause state, forward/back are disabled if not 
> possible and the controls, obviously, are only shown for tasks with an 
> associated mpris interface.
> 
> 
> Diffs
> -
> 
>   applets/taskmanager/package/contents/ui/Task.qml 2a6 
>   applets/taskmanager/package/contents/ui/ToolTipDelegate.qml 972dd62 
> 
> Diff: https://git.reviewboard.kde.org/r/126647/diff/
> 
> 
> Testing
> ---
> 
> Works with VLC and Audacious, does not work with Dragon as the player 
> announces itself as "dragonplayer" while its Desktop file says "dragon"
> 
> 
> File Attachments
> 
> 
> Tooltip with media controls
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/79c94b3c-5d64-4eb2-8cc6-1541abf28e5f__mpristaskfade.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins-kde-ci: plasma-workspace Plasma-5.5 stable-kf5-qt5 » Linux,gcc - Build # 33 - Still Failing!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/plasma-workspace%20Plasma-5.5%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/33/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 05 Jan 2016 19:50:14 +
Build duration: 1 min 55 sec

CHANGE SET
Revision 80ccb1c88d41752fb41032e9c3f88360281571a3 by kde: ([KUIserver] Return 
the proper value)
  change: edit kuiserver/jobview.cpp
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 126647: [Task Manager] Provide media controls in tooltips

[Kai Uwe Broulik]

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

Review request for Plasma, KDE Usability and Eike Hein.


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


Repository: plasma-desktop


Description
---

This adds media player controls to the tooltip of a media player, using the 
already existing mpris dataengine this was pretty straightforward to implement.

In order not to change the tooltip dialog size, the controls are placed ontop 
of the thumbnail with a little fade effect at the bottom to improve contrast.

There could be multiple grouped windows of a given player, unlikely though, but 
it doesn't look too bad with that either.

The app in the screenshot is just for demo purposes, the buttons are disabled 
in the screenshot, they're a darker black usually.
The button reflects play/pause state, forward/back are disabled if not possible 
and the controls, obviously, are only shown for tasks with an associated mpris 
interface.


Diffs
-

  applets/taskmanager/package/contents/ui/Task.qml 2a6 
  applets/taskmanager/package/contents/ui/ToolTipDelegate.qml 972dd62 

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


Testing
---

Works with VLC and Audacious, does not work with Dragon as the player announces 
itself as "dragonplayer" while its Desktop file says "dragon"


File Attachments


Tooltip with media controls
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/79c94b3c-5d64-4eb2-8cc6-1541abf28e5f__mpristaskfade.png


Thanks,

Kai Uwe Broulik

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126621: [Task Manager] Add support for Unity Launcher API and Application Jobs

[Eike Hein]

> On Jan. 4, 2016, 11:01 p.m., Eike Hein wrote:
> > Ship It!
> 
> Kai Uwe Broulik wrote:
> I need a proper frame graphic, "hover" isn't particularly good but I 
> don't want to mess around with the tasks.svgz due to Review 126373
> 
> Kai Uwe Broulik wrote:
> What am I supposed to do in this case: the desktop file is 
> "org.kde.dolphin.desktop" but the qApp applicationName is "dolphin" (which is 
> what JobViewServer tells us as app name) and so the mapping fails because 
> KService::serviceFromStorageId("dolphin") doesn't work now.

This is more or less a variant of the problem libtaskmanager faces when trying 
to map WM_CLASS to .desktop files, so you can find some code there. We've (Ivan 
+ me) struggled with this with KActivities too however and the best we came up 
with so far is the awful storageIdFromService() in Kicker's actionlist.cpp.


- Eike


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


On Jan. 4, 2016, 10:50 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126621/
> ---
> 
> (Updated Jan. 4, 2016, 10:50 p.m.)
> 
> 
> Review request for Plasma, KDE Usability, Craig Drummond, Eike Hein, and 
> Lukáš Tinkl.
> 
> 
> Bugs: 343632
> https://bugs.kde.org/show_bug.cgi?id=343632
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This adds support for the Unity Launcher API [1] with which applications can 
> show a progress indicator, a number badge as well as demand the user's 
> attention. It also shows application progress (such as copying a file) with 
> the respective application.
> 
> This functionality has been present in the Icon Tasks applet [2] in Plasma 4 
> times. libunity must be present for most applications to actually use this.
> 
> I did not want to pollute libtaskmanager with this, so I made it a plugin in 
> the Task Manager applet, which should also be fairly trivial to update to the 
> new Launcher API that Unity 8 is going to use [3], or if we come up with our 
> own solution at some point, maybe.
> 
> The primary focus is still the icons only task manager as the Unity API works 
> on a per-application/per-launcher basis rather than per-window, however, 
> where it makes sense the functonality is also offered to the traditional task 
> manager. A downside of this is that (in the current implementation, anyways) 
> in case you do not group your tasks and you have multiple windows of the same 
> task open, it will show the same information on all entries.
> 
> For progress it gradually fills up the background of the task (VDG: I need a 
> better graphic here, I currently abuse the "hover" tasks SVG, also I find the 
> "+2" badge less than optimal) in all cases. The badges are only shown if 1) 
> the cell is large enough 2) the label is *not* shown (ie. icon tasks manager 
> or the regular one in very narrow). The badge is just a circle in theme 
> highlight color, not an actual SVG - it cuts off part of the icon to provide 
> more contrast. The "urgent" state just highlights the entry as if it 
> requested attention, there's no wiggle animation and this is nowhere 
> integrated with the window manager, also I did not find an application that 
> used this, so I have no idea how it's used by them.
> 
> A video with the regular task manager on the top, a regular task manager and 
> an icon tasks applet in the left panel and an icon tasks applet on the 
> desktop (the latter is broken in the video, fixed in this patch) can be found 
> here [4].
> 
> (There's still a ton of qDebug in the code at this point)
> 
> [1] https://wiki.ubuntu.com/Unity/LauncherAPI
> [2] http://kde-apps.org/content/show.php/Icon+Tasks?content=144808
> [3] 
> http://bazaar.launchpad.net/~unity-team/unity8/trunk/files/head:/plugins/Unity/Launcher/
> [4] https://www.youtube.com/watch?v=aBPGjlP6Wd8
> 
> 
> Diffs
> -
> 
>   applets/taskmanager/CMakeLists.txt 3c94cb7 
>   applets/taskmanager/package/contents/config/main.xml f89fd51 
>   applets/taskmanager/package/contents/ui/ConfigGeneral.qml bd97506 
>   applets/taskmanager/package/contents/ui/Task.qml 2a6 
>   applets/taskmanager/package/contents/ui/TaskBadgeOverlay.qml PRE-CREATION 
>   applets/taskmanager/package/contents/ui/TaskProgressOverlay.qml 
> PRE-CREATION 
>   applets/taskmanager/plugin/smartlaunchers/smartlauncherbackend.h 
> PRE-CREATION 
>   applets/taskmanager/plugin/smartlaunchers/smartlauncherbackend.cpp 
> PRE-CREATION 
>   applets/taskmanager/plugin/smartlaunchers/smartlauncheritem.h PRE-CREATION 
>   applets/taskmanager/plugin/smartlaunchers/smartlauncheritem.cpp 
> PRE-CREATION 
>   applets/taskmanager/plugin/taskmanager

Re: Review Request 126621: [Task Manager] Add support for Unity Launcher API and Application Jobs

[Kai Uwe Broulik]

> On Jan. 4, 2016, 11:01 nachm., Eike Hein wrote:
> > Ship It!
> 
> Kai Uwe Broulik wrote:
> I need a proper frame graphic, "hover" isn't particularly good but I 
> don't want to mess around with the tasks.svgz due to Review 126373

What am I supposed to do in this case: the desktop file is 
"org.kde.dolphin.desktop" but the qApp applicationName is "dolphin" (which is 
what JobViewServer tells us as app name) and so the mapping fails because 
KService::serviceFromStorageId("dolphin") doesn't work now.


- Kai Uwe


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


On Jan. 4, 2016, 10:50 nachm., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126621/
> ---
> 
> (Updated Jan. 4, 2016, 10:50 nachm.)
> 
> 
> Review request for Plasma, KDE Usability, Craig Drummond, Eike Hein, and 
> Lukáš Tinkl.
> 
> 
> Bugs: 343632
> https://bugs.kde.org/show_bug.cgi?id=343632
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This adds support for the Unity Launcher API [1] with which applications can 
> show a progress indicator, a number badge as well as demand the user's 
> attention. It also shows application progress (such as copying a file) with 
> the respective application.
> 
> This functionality has been present in the Icon Tasks applet [2] in Plasma 4 
> times. libunity must be present for most applications to actually use this.
> 
> I did not want to pollute libtaskmanager with this, so I made it a plugin in 
> the Task Manager applet, which should also be fairly trivial to update to the 
> new Launcher API that Unity 8 is going to use [3], or if we come up with our 
> own solution at some point, maybe.
> 
> The primary focus is still the icons only task manager as the Unity API works 
> on a per-application/per-launcher basis rather than per-window, however, 
> where it makes sense the functonality is also offered to the traditional task 
> manager. A downside of this is that (in the current implementation, anyways) 
> in case you do not group your tasks and you have multiple windows of the same 
> task open, it will show the same information on all entries.
> 
> For progress it gradually fills up the background of the task (VDG: I need a 
> better graphic here, I currently abuse the "hover" tasks SVG, also I find the 
> "+2" badge less than optimal) in all cases. The badges are only shown if 1) 
> the cell is large enough 2) the label is *not* shown (ie. icon tasks manager 
> or the regular one in very narrow). The badge is just a circle in theme 
> highlight color, not an actual SVG - it cuts off part of the icon to provide 
> more contrast. The "urgent" state just highlights the entry as if it 
> requested attention, there's no wiggle animation and this is nowhere 
> integrated with the window manager, also I did not find an application that 
> used this, so I have no idea how it's used by them.
> 
> A video with the regular task manager on the top, a regular task manager and 
> an icon tasks applet in the left panel and an icon tasks applet on the 
> desktop (the latter is broken in the video, fixed in this patch) can be found 
> here [4].
> 
> (There's still a ton of qDebug in the code at this point)
> 
> [1] https://wiki.ubuntu.com/Unity/LauncherAPI
> [2] http://kde-apps.org/content/show.php/Icon+Tasks?content=144808
> [3] 
> http://bazaar.launchpad.net/~unity-team/unity8/trunk/files/head:/plugins/Unity/Launcher/
> [4] https://www.youtube.com/watch?v=aBPGjlP6Wd8
> 
> 
> Diffs
> -
> 
>   applets/taskmanager/CMakeLists.txt 3c94cb7 
>   applets/taskmanager/package/contents/config/main.xml f89fd51 
>   applets/taskmanager/package/contents/ui/ConfigGeneral.qml bd97506 
>   applets/taskmanager/package/contents/ui/Task.qml 2a6 
>   applets/taskmanager/package/contents/ui/TaskBadgeOverlay.qml PRE-CREATION 
>   applets/taskmanager/package/contents/ui/TaskProgressOverlay.qml 
> PRE-CREATION 
>   applets/taskmanager/plugin/smartlaunchers/smartlauncherbackend.h 
> PRE-CREATION 
>   applets/taskmanager/plugin/smartlaunchers/smartlauncherbackend.cpp 
> PRE-CREATION 
>   applets/taskmanager/plugin/smartlaunchers/smartlauncheritem.h PRE-CREATION 
>   applets/taskmanager/plugin/smartlaunchers/smartlauncheritem.cpp 
> PRE-CREATION 
>   applets/taskmanager/plugin/taskmanagerplugin.cpp 1be1fed 
> 
> Diff: https://git.reviewboard.kde.org/r/126621/diff/
> 
> 
> Testing
> ---
> 
> I started a download in Chromium and got progress as well as a badge 
> indicating how many download jobs were in progress. Thunderbird also 
> registered a launcher on DBus but it never actually set a badge although I 
> had unread mail. 

Re: Review Request 126637: IconItem: Add animated property

[David Rosca]

> On Jan. 5, 2016, 1:56 p.m., David Edmundson wrote:
> > +1 from me
> > 
> > Though AFIAK Kai was doing something related here too?
> 
> David Rosca wrote:
> Yes, but that is only to disable the animation when showing the IconItem 
> after being hidden.
> This completely disables the animation, which I think would be useful in 
> some cases (eg. as Heike mentioned in the Kai's review, for kicker).
> 
> I'd like to disable the icon animation for tooltips completely (which 
> I'll post in next review).
> 
> Eike Hein wrote:
> *Eike, nice work though

Oh, sorry.


- David


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


On Jan. 5, 2016, 12:52 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126637/
> ---
> 
> (Updated Jan. 5, 2016, 12:52 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Add property animated, that allows to disable cross-fade animation when 
> changing icon (enabled by default).
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/iconitem.h 366edf3 
>   src/declarativeimports/core/iconitem.cpp db15d0f 
> 
> Diff: https://git.reviewboard.kde.org/r/126637/diff/
> 
> 
> Testing
> ---
> 
> Setting `animated: false` disables the animation.
> 
> 
> Thanks,
> 
> David Rosca
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126637: IconItem: Add animated property

[Eike Hein]

> On Jan. 5, 2016, 1:56 p.m., David Edmundson wrote:
> > +1 from me
> > 
> > Though AFIAK Kai was doing something related here too?
> 
> David Rosca wrote:
> Yes, but that is only to disable the animation when showing the IconItem 
> after being hidden.
> This completely disables the animation, which I think would be useful in 
> some cases (eg. as Heike mentioned in the Kai's review, for kicker).
> 
> I'd like to disable the icon animation for tooltips completely (which 
> I'll post in next review).

*Eike, nice work though


- Eike


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


On Jan. 5, 2016, 12:52 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126637/
> ---
> 
> (Updated Jan. 5, 2016, 12:52 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Add property animated, that allows to disable cross-fade animation when 
> changing icon (enabled by default).
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/iconitem.h 366edf3 
>   src/declarativeimports/core/iconitem.cpp db15d0f 
> 
> Diff: https://git.reviewboard.kde.org/r/126637/diff/
> 
> 
> Testing
> ---
> 
> Setting `animated: false` disables the animation.
> 
> 
> Thanks,
> 
> David Rosca
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126642: [Theme] Take Plasma Framework version into account in theme cache

[David Edmundson]

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


I don't really understand the problem this is solving.
This wont' solve the problem of downstreams doing their own themes and failing 
to update their version numbers properly unless they always release at the same 
time as plasma-framework.

- David Edmundson


On Jan. 5, 2016, 6:11 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126642/
> ---
> 
> (Updated Jan. 5, 2016, 6:11 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> We have the version number of the theme and some mtime heuristic yet still we 
> often end up with a broken theme after upgrades when it is changed, when 
> downstreams forget to adjust the version in their theme and so on.
> 
> (I just noticed I never delete the old theme caches...)
> 
> 
> Diffs
> -
> 
>   src/plasma/private/theme_p.cpp 18419bb 
> 
> Diff: https://git.reviewboard.kde.org/r/126642/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 126642: [Theme] Take Plasma Framework version into account in theme cache

[Kai Uwe Broulik]

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

Review request for Plasma.


Repository: plasma-framework


Description
---

We have the version number of the theme and some mtime heuristic yet still we 
often end up with a broken theme after upgrades when it is changed, when 
downstreams forget to adjust the version in their theme and so on.

(I just noticed I never delete the old theme caches...)


Diffs
-

  src/plasma/private/theme_p.cpp 18419bb 

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


Testing
---


Thanks,

Kai Uwe Broulik

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126641: [Units] scale desktop icon sizes

[David Edmundson]

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



src/declarativeimports/core/units.cpp (line 119)


this comment appears to be a great big lie?


- David Edmundson


On Jan. 5, 2016, 5:41 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126641/
> ---
> 
> (Updated Jan. 5, 2016, 5:41 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Given with Qt high dpi support manually adjusting the icon sizes to match is 
> mostly obsolete because the applications do that, we should do the same in 
> Plasma.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/units.cpp fa34772 
> 
> Diff: https://git.reviewboard.kde.org/r/126641/diff/
> 
> 
> Testing
> ---
> 
> I no longer get tiny icons in Task Manager tooltips
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126641: [Units] scale desktop icon sizes

[Kai Uwe Broulik]

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

(Updated Jan. 5, 2016, 5:41 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit 073e7ec7ae9821c232ff16f55f514eb1b9e7d6f5 by Kai Uwe 
Broulik to branch master.


Repository: plasma-framework


Description
---

Given with Qt high dpi support manually adjusting the icon sizes to match is 
mostly obsolete because the applications do that, we should do the same in 
Plasma.


Diffs
-

  src/declarativeimports/core/units.cpp fa34772 

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


Testing
---

I no longer get tiny icons in Task Manager tooltips


Thanks,

Kai Uwe Broulik

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126641: [Units] scale desktop icon sizes

[Sebastian Kügler]

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

Ship it!


Hm, that was the idea all along, and I recall having already done this. I 
wonder how and why that code got removed...

- Sebastian Kügler


On Jan. 5, 2016, 5:26 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126641/
> ---
> 
> (Updated Jan. 5, 2016, 5:26 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Given with Qt high dpi support manually adjusting the icon sizes to match is 
> mostly obsolete because the applications do that, we should do the same in 
> Plasma.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/units.cpp fa34772 
> 
> Diff: https://git.reviewboard.kde.org/r/126641/diff/
> 
> 
> Testing
> ---
> 
> I no longer get tiny icons in Task Manager tooltips
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 126641: [Units] scale desktop icon sizes

[Kai Uwe Broulik]

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

Review request for Plasma.


Repository: plasma-framework


Description
---

Given with Qt high dpi support manually adjusting the icon sizes to match is 
mostly obsolete because the applications do that, we should do the same in 
Plasma.


Diffs
-

  src/declarativeimports/core/units.cpp fa34772 

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


Testing
---

I no longer get tiny icons in Task Manager tooltips


Thanks,

Kai Uwe Broulik

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126636: TaskManager: Enable vertical scroll in tooltip

[Kai Uwe Broulik]

> On Jan. 5, 2016, 2:02 nachm., David Edmundson wrote:
> > applets/taskmanager/package/contents/ui/ToolTipDelegate.qml, line 62
> > 
> >
> > I'm a bit confused.
> > 
> > We explicitly disable interactive (scrolling) on the scrollArea
> > 
> > then we put a mouse area on top which forwards scroll events to the 
> > scroll area.
> 
> David Rosca wrote:
> This translates vertical scroll to horizontal. It only actually scrolls 
> when the ScrollArea is interactive = when all windows don't fit in tooltip.
> 
> Marco Martin wrote:
> if a flickable has only horizontal scrolling enabled, iirc the mouse 
> wheel will scroll horizontally?
> 
> David Rosca wrote:
> It doesn't, at least not for me (Qt 5.6).

> if a flickable has only horizontal scrolling enabled, iirc the mouse wheel 
> will scroll horizontally?

Unfortunately not, this is also an issue in the Lock Screen, reported here 
https://bugreports.qt.io/browse/QTBUG-47579


- Kai Uwe


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


On Jan. 5, 2016, 12:52 nachm., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126636/
> ---
> 
> (Updated Jan. 5, 2016, 12:52 nachm.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> Enable vertical scroll for windows ScrollArea.
> 
> 
> Diffs
> -
> 
>   applets/taskmanager/package/contents/ui/ToolTipDelegate.qml 972dd62 
> 
> Diff: https://git.reviewboard.kde.org/r/126636/diff/
> 
> 
> Testing
> ---
> 
> Scrolling works
> 
> 
> Thanks,
> 
> David Rosca
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126636: TaskManager: Enable vertical scroll in tooltip

[David Rosca]

> On Jan. 5, 2016, 2:02 p.m., David Edmundson wrote:
> > applets/taskmanager/package/contents/ui/ToolTipDelegate.qml, line 62
> > 
> >
> > I'm a bit confused.
> > 
> > We explicitly disable interactive (scrolling) on the scrollArea
> > 
> > then we put a mouse area on top which forwards scroll events to the 
> > scroll area.
> 
> David Rosca wrote:
> This translates vertical scroll to horizontal. It only actually scrolls 
> when the ScrollArea is interactive = when all windows don't fit in tooltip.
> 
> Marco Martin wrote:
> if a flickable has only horizontal scrolling enabled, iirc the mouse 
> wheel will scroll horizontally?

It doesn't, at least not for me (Qt 5.6).


- David


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


On Jan. 5, 2016, 12:52 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126636/
> ---
> 
> (Updated Jan. 5, 2016, 12:52 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> Enable vertical scroll for windows ScrollArea.
> 
> 
> Diffs
> -
> 
>   applets/taskmanager/package/contents/ui/ToolTipDelegate.qml 972dd62 
> 
> Diff: https://git.reviewboard.kde.org/r/126636/diff/
> 
> 
> Testing
> ---
> 
> Scrolling works
> 
> 
> Thanks,
> 
> David Rosca
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126636: TaskManager: Enable vertical scroll in tooltip

[Marco Martin]

> On Jan. 5, 2016, 2:02 p.m., David Edmundson wrote:
> > applets/taskmanager/package/contents/ui/ToolTipDelegate.qml, line 62
> > 
> >
> > I'm a bit confused.
> > 
> > We explicitly disable interactive (scrolling) on the scrollArea
> > 
> > then we put a mouse area on top which forwards scroll events to the 
> > scroll area.
> 
> David Rosca wrote:
> This translates vertical scroll to horizontal. It only actually scrolls 
> when the ScrollArea is interactive = when all windows don't fit in tooltip.

if a flickable has only horizontal scrolling enabled, iirc the mouse wheel will 
scroll horizontally?


- Marco


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


On Jan. 5, 2016, 12:52 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126636/
> ---
> 
> (Updated Jan. 5, 2016, 12:52 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> Enable vertical scroll for windows ScrollArea.
> 
> 
> Diffs
> -
> 
>   applets/taskmanager/package/contents/ui/ToolTipDelegate.qml 972dd62 
> 
> Diff: https://git.reviewboard.kde.org/r/126636/diff/
> 
> 
> Testing
> ---
> 
> Scrolling works
> 
> 
> Thanks,
> 
> David Rosca
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

some feedback from a mobile application development team

[Dirk Hohndel]

Hi there,

I just subscribed so please bear with me if I'm going over things that
have been discussed.

Some background for context:

Subsurface is a reasonably popular open source dive log program aimed
primarily at scuba divers. It's somewhat known in open source circles as
it was started by Linus Torvalds, but for the past three years I have been
the maintainer. Two years ago we got some public interest again because we
switched from Gtk to Qt - we are now Qt5 based.

Last spring we started working on a mobile version. Early attempts were
done as part of the Google Summer of Code by a student, then thankfully
Sebastian decided to help us out and the mobile app took a huge leap
forward to the point that it's starting to be usable.

When doing that Sebastian used the plasma MobileComponents and implemented
what I understand to be the Plasma mobile interface defaults.

Right now the Subsurface team has run into a few issues with the
components (I think we may no longer be in sync with upstream which is in
part why I joined this mailing list).

a) the context drawer on some devices ends up being too narrow. We have a
patch for that

b) the shading of the icons causes them to be rendered as black squares on
some Android devices (likely because of buggy GLES drivers). Right now we
just commented out the gamma setting - I believe this has been discussed
here recently

c) the user feedback (about 25 alpha testers on about 30 Android devices,
we haven't gotten the iOS build to work, yet, as some of our dependency
libraries are causing us trouble) is very negative on the action button.
People find it very unintuitive and a solution looking for a problem.
In my latest builds I have hacked our copy of the MobileComponents to
simply disable the action button and instead added traditional three
bar / three dot menus to the top bar - this was very well received with
the testers. The context menu button (three vertical dots in the top
right corner) only shows up when there is a contextDrawer. Tapping on 
either of the buttons opens the coresponding drawer.
The Subsurface team would love to see an option to cleanly disable the
action button in the MobileComponents.

I will talk to Sebastian about synching our code base with upstream again
and hope that I can help contribute to the upstream project.

Thanks

/D
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins-kde-ci: plasma-workspace Plasma-5.5 stable-kf5-qt5 » Linux,gcc - Build # 32 - Still Failing!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/plasma-workspace%20Plasma-5.5%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/32/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 05 Jan 2016 16:03:01 +
Build duration: 1 min 52 sec

CHANGE SET
Revision cccf297b25f8d03903d24ff048819295fdae6381 by scripty: (SVN_SILENT made 
messages (.desktop file))
  change: edit applets/systemmonitor/diskactivity/metadata.desktop
  change: edit applets/systemmonitor/diskusage/metadata.desktop
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126632: add a "Complementary" color scheme to kcolorscheme

[Aleix Pol Gonzalez]

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


+1 makes sense to me.

- Aleix Pol Gonzalez


On Jan. 5, 2016, 12:16 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126632/
> ---
> 
> (Updated Jan. 5, 2016, 12:16 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kconfigwidgets
> 
> 
> Description
> ---
> 
> Since some releases, plasma-frameworks locally expands kcolorscheme to have a 
> new "Complementary" section: this is done for things like the lockscreen and 
> the logout ui, where the colors are flipped from the current theme.
> A local extension there is kinda unfortunate as makes the color configs files 
> not completely compatible, and I think there is an use case for this in 
> normal applications as well (Gwenview switches to a dark palette when in 
> fullscreen mode for instance)
> Since I want to make the default plasma theme follow the system color scheme, 
> I would need for it to support this "complementary" area as well.
> 
> 
> Diffs
> -
> 
>   src/kcolorscheme.h 22bc21b 
>   src/kcolorscheme.cpp 427ffa4 
> 
> Diff: https://git.reviewboard.kde.org/r/126632/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 126640: [WindowThumbnail] Discard pixmap on map events.

[Mihail Ivchenko]

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

Review request for Plasma.


Repository: plasma-framework


Description
---

According to [X.org 
docs](http://www.x.org/releases/X11R7.7/doc/compositeproto/compositeproto.txt) 
regarding NameWindowPixmap:

"This pixmap will remain allocated until freed, even if 'window' is unmapped, 
reconfigured or destroyed. However, 'window' will get a new pixmap allocated 
each time it is mapped or resized, so this request will need to be reinvoked"

So, pixmap needs to be discarded not only on XCB_CONFIGURE_NOTIFY event but on 
XCB_MAP_NOTIFY event also.


Diffs
-

  src/declarativeimports/core/windowthumbnail.cpp 21e655e 

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


Testing
---

Tested by using simple qml app with WindowThumbnail and minimizing\unminimizing 
of corresponding window. Now after unminimizing pixmap is still valid and live 
updating works.


Thanks,

Mihail Ivchenko

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126636: TaskManager: Enable vertical scroll in tooltip

[David Rosca]

> On Jan. 5, 2016, 2:02 p.m., David Edmundson wrote:
> > applets/taskmanager/package/contents/ui/ToolTipDelegate.qml, line 62
> > 
> >
> > I'm a bit confused.
> > 
> > We explicitly disable interactive (scrolling) on the scrollArea
> > 
> > then we put a mouse area on top which forwards scroll events to the 
> > scroll area.

This translates vertical scroll to horizontal. It only actually scrolls when 
the ScrollArea is interactive = when all windows don't fit in tooltip.


- David


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


On Jan. 5, 2016, 12:52 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126636/
> ---
> 
> (Updated Jan. 5, 2016, 12:52 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> Enable vertical scroll for windows ScrollArea.
> 
> 
> Diffs
> -
> 
>   applets/taskmanager/package/contents/ui/ToolTipDelegate.qml 972dd62 
> 
> Diff: https://git.reviewboard.kde.org/r/126636/diff/
> 
> 
> Testing
> ---
> 
> Scrolling works
> 
> 
> Thanks,
> 
> David Rosca
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5.6 schedule

[Jonathan Riddell]

No comments on this so let's go with it

Jonathan


On Sat, Dec 26, 2015 at 04:07:46PM +, Jonathan Riddell wrote:
> Here's a proposed schedule for Plasma 5.6 as discussed at the kickoff meeting
> 
> https://techbase.kde.org/Schedules/Plasma_5
> https://calendar.google.com/calendar/embed?src=031gkgqg1hjf8lcmj0em1d2sj8%40group.calendar.google.com&ctz=Europe/London
> 
> Frameworks tag is Feb 6th for Frameworks 5.19
> Repo freeze Feb 18th
> Beta is March 3rd
> Plasma sprint schedules for 7-13 March
> 5.6.0 tag on Thu 17 March
> and then fibbonachi sequence bugfixes releases at 1 week, 1 week, 2
> weeks, 3 weeks, 5 weeks
> 
> Jonathan
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126636: TaskManager: Enable vertical scroll in tooltip

[David Rosca]

> On Jan. 5, 2016, 2:02 p.m., David Edmundson wrote:
> > how do you get a situation where you need vertical scrolling?

I want to scroll with mouse wheel (vertical) through all windows. Without this 
patch, I must scroll horizontally, which is slow on my mouse and also not every 
mouse even can scroll horizontally.


- David


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


On Jan. 5, 2016, 12:52 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126636/
> ---
> 
> (Updated Jan. 5, 2016, 12:52 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> Enable vertical scroll for windows ScrollArea.
> 
> 
> Diffs
> -
> 
>   applets/taskmanager/package/contents/ui/ToolTipDelegate.qml 972dd62 
> 
> Diff: https://git.reviewboard.kde.org/r/126636/diff/
> 
> 
> Testing
> ---
> 
> Scrolling works
> 
> 
> Thanks,
> 
> David Rosca
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126637: IconItem: Add animated property

[David Rosca]

> On Jan. 5, 2016, 1:56 p.m., David Edmundson wrote:
> > +1 from me
> > 
> > Though AFIAK Kai was doing something related here too?

Yes, but that is only to disable the animation when showing the IconItem after 
being hidden.
This completely disables the animation, which I think would be useful in some 
cases (eg. as Heike mentioned in the Kai's review, for kicker).

I'd like to disable the icon animation for tooltips completely (which I'll post 
in next review).


- David


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


On Jan. 5, 2016, 12:52 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126637/
> ---
> 
> (Updated Jan. 5, 2016, 12:52 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Add property animated, that allows to disable cross-fade animation when 
> changing icon (enabled by default).
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/iconitem.h 366edf3 
>   src/declarativeimports/core/iconitem.cpp db15d0f 
> 
> Diff: https://git.reviewboard.kde.org/r/126637/diff/
> 
> 
> Testing
> ---
> 
> Setting `animated: false` disables the animation.
> 
> 
> Thanks,
> 
> David Rosca
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126636: TaskManager: Enable vertical scroll in tooltip

[David Edmundson]

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


how do you get a situation where you need vertical scrolling?


applets/taskmanager/package/contents/ui/ToolTipDelegate.qml (line 62)


I'm a bit confused.

We explicitly disable interactive (scrolling) on the scrollArea

then we put a mouse area on top which forwards scroll events to the scroll 
area.


- David Edmundson


On Jan. 5, 2016, 12:52 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126636/
> ---
> 
> (Updated Jan. 5, 2016, 12:52 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> Enable vertical scroll for windows ScrollArea.
> 
> 
> Diffs
> -
> 
>   applets/taskmanager/package/contents/ui/ToolTipDelegate.qml 972dd62 
> 
> Diff: https://git.reviewboard.kde.org/r/126636/diff/
> 
> 
> Testing
> ---
> 
> Scrolling works
> 
> 
> Thanks,
> 
> David Rosca
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126637: IconItem: Add animated property

[David Edmundson]

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


+1 from me

Though AFIAK Kai was doing something related here too?

- David Edmundson


On Jan. 5, 2016, 12:52 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126637/
> ---
> 
> (Updated Jan. 5, 2016, 12:52 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Add property animated, that allows to disable cross-fade animation when 
> changing icon (enabled by default).
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/iconitem.h 366edf3 
>   src/declarativeimports/core/iconitem.cpp db15d0f 
> 
> Diff: https://git.reviewboard.kde.org/r/126637/diff/
> 
> 
> Testing
> ---
> 
> Setting `animated: false` disables the animation.
> 
> 
> Thanks,
> 
> David Rosca
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126635: TaskManager: Fix tooltip overflowing screen size

[David Edmundson]

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

Ship it!


- David Edmundson


On Jan. 5, 2016, 12:52 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126635/
> ---
> 
> (Updated Jan. 5, 2016, 12:52 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> Plasma.Dialog ensures the tooltip doesn't overflow the screen size, but it 
> only works when QtQuick.Layouts is used.
> 
> 
> Diffs
> -
> 
>   applets/taskmanager/package/contents/ui/ToolTipDelegate.qml 972dd62 
> 
> Diff: https://git.reviewboard.kde.org/r/126635/diff/
> 
> 
> Testing
> ---
> 
> The tooltip no longer overflows the screen size with too many windows and 
> scrolling works.
> 
> 
> Thanks,
> 
> David Rosca
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126629: update the sddm kcm first step

[David Edmundson]

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

Ship it!


Ship It!

- David Edmundson


On Jan. 5, 2016, 2:34 a.m., Andreas ka wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126629/
> ---
> 
> (Updated Jan. 5, 2016, 2:34 a.m.)
> 
> 
> Review request for Plasma and David Edmundson.
> 
> 
> Repository: sddm-kcm
> 
> 
> Description
> ---
> 
> my first qml edit so I start with a small step one qml file.
> 
> can someone say me how to align right the second column. thanks
> 
> 
> Diffs
> -
> 
>   src/qml/main.qml 0f71aef 
> 
> Diff: https://git.reviewboard.kde.org/r/126629/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> how it looks after the update see preview section
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/8561c1e7-8d68-45b1-9bc2-23342a762071__sddm-kcm.png
> 
> 
> Thanks,
> 
> Andreas ka
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126629: update the sddm kcm first step

[andreas kainz]

> On Jan. 5, 2016, 12:45 nachm., Aleix Pol Gonzalez wrote:
> > What do you mean by "align right"? You want it to take all the horizontal 
> > space?

the mail adddress and Version should be right align to the preview


- andreas


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


On Jan. 5, 2016, 2:34 vorm., Andreas ka wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126629/
> ---
> 
> (Updated Jan. 5, 2016, 2:34 vorm.)
> 
> 
> Review request for Plasma and David Edmundson.
> 
> 
> Repository: sddm-kcm
> 
> 
> Description
> ---
> 
> my first qml edit so I start with a small step one qml file.
> 
> can someone say me how to align right the second column. thanks
> 
> 
> Diffs
> -
> 
>   src/qml/main.qml 0f71aef 
> 
> Diff: https://git.reviewboard.kde.org/r/126629/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> how it looks after the update see preview section
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/8561c1e7-8d68-45b1-9bc2-23342a762071__sddm-kcm.png
> 
> 
> Thanks,
> 
> Andreas ka
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 126637: IconItem: Add animated property

[David Rosca]

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

Review request for Plasma.


Repository: plasma-framework


Description
---

Add property animated, that allows to disable cross-fade animation when 
changing icon (enabled by default).


Diffs
-

  src/declarativeimports/core/iconitem.h 366edf3 
  src/declarativeimports/core/iconitem.cpp db15d0f 

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


Testing
---

Setting `animated: false` disables the animation.


Thanks,

David Rosca

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 126636: TaskManager: Enable vertical scroll in tooltip

[David Rosca]

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

Review request for Plasma.


Repository: plasma-desktop


Description
---

Enable vertical scroll for windows ScrollArea.


Diffs
-

  applets/taskmanager/package/contents/ui/ToolTipDelegate.qml 972dd62 

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


Testing
---

Scrolling works


Thanks,

David Rosca

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 126635: TaskManager: Fix tooltip overflowing screen size

[David Rosca]

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

Review request for Plasma.


Repository: plasma-desktop


Description
---

Plasma.Dialog ensures the tooltip doesn't overflow the screen size, but it only 
works when QtQuick.Layouts is used.


Diffs
-

  applets/taskmanager/package/contents/ui/ToolTipDelegate.qml 972dd62 

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


Testing
---

The tooltip no longer overflows the screen size with too many windows and 
scrolling works.


Thanks,

David Rosca

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126629: update the sddm kcm first step

[Aleix Pol Gonzalez]

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


What do you mean by "align right"? You want it to take all the horizontal space?

- Aleix Pol Gonzalez


On Jan. 5, 2016, 3:34 a.m., Andreas ka wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126629/
> ---
> 
> (Updated Jan. 5, 2016, 3:34 a.m.)
> 
> 
> Review request for Plasma and David Edmundson.
> 
> 
> Repository: sddm-kcm
> 
> 
> Description
> ---
> 
> my first qml edit so I start with a small step one qml file.
> 
> can someone say me how to align right the second column. thanks
> 
> 
> Diffs
> -
> 
>   src/qml/main.qml 0f71aef 
> 
> Diff: https://git.reviewboard.kde.org/r/126629/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> how it looks after the update see preview section
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/8561c1e7-8d68-45b1-9bc2-23342a762071__sddm-kcm.png
> 
> 
> Thanks,
> 
> Andreas ka
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126634: SystemTray: Fix height of lines in table in Entries config

[David Rosca]

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

(Updated Jan. 5, 2016, 12:34 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit 5219f7977e7b0391972c536aa71992f795205228 by David Rosca 
to branch master.


Repository: plasma-workspace


Description
---

Setting text to button makes its height return useful value.


Diffs
-

  applets/systemtray/package/contents/ui/ConfigEntries.qml 7a59702 

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


Testing
---

Looks fine now with Qt 5.6. Not sure if the issue is also in Plasma/5.5 (works 
fine for me with Qt 5.5)


File Attachments


before.png
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/1ed0a142-bc33-4cee-b912-c5f8423c6eb8__before.png
after.png
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/ea5b0e08-1d61-4299-ae03-03601341bbcc__after.png


Thanks,

David Rosca

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126634: SystemTray: Fix height of lines in table in Entries config

[Sebastian Kügler]

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

Ship it!


Ship It!

- Sebastian Kügler


On Jan. 5, 2016, 12:27 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126634/
> ---
> 
> (Updated Jan. 5, 2016, 12:27 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Setting text to button makes its height return useful value.
> 
> 
> Diffs
> -
> 
>   applets/systemtray/package/contents/ui/ConfigEntries.qml 7a59702 
> 
> Diff: https://git.reviewboard.kde.org/r/126634/diff/
> 
> 
> Testing
> ---
> 
> Looks fine now with Qt 5.6. Not sure if the issue is also in Plasma/5.5 
> (works fine for me with Qt 5.5)
> 
> 
> File Attachments
> 
> 
> before.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/1ed0a142-bc33-4cee-b912-c5f8423c6eb8__before.png
> after.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/ea5b0e08-1d61-4299-ae03-03601341bbcc__after.png
> 
> 
> Thanks,
> 
> David Rosca
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 126634: SystemTray: Fix height of lines in table in Entries config

[David Rosca]

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

Review request for Plasma.


Repository: plasma-workspace


Description
---

Setting text to button makes its height return useful value.


Diffs
-

  applets/systemtray/package/contents/ui/ConfigEntries.qml 7a59702 

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


Testing
---

Looks fine now with Qt 5.6. Not sure if the issue is also in Plasma/5.5 (works 
fine for me with Qt 5.5)


File Attachments


before.png
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/1ed0a142-bc33-4cee-b912-c5f8423c6eb8__before.png
after.png
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/ea5b0e08-1d61-4299-ae03-03601341bbcc__after.png


Thanks,

David Rosca

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126630: Do not unconditionally enable logging

[Sebastian Kügler]

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


Please also disable it in the same way for the kwayland backend.

- Sebastian Kügler


On Jan. 5, 2016, 12:08 p.m., Peter Wu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126630/
> ---
> 
> (Updated Jan. 5, 2016, 12:08 p.m.)
> 
> 
> Review request for Plasma, Solid, Daniel Vrátil, and Sebastian Kügler.
> 
> 
> Repository: libkscreen
> 
> 
> Description
> ---
> 
> Logging is [enabled by default][1], there is no read to use setFilterRules
> and [override][2] any user preferences in QtProject/qtlogging.ini.
> 
> Keep unconditional logging enabled for the fake backend though, this
> ensures that unit tests have log messages even if the user disabled all
> other debug messages.
> 
>  [1]: https://doc.qt.io/qt-5/qloggingcategory.html#Q_LOGGING_CATEGORY
>  [2]: https://doc.qt.io/qt-5/qloggingcategory.html#configuring-categories
> 
> 
> Diffs
> -
> 
>   backends/kwayland/waylandbackend.cpp 0700e22 
>   backends/qscreen/qscreenbackend.cpp 56b5a7c 
>   backends/xcbeventlistener.cpp ee415d7 
>   backends/xrandr/xrandr.cpp fae1dcc 
>   backends/xrandr1.1/xrandr11.cpp 631bcc9 
>   src/debug_p.cpp 5934417 
> 
> Diff: https://git.reviewboard.kde.org/r/126630/diff/
> 
> 
> Testing
> ---
> 
> Tested on v5.5.2 (cherry-picked, ignored missing 
> backends/kwayland/waylandbackend.cpp).
> 
> Test:
> 
>  1. Have no kscreen related lines in ~/.config/QtProject/qtlogging.ini
>  2. killall kscreen_backend_launcher
>  3. Change brightness levels via the keyboard. (Result: 
> `RRNotify_OutputProperty` messages in `journalctl`)
>  4. Add the following lines to qtlogging.ini:
> ```
> kscreen.debug=false
> kscreen.xrandr.debug=false
> kscreen.xcb.helper.debug=false
> ```
>  5. killall kscreen_backend_launcher
>  6. Change brightness levels again. (Result: no log spam!)
> 
> 
> Thanks,
> 
> Peter Wu
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Request, 195 lines] D742: Wayland integration: support for server-side decorations

[Martin Gräßlin]

graesslin created this revision.
graesslin added reviewers: mart, sebas.
graesslin added a subscriber: plasma-devel.
graesslin set the repository for this revision to rPLASMAINTEGRATION 
Integration for Qt applications in Plasma.

REVISION SUMMARY
  If the application runs on Wayland, check whether the
  ServerSideDecoration protocol is supported. If that's the case, disable
  Qt's decoration and tell the Wayland server to use Server side decoration
  for normal windows and no decoration for popus, etc.

REPOSITORY
  rPLASMAINTEGRATION Integration for Qt applications in Plasma

BRANCH
  wayland-server-side-deco

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

AFFECTED FILES
  CMakeLists.txt
  autotests/CMakeLists.txt
  src/platformtheme/CMakeLists.txt
  src/platformtheme/config-platformtheme.h.cmake
  src/platformtheme/kdeplatformtheme.cpp
  src/platformtheme/kdeplatformtheme.h
  src/platformtheme/kwaylandintegration.cpp
  src/platformtheme/kwaylandintegration.h

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

To: graesslin, mart, sebas
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126630: Do not unconditionally enable logging

[Peter Wu]

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

(Updated Jan. 5, 2016, 1:08 p.m.)


Review request for Plasma, Solid, Daniel Vrátil, and Sebastian Kügler.


Changes
---

dropped fake and update commit message


Repository: libkscreen


Description (updated)
---

Logging is [enabled by default][1], there is no read to use setFilterRules
and [override][2] any user preferences in QtProject/qtlogging.ini.

Keep unconditional logging enabled for the fake backend though, this
ensures that unit tests have log messages even if the user disabled all
other debug messages.

 [1]: https://doc.qt.io/qt-5/qloggingcategory.html#Q_LOGGING_CATEGORY
 [2]: https://doc.qt.io/qt-5/qloggingcategory.html#configuring-categories


Diffs (updated)
-

  backends/kwayland/waylandbackend.cpp 0700e22 
  backends/qscreen/qscreenbackend.cpp 56b5a7c 
  backends/xcbeventlistener.cpp ee415d7 
  backends/xrandr/xrandr.cpp fae1dcc 
  backends/xrandr1.1/xrandr11.cpp 631bcc9 
  src/debug_p.cpp 5934417 

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


Testing
---

Tested on v5.5.2 (cherry-picked, ignored missing 
backends/kwayland/waylandbackend.cpp).

Test:

 1. Have no kscreen related lines in ~/.config/QtProject/qtlogging.ini
 2. killall kscreen_backend_launcher
 3. Change brightness levels via the keyboard. (Result: 
`RRNotify_OutputProperty` messages in `journalctl`)
 4. Add the following lines to qtlogging.ini:
```
kscreen.debug=false
kscreen.xrandr.debug=false
kscreen.xcb.helper.debug=false
```
 5. killall kscreen_backend_launcher
 6. Change brightness levels again. (Result: no log spam!)


Thanks,

Peter Wu

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Abandoned] D741: Adding .arcconfig

[Martin Gräßlin]

graesslin abandoned this revision.

REPOSITORY
  rPLASMAINTEGRATION Integration for Qt applications in Plasma

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

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

To: graesslin, sebas, mart
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126630: Do not unconditionally enable logging

[Daniel Vrátil]

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



backends/fake/fake.cpp 


Keep this one, fake backend is only for unit-tests.


- Daniel Vrátil


On Jan. 5, 2016, 12:27 p.m., Peter Wu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126630/
> ---
> 
> (Updated Jan. 5, 2016, 12:27 p.m.)
> 
> 
> Review request for Plasma, Solid, Daniel Vrátil, and Sebastian Kügler.
> 
> 
> Repository: libkscreen
> 
> 
> Description
> ---
> 
> Logging is [enabled by default][1], there is no read to use setFilterRules
> and [override][2] any user preferences in QtProject/qtlogging.ini.
> 
>  [1]: https://doc.qt.io/qt-5/qloggingcategory.html#Q_LOGGING_CATEGORY
>  [2]: https://doc.qt.io/qt-5/qloggingcategory.html#configuring-categories
> 
> 
> Diffs
> -
> 
>   backends/fake/fake.cpp 94586bc 
>   backends/kwayland/waylandbackend.cpp 0700e22 
>   backends/qscreen/qscreenbackend.cpp 56b5a7c 
>   backends/xcbeventlistener.cpp ee415d7 
>   backends/xrandr/xrandr.cpp fae1dcc 
>   backends/xrandr1.1/xrandr11.cpp 631bcc9 
>   src/debug_p.cpp 5934417 
> 
> Diff: https://git.reviewboard.kde.org/r/126630/diff/
> 
> 
> Testing
> ---
> 
> Tested on v5.5.2 (cherry-picked, ignored missing 
> backends/kwayland/waylandbackend.cpp).
> 
> Test:
> 
>  1. Have no kscreen related lines in ~/.config/QtProject/qtlogging.ini
>  2. killall kscreen_backend_launcher
>  3. Change brightness levels via the keyboard. (Result: 
> `RRNotify_OutputProperty` messages in `journalctl`)
>  4. Add the following lines to qtlogging.ini:
> ```
> kscreen.debug=false
> kscreen.xrandr.debug=false
> kscreen.xcb.helper.debug=false
> ```
>  5. killall kscreen_backend_launcher
>  6. Change brightness levels again. (Result: no log spam!)
> 
> 
> Thanks,
> 
> Peter Wu
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126373: change the taskbar color from blue to gray

[andreas kainz]

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

(Updated Jan. 5, 2016, noon)


Status
--

This change has been marked as submitted.


Review request for Plasma, Marco Martin and Uri Herrera.


Changes
---

Submitted with commit 5af3ed10d98f4e65c4a056e99705b04d81d19ea7 by Marco Martin 
to branch master.


Repository: plasma-framework


Description
---

Problem
===
with the new taskbar we look that the look and feel is consistent between 
plasma and the applications therefore Uri change the selected application 
taskbar button to a blue background. The problem is that the blue background 
couldn't be the same blue than e.g. in the dolphin sidebar cause when you 
select an element in the sidebar the text color change from "black" to white 
which isn't possible in the system tray and than the contrast isn't that good 
in the panel for selected application (gray text on blue background). In 
addition the blue is very visible. see screenshot before.

Solution

I like that we use the same color language but when you look at the dolphin 
toolbar on top selected elements (e.g. preview in the screenshot) are gray so I 
change the blue color for the selected application to gray and change minimized 
app to no border.

what do you think?


Diffs
-

  src/desktoptheme/breeze/widgets/tasks.svgz 086558b 

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


Testing
---

I will test the new taskbar and hope someone else can test it too before we may 
ship it.


File Attachments


taskbar style old
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/28f02c74-3489-4e35-a83f-45bd59a1e681__PlasmaThemeTaskbarBefore.png
taskbar style new
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/1f9c7570-114d-4192-b2e5-0c713adfaad7__PlasmaThemeTaskbarAfter.png
new tasks.svgz file move to /usr/share/plasma/desktoptheme/breeze/widgets/
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/a6faa46d-1f81-4140-824c-983f6bb5671f__tasks.svgz
taskbar old and new
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/fafdc5e8-bd92-43bd-8006-71088af6fdf4__taskbar.png
tasks new blue boarder in difference to the original one
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/46755f5c-9c95-4e13-b5c6-4966496a5056__tasks.svgz
new draft, origin, old draft
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/0851a433-b3f5-4d93-a7be-7540be0f0692__taskbar3.png


Thanks,

andreas kainz

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Request, 199 lines] D741: Adding .arcconfig

[Martin Gräßlin]

graesslin created this revision.
graesslin added reviewers: sebas, mart.
graesslin added a subscriber: plasma-devel.

REVISION SUMMARY
  Adding .arcconfig
  
  Wayland integration: support for server-side decorations
  
  If the application runs on Wayland, check whether the
  ServerSideDecoration protocol is supported. If that's the case, disable
  Qt's decoration and tell the Wayland server to use Server side decoration
  for normal windows and no decoration for popus, etc.

REPOSITORY
  rPLASMAINTEGRATION Integration for Qt applications in Plasma

BRANCH
  wayland-server-side-deco

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

AFFECTED FILES
  .arcconfig
  CMakeLists.txt
  autotests/CMakeLists.txt
  src/platformtheme/CMakeLists.txt
  src/platformtheme/config-platformtheme.h.cmake
  src/platformtheme/kdeplatformtheme.cpp
  src/platformtheme/kdeplatformtheme.h
  src/platformtheme/kwaylandintegration.cpp
  src/platformtheme/kwaylandintegration.h

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

To: graesslin, sebas, mart
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126373: change the taskbar color from blue to gray

[Andreas ka]

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

Ship it!


Ship It!

- Andreas ka


On Dez. 16, 2015, 7:23 nachm., andreas kainz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126373/
> ---
> 
> (Updated Dez. 16, 2015, 7:23 nachm.)
> 
> 
> Review request for Plasma, Marco Martin and Uri Herrera.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Problem
> ===
> with the new taskbar we look that the look and feel is consistent between 
> plasma and the applications therefore Uri change the selected application 
> taskbar button to a blue background. The problem is that the blue background 
> couldn't be the same blue than e.g. in the dolphin sidebar cause when you 
> select an element in the sidebar the text color change from "black" to white 
> which isn't possible in the system tray and than the contrast isn't that good 
> in the panel for selected application (gray text on blue background). In 
> addition the blue is very visible. see screenshot before.
> 
> Solution
> 
> I like that we use the same color language but when you look at the dolphin 
> toolbar on top selected elements (e.g. preview in the screenshot) are gray so 
> I change the blue color for the selected application to gray and change 
> minimized app to no border.
> 
> what do you think?
> 
> 
> Diffs
> -
> 
>   src/desktoptheme/breeze/widgets/tasks.svgz 086558b 
> 
> Diff: https://git.reviewboard.kde.org/r/126373/diff/
> 
> 
> Testing
> ---
> 
> I will test the new taskbar and hope someone else can test it too before we 
> may ship it.
> 
> 
> File Attachments
> 
> 
> taskbar style old
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/28f02c74-3489-4e35-a83f-45bd59a1e681__PlasmaThemeTaskbarBefore.png
> taskbar style new
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/1f9c7570-114d-4192-b2e5-0c713adfaad7__PlasmaThemeTaskbarAfter.png
> new tasks.svgz file move to /usr/share/plasma/desktoptheme/breeze/widgets/
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/a6faa46d-1f81-4140-824c-983f6bb5671f__tasks.svgz
> taskbar old and new
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/fafdc5e8-bd92-43bd-8006-71088af6fdf4__taskbar.png
> tasks new blue boarder in difference to the original one
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/46755f5c-9c95-4e13-b5c6-4966496a5056__tasks.svgz
> new draft, origin, old draft
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/0851a433-b3f5-4d93-a7be-7540be0f0692__taskbar3.png
> 
> 
> Thanks,
> 
> andreas kainz
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 126630: Do not unconditionally enable logging

[Peter Wu]

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

Review request for Plasma, Solid, Daniel Vrátil, and Sebastian Kügler.


Repository: libkscreen


Description
---

Logging is [enabled by default][1], there is no read to use setFilterRules
and [override][2] any user preferences in QtProject/qtlogging.ini.

 [1]: https://doc.qt.io/qt-5/qloggingcategory.html#Q_LOGGING_CATEGORY
 [2]: https://doc.qt.io/qt-5/qloggingcategory.html#configuring-categories


Diffs
-

  backends/fake/fake.cpp 94586bc 
  backends/kwayland/waylandbackend.cpp 0700e22 
  backends/qscreen/qscreenbackend.cpp 56b5a7c 
  backends/xcbeventlistener.cpp ee415d7 
  backends/xrandr/xrandr.cpp fae1dcc 
  backends/xrandr1.1/xrandr11.cpp 631bcc9 
  src/debug_p.cpp 5934417 

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


Testing
---

Tested on v5.5.2 (cherry-picked, ignored missing 
backends/kwayland/waylandbackend.cpp).

Test:

 1. Have no kscreen related lines in ~/.config/QtProject/qtlogging.ini
 2. killall kscreen_backend_launcher
 3. Change brightness levels via the keyboard. (Result: 
`RRNotify_OutputProperty` messages in `journalctl`)
 4. Add the following lines to qtlogging.ini:
```
kscreen.debug=false
kscreen.xrandr.debug=false
kscreen.xcb.helper.debug=false
```
 5. killall kscreen_backend_launcher
 6. Change brightness levels again. (Result: no log spam!)


Thanks,

Peter Wu

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126632: add a "Complementary" color scheme to kcolorscheme

[Marco Martin]

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

(Updated Jan. 5, 2016, 11:16 a.m.)


Review request for KDE Frameworks and Plasma.


Repository: kconfigwidgets


Description
---

Since some releases, plasma-frameworks locally expands kcolorscheme to have a 
new "Complementary" section: this is done for things like the lockscreen and 
the logout ui, where the colors are flipped from the current theme.
A local extension there is kinda unfortunate as makes the color configs files 
not completely compatible, and I think there is an use case for this in normal 
applications as well (Gwenview switches to a dark palette when in fullscreen 
mode for instance)
Since I want to make the default plasma theme follow the system color scheme, I 
would need for it to support this "complementary" area as well.


Diffs (updated)
-

  src/kcolorscheme.h 22bc21b 
  src/kcolorscheme.cpp 427ffa4 

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


Testing
---


Thanks,

Marco Martin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 126632: add a "Complementary" color scheme to kcolorscheme

[Marco Martin]

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

Review request for KDE Frameworks and Plasma.


Repository: kconfigwidgets


Description
---

Since some releases, plasma-frameworks locally expands kcolorscheme to have a 
new "Complementary" section: this is done for things like the lockscreen and 
the logout ui, where the colors are flipped from the current theme.
A local extension there is kinda unfortunate as makes the color configs files 
not completely compatible, and I think there is an use case for this in normal 
applications as well (Gwenview switches to a dark palette when in fullscreen 
mode for instance)
Since I want to make the default plasma theme follow the system color scheme, I 
would need for it to support this "complementary" area as well.


Diffs
-

  src/kcolorscheme.h 22bc21b 
  src/kcolorscheme.cpp 427ffa4 

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


Testing
---


Thanks,

Marco Martin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Closed] D740: Wayland integration: support for server-side decorations

[Martin Gräßlin]

This revision was automatically updated to reflect the committed changes.
Closed by commit rPLASMAINTEGRATION5ba5cdf2326c: Adding .arcconfig (authored by 
graesslin).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D740?vs=1744&id=1746#toc

REPOSITORY
  rPLASMAINTEGRATION Integration for Qt applications in Plasma

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D740?vs=1744&id=1746

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

AFFECTED FILES
  .arcconfig

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

To: graesslin, sebas, mart
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Request for delaying Plasma 5.5.2 by a day

[Jonathan Riddell]

Tomorrow should be fine, just ping me when you're happy with it

Jonathan


On 5 January 2016 at 05:04, Martin Klapetek  wrote:
> Hey all,
>
> I was hoping the [1] would get at least one more
> tester over the Christmas but I got none. I consider
> that bug that crept in 5.5 to be quite serious (some
> people get random notifications positions on screen)
> and because nobody tested and/or reviewed it and
> 5.5.2 is upon us, I decided to push it after I've tested
> it extensively myself, including on multiscreen.
>
> But I would still like to get at least _some_ feedback
> before 5.5.2 is released (today), so I'd like to delay
> the release by a day (to Wednesday) so that at least
> Plasma people can run it for a day.
>
> Just please update your plasma-workspace, restart
> plasmashell and watch for notifications acting up.
>
> If all is well, 5.5.2 can be released as is. If there are
> troubles, I'll revert and postpone to 5.5.3.
>
> [1] - https://git.reviewboard.kde.org/r/126408/
>
> Cheers
> --
> Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126373: change the taskbar color from blue to gray

[Marco Martin]

> On Dec. 20, 2015, 8:45 p.m., Eike Hein wrote:
> > General PSA: I will soon push a fixed-up version of tasks.svgz to the repo 
> > that cleans up all the random margins and inconsistent corner styles in it 
> > that currently mess up alignments inside and outside of task buttons as 
> > well as corner appearance. Whatever the outcome of this, it needs to be 
> > rebased against those fixes first.
> 
> Uri Herrera wrote:
> The margins are not random. I literally had to use kruler and kmag to 
> properly align that. I even used a layered file with a red rectangle in it 
> because that area consists of a deadzone. I pointed that out when I made the 
> reveiw request originally.
> 
> Eike Hein wrote:
> The inside margins are currently inconsistent at the top and bottom 
> causing the icon to be vertically misaligned. The outside margins are 
> inconsistent as well - I think it's trying to position the button well inside 
> the panel, but this is an incorrect approach to the problem (the optical 
> imbalance with consistent margins is caused by how the panel inside margins 
> function, which is something we need to address in the theming system - my 
> approach to fix it was rejected, I'll be trying again though). The outside 
> margins and the corners (top ones rounded, bottom ones not) subtly break 
> things when the panel is anywhere but the bottom.
> 
> I'm working on a series of changes to make the panel and Task Manager 
> finally pixel-perfect - fix the theme, fix the panel controller when 
> resizing, fix the panel default size, and fix something in FrameSVG/the panel 
> containment.
> 
> Johan Ouwerkerk wrote:
> In any case, the top version (new draft?) has markedly better alignment 
> of the text with icons... The other two versions seem vertically imbalanced 
> (more margin on the bottom than at the top).
> Ideally, the icon is vertically aligned with the baseline of the text 
> such that ascenders and descenders extend equally far beyond the 
> corresponding border of the icon, hough this may be rather tricky when 
> considering languages with different baseline conventions (hanging or 
> variable or none).
> 
> Eike Hein wrote:
> The top version on the screenshot still shows all of the problems I'm 
> currently fixing FWIW.
> 
> Eike Hein wrote:
> I've now pushed the cleaned up tasks.svgz to git master. This fixes:
> 
> * Fix inconsistent inside margins causing vertical misalignment inside 
> Task Buttons.
> * Fix inconsistent outside margins causing incorrect alignment inside 
> panel.
> * Fix outside margins and button corner appearance in locations other 
> than South.
> * Align button frames with things like the pager edges.
> * Fix a few instances of incorrect color scheme application.
> * Remove many unused elements.
> 
> This is what this gets us: http://i.imgur.com/7KaeJH5.png
> 
> This took *hours* to fix. If anyone breaks these margins I will *eat* 
> them. Please base future changes on this version of the file!
> 
> Johan Ouwerkerk wrote:
> Much better! Appreciated.
> 
> Perhaps a test application that sets window name in a variety of scripts 
> might be useful to check how it performs on various scripts...?
> 
> Eike Hein wrote:
> I test CJK and Arabic fairly regularly.
> 
> andreas kainz wrote:
> as I'm to jung to die can you change the behavior from your new 
> tasks.svgz file to 
> 
> 3. add blue boarder as all other tasks have (see first line in 
> taskbar3.png)
> 
> as suggested above.
> 
> Kai Uwe Broulik wrote:
> Looking good, Eike, I'm just not sure about the gray background for 
> minimized tasks. It makes them more prominent than the non-minimized ones - I 
> liked the frameless variant for those better.
> 
> andreas kainz wrote:
> Eike can I have a blue boarder for the selected task as fare as I see 
> it's the only selection mode without border.
> 
> Marco Martin wrote:
> I added a tasks.svgz to the review request.
> I did *not* change any margin or metric, but i made the look more 
> translucent with visible blue border
> (also fixed the stylesheet that was broken in a way that continued to 
> work on plasma, but was completely broken in inkscape)
> 
> Eike Hein wrote:
> Martin, did you forget to add it? I got no email about it and rbt patch 
> says the patch doesn't apply.

it's the tasks.svgz in the "files" section of the review request


- Marco


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


On Dec. 16, 2015, 7:23 p.m., andreas kainz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126373/
> -

[Differential] [Updated] D740: Wayland integration: support for server-side decorations

[Martin Gräßlin]

graesslin retitled this revision from "Adding .arcconfig" to "Wayland 
integration: support for server-side decorations".

REPOSITORY
  rPLASMAINTEGRATION Integration for Qt applications in Plasma

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

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

To: graesslin, sebas, mart
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D740: Adding .arcconfig

[Martin Gräßlin]

graesslin added inline comments.

INLINE COMMENTS
  .arcconfig:1 This file is already in master. Should not have been included. 
Trying to learn phab ;-)

REPOSITORY
  rPLASMAINTEGRATION Integration for Qt applications in Plasma

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

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

To: graesslin, sebas, mart
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Request, 199 lines] D740: Adding .arcconfig

[Martin Gräßlin]

graesslin created this revision.
graesslin added reviewers: sebas, mart.
graesslin added a subscriber: plasma-devel.

REVISION SUMMARY
  Wayland integration: support for server-side decorations
  
  If the application runs on Wayland, check whether the
  ServerSideDecoration protocol is supported. If that's the case, disable
  Qt's decoration and tell the Wayland server to use Server side decoration
  for normal windows and no decoration for popus, etc.

REPOSITORY
  rPLASMAINTEGRATION Integration for Qt applications in Plasma

BRANCH
  wayland-server-side-deco

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

AFFECTED FILES
  .arcconfig
  CMakeLists.txt
  autotests/CMakeLists.txt
  src/platformtheme/CMakeLists.txt
  src/platformtheme/config-platformtheme.h.cmake
  src/platformtheme/kdeplatformtheme.cpp
  src/platformtheme/kdeplatformtheme.h
  src/platformtheme/kwaylandintegration.cpp
  src/platformtheme/kwaylandintegration.h

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

To: graesslin, sebas, mart
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Accepted] D739: Disable ptrace

[bshah (Bhushan Shah)]

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

Looks good to me.


REPOSITORY
  rPOLKITKDEAGENT Policykit (Polkit) KDE Agent

BRANCH
  disable-ptrace

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

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

To: graesslin, sitter, lukas, bshah
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated] D739: Disable ptrace

[Martin Gräßlin]

graesslin added reviewers: sitter, lukas, bshah.
graesslin added a subscriber: plasma-devel.

REPOSITORY
  rPOLKITKDEAGENT Policykit (Polkit) KDE Agent

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

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

To: graesslin, sitter, lukas, bshah
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel