Re: 5.5 video

[Marco Martin]

On Wed, Dec 2, 2015 at 3:05 PM, Jonathan Riddell  wrote:
> Lucas has made a 5.5 video and is after comments for any changes
>
> https://youtu.be/rYUqgFiY5Go
>

It seems really well done!
only things i'm not sure is the "powered by KDE" text, and in general
that 3d effect for the titles
--
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: 5.5 video

[Eike Hein]

On 12/02/2015 03:05 PM, Jonathan Riddell wrote:
> Lucas has made a 5.5 video and is after comments for any changes
> 
> https://youtu.be/rYUqgFiY5Go

* The 3D titles as well as any on screen type should use
  type faces from the Breeze visual design
* The colors should be from the Breeze palette
* The overlay title cards definitely need more contrast


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

Re: 5.5 video

[Martin Klapetek]

On Wed, Dec 2, 2015 at 9:05 AM, Jonathan Riddell  wrote:

> Lucas has made a 5.5 video and is after comments for any changes
>
> https://youtu.be/rYUqgFiY5Go


Is this going to be an official video or something like that?

Cheers
-- 
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: 5.5 video

[Martin Klapetek]

On Wed, Dec 2, 2015 at 11:18 AM, Eike Hein  wrote:

>
>
> On 12/02/2015 03:05 PM, Jonathan Riddell wrote:
> > Lucas has made a 5.5 video and is after comments for any changes
> >
> > https://youtu.be/rYUqgFiY5Go
>
> * The 3D titles as well as any on screen type should use
>   type faces from the Breeze visual design
> * The colors should be from the Breeze palette
> * The overlay title cards definitely need more contrast
>

Expanding on that, the text in the video has very bad readability.

As it has been put in the official announcement, I have couple more
comments.

The video has some flickering when transitioning through the splashy
animation to the wall thing.

I'm not entirely sure that "two column widget explorer" is such a huge
news that it is shown first (the most prominent). I think going with
"New applets in this release" could be first and then show the user
switcher, color picker and quick launcher and whatever new we have.
The "two column widget explorer" is imo such a minor change that it
should be either part of the "new applets" part or be put at the end.

The screencapture is actually cropped, cropping away third of the K
icon and the burger menu on the panel.

User switcher applet does not actually show user switcher applet
but the new launcher.

The animation starting at 00:45 looks like it should not be there.

The animation at 1:17 is confusingly fast.

The windows shown at 1:35 are so quickly clicked-through that I have
no idea what are they showing to me or what's their purpose in the
video. Actually the same goes with the inkscape part, it doesn't really
show the breeze-gtk theme imho, it just shows inkscape. This could
use some video panning over the widgets/menus.

Also, fwiw, Gnome release video:

https://www.youtube.com/watch?v=WxRLa5hTGkg

Cheers
-- 
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: 5.5 video

[Alfonso Hernandez]

excellent, we chose an excellent desktop to ours and to participate in the 
developer of the same. I like :) I like for people to know our distribution 
based on Arch Linux. Coming soon see the light for download. Alfonso Hernandez
CEOPhone: +573057496424Skype: Ponchale
EasyLabs S.A.S 


El Miércoles, 2 de diciembre, 2015 9:50:18, Marco Martin 
 escribió:
 

 On Wed, Dec 2, 2015 at 3:05 PM, Jonathan Riddell  wrote:
> Lucas has made a 5.5 video and is after comments for any changes
>
> https://youtu.be/rYUqgFiY5Go
>

It seems really well done!
only things i'm not sure is the "powered by KDE" text, and in general
that 3d effect for the titles
--
Marco Martin
___
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

Review Request 126221: Rework the notifications positioning a bit

[Martin Klapetek]

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

Review request for Plasma.


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


Repository: plasma-workspace


Description
---

The notifications popup positioning recently regressed
by some other changes (looks like Qt) and the popups
would fly across the screen (bug 355069).

The proper solution is using KWin effect but given how
close the release is, this needs to be dealt with in a
different way.

The main problem is calculating the initial popup size
because as long as the Dialog is invisible, it has an
incorrect geometry, so it needs to be positioned right
after it's being displayed. The Dialog however gets the
sizes even later, so the code now calls a slot from Dialog
that ensures the sizes are correct before the initial
placement on screen. It's not ideal but I'm out of ideas
otherwise. Plus it should be only temporary until the
KWin effect will replace it.


Diffs
-

  applets/notifications/package/contents/ui/Notifications.qml 306169c 
  applets/notifications/lib/notificationsapplet.cpp aa50aef 
  applets/notifications/lib/notificationsapplet.h dc31e1d 
  applets/notifications/plugin/notificationshelper.h cb9b335 
  applets/notifications/plugin/notificationshelper.cpp 7c0dd99 

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


Testing
---

I can no longer reproduce notifications flying across
the screen.


Thanks,

Martin Klapetek

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

Re: Review Request 126126: kicker: always show arrows for items with children

[Pino Toscano]

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

(Updated Dec. 2, 2015, 5:55 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit f08c6923c2c2bfd4b92d9f259b97537ea370470c by Eike Hein to 
branch Plasma/5.5.


Repository: plasma-desktop


Description
---

Always show the arrow in menu items which represent a submenu, instead
of only when hovering on them. This eases the discovery of which items
are actually submenus as opposed to actual entries.


Diffs
-

  applets/kicker/package/contents/ui/ItemListDelegate.qml 
becf13d278862b20f46eacae628364708abadfdc 

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


Testing
---


Thanks,

Pino Toscano

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

Re: Review Request 126221: Rework the notifications positioning a bit

[Martin Klapetek]

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

(Updated Dec. 2, 2015, 8:32 p.m.)


Review request for Plasma.


Changes
---

Use QMetaObject::invokeMethod instead of QMetaMethod


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


Repository: plasma-workspace


Description
---

The notifications popup positioning recently regressed
by some other changes (looks like Qt) and the popups
would fly across the screen (bug 355069).

The proper solution is using KWin effect but given how
close the release is, this needs to be dealt with in a
different way.

The main problem is calculating the initial popup size
because as long as the Dialog is invisible, it has an
incorrect geometry, so it needs to be positioned right
after it's being displayed. The Dialog however gets the
sizes even later, so the code now calls a slot from Dialog
that ensures the sizes are correct before the initial
placement on screen. It's not ideal but I'm out of ideas
otherwise. Plus it should be only temporary until the
KWin effect will replace it.


Diffs (updated)
-

  applets/notifications/lib/notificationsapplet.cpp aa50aef 
  applets/notifications/package/contents/ui/Notifications.qml 306169c 
  applets/notifications/plugin/notificationshelper.h cb9b335 
  applets/notifications/plugin/notificationshelper.cpp 7c0dd99 
  applets/notifications/lib/notificationsapplet.h dc31e1d 

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


Testing
---

I can no longer reproduce notifications flying across
the screen.


Thanks,

Martin Klapetek

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

Re: Review Request 126221: Rework the notifications positioning a bit

[Martin Klapetek]

> On Dec. 2, 2015, 5:17 p.m., David Edmundson wrote:
> > applets/notifications/lib/notificationsapplet.cpp, line 46
> > 
> >
> > what about when it's just "Left" or "Right" ?

It's not, ever. http://paste.opensuse.org/view/raw/abc75d49


> On Dec. 2, 2015, 5:17 p.m., David Edmundson wrote:
> > applets/notifications/plugin/notificationshelper.cpp, line 73
> > 
> >
> > what if it's "Default" and the panel happens to be top?

This is resolved in NotificationsApplet::onAppletLocationChanged (connected to 
Plasma::Applet::locationChanged; which is emitted on applet load). So when it's 
Default, the applet follows the panel and resolves the value to one of the 
actual values (Top* or Bottom*).


- Martin


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


On Dec. 2, 2015, 5:07 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126221/
> ---
> 
> (Updated Dec. 2, 2015, 5:07 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 355069
> https://bugs.kde.org/show_bug.cgi?id=355069
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> The notifications popup positioning recently regressed
> by some other changes (looks like Qt) and the popups
> would fly across the screen (bug 355069).
> 
> The proper solution is using KWin effect but given how
> close the release is, this needs to be dealt with in a
> different way.
> 
> The main problem is calculating the initial popup size
> because as long as the Dialog is invisible, it has an
> incorrect geometry, so it needs to be positioned right
> after it's being displayed. The Dialog however gets the
> sizes even later, so the code now calls a slot from Dialog
> that ensures the sizes are correct before the initial
> placement on screen. It's not ideal but I'm out of ideas
> otherwise. Plus it should be only temporary until the
> KWin effect will replace it.
> 
> 
> Diffs
> -
> 
>   applets/notifications/package/contents/ui/Notifications.qml 306169c 
>   applets/notifications/lib/notificationsapplet.cpp aa50aef 
>   applets/notifications/lib/notificationsapplet.h dc31e1d 
>   applets/notifications/plugin/notificationshelper.h cb9b335 
>   applets/notifications/plugin/notificationshelper.cpp 7c0dd99 
> 
> Diff: https://git.reviewboard.kde.org/r/126221/diff/
> 
> 
> Testing
> ---
> 
> I can no longer reproduce notifications flying across
> the screen.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 126166: use stylesheets in breeze icons

[andreas kainz]

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

Ship it!


Ship It!

- andreas kainz


On Nov. 25, 2015, 1:54 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126166/
> ---
> 
> (Updated Nov. 25, 2015, 1:54 p.m.)
> 
> 
> Review request for Plasma, andreas kainz and Uri Herrera.
> 
> 
> Repository: breeze-icons
> 
> 
> Description
> ---
> 
> unfortunately the diff was about 35 megabytes, so was too big for reviewboard 
> little mind ;)
> a tarball of the modified icons can be found at 
> http://notmart.org/misc/breeze-icons.tar.bz2
> this changes the monochrome breeze icons (other icons are untouched) to use 
> stylesheets instead of hardcoded colors, at least with text color for the 
> black bits, background for the light bits.
> This is kinda needed for icons loaded in plasma (even tough some basic icons 
> in the plasma theme systray and actions are still needed, less duplication 
> would be needed)
> Will be needed a bit more stringently in plasma mobile, where the plasma 
> theme is used as theme for applications (and probably some effects will be 
> needed like changing icons from black to white on the fly)
> 
> This change is not supposed to change the look of any icon anywhere: for 
> desktop applications all of them should look *exactly* the same as they did 
> (please doublecheck this ;))
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 886ab74 
> 
> Diff: https://git.reviewboard.kde.org/r/126166/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 126221: Rework the notifications positioning a bit

[David Edmundson]

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

Ship it!


Ship It!

- David Edmundson


On Dec. 2, 2015, 7:32 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126221/
> ---
> 
> (Updated Dec. 2, 2015, 7:32 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 355069
> https://bugs.kde.org/show_bug.cgi?id=355069
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> The notifications popup positioning recently regressed
> by some other changes (looks like Qt) and the popups
> would fly across the screen (bug 355069).
> 
> The proper solution is using KWin effect but given how
> close the release is, this needs to be dealt with in a
> different way.
> 
> The main problem is calculating the initial popup size
> because as long as the Dialog is invisible, it has an
> incorrect geometry, so it needs to be positioned right
> after it's being displayed. The Dialog however gets the
> sizes even later, so the code now calls a slot from Dialog
> that ensures the sizes are correct before the initial
> placement on screen. It's not ideal but I'm out of ideas
> otherwise. Plus it should be only temporary until the
> KWin effect will replace it.
> 
> 
> Diffs
> -
> 
>   applets/notifications/lib/notificationsapplet.cpp aa50aef 
>   applets/notifications/package/contents/ui/Notifications.qml 306169c 
>   applets/notifications/plugin/notificationshelper.h cb9b335 
>   applets/notifications/plugin/notificationshelper.cpp 7c0dd99 
>   applets/notifications/lib/notificationsapplet.h dc31e1d 
> 
> Diff: https://git.reviewboard.kde.org/r/126221/diff/
> 
> 
> Testing
> ---
> 
> I can no longer reproduce notifications flying across
> the screen.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 126166: use stylesheets in breeze icons

[andreas kainz]

> On Nov. 26, 2015, 5 p.m., Marco Martin wrote:
> > *please* VDG people, take a look at this asap. I already seen that new 
> > changes have been done to icons in master, which means that i'll have to 
> > redo this from scratch.
> 
> Uri Herrera wrote:
> This needs to be documented first. Properly. Once it's documented then 
> we'll go on with the change.
> 
> Marco Martin wrote:
> the documentation talking about it so far is
> 
> https://techbase.kde.org/Development/Tutorials/Plasma5/ThemeDetails#Using_system_colors
> 
> I know is just a small paragraph, but i'm not sure what's needed more to 
> be clearly understandable.. I can expand on that if I am explained the 
> unclear points.
> 
> Uri Herrera wrote:
> If I run apply-stylesheet.sh in icons that don't have the attribute the 
> script will add it? or would I have to run currentColorFix.sh first and then 
> apply-stylesheet.sh?.
> 
> Marco Martin wrote:
> it should add it, it depends also what are the colors used, as in those 
> icons the monochrome dark color is #4d4d4d, would need the parameters 
> --TextFrom=#4d4d4d --TextTo=#4d4d4d  that tells what color to replace with 
> the TextColor class.
> 
> Marco Martin wrote:
> anyways, if the status in the tarball is still current, would be good to 
> apply it, as I see so far only system-lock-screen has diverged (and a 
> mimetype added)
> 
> andreas kainz wrote:
> hi 
> 
> I don't know how I can test them but I would prefere an automatic 
> solution also for applications cause some applications want to use dark 
> background and than the icons should be automatic the dark ones. as we have 
> dark and light icons why you don't say plasma dark is used => use dark icons 
> and at the applications the same dark color scheme => dark icons. we can also 
> use the stylesheet script but than we should reduce the icon set to breeze 
> and breeze dark was generated via stylesheet.
> 
> sorry for the late replay I didn't have spare time in the past weeks.
> 
> Marco Martin wrote:
> the testing i'm interested in, is just to see that they don't change 
> their look when used in normal applications or opened in inkscape.
> i need this stylesheet thing in plasma as in plsma mobile we are going to 
> have different areas where the icon can be either dark or light in the same 
> application, plus applications that define their own color.
> Desktop applications have an old broken way to load icons and there is 
> nothing that can be done, but i don't want to keep being pushed back by that 
> for QML applications that don't have the same limits.
> And yeah, would be quite silly to use a patched clone of the breeze icons 
> for plasma mobile, but that's how we need monochrome icons to be done.

I open an file with inkscape delete everything say clear file and make 
everything new. It works. so I would say ship it. but I will have an solution 
for kde applications also.


- andreas


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


On Nov. 25, 2015, 1:54 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126166/
> ---
> 
> (Updated Nov. 25, 2015, 1:54 p.m.)
> 
> 
> Review request for Plasma, andreas kainz and Uri Herrera.
> 
> 
> Repository: breeze-icons
> 
> 
> Description
> ---
> 
> unfortunately the diff was about 35 megabytes, so was too big for reviewboard 
> little mind ;)
> a tarball of the modified icons can be found at 
> http://notmart.org/misc/breeze-icons.tar.bz2
> this changes the monochrome breeze icons (other icons are untouched) to use 
> stylesheets instead of hardcoded colors, at least with text color for the 
> black bits, background for the light bits.
> This is kinda needed for icons loaded in plasma (even tough some basic icons 
> in the plasma theme systray and actions are still needed, less duplication 
> would be needed)
> Will be needed a bit more stringently in plasma mobile, where the plasma 
> theme is used as theme for applications (and probably some effects will be 
> needed like changing icons from black to white on the fly)
> 
> This change is not supposed to change the look of any icon anywhere: for 
> desktop applications all of them should look *exactly* the same as they did 
> (please doublecheck this ;))
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 886ab74 
> 
> Diff: https://git.reviewboard.kde.org/r/126166/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
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 # 4 - 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/4/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 03 Dec 2015 04:12:09 +
Build duration: 2 min 3 sec

CHANGE SET
Revision 4a6f7db0018a2a7366ac7f2ad61fc33f31566c03 by Martin Klapetek: 
([notifications] Rework the notifications positioning a bit)
  change: edit applets/notifications/plugin/notificationshelper.h
  change: edit applets/notifications/plugin/notificationshelper.cpp
  change: edit applets/notifications/package/contents/ui/Notifications.qml
  change: edit applets/notifications/lib/notificationsapplet.h
  change: edit applets/notifications/lib/notificationsapplet.cpp
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126221: Rework the notifications positioning a bit

[Martin Klapetek]

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

(Updated Dec. 3, 2015, 4:11 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit 4a6f7db0018a2a7366ac7f2ad61fc33f31566c03 by Martin 
Klapetek to branch Plasma/5.5.


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


Repository: plasma-workspace


Description
---

The notifications popup positioning recently regressed
by some other changes (looks like Qt) and the popups
would fly across the screen (bug 355069).

The proper solution is using KWin effect but given how
close the release is, this needs to be dealt with in a
different way.

The main problem is calculating the initial popup size
because as long as the Dialog is invisible, it has an
incorrect geometry, so it needs to be positioned right
after it's being displayed. The Dialog however gets the
sizes even later, so the code now calls a slot from Dialog
that ensures the sizes are correct before the initial
placement on screen. It's not ideal but I'm out of ideas
otherwise. Plus it should be only temporary until the
KWin effect will replace it.


Diffs
-

  applets/notifications/lib/notificationsapplet.cpp aa50aef 
  applets/notifications/package/contents/ui/Notifications.qml 306169c 
  applets/notifications/plugin/notificationshelper.h cb9b335 
  applets/notifications/plugin/notificationshelper.cpp 7c0dd99 
  applets/notifications/lib/notificationsapplet.h dc31e1d 

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


Testing
---

I can no longer reproduce notifications flying across
the screen.


Thanks,

Martin Klapetek

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

Re: Review Request 126221: Rework the notifications positioning a bit

[Bhushan Shah]

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

Ship it!


This fixes bug for me :)

- Bhushan Shah


On Dec. 3, 2015, 1:02 a.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126221/
> ---
> 
> (Updated Dec. 3, 2015, 1:02 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 355069
> https://bugs.kde.org/show_bug.cgi?id=355069
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> The notifications popup positioning recently regressed
> by some other changes (looks like Qt) and the popups
> would fly across the screen (bug 355069).
> 
> The proper solution is using KWin effect but given how
> close the release is, this needs to be dealt with in a
> different way.
> 
> The main problem is calculating the initial popup size
> because as long as the Dialog is invisible, it has an
> incorrect geometry, so it needs to be positioned right
> after it's being displayed. The Dialog however gets the
> sizes even later, so the code now calls a slot from Dialog
> that ensures the sizes are correct before the initial
> placement on screen. It's not ideal but I'm out of ideas
> otherwise. Plus it should be only temporary until the
> KWin effect will replace it.
> 
> 
> Diffs
> -
> 
>   applets/notifications/lib/notificationsapplet.cpp aa50aef 
>   applets/notifications/package/contents/ui/Notifications.qml 306169c 
>   applets/notifications/plugin/notificationshelper.h cb9b335 
>   applets/notifications/plugin/notificationshelper.cpp 7c0dd99 
>   applets/notifications/lib/notificationsapplet.h dc31e1d 
> 
> Diff: https://git.reviewboard.kde.org/r/126221/diff/
> 
> 
> Testing
> ---
> 
> I can no longer reproduce notifications flying across
> the screen.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 126221: Rework the notifications positioning a bit

[Martin Gräßlin]

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


I'm glad that you found a solution which works just in time for the release! 
Good work!

- Martin Gräßlin


On Dec. 3, 2015, 5:11 a.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126221/
> ---
> 
> (Updated Dec. 3, 2015, 5:11 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 355069
> https://bugs.kde.org/show_bug.cgi?id=355069
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> The notifications popup positioning recently regressed
> by some other changes (looks like Qt) and the popups
> would fly across the screen (bug 355069).
> 
> The proper solution is using KWin effect but given how
> close the release is, this needs to be dealt with in a
> different way.
> 
> The main problem is calculating the initial popup size
> because as long as the Dialog is invisible, it has an
> incorrect geometry, so it needs to be positioned right
> after it's being displayed. The Dialog however gets the
> sizes even later, so the code now calls a slot from Dialog
> that ensures the sizes are correct before the initial
> placement on screen. It's not ideal but I'm out of ideas
> otherwise. Plus it should be only temporary until the
> KWin effect will replace it.
> 
> 
> Diffs
> -
> 
>   applets/notifications/lib/notificationsapplet.cpp aa50aef 
>   applets/notifications/package/contents/ui/Notifications.qml 306169c 
>   applets/notifications/plugin/notificationshelper.h cb9b335 
>   applets/notifications/plugin/notificationshelper.cpp 7c0dd99 
>   applets/notifications/lib/notificationsapplet.h dc31e1d 
> 
> Diff: https://git.reviewboard.kde.org/r/126221/diff/
> 
> 
> Testing
> ---
> 
> I can no longer reproduce notifications flying across
> the screen.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

[Plasma Workspace Wallpapers] [Bug 354379] Wallpaper fails to rotate 90 on dual screen with external scr. on left. Stays horiz. and spills over onto right scr.

[PhillB via KDE Bugzilla]

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

--- Comment #15 from PhillB  ---
Latest update to Fedora 23 seems to have fixed my issue. Thanks.

Please close.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126221: Rework the notifications positioning a bit

[Martin Klapetek]

> On Dec. 3, 2015, 12:36 a.m., Mark Gaiser wrote:
> > I had this issue for quite a while!
> > It's in bug #349669, i have high hopes that this change fixes my case as 
> > well :)
> > 
> > Will try this out somewhere this weekend.

No, unfortunately this will not fix this issue, but it is related.
It's the same problem, in fact, but as the notifications use manual
positioning on the screen, it needs a fix in that code first.

Afaiu the problem happens when something positions a window "out of
bounds", ie. out of screen and/or in panel struts, then something else
takes it (either KWin or Qt/X11 or PlasmaQuick::Dialog) and puts it
back within bounds, but with y=0. Unfortunately I don't understand
window placement enough to precisely pinpoint where/why it goes to y=0.


- Martin


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


On Dec. 2, 2015, 8:32 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126221/
> ---
> 
> (Updated Dec. 2, 2015, 8:32 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 355069
> https://bugs.kde.org/show_bug.cgi?id=355069
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> The notifications popup positioning recently regressed
> by some other changes (looks like Qt) and the popups
> would fly across the screen (bug 355069).
> 
> The proper solution is using KWin effect but given how
> close the release is, this needs to be dealt with in a
> different way.
> 
> The main problem is calculating the initial popup size
> because as long as the Dialog is invisible, it has an
> incorrect geometry, so it needs to be positioned right
> after it's being displayed. The Dialog however gets the
> sizes even later, so the code now calls a slot from Dialog
> that ensures the sizes are correct before the initial
> placement on screen. It's not ideal but I'm out of ideas
> otherwise. Plus it should be only temporary until the
> KWin effect will replace it.
> 
> 
> Diffs
> -
> 
>   applets/notifications/lib/notificationsapplet.cpp aa50aef 
>   applets/notifications/package/contents/ui/Notifications.qml 306169c 
>   applets/notifications/plugin/notificationshelper.h cb9b335 
>   applets/notifications/plugin/notificationshelper.cpp 7c0dd99 
>   applets/notifications/lib/notificationsapplet.h dc31e1d 
> 
> Diff: https://git.reviewboard.kde.org/r/126221/diff/
> 
> 
> Testing
> ---
> 
> I can no longer reproduce notifications flying across
> the screen.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

[Plasma Workspace Wallpapers] [Bug 354379] Wallpaper fails to rotate 90 on dual screen with external scr. on left. Stays horiz. and spills over onto right scr.

[Martin Klapetek via KDE Bugzilla]

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

Martin Klapetek  changed:

   What|Removed |Added

 CC||mklape...@kde.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126221: Rework the notifications positioning a bit

[Mark Gaiser]

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

Ship it!


I had this issue for quite a while!
It's in bug #349669, i have high hopes that this change fixes my case as well :)

Will try this out somewhere this weekend.

- Mark Gaiser


On dec 2, 2015, 7:32 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126221/
> ---
> 
> (Updated dec 2, 2015, 7:32 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 355069
> https://bugs.kde.org/show_bug.cgi?id=355069
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> The notifications popup positioning recently regressed
> by some other changes (looks like Qt) and the popups
> would fly across the screen (bug 355069).
> 
> The proper solution is using KWin effect but given how
> close the release is, this needs to be dealt with in a
> different way.
> 
> The main problem is calculating the initial popup size
> because as long as the Dialog is invisible, it has an
> incorrect geometry, so it needs to be positioned right
> after it's being displayed. The Dialog however gets the
> sizes even later, so the code now calls a slot from Dialog
> that ensures the sizes are correct before the initial
> placement on screen. It's not ideal but I'm out of ideas
> otherwise. Plus it should be only temporary until the
> KWin effect will replace it.
> 
> 
> Diffs
> -
> 
>   applets/notifications/lib/notificationsapplet.cpp aa50aef 
>   applets/notifications/package/contents/ui/Notifications.qml 306169c 
>   applets/notifications/plugin/notificationshelper.h cb9b335 
>   applets/notifications/plugin/notificationshelper.cpp 7c0dd99 
>   applets/notifications/lib/notificationsapplet.h dc31e1d 
> 
> Diff: https://git.reviewboard.kde.org/r/126221/diff/
> 
> 
> Testing
> ---
> 
> I can no longer reproduce notifications flying across
> the screen.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 126216: Do not produce negative struts on switching screens

[Jan Kundrát]

> On Dec. 1, 2015, 11:30 p.m., Aleix Pol Gonzalez wrote:
> > Looking at the documentation, it seems like it should never return invalid 
> > (at least if ::geometry also isn't invalid).
> > 
> > I'll add some debug locally and try to reproduce the issue. Thanks for 
> > looking into this!

For the record, this is with qtbase a5f470240f31d35e694a40fe837fc4f49bc32072. I 
see that the screen changing changed once again in the dev (5.6) branch (yeah, 
I know you wrote these patches).


- Jan


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


On Dec. 1, 2015, 6:45 p.m., Jan Kundrát wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126216/
> ---
> 
> (Updated Dec. 1, 2015, 6:45 p.m.)
> 
> 
> Review request for Plasma and Martin Gräßlin.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Turns out that this method is sometimes called at the time where the
> virtualGeometry() is invalid. Rather than producing values which are
> surely invalid, try to come up with something which might be incorrect
> on some multiscreen setups (right?), but which at least happens to work
> on my setup.
> 
> 
> Diffs
> -
> 
>   shell/panelview.cpp 34075013b22995d81c98d933db596dff520bd812 
> 
> Diff: https://git.reviewboard.kde.org/r/126216/diff/
> 
> 
> Testing
> ---
> 
> Here's how the stack traces look like BTW:
> 
> 389 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:
>  No such file or directory.
> (gdb) bt
> #0  PanelView::positionPanel (this=0x58162660) at 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:389
> #1  0x5559e6a9 in PanelView::containmentChanged (this=0x58162660) 
> at 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:1036
> #2  0x5559fdf5 in PanelView::qt_static_metacall (_o=, 
> _c=, _id=, _a=)
> at 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-_build/shell/moc_panelview.cpp:224
> #3  0x72bbbf79 in QMetaObject::activate (sender=0x58162660, 
> signalOffset=, local_signal_index=local_signal_index@entry=2, 
> argv=argv@entry=0x0)
> at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3713
> #4  0x72bbc6d5 in QMetaObject::activate (sender=, 
> m=m@entry=0x77bd0600 , 
> local_signal_index=local_signal_index@entry=2, argv=argv@entry=0x0) at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3578
> #5  0x779ab309 in PlasmaQuick::ContainmentView::containmentChanged 
> (this=)
> at 
> /var/tmp/portage/kde-frameworks/plasma-/work/plasma-_build/src/plasmaquick/moc_containmentview.cpp:257
> #6  0x779abdf0 in PlasmaQuick::ContainmentViewPrivate::setContainment 
> (this=0x58225fb0, cont=0x55da3270)
> at 
> /var/tmp/portage/kde-frameworks/plasma-/work/plasma-/src/plasmaquick/containmentview.cpp:96
> #7  0x779ac5df in PlasmaQuick::ContainmentView::setContainment 
> (this=this@entry=0x58162660, cont=)
> at 
> /var/tmp/portage/kde-frameworks/plasma-/work/plasma-/src/plasmaquick/containmentview.cpp:246
> #8  0x555b08ab in ShellCorona::createWaitingPanels 
> (this=0x558c6790) at 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/shellcorona.cpp:1023
> #9  0x72bbba00 in call (a=0x7fffce10, r=0x558c6790, 
> this=0x558df440) at 
> ../../include/QtCore/../../../qtcore-5.5./src/corelib/kernel/qobject_impl.h:124
> #10 QMetaObject::activate (sender=sender@entry=0x558c6840, 
> signalOffset=, local_signal_index=local_signal_index@entry=0, 
> argv=argv@entry=0x0)
> at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3698
> #11 0x72bbc6d5 in QMetaObject::activate 
> (sender=sender@entry=0x558c6840, m=m@entry=0x72dd84a0 
> , local_signal_index=local_signal_index@entry=0, 
> argv=argv@entry=0x0) at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3578
> #12 0x72c47016 in QTimer::timeout (this=this@entry=0x558c6840) at 
> .moc/moc_qtimer.cpp:197
> #13 0x72bca552 in QTimer::timerEvent (this=0x558c6840, 
> e=) at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qtimer.cpp:247
> #14 0x72bbd2b4 in QObject::event (this=0x558c6840, e= out>) at 
> 

Re: Review Request 126216: Do not produce negative struts on switching screens

[Jan Kundrát]

> On Dec. 1, 2015, 10:28 p.m., David Edmundson wrote:
> > shell/panelview.cpp, line 918
> > 
> >
> > This basically says:
> > if the whole desktop workarea is null assume we only have one screen
> > 
> > That doesn't make a lot of sense.
> > 
> > Can you instead maybe port wholeScreen to use:
> > m_corona->screensConfiguration()->screen()->currentSize() ?
> > 
> > it's what's triggering the signal to get into this method, so it should 
> > be in sync.

Not sure if this is what you had in mind (maybe I should call out to m_corona 
unconditionally?).


- Jan


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


On Dec. 1, 2015, 6:45 p.m., Jan Kundrát wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126216/
> ---
> 
> (Updated Dec. 1, 2015, 6:45 p.m.)
> 
> 
> Review request for Plasma and Martin Gräßlin.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Turns out that this method is sometimes called at the time where the
> virtualGeometry() is invalid. Rather than producing values which are
> surely invalid, try to come up with something which might be incorrect
> on some multiscreen setups (right?), but which at least happens to work
> on my setup.
> 
> 
> Diffs
> -
> 
>   shell/panelview.cpp 34075013b22995d81c98d933db596dff520bd812 
> 
> Diff: https://git.reviewboard.kde.org/r/126216/diff/
> 
> 
> Testing
> ---
> 
> Here's how the stack traces look like BTW:
> 
> 389 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:
>  No such file or directory.
> (gdb) bt
> #0  PanelView::positionPanel (this=0x58162660) at 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:389
> #1  0x5559e6a9 in PanelView::containmentChanged (this=0x58162660) 
> at 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:1036
> #2  0x5559fdf5 in PanelView::qt_static_metacall (_o=, 
> _c=, _id=, _a=)
> at 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-_build/shell/moc_panelview.cpp:224
> #3  0x72bbbf79 in QMetaObject::activate (sender=0x58162660, 
> signalOffset=, local_signal_index=local_signal_index@entry=2, 
> argv=argv@entry=0x0)
> at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3713
> #4  0x72bbc6d5 in QMetaObject::activate (sender=, 
> m=m@entry=0x77bd0600 , 
> local_signal_index=local_signal_index@entry=2, argv=argv@entry=0x0) at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3578
> #5  0x779ab309 in PlasmaQuick::ContainmentView::containmentChanged 
> (this=)
> at 
> /var/tmp/portage/kde-frameworks/plasma-/work/plasma-_build/src/plasmaquick/moc_containmentview.cpp:257
> #6  0x779abdf0 in PlasmaQuick::ContainmentViewPrivate::setContainment 
> (this=0x58225fb0, cont=0x55da3270)
> at 
> /var/tmp/portage/kde-frameworks/plasma-/work/plasma-/src/plasmaquick/containmentview.cpp:96
> #7  0x779ac5df in PlasmaQuick::ContainmentView::setContainment 
> (this=this@entry=0x58162660, cont=)
> at 
> /var/tmp/portage/kde-frameworks/plasma-/work/plasma-/src/plasmaquick/containmentview.cpp:246
> #8  0x555b08ab in ShellCorona::createWaitingPanels 
> (this=0x558c6790) at 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/shellcorona.cpp:1023
> #9  0x72bbba00 in call (a=0x7fffce10, r=0x558c6790, 
> this=0x558df440) at 
> ../../include/QtCore/../../../qtcore-5.5./src/corelib/kernel/qobject_impl.h:124
> #10 QMetaObject::activate (sender=sender@entry=0x558c6840, 
> signalOffset=, local_signal_index=local_signal_index@entry=0, 
> argv=argv@entry=0x0)
> at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3698
> #11 0x72bbc6d5 in QMetaObject::activate 
> (sender=sender@entry=0x558c6840, m=m@entry=0x72dd84a0 
> , local_signal_index=local_signal_index@entry=0, 
> argv=argv@entry=0x0) at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3578
> #12 0x72c47016 in QTimer::timeout (this=this@entry=0x558c6840) at 
> .moc/moc_qtimer.cpp:197
> #13 0x72bca552 in QTimer::timerEvent (this=0x558c6840, 
> e=) at 
> 

Re: Review Request 126216: Do not produce negative struts on switching screens

[Jan Kundrát]

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

(Updated Dec. 2, 2015, 10:53 a.m.)


Review request for Plasma and Martin Gräßlin.


Repository: plasma-workspace


Description
---

Turns out that this method is sometimes called at the time where the
virtualGeometry() is invalid. Rather than producing values which are
surely invalid, try to come up with something which might be incorrect
on some multiscreen setups (right?), but which at least happens to work
on my setup.


Diffs (updated)
-

  shell/panelview.cpp 34075013b22995d81c98d933db596dff520bd812 

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


Testing
---

Here's how the stack traces look like BTW:

389 
/var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:
 No such file or directory.
(gdb) bt
#0  PanelView::positionPanel (this=0x58162660) at 
/var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:389
#1  0x5559e6a9 in PanelView::containmentChanged (this=0x58162660) 
at 
/var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:1036
#2  0x5559fdf5 in PanelView::qt_static_metacall (_o=, 
_c=, _id=, _a=)
at 
/var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-_build/shell/moc_panelview.cpp:224
#3  0x72bbbf79 in QMetaObject::activate (sender=0x58162660, 
signalOffset=, local_signal_index=local_signal_index@entry=2, 
argv=argv@entry=0x0)
at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3713
#4  0x72bbc6d5 in QMetaObject::activate (sender=, 
m=m@entry=0x77bd0600 , 
local_signal_index=local_signal_index@entry=2, argv=argv@entry=0x0) at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3578
#5  0x779ab309 in PlasmaQuick::ContainmentView::containmentChanged 
(this=)
at 
/var/tmp/portage/kde-frameworks/plasma-/work/plasma-_build/src/plasmaquick/moc_containmentview.cpp:257
#6  0x779abdf0 in PlasmaQuick::ContainmentViewPrivate::setContainment 
(this=0x58225fb0, cont=0x55da3270)
at 
/var/tmp/portage/kde-frameworks/plasma-/work/plasma-/src/plasmaquick/containmentview.cpp:96
#7  0x779ac5df in PlasmaQuick::ContainmentView::setContainment 
(this=this@entry=0x58162660, cont=)
at 
/var/tmp/portage/kde-frameworks/plasma-/work/plasma-/src/plasmaquick/containmentview.cpp:246
#8  0x555b08ab in ShellCorona::createWaitingPanels 
(this=0x558c6790) at 
/var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/shellcorona.cpp:1023
#9  0x72bbba00 in call (a=0x7fffce10, r=0x558c6790, 
this=0x558df440) at 
../../include/QtCore/../../../qtcore-5.5./src/corelib/kernel/qobject_impl.h:124
#10 QMetaObject::activate (sender=sender@entry=0x558c6840, 
signalOffset=, local_signal_index=local_signal_index@entry=0, 
argv=argv@entry=0x0)
at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3698
#11 0x72bbc6d5 in QMetaObject::activate 
(sender=sender@entry=0x558c6840, m=m@entry=0x72dd84a0 
, local_signal_index=local_signal_index@entry=0, 
argv=argv@entry=0x0) at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3578
#12 0x72c47016 in QTimer::timeout (this=this@entry=0x558c6840) at 
.moc/moc_qtimer.cpp:197
#13 0x72bca552 in QTimer::timerEvent (this=0x558c6840, e=) at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qtimer.cpp:247
#14 0x72bbd2b4 in QObject::event (this=0x558c6840, e=) at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:1220
#15 0x73672c1c in QApplicationPrivate::notify_helper 
(this=this@entry=0x55810f70, receiver=receiver@entry=0x558c6840, 
e=e@entry=0x7fffd240)
at 
/var/tmp/portage/dev-qt/qtwidgets-5.5./work/qtwidgets-5.5./src/widgets/kernel/qapplication.cpp:3716
#16 0x7367847a in QApplication::notify (this=0x7fffd670, 
receiver=0x558c6840, e=0x7fffd240)
at 
/var/tmp/portage/dev-qt/qtwidgets-5.5./work/qtwidgets-5.5./src/widgets/kernel/qapplication.cpp:3499
#17 0x72b8c57d in QCoreApplication::notifyInternal 
(this=0x7fffd670, receiver=0x558c6840, event=event@entry=0x7fffd240)
at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qcoreapplication.cpp:965
#18 0x72be60cc in sendEvent (event=0x7fffd240, receiver=) at 
../../include/QtCore/../../../qtcore-5.5./src/corelib/kernel/qcoreapplication.h:224
#19 

Re: Review Request 126203: Disable ptrace for kcheckpass and the greeter

[Martin Gräßlin]

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

(Updated Dec. 2, 2015, 8:11 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma and Tobias Berner.


Changes
---

Submitted with commit 88a497e4c6b7599cf859703e25d65ba8bb2873ce by Martin 
Gräßlin to branch master.


Repository: kscreenlocker


Description
---

Setting the PR_SET_DUMPABLE flag to 0 for the security relevant
command kcheckpass and kscreenlocker_greet. If one wants to gdb into
the running command it will result in:

ptrace: Operation not permitted.

For kscreenlocker_greet ptrace is permitted in testing mode.

As root it's still possible to attach to the process.

---

@Tobias: I assume this is a strong linux-ism. Is there a FreeBSD compareable 
functionality?

I'm considering to push this explicitly without an ifdef. It's a new security 
feature and I want to make non-Linux systems aware of the fact that it adds a 
new feature and that a replacement should be added.


Diffs
-

  CMakeLists.txt f48bd53cafc188f79e041518dae0769d57597c69 
  config-kscreenlocker.h.cmake 2a034dee8ec21e426bc1db1d56b0ed152d3de2ca 
  greeter/main.cpp e4e679e7ef40b319665428281fdba5f4e0b4eb25 
  kcheckpass/kcheckpass.c fd2d2215bf2199f159a121bb0ce08e7b2b254aaa 

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


Testing
---

Tried to gdb into the processes: failed
Tried to gdb into kscreenlocker_greet --testing: succeeded
Tried to gdb into kscreenlocker_greet as root: succeeded


Thanks,

Martin Gräßlin

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

Re: Review Request 126166: use stylesheets in breeze icons

[Marco Martin]

> On Nov. 26, 2015, 5 p.m., Marco Martin wrote:
> > *please* VDG people, take a look at this asap. I already seen that new 
> > changes have been done to icons in master, which means that i'll have to 
> > redo this from scratch.
> 
> Uri Herrera wrote:
> This needs to be documented first. Properly. Once it's documented then 
> we'll go on with the change.
> 
> Marco Martin wrote:
> the documentation talking about it so far is
> 
> https://techbase.kde.org/Development/Tutorials/Plasma5/ThemeDetails#Using_system_colors
> 
> I know is just a small paragraph, but i'm not sure what's needed more to 
> be clearly understandable.. I can expand on that if I am explained the 
> unclear points.
> 
> Uri Herrera wrote:
> If I run apply-stylesheet.sh in icons that don't have the attribute the 
> script will add it? or would I have to run currentColorFix.sh first and then 
> apply-stylesheet.sh?.
> 
> Marco Martin wrote:
> it should add it, it depends also what are the colors used, as in those 
> icons the monochrome dark color is #4d4d4d, would need the parameters 
> --TextFrom=#4d4d4d --TextTo=#4d4d4d  that tells what color to replace with 
> the TextColor class.
> 
> Marco Martin wrote:
> anyways, if the status in the tarball is still current, would be good to 
> apply it, as I see so far only system-lock-screen has diverged (and a 
> mimetype added)
> 
> andreas kainz wrote:
> hi 
> 
> I don't know how I can test them but I would prefere an automatic 
> solution also for applications cause some applications want to use dark 
> background and than the icons should be automatic the dark ones. as we have 
> dark and light icons why you don't say plasma dark is used => use dark icons 
> and at the applications the same dark color scheme => dark icons. we can also 
> use the stylesheet script but than we should reduce the icon set to breeze 
> and breeze dark was generated via stylesheet.
> 
> sorry for the late replay I didn't have spare time in the past weeks.

the testing i'm interested in, is just to see that they don't change their look 
when used in normal applications or opened in inkscape.
i need this stylesheet thing in plasma as in plsma mobile we are going to have 
different areas where the icon can be either dark or light in the same 
application, plus applications that define their own color.
Desktop applications have an old broken way to load icons and there is nothing 
that can be done, but i don't want to keep being pushed back by that for QML 
applications that don't have the same limits.
And yeah, would be quite silly to use a patched clone of the breeze icons for 
plasma mobile, but that's how we need monochrome icons to be done.


- Marco


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


On Nov. 25, 2015, 1:54 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126166/
> ---
> 
> (Updated Nov. 25, 2015, 1:54 p.m.)
> 
> 
> Review request for Plasma, andreas kainz and Uri Herrera.
> 
> 
> Repository: breeze-icons
> 
> 
> Description
> ---
> 
> unfortunately the diff was about 35 megabytes, so was too big for reviewboard 
> little mind ;)
> a tarball of the modified icons can be found at 
> http://notmart.org/misc/breeze-icons.tar.bz2
> this changes the monochrome breeze icons (other icons are untouched) to use 
> stylesheets instead of hardcoded colors, at least with text color for the 
> black bits, background for the light bits.
> This is kinda needed for icons loaded in plasma (even tough some basic icons 
> in the plasma theme systray and actions are still needed, less duplication 
> would be needed)
> Will be needed a bit more stringently in plasma mobile, where the plasma 
> theme is used as theme for applications (and probably some effects will be 
> needed like changing icons from black to white on the fly)
> 
> This change is not supposed to change the look of any icon anywhere: for 
> desktop applications all of them should look *exactly* the same as they did 
> (please doublecheck this ;))
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 886ab74 
> 
> Diff: https://git.reviewboard.kde.org/r/126166/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 126216: Do not produce negative struts on switching screens

[David Edmundson]

> On Dec. 1, 2015, 10:28 p.m., David Edmundson wrote:
> > shell/panelview.cpp, line 918
> > 
> >
> > This basically says:
> > if the whole desktop workarea is null assume we only have one screen
> > 
> > That doesn't make a lot of sense.
> > 
> > Can you instead maybe port wholeScreen to use:
> > m_corona->screensConfiguration()->screen()->currentSize() ?
> > 
> > it's what's triggering the signal to get into this method, so it should 
> > be in sync.
> 
> Jan Kundrát wrote:
> Not sure if this is what you had in mind (maybe I should call out to 
> m_corona unconditionally?).

I think you're right, unconditionally will be more readable and predictable.


- David


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


On Dec. 2, 2015, 10:53 a.m., Jan Kundrát wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126216/
> ---
> 
> (Updated Dec. 2, 2015, 10:53 a.m.)
> 
> 
> Review request for Plasma and Martin Gräßlin.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Turns out that this method is sometimes called at the time where the
> virtualGeometry() is invalid. Rather than producing values which are
> surely invalid, try to come up with something which might be incorrect
> on some multiscreen setups (right?), but which at least happens to work
> on my setup.
> 
> 
> Diffs
> -
> 
>   shell/panelview.cpp 34075013b22995d81c98d933db596dff520bd812 
> 
> Diff: https://git.reviewboard.kde.org/r/126216/diff/
> 
> 
> Testing
> ---
> 
> Here's how the stack traces look like BTW:
> 
> 389 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:
>  No such file or directory.
> (gdb) bt
> #0  PanelView::positionPanel (this=0x58162660) at 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:389
> #1  0x5559e6a9 in PanelView::containmentChanged (this=0x58162660) 
> at 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:1036
> #2  0x5559fdf5 in PanelView::qt_static_metacall (_o=, 
> _c=, _id=, _a=)
> at 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-_build/shell/moc_panelview.cpp:224
> #3  0x72bbbf79 in QMetaObject::activate (sender=0x58162660, 
> signalOffset=, local_signal_index=local_signal_index@entry=2, 
> argv=argv@entry=0x0)
> at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3713
> #4  0x72bbc6d5 in QMetaObject::activate (sender=, 
> m=m@entry=0x77bd0600 , 
> local_signal_index=local_signal_index@entry=2, argv=argv@entry=0x0) at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3578
> #5  0x779ab309 in PlasmaQuick::ContainmentView::containmentChanged 
> (this=)
> at 
> /var/tmp/portage/kde-frameworks/plasma-/work/plasma-_build/src/plasmaquick/moc_containmentview.cpp:257
> #6  0x779abdf0 in PlasmaQuick::ContainmentViewPrivate::setContainment 
> (this=0x58225fb0, cont=0x55da3270)
> at 
> /var/tmp/portage/kde-frameworks/plasma-/work/plasma-/src/plasmaquick/containmentview.cpp:96
> #7  0x779ac5df in PlasmaQuick::ContainmentView::setContainment 
> (this=this@entry=0x58162660, cont=)
> at 
> /var/tmp/portage/kde-frameworks/plasma-/work/plasma-/src/plasmaquick/containmentview.cpp:246
> #8  0x555b08ab in ShellCorona::createWaitingPanels 
> (this=0x558c6790) at 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/shellcorona.cpp:1023
> #9  0x72bbba00 in call (a=0x7fffce10, r=0x558c6790, 
> this=0x558df440) at 
> ../../include/QtCore/../../../qtcore-5.5./src/corelib/kernel/qobject_impl.h:124
> #10 QMetaObject::activate (sender=sender@entry=0x558c6840, 
> signalOffset=, local_signal_index=local_signal_index@entry=0, 
> argv=argv@entry=0x0)
> at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3698
> #11 0x72bbc6d5 in QMetaObject::activate 
> (sender=sender@entry=0x558c6840, m=m@entry=0x72dd84a0 
> , local_signal_index=local_signal_index@entry=0, 
> argv=argv@entry=0x0) at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3578
> #12 0x72c47016 in QTimer::timeout (this=this@entry=0x558c6840) at 
> .moc/moc_qtimer.cpp:197
> #13 

Re: Review Request 126216: Do not produce negative struts on switching screens

[Jan Kundrát]

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

(Updated Dec. 2, 2015, 11:29 a.m.)


Review request for Plasma and Martin Gräßlin.


Changes
---

using the KScreen unconditionally


Repository: plasma-workspace


Description
---

Turns out that this method is sometimes called at the time where the
virtualGeometry() is invalid. Rather than producing values which are
surely invalid, try to come up with something which might be incorrect
on some multiscreen setups (right?), but which at least happens to work
on my setup.


Diffs (updated)
-

  shell/panelview.cpp 34075013b22995d81c98d933db596dff520bd812 

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


Testing
---

Here's how the stack traces look like BTW:

389 
/var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:
 No such file or directory.
(gdb) bt
#0  PanelView::positionPanel (this=0x58162660) at 
/var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:389
#1  0x5559e6a9 in PanelView::containmentChanged (this=0x58162660) 
at 
/var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:1036
#2  0x5559fdf5 in PanelView::qt_static_metacall (_o=, 
_c=, _id=, _a=)
at 
/var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-_build/shell/moc_panelview.cpp:224
#3  0x72bbbf79 in QMetaObject::activate (sender=0x58162660, 
signalOffset=, local_signal_index=local_signal_index@entry=2, 
argv=argv@entry=0x0)
at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3713
#4  0x72bbc6d5 in QMetaObject::activate (sender=, 
m=m@entry=0x77bd0600 , 
local_signal_index=local_signal_index@entry=2, argv=argv@entry=0x0) at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3578
#5  0x779ab309 in PlasmaQuick::ContainmentView::containmentChanged 
(this=)
at 
/var/tmp/portage/kde-frameworks/plasma-/work/plasma-_build/src/plasmaquick/moc_containmentview.cpp:257
#6  0x779abdf0 in PlasmaQuick::ContainmentViewPrivate::setContainment 
(this=0x58225fb0, cont=0x55da3270)
at 
/var/tmp/portage/kde-frameworks/plasma-/work/plasma-/src/plasmaquick/containmentview.cpp:96
#7  0x779ac5df in PlasmaQuick::ContainmentView::setContainment 
(this=this@entry=0x58162660, cont=)
at 
/var/tmp/portage/kde-frameworks/plasma-/work/plasma-/src/plasmaquick/containmentview.cpp:246
#8  0x555b08ab in ShellCorona::createWaitingPanels 
(this=0x558c6790) at 
/var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/shellcorona.cpp:1023
#9  0x72bbba00 in call (a=0x7fffce10, r=0x558c6790, 
this=0x558df440) at 
../../include/QtCore/../../../qtcore-5.5./src/corelib/kernel/qobject_impl.h:124
#10 QMetaObject::activate (sender=sender@entry=0x558c6840, 
signalOffset=, local_signal_index=local_signal_index@entry=0, 
argv=argv@entry=0x0)
at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3698
#11 0x72bbc6d5 in QMetaObject::activate 
(sender=sender@entry=0x558c6840, m=m@entry=0x72dd84a0 
, local_signal_index=local_signal_index@entry=0, 
argv=argv@entry=0x0) at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3578
#12 0x72c47016 in QTimer::timeout (this=this@entry=0x558c6840) at 
.moc/moc_qtimer.cpp:197
#13 0x72bca552 in QTimer::timerEvent (this=0x558c6840, e=) at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qtimer.cpp:247
#14 0x72bbd2b4 in QObject::event (this=0x558c6840, e=) at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:1220
#15 0x73672c1c in QApplicationPrivate::notify_helper 
(this=this@entry=0x55810f70, receiver=receiver@entry=0x558c6840, 
e=e@entry=0x7fffd240)
at 
/var/tmp/portage/dev-qt/qtwidgets-5.5./work/qtwidgets-5.5./src/widgets/kernel/qapplication.cpp:3716
#16 0x7367847a in QApplication::notify (this=0x7fffd670, 
receiver=0x558c6840, e=0x7fffd240)
at 
/var/tmp/portage/dev-qt/qtwidgets-5.5./work/qtwidgets-5.5./src/widgets/kernel/qapplication.cpp:3499
#17 0x72b8c57d in QCoreApplication::notifyInternal 
(this=0x7fffd670, receiver=0x558c6840, event=event@entry=0x7fffd240)
at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qcoreapplication.cpp:965
#18 0x72be60cc in sendEvent (event=0x7fffd240, receiver=) at 

Re: Review Request 126216: Do not produce negative struts on switching screens

[David Edmundson]

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

Ship it!


- David Edmundson


On Dec. 2, 2015, 11:29 a.m., Jan Kundrát wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126216/
> ---
> 
> (Updated Dec. 2, 2015, 11:29 a.m.)
> 
> 
> Review request for Plasma and Martin Gräßlin.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Turns out that this method is sometimes called at the time where the
> virtualGeometry() is invalid. Rather than producing values which are
> surely invalid, try to come up with something which might be incorrect
> on some multiscreen setups (right?), but which at least happens to work
> on my setup.
> 
> 
> Diffs
> -
> 
>   shell/panelview.cpp 34075013b22995d81c98d933db596dff520bd812 
> 
> Diff: https://git.reviewboard.kde.org/r/126216/diff/
> 
> 
> Testing
> ---
> 
> Here's how the stack traces look like BTW:
> 
> 389 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:
>  No such file or directory.
> (gdb) bt
> #0  PanelView::positionPanel (this=0x58162660) at 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:389
> #1  0x5559e6a9 in PanelView::containmentChanged (this=0x58162660) 
> at 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:1036
> #2  0x5559fdf5 in PanelView::qt_static_metacall (_o=, 
> _c=, _id=, _a=)
> at 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-_build/shell/moc_panelview.cpp:224
> #3  0x72bbbf79 in QMetaObject::activate (sender=0x58162660, 
> signalOffset=, local_signal_index=local_signal_index@entry=2, 
> argv=argv@entry=0x0)
> at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3713
> #4  0x72bbc6d5 in QMetaObject::activate (sender=, 
> m=m@entry=0x77bd0600 , 
> local_signal_index=local_signal_index@entry=2, argv=argv@entry=0x0) at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3578
> #5  0x779ab309 in PlasmaQuick::ContainmentView::containmentChanged 
> (this=)
> at 
> /var/tmp/portage/kde-frameworks/plasma-/work/plasma-_build/src/plasmaquick/moc_containmentview.cpp:257
> #6  0x779abdf0 in PlasmaQuick::ContainmentViewPrivate::setContainment 
> (this=0x58225fb0, cont=0x55da3270)
> at 
> /var/tmp/portage/kde-frameworks/plasma-/work/plasma-/src/plasmaquick/containmentview.cpp:96
> #7  0x779ac5df in PlasmaQuick::ContainmentView::setContainment 
> (this=this@entry=0x58162660, cont=)
> at 
> /var/tmp/portage/kde-frameworks/plasma-/work/plasma-/src/plasmaquick/containmentview.cpp:246
> #8  0x555b08ab in ShellCorona::createWaitingPanels 
> (this=0x558c6790) at 
> /var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/shellcorona.cpp:1023
> #9  0x72bbba00 in call (a=0x7fffce10, r=0x558c6790, 
> this=0x558df440) at 
> ../../include/QtCore/../../../qtcore-5.5./src/corelib/kernel/qobject_impl.h:124
> #10 QMetaObject::activate (sender=sender@entry=0x558c6840, 
> signalOffset=, local_signal_index=local_signal_index@entry=0, 
> argv=argv@entry=0x0)
> at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3698
> #11 0x72bbc6d5 in QMetaObject::activate 
> (sender=sender@entry=0x558c6840, m=m@entry=0x72dd84a0 
> , local_signal_index=local_signal_index@entry=0, 
> argv=argv@entry=0x0) at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3578
> #12 0x72c47016 in QTimer::timeout (this=this@entry=0x558c6840) at 
> .moc/moc_qtimer.cpp:197
> #13 0x72bca552 in QTimer::timerEvent (this=0x558c6840, 
> e=) at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qtimer.cpp:247
> #14 0x72bbd2b4 in QObject::event (this=0x558c6840, e= out>) at 
> /var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:1220
> #15 0x73672c1c in QApplicationPrivate::notify_helper 
> (this=this@entry=0x55810f70, receiver=receiver@entry=0x558c6840, 
> e=e@entry=0x7fffd240)
> at 
> /var/tmp/portage/dev-qt/qtwidgets-5.5./work/qtwidgets-5.5./src/widgets/kernel/qapplication.cpp:3716
> #16 0x7367847a in QApplication::notify (this=0x7fffd670, 
> receiver=0x558c6840, e=0x7fffd240)
> at 
> 

Re: Review Request 126216: Do not produce negative struts on switching screens

[Jan Kundrát]

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

(Updated Dec. 2, 2015, 12:34 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma and Martin Gräßlin.


Changes
---

Submitted with commit 0059d87b6f74f950b2aac94763c2934ec710c6c4 by Jan Kundrát 
to branch master.


Repository: plasma-workspace


Description
---

Turns out that this method is sometimes called at the time where the
virtualGeometry() is invalid. Rather than producing values which are
surely invalid, try to come up with something which might be incorrect
on some multiscreen setups (right?), but which at least happens to work
on my setup.


Diffs
-

  shell/panelview.cpp 34075013b22995d81c98d933db596dff520bd812 

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


Testing
---

Here's how the stack traces look like BTW:

389 
/var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:
 No such file or directory.
(gdb) bt
#0  PanelView::positionPanel (this=0x58162660) at 
/var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:389
#1  0x5559e6a9 in PanelView::containmentChanged (this=0x58162660) 
at 
/var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/panelview.cpp:1036
#2  0x5559fdf5 in PanelView::qt_static_metacall (_o=, 
_c=, _id=, _a=)
at 
/var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-_build/shell/moc_panelview.cpp:224
#3  0x72bbbf79 in QMetaObject::activate (sender=0x58162660, 
signalOffset=, local_signal_index=local_signal_index@entry=2, 
argv=argv@entry=0x0)
at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3713
#4  0x72bbc6d5 in QMetaObject::activate (sender=, 
m=m@entry=0x77bd0600 , 
local_signal_index=local_signal_index@entry=2, argv=argv@entry=0x0) at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3578
#5  0x779ab309 in PlasmaQuick::ContainmentView::containmentChanged 
(this=)
at 
/var/tmp/portage/kde-frameworks/plasma-/work/plasma-_build/src/plasmaquick/moc_containmentview.cpp:257
#6  0x779abdf0 in PlasmaQuick::ContainmentViewPrivate::setContainment 
(this=0x58225fb0, cont=0x55da3270)
at 
/var/tmp/portage/kde-frameworks/plasma-/work/plasma-/src/plasmaquick/containmentview.cpp:96
#7  0x779ac5df in PlasmaQuick::ContainmentView::setContainment 
(this=this@entry=0x58162660, cont=)
at 
/var/tmp/portage/kde-frameworks/plasma-/work/plasma-/src/plasmaquick/containmentview.cpp:246
#8  0x555b08ab in ShellCorona::createWaitingPanels 
(this=0x558c6790) at 
/var/tmp/portage/kde-plasma/plasma-workspace-/work/plasma-workspace-/shell/shellcorona.cpp:1023
#9  0x72bbba00 in call (a=0x7fffce10, r=0x558c6790, 
this=0x558df440) at 
../../include/QtCore/../../../qtcore-5.5./src/corelib/kernel/qobject_impl.h:124
#10 QMetaObject::activate (sender=sender@entry=0x558c6840, 
signalOffset=, local_signal_index=local_signal_index@entry=0, 
argv=argv@entry=0x0)
at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3698
#11 0x72bbc6d5 in QMetaObject::activate 
(sender=sender@entry=0x558c6840, m=m@entry=0x72dd84a0 
, local_signal_index=local_signal_index@entry=0, 
argv=argv@entry=0x0) at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:3578
#12 0x72c47016 in QTimer::timeout (this=this@entry=0x558c6840) at 
.moc/moc_qtimer.cpp:197
#13 0x72bca552 in QTimer::timerEvent (this=0x558c6840, e=) at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qtimer.cpp:247
#14 0x72bbd2b4 in QObject::event (this=0x558c6840, e=) at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qobject.cpp:1220
#15 0x73672c1c in QApplicationPrivate::notify_helper 
(this=this@entry=0x55810f70, receiver=receiver@entry=0x558c6840, 
e=e@entry=0x7fffd240)
at 
/var/tmp/portage/dev-qt/qtwidgets-5.5./work/qtwidgets-5.5./src/widgets/kernel/qapplication.cpp:3716
#16 0x7367847a in QApplication::notify (this=0x7fffd670, 
receiver=0x558c6840, e=0x7fffd240)
at 
/var/tmp/portage/dev-qt/qtwidgets-5.5./work/qtwidgets-5.5./src/widgets/kernel/qapplication.cpp:3499
#17 0x72b8c57d in QCoreApplication::notifyInternal 
(this=0x7fffd670, receiver=0x558c6840, event=event@entry=0x7fffd240)
at 
/var/tmp/portage/dev-qt/qtcore-5.5./work/qtcore-5.5./src/corelib/kernel/qcoreapplication.cpp:965

Re: Review Request 126166: use stylesheets in breeze icons

[andreas kainz]

> On Nov. 26, 2015, 5 p.m., Marco Martin wrote:
> > *please* VDG people, take a look at this asap. I already seen that new 
> > changes have been done to icons in master, which means that i'll have to 
> > redo this from scratch.
> 
> Uri Herrera wrote:
> This needs to be documented first. Properly. Once it's documented then 
> we'll go on with the change.
> 
> Marco Martin wrote:
> the documentation talking about it so far is
> 
> https://techbase.kde.org/Development/Tutorials/Plasma5/ThemeDetails#Using_system_colors
> 
> I know is just a small paragraph, but i'm not sure what's needed more to 
> be clearly understandable.. I can expand on that if I am explained the 
> unclear points.
> 
> Uri Herrera wrote:
> If I run apply-stylesheet.sh in icons that don't have the attribute the 
> script will add it? or would I have to run currentColorFix.sh first and then 
> apply-stylesheet.sh?.
> 
> Marco Martin wrote:
> it should add it, it depends also what are the colors used, as in those 
> icons the monochrome dark color is #4d4d4d, would need the parameters 
> --TextFrom=#4d4d4d --TextTo=#4d4d4d  that tells what color to replace with 
> the TextColor class.
> 
> Marco Martin wrote:
> anyways, if the status in the tarball is still current, would be good to 
> apply it, as I see so far only system-lock-screen has diverged (and a 
> mimetype added)

hi 

I don't know how I can test them but I would prefere an automatic solution also 
for applications cause some applications want to use dark background and than 
the icons should be automatic the dark ones. as we have dark and light icons 
why you don't say plasma dark is used => use dark icons and at the applications 
the same dark color scheme => dark icons. we can also use the stylesheet script 
but than we should reduce the icon set to breeze and breeze dark was generated 
via stylesheet.

sorry for the late replay I didn't have spare time in the past weeks.


- andreas


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


On Nov. 25, 2015, 1:54 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126166/
> ---
> 
> (Updated Nov. 25, 2015, 1:54 p.m.)
> 
> 
> Review request for Plasma, andreas kainz and Uri Herrera.
> 
> 
> Repository: breeze-icons
> 
> 
> Description
> ---
> 
> unfortunately the diff was about 35 megabytes, so was too big for reviewboard 
> little mind ;)
> a tarball of the modified icons can be found at 
> http://notmart.org/misc/breeze-icons.tar.bz2
> this changes the monochrome breeze icons (other icons are untouched) to use 
> stylesheets instead of hardcoded colors, at least with text color for the 
> black bits, background for the light bits.
> This is kinda needed for icons loaded in plasma (even tough some basic icons 
> in the plasma theme systray and actions are still needed, less duplication 
> would be needed)
> Will be needed a bit more stringently in plasma mobile, where the plasma 
> theme is used as theme for applications (and probably some effects will be 
> needed like changing icons from black to white on the fly)
> 
> This change is not supposed to change the look of any icon anywhere: for 
> desktop applications all of them should look *exactly* the same as they did 
> (please doublecheck this ;))
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 886ab74 
> 
> Diff: https://git.reviewboard.kde.org/r/126166/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 126126: kicker: always show arrows for items with children

[Eike Hein]

> On Nov. 30, 2015, 1:50 p.m., Marco Martin wrote:
> > ping? what's the status of this?
> 
> Eike Hein wrote:
> I was waiting for Pino, but here's a shot of the proposed variant:
> 
> ![All arrows everywhere](http://i.imgur.com/FwAmgGZ.png)
> 
> Marco Martin wrote:
> it looks aa bit more busy indeed, but may really help for submenus that 
> have both categories and apps
> 
> Kai Uwe Broulik wrote:
> I like it. It might help to add "usability" to such review requests.
> 
> Martin Klapetek wrote:
> Should kickoff maybe get those arrows too? I think that similar case 
> applies there to its submenus.
> 
> Kai Uwe Broulik wrote:
> Plasma 4 kickoff had them.

I'll enable them in both today.


- Eike


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


On Nov. 21, 2015, 12:25 p.m., Pino Toscano wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126126/
> ---
> 
> (Updated Nov. 21, 2015, 12:25 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> Always show the arrow in menu items which represent a submenu, instead
> of only when hovering on them. This eases the discovery of which items
> are actually submenus as opposed to actual entries.
> 
> 
> Diffs
> -
> 
>   applets/kicker/package/contents/ui/ItemListDelegate.qml 
> becf13d278862b20f46eacae628364708abadfdc 
> 
> Diff: https://git.reviewboard.kde.org/r/126126/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Pino Toscano
> 
>

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

Re: Review Request 126166: use stylesheets in breeze icons

[andreas kainz]

> On Nov. 26, 2015, 5 p.m., Marco Martin wrote:
> > *please* VDG people, take a look at this asap. I already seen that new 
> > changes have been done to icons in master, which means that i'll have to 
> > redo this from scratch.
> 
> Uri Herrera wrote:
> This needs to be documented first. Properly. Once it's documented then 
> we'll go on with the change.
> 
> Marco Martin wrote:
> the documentation talking about it so far is
> 
> https://techbase.kde.org/Development/Tutorials/Plasma5/ThemeDetails#Using_system_colors
> 
> I know is just a small paragraph, but i'm not sure what's needed more to 
> be clearly understandable.. I can expand on that if I am explained the 
> unclear points.
> 
> Uri Herrera wrote:
> If I run apply-stylesheet.sh in icons that don't have the attribute the 
> script will add it? or would I have to run currentColorFix.sh first and then 
> apply-stylesheet.sh?.
> 
> Marco Martin wrote:
> it should add it, it depends also what are the colors used, as in those 
> icons the monochrome dark color is #4d4d4d, would need the parameters 
> --TextFrom=#4d4d4d --TextTo=#4d4d4d  that tells what color to replace with 
> the TextColor class.
> 
> Marco Martin wrote:
> anyways, if the status in the tarball is still current, would be good to 
> apply it, as I see so far only system-lock-screen has diverged (and a 
> mimetype added)
> 
> andreas kainz wrote:
> hi 
> 
> I don't know how I can test them but I would prefere an automatic 
> solution also for applications cause some applications want to use dark 
> background and than the icons should be automatic the dark ones. as we have 
> dark and light icons why you don't say plasma dark is used => use dark icons 
> and at the applications the same dark color scheme => dark icons. we can also 
> use the stylesheet script but than we should reduce the icon set to breeze 
> and breeze dark was generated via stylesheet.
> 
> sorry for the late replay I didn't have spare time in the past weeks.
> 
> Marco Martin wrote:
> the testing i'm interested in, is just to see that they don't change 
> their look when used in normal applications or opened in inkscape.
> i need this stylesheet thing in plasma as in plsma mobile we are going to 
> have different areas where the icon can be either dark or light in the same 
> application, plus applications that define their own color.
> Desktop applications have an old broken way to load icons and there is 
> nothing that can be done, but i don't want to keep being pushed back by that 
> for QML applications that don't have the same limits.
> And yeah, would be quite silly to use a patched clone of the breeze icons 
> for plasma mobile, but that's how we need monochrome icons to be done.
> 
> andreas kainz wrote:
> I open an file with inkscape delete everything say clear file and make 
> everything new. It works. so I would say ship it. but I will have an solution 
> for kde applications also.

I add some icons in icons/status/22 folder so this icons are missing in your 
diff.


- andreas


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


On Nov. 25, 2015, 1:54 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126166/
> ---
> 
> (Updated Nov. 25, 2015, 1:54 p.m.)
> 
> 
> Review request for Plasma, andreas kainz and Uri Herrera.
> 
> 
> Repository: breeze-icons
> 
> 
> Description
> ---
> 
> unfortunately the diff was about 35 megabytes, so was too big for reviewboard 
> little mind ;)
> a tarball of the modified icons can be found at 
> http://notmart.org/misc/breeze-icons.tar.bz2
> this changes the monochrome breeze icons (other icons are untouched) to use 
> stylesheets instead of hardcoded colors, at least with text color for the 
> black bits, background for the light bits.
> This is kinda needed for icons loaded in plasma (even tough some basic icons 
> in the plasma theme systray and actions are still needed, less duplication 
> would be needed)
> Will be needed a bit more stringently in plasma mobile, where the plasma 
> theme is used as theme for applications (and probably some effects will be 
> needed like changing icons from black to white on the fly)
> 
> This change is not supposed to change the look of any icon anywhere: for 
> desktop applications all of them should look *exactly* the same as they did 
> (please doublecheck this ;))
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 886ab74 
> 
> Diff: https://git.reviewboard.kde.org/r/126166/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

5.5 video

[Jonathan Riddell]

Lucas has made a 5.5 video and is after comments for any changes

https://youtu.be/rYUqgFiY5Go

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

Re: Review Request 126016: fix: properly recognise Plasma 5 KCM modules (wmClass=kcmshell5)

[Johan Ouwerkerk]

> On Nov. 11, 2015, 7:14 a.m., Martin Gräßlin wrote:
> > personal comment from X world: this is horrible, horrible ;-) What we 
> > should try is to make the desktop file available to the window. With KF 
> > 5.16 we will have all that's needed available. Let's try to improve this in 
> > Plasma 5.5 and scratch the code completely.
> 
> Eike Hein wrote:
> +1, I want to get rid of hacks, not pile on them
> 
> Johan Ouwerkerk wrote:
> > With KF 5.16 we will have all that's needed available. Let's try to 
> improve this in Plasma 5.5 and scratch the code completely.
> 
> Great and I agree that the code is not great --all those wasted service 
> lookups and subtly broken caching of the answer-- but: where is this 
> alternative code that fixes everything? ;) Right now, I think this change 
> amounts to a trivial fix (just one forgotten case in the if-clause) to an 
> existing 'feature'/workaround that has a fairly immediate benefit (something 
> works again) and little cost: it's hardly a new one.
> 
> Martin Gräßlin wrote:
> yeah sure, this was not meant as a "blocking" comment. I think the change 
> should go in, but leave the decision to Eike.
> 
> I btw. already started working on the improvement by proposing a new 
> addition to the NETWM spec and implementing it in KWindowSystem.
> 
> Johan Ouwerkerk wrote:
> Eike: what's your verdict? To ship or not to ship?
> 
> (In the case of shipping it: please note that I do not have commit access 
> (just a KDE identity account) so please pull these changes because I cannot 
> commit them.)

Now that my developer account has been approved (that took a few weeks), let's 
revisit this:

@Eike: should I push to master or not?


- Johan


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


On Nov. 10, 2015, 6:54 p.m., Johan Ouwerkerk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126016/
> ---
> 
> (Updated Nov. 10, 2015, 6:54 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Previously the taskmanager library contained a special case logic for windows 
> of KDE-4 KCM modules (only).
> These modules were recognised by finding wmClass=Kcmshell4.
> This logic is extended to cover kcmshell5 windows as well, meaning that KCMs 
> written for Plasma 5 are properly recognised now.
> The net benefit is that these KCMs are displayed in the task manager with 
> their proper KCM program icons.
> 
> This patch can be pulled from the kcmshell5-task-url-fixes branch at: 
> g...@github.com:cmacq2/plasma-workspace.git
> 
> 
> Diffs
> -
> 
>   libtaskmanager/taskitem.cpp 3b2a4188fc8ed087a331999aee279ecd919c628e 
> 
> Diff: https://git.reviewboard.kde.org/r/126016/diff/
> 
> 
> Testing
> ---
> 
> Built with kdesrc-build, and tested using: `plasmawindowed 
> org.kde.plasma.icontasks`.
> I checked the change works as expected by running `which kcmshell5` style as 
> well as `kcmshell5 style`: the icon of the window matches that in system 
> settings (as expected).
> 
> 
> Thanks,
> 
> Johan Ouwerkerk
> 
>

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