Re: Re: Stress testing KWin's screen handling

[Martin Gräßlin]

On Tuesday 25 November 2014 16:28:16 Daniel Vrátil wrote:
> On Tuesday 25 of November 2014 13:17:28 Martin Gräßlin wrote:
> > Hi all,
> > 
> > I spent some time on screen management in KWin today and got it to the
> > point where it doesn't fail any more no matter what I try. So please
> > everyone using multiple screens and especially dynamically plug in and
> > out, please give a try to the patch set in [1]. Please ensure to have
> > latest master as it contains a crash fix for a crash triggered by the
> > patch set.
> > 
> > Short summary of the changes in the patch set:
> > * uses XRandR instead of QDesktopWidget
> > * uses KWin internal information about overall screen geometry instead of
> > relying on the information in the X11 screen structure.
> > 
> > The second part is the code I added today. My testing showed that
> > unplugging a screen gives us proper XRandR events so KWin's internal is
> > up to date, but the X11 screen information is wrong. So when we partially
> > used the one and partially the other the rendering was just horribly
> > broken. Now it's all based on the KWin internal information and I
> > couldn't get the rendering broken any more.
> > 
> > When changing screens please be patient. It takes time to settle the
> > changes. Especially plasmashell takes quite some time on my system to
> > render correctly again.
> 
> Coincidentally, I just merged my KScreen redesign, which should make this
> faster.

sounds like I need to trigger kdesrc-build ;-)

> 
> > I hope that it doesn't fail for others and we can get the changes in to
> > improve the situation.
> 
> So far it's much better than before, but still it sometimes happens, that
> after screen reshuffle, window decorations get detached from the windows and
> moved elsewhere. It just happened to me, after plugging in the 3rd screen:
> http://pub.dvratil.cz/kwin-bug.ogv, but I'm not able to reliably reproduce
> this.

ok, that still sounds like a rendering error. A few questions:
* does qdus.org.kde.KWin /KWin supportInformation report correct screen 
information?
* does xrandr report correct screen information?
* does restarting compositing fix it?

For three screens I'm completely out of testing possibilities. I don't have 
three screens and even if I had I would not be able to connect them.

A kingdom, a kingdom for unit testing xrandr.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121253: Fix password focus in lockscreen

[Martin Gräßlin]

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

Ship it!


Ship It!

- Martin Gräßlin


On Nov. 25, 2014, 11:44 p.m., Sebastian Kügler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121253/
> ---
> 
> (Updated Nov. 25, 2014, 11:44 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Fix password focus in lockscreen
> 
> When navigating the listview with the keyboard, the focus of the
> password field can get lost as it moves to the button. This patch
> reclaims the focus whenever the password field becomes visible.
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/lockscreen/LockScreen.qml 
> 8a495ea208325ba3b2ef09efaef49515cc99830d 
> 
> Diff: https://git.reviewboard.kde.org/r/121253/diff/
> 
> 
> Testing
> ---
> 
> Navigated lockscreen with keyboard and mouse. Focus is handled correctly.
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

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

Re: [kde-promo] Plasma 5.1.1 announcement

[Ömer Fadıl USTA]

Link has a typo. "Plasma 5.1
" link is showing to :
http://kde.org/announcements/plasma5.1/index.php
on the other hand it must be :
http://kde.org/announcements/plasma-5.1/index.php

(The - is missing between plasma and 5.1 )

[image: Ömer Fadıl Usta on about.me]

Ömer Fadıl Usta
about.me/omerusta
  

2014-11-25 23:49 GMT+02:00 Albert Astals Cid :

> El Dimecres, 19 de novembre de 2014, a les 10:50:55, Ben Cooksley va
> escriure:
> > On Wed, Nov 19, 2014 at 8:14 AM, Albert Astals Cid 
> wrote:
> > > El Dimarts, 11 de novembre de 2014, a les 22:53:58, Albert Astals Cid
> va
> > >
> > > escriure:
> > >> Hi guys, is there any reason
> > >> https://www.kde.org/announcements/plasma-5.1.1.php
> > >>
> > >> says "Plasma 5 was released in July" and links to
> > >> https://www.kde.org/announcements/plasma5.0/index.php
> > >>
> > >> instead of saying "Plasma 5.1 was released in October" and link to
> > >> https://www.kde.org/announcements/plasma-5.1/index.php
> > >>
> > >> ?
> > >
> > > Was the announcement written by a ghost?
> > >
> > > Or is the person that wrote the announcement for Plasma 5.1.1 not
> > > subscribed to neither kde-promo nor plasma-devel?
> > >
> > > Anyway, if noone oposes i'll fix it to refer Plasma 5.1 instead of
> Plasma
> > > 5.0.
> > I would recommend going ahead and making the change,
>
> Done.
>
> Albert
>
> > I already had to
> > fix the download urls for 5.1.1 which were broken.
> >
> > > Cheers,
> > >
> > >   Albert
> >
> > Thanks,
> > Ben
> >
> > >> Cheers,
> > >>
> > >>   Albert
> > >>
> > >> ___
> > >> This message is from the kde-promo mailing list.
> > >>
> > >> Visit https://mail.kde.org/mailman/listinfo/kde-promo to
> unsubscribe, set
> > >> digest on or temporarily stop your subscription.
> > >
> > > ___
> > > This message is from the kde-promo mailing list.
> > >
> > > Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe,
> set
> > > digest on or temporarily stop your subscription.
> > ___
> > This message is from the kde-promo mailing list.
> >
> > Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe,
> set
> > digest on or temporarily stop your subscription.
>
> ___
> 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 121244: Remove workarounds we had for the nested event loops

[Aleix Pol Gonzalez]

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

(Updated Nov. 25, 2014, 11:58 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: plasma-workspace


Description
---

Instead of keeping the state, expect the code to follow the order it's expected 
from it.

Needs to bump the KF5 requirement to current KDeclarative (master), or it can 
run in problems.


Diffs
-

  CMakeLists.txt 7856833 
  shell/shellcorona.h 37f8b0e 
  shell/shellcorona.cpp fd8e9b7 

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


Testing
---

Been running it for the last week.


Thanks,

Aleix Pol Gonzalez

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

Re: Review Request 121244: Remove workarounds we had for the nested event loops

[Aleix Pol Gonzalez]

> On Nov. 25, 2014, 6:43 p.m., Marco Martin wrote:
> > CMakeLists.txt, line 16
> > 
> >
> > unrelated commit?

No, I just can't enforce 5.4 if Baloo is 5.2, so I moved it into a separate 
find_package call.


- Aleix


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


On Nov. 25, 2014, 6:33 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121244/
> ---
> 
> (Updated Nov. 25, 2014, 6:33 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Instead of keeping the state, expect the code to follow the order it's 
> expected from it.
> 
> Needs to bump the KF5 requirement to current KDeclarative (master), or it can 
> run in problems.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 7856833 
>   shell/shellcorona.h 37f8b0e 
>   shell/shellcorona.cpp fd8e9b7 
> 
> Diff: https://git.reviewboard.kde.org/r/121244/diff/
> 
> 
> Testing
> ---
> 
> Been running it for the last week.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 121240: Port to new KScreen API

[Aleix Pol]

On Tue, Nov 25, 2014 at 9:13 PM, Luca Beltrame  wrote:

> In data martedì 25 novembre 2014 11:48:02, Daniel Vrátil ha scritto:
>
> > ShellCorona is not a public class, so nothing outside plasma-workspace
> needs
> > it, and the rest of plasma-workspace compiles just fine without it.
>
> Posting here for those who missed it in #plasma: this change makes
> plasmashell
> crash if kactivitymanagerd is running (because KScreen isn't done yet and
> yet
> kamd tries to access screenForContainment). The fault lies in
> kactivitymanagerd: I tried to look at the code but I couldn't find anything
> obvious.
>
> Can someone more knowledgeable have an insight of why this happens?
>
> This is the bt:
>
> Thread 1 (Thread 0x7f62be2477c0 (LWP 24141)):
> [KCrash Handler]
> #5  0x7f62bd0f1dc4 in KScreen::Config::outputs() const () at
> /usr/lib64/libKF5Screen.so.5
> #6  0x0044e2a3 in
> ShellCorona::screenForContainment(Plasma::Containment const*) const ()
> #7  0x7f62bc90a2df in Plasma::CoronaPrivate::importLayout(KConfigGroup
> const&, bool) (this=0x2639b20, conf=..., mergeConfig=mergeConfig@entry
> =false)
> at /usr/src/debug/plasma-framework-5.5.0git/src/plasma/corona.cpp:566
> #8  0x7f62bc90a485 in Plasma::Corona::loadLayout(QString const&)
> (this=0x2664b80, configName=...) at /usr/src/debug/plasma-
> framework-5.5.0git/src/plasma/corona.cpp:161
> #9  0x00455581 in  ()
> #10 0x00456b65 in  ()
> #11 0x7f62b883d3e1 in QMetaObject::activate(QObject*, int, int,
> void**) ()
> at /usr/lib64/libQt5Core.so.5
> #12 0x7f62bd3339b1 in
>
> KActivities::Consumer::serviceStatusChanged(KActivities::Consumer::ServiceStatus)
> () at /usr/lib64/libKF5Activities.so.5
> #13 0x7f62b883d3e1 in QMetaObject::activate(QObject*, int, int,
> void**) ()
> at /usr/lib64/libQt5Core.so.5
> #14 0x7f62bd333921 in  () at /usr/lib64/libKF5Activities.so.5
> #15 0x7f62bd32e0b0 in  () at /usr/lib64/libKF5Activities.so.5
> #16 0x7f62bd32f827 in  () at /usr/lib64/libKF5Activities.so.5
> #17 0x7f62bd32d932 in  () at /usr/lib64/libKF5Activities.so.5
> #18 0x7f62bd3341a4 in  () at /usr/lib64/libKF5Activities.so.5
> #19 0x7f62b883d3e1 in QMetaObject::activate(QObject*, int, int,
> void**) ()
> at /usr/lib64/libQt5Core.so.5
> #20 0x7f62b95d1caf in
> QDBusPendingCallWatcher::finished(QDBusPendingCallWatcher*) () at
> /usr/lib64/libQt5DBus.so.5
> #21 0x7f62b95d3337 in  () at /usr/lib64/libQt5DBus.so.5
> #22 0x7f62b883e1e6 in QObject::event(QEvent*) () at
> /usr/lib64/libQt5Core.so.5
> #23 0x7f62b9b602ec in QApplicationPrivate::notify_helper(QObject*,
> QEvent*) () at /usr/lib64/libQt5Widgets.so.5
> #24 0x7f62b9b65350 in QApplication::notify(QObject*, QEvent*) () at
> /usr/lib64/libQt5Widgets.so.5
> #25 0x7f62b880db85 in QCoreApplication::notifyInternal(QObject*,
> QEvent*)
> () at /usr/lib64/libQt5Core.so.5
> #26 0x7f62b880fa1f in
> QCoreApplicationPrivate::sendPostedEvents(QObject*,
> int, QThreadData*) () at /usr/lib64/libQt5Core.so.5
> #27 0x7f62b88659f3 in  () at /usr/lib64/libQt5Core.so.5
> #28 0x7f62b46e6a04 in g_main_context_dispatch () at
> /usr/lib64/libglib-2.0.so.0
> #29 0x7f62b46e6c48 in  () at /usr/lib64/libglib-2.0.so.0
> #30 0x7f62b46e6cec in g_main_context_iteration () at
> /usr/lib64/libglib-2.0.so.0
> #31 0x7f62b8864e6c in
> QEventDispatcherGlib::processEvents(QFlags)
> ()
> at /usr/lib64/libQt5Core.so.5
> #32 0x7f62b880baeb in
> QEventLoop::exec(QFlags) () at
> /usr/lib64/libQt5Core.so.5
> #33 0x7f62b8813156 in QCoreApplication::exec() () at
> /usr/lib64/libQt5Core.so.5
> #34 0x00432024 in main ()
>
>
> --
> Luca Beltrame - KDE Forums team
> KDE Science supporter
> GPG key ID: 6E1A4E79
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
Can you check if you still get this crash now?

http://commits.kde.org/plasma-workspace/55bb013376c8688b74b5401587289b662fc5315b

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

Re: Review Request 121240: Port to new KScreen API

[Aleix Pol]

On Tue, Nov 25, 2014 at 9:13 PM, Luca Beltrame  wrote:

> In data martedì 25 novembre 2014 11:48:02, Daniel Vrátil ha scritto:
>
> > ShellCorona is not a public class, so nothing outside plasma-workspace
> needs
> > it, and the rest of plasma-workspace compiles just fine without it.
>
> Posting here for those who missed it in #plasma: this change makes
> plasmashell
> crash if kactivitymanagerd is running (because KScreen isn't done yet and
> yet
> kamd tries to access screenForContainment). The fault lies in
> kactivitymanagerd: I tried to look at the code but I couldn't find anything
> obvious.
>
> Can someone more knowledgeable have an insight of why this happens?
>
> This is the bt:
>
> Thread 1 (Thread 0x7f62be2477c0 (LWP 24141)):
> [KCrash Handler]
> #5  0x7f62bd0f1dc4 in KScreen::Config::outputs() const () at
> /usr/lib64/libKF5Screen.so.5
> #6  0x0044e2a3 in
> ShellCorona::screenForContainment(Plasma::Containment const*) const ()
> #7  0x7f62bc90a2df in Plasma::CoronaPrivate::importLayout(KConfigGroup
> const&, bool) (this=0x2639b20, conf=..., mergeConfig=mergeConfig@entry
> =false)
> at /usr/src/debug/plasma-framework-5.5.0git/src/plasma/corona.cpp:566
> #8  0x7f62bc90a485 in Plasma::Corona::loadLayout(QString const&)
> (this=0x2664b80, configName=...) at /usr/src/debug/plasma-
> framework-5.5.0git/src/plasma/corona.cpp:161
> #9  0x00455581 in  ()
> #10 0x00456b65 in  ()
> #11 0x7f62b883d3e1 in QMetaObject::activate(QObject*, int, int,
> void**) ()
> at /usr/lib64/libQt5Core.so.5
> #12 0x7f62bd3339b1 in
>
> KActivities::Consumer::serviceStatusChanged(KActivities::Consumer::ServiceStatus)
> () at /usr/lib64/libKF5Activities.so.5
> #13 0x7f62b883d3e1 in QMetaObject::activate(QObject*, int, int,
> void**) ()
> at /usr/lib64/libQt5Core.so.5
> #14 0x7f62bd333921 in  () at /usr/lib64/libKF5Activities.so.5
> #15 0x7f62bd32e0b0 in  () at /usr/lib64/libKF5Activities.so.5
> #16 0x7f62bd32f827 in  () at /usr/lib64/libKF5Activities.so.5
> #17 0x7f62bd32d932 in  () at /usr/lib64/libKF5Activities.so.5
> #18 0x7f62bd3341a4 in  () at /usr/lib64/libKF5Activities.so.5
> #19 0x7f62b883d3e1 in QMetaObject::activate(QObject*, int, int,
> void**) ()
> at /usr/lib64/libQt5Core.so.5
> #20 0x7f62b95d1caf in
> QDBusPendingCallWatcher::finished(QDBusPendingCallWatcher*) () at
> /usr/lib64/libQt5DBus.so.5
> #21 0x7f62b95d3337 in  () at /usr/lib64/libQt5DBus.so.5
> #22 0x7f62b883e1e6 in QObject::event(QEvent*) () at
> /usr/lib64/libQt5Core.so.5
> #23 0x7f62b9b602ec in QApplicationPrivate::notify_helper(QObject*,
> QEvent*) () at /usr/lib64/libQt5Widgets.so.5
> #24 0x7f62b9b65350 in QApplication::notify(QObject*, QEvent*) () at
> /usr/lib64/libQt5Widgets.so.5
> #25 0x7f62b880db85 in QCoreApplication::notifyInternal(QObject*,
> QEvent*)
> () at /usr/lib64/libQt5Core.so.5
> #26 0x7f62b880fa1f in
> QCoreApplicationPrivate::sendPostedEvents(QObject*,
> int, QThreadData*) () at /usr/lib64/libQt5Core.so.5
> #27 0x7f62b88659f3 in  () at /usr/lib64/libQt5Core.so.5
> #28 0x7f62b46e6a04 in g_main_context_dispatch () at
> /usr/lib64/libglib-2.0.so.0
> #29 0x7f62b46e6c48 in  () at /usr/lib64/libglib-2.0.so.0
> #30 0x7f62b46e6cec in g_main_context_iteration () at
> /usr/lib64/libglib-2.0.so.0
> #31 0x7f62b8864e6c in
> QEventDispatcherGlib::processEvents(QFlags)
> ()
> at /usr/lib64/libQt5Core.so.5
> #32 0x7f62b880baeb in
> QEventLoop::exec(QFlags) () at
> /usr/lib64/libQt5Core.so.5
> #33 0x7f62b8813156 in QCoreApplication::exec() () at
> /usr/lib64/libQt5Core.so.5
> #34 0x00432024 in main ()
>
>
> --
> Luca Beltrame - KDE Forums team
> KDE Science supporter
> GPG key ID: 6E1A4E79
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
I'm getting crashes too, investigating

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

Re: Review Request 121240: Port to new KScreen API

[Luca Beltrame]

In data martedì 25 novembre 2014 21:13:07, Luca Beltrame ha scritto:

> plasmashell crash if kactivitymanagerd is running (because KScreen isn't
> done yet and yet kamd tries to access screenForContainment). The fault lies

Follow up: I noticed that in the KCM the primary display was reset as not 
defined. When setting a primary display, the crash does not occur.

-- 
Luca Beltrame - KDE Forums team
KDE Science supporter
GPG key ID: 6E1A4E79


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 121253: Fix password focus in lockscreen

[Sebastian Kügler]

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

Review request for Plasma.


Repository: plasma-workspace


Description
---

Fix password focus in lockscreen

When navigating the listview with the keyboard, the focus of the
password field can get lost as it moves to the button. This patch
reclaims the focus whenever the password field becomes visible.


Diffs
-

  lookandfeel/contents/lockscreen/LockScreen.qml 
8a495ea208325ba3b2ef09efaef49515cc99830d 

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


Testing
---

Navigated lockscreen with keyboard and mouse. Focus is handled correctly.


Thanks,

Sebastian Kügler

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

Re: [kde-promo] Plasma 5.1.1 announcement

[Albert Astals Cid]

El Dimecres, 19 de novembre de 2014, a les 10:50:55, Ben Cooksley va escriure:
> On Wed, Nov 19, 2014 at 8:14 AM, Albert Astals Cid  wrote:
> > El Dimarts, 11 de novembre de 2014, a les 22:53:58, Albert Astals Cid va
> > 
> > escriure:
> >> Hi guys, is there any reason
> >> https://www.kde.org/announcements/plasma-5.1.1.php
> >> 
> >> says "Plasma 5 was released in July" and links to
> >> https://www.kde.org/announcements/plasma5.0/index.php
> >> 
> >> instead of saying "Plasma 5.1 was released in October" and link to
> >> https://www.kde.org/announcements/plasma-5.1/index.php
> >> 
> >> ?
> > 
> > Was the announcement written by a ghost?
> > 
> > Or is the person that wrote the announcement for Plasma 5.1.1 not
> > subscribed to neither kde-promo nor plasma-devel?
> > 
> > Anyway, if noone oposes i'll fix it to refer Plasma 5.1 instead of Plasma
> > 5.0.
> I would recommend going ahead and making the change, 

Done.

Albert

> I already had to
> fix the download urls for 5.1.1 which were broken.
> 
> > Cheers,
> > 
> >   Albert
> 
> Thanks,
> Ben
> 
> >> Cheers,
> >> 
> >>   Albert
> >> 
> >> ___
> >> This message is from the kde-promo mailing list.
> >> 
> >> Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set
> >> digest on or temporarily stop your subscription.
> > 
> > ___
> > This message is from the kde-promo mailing list.
> > 
> > Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set
> > digest on or temporarily stop your subscription.
> ___
> This message is from the kde-promo mailing list.
> 
> Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set
> digest on or temporarily stop your subscription.

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

Re: Review Request 121240: Port to new KScreen API

[Luca Beltrame]

In data martedì 25 novembre 2014 11:48:02, Daniel Vrátil ha scritto:

> ShellCorona is not a public class, so nothing outside plasma-workspace needs
> it, and the rest of plasma-workspace compiles just fine without it.

Posting here for those who missed it in #plasma: this change makes plasmashell 
crash if kactivitymanagerd is running (because KScreen isn't done yet and yet 
kamd tries to access screenForContainment). The fault lies in 
kactivitymanagerd: I tried to look at the code but I couldn't find anything 
obvious.

Can someone more knowledgeable have an insight of why this happens?

This is the bt:

Thread 1 (Thread 0x7f62be2477c0 (LWP 24141)):
[KCrash Handler]
#5  0x7f62bd0f1dc4 in KScreen::Config::outputs() const () at 
/usr/lib64/libKF5Screen.so.5
#6  0x0044e2a3 in 
ShellCorona::screenForContainment(Plasma::Containment const*) const ()
#7  0x7f62bc90a2df in Plasma::CoronaPrivate::importLayout(KConfigGroup 
const&, bool) (this=0x2639b20, conf=..., mergeConfig=mergeConfig@entry=false) 
at /usr/src/debug/plasma-framework-5.5.0git/src/plasma/corona.cpp:566
#8  0x7f62bc90a485 in Plasma::Corona::loadLayout(QString const&) 
(this=0x2664b80, configName=...) at /usr/src/debug/plasma-
framework-5.5.0git/src/plasma/corona.cpp:161
#9  0x00455581 in  ()
#10 0x00456b65 in  ()
#11 0x7f62b883d3e1 in QMetaObject::activate(QObject*, int, int, void**) () 
at /usr/lib64/libQt5Core.so.5
#12 0x7f62bd3339b1 in 
KActivities::Consumer::serviceStatusChanged(KActivities::Consumer::ServiceStatus)
 
() at /usr/lib64/libKF5Activities.so.5
#13 0x7f62b883d3e1 in QMetaObject::activate(QObject*, int, int, void**) () 
at /usr/lib64/libQt5Core.so.5
#14 0x7f62bd333921 in  () at /usr/lib64/libKF5Activities.so.5
#15 0x7f62bd32e0b0 in  () at /usr/lib64/libKF5Activities.so.5
#16 0x7f62bd32f827 in  () at /usr/lib64/libKF5Activities.so.5
#17 0x7f62bd32d932 in  () at /usr/lib64/libKF5Activities.so.5
#18 0x7f62bd3341a4 in  () at /usr/lib64/libKF5Activities.so.5
#19 0x7f62b883d3e1 in QMetaObject::activate(QObject*, int, int, void**) () 
at /usr/lib64/libQt5Core.so.5
#20 0x7f62b95d1caf in 
QDBusPendingCallWatcher::finished(QDBusPendingCallWatcher*) () at 
/usr/lib64/libQt5DBus.so.5
#21 0x7f62b95d3337 in  () at /usr/lib64/libQt5DBus.so.5
#22 0x7f62b883e1e6 in QObject::event(QEvent*) () at 
/usr/lib64/libQt5Core.so.5
#23 0x7f62b9b602ec in QApplicationPrivate::notify_helper(QObject*, 
QEvent*) () at /usr/lib64/libQt5Widgets.so.5
#24 0x7f62b9b65350 in QApplication::notify(QObject*, QEvent*) () at 
/usr/lib64/libQt5Widgets.so.5
#25 0x7f62b880db85 in QCoreApplication::notifyInternal(QObject*, QEvent*) 
() at /usr/lib64/libQt5Core.so.5
#26 0x7f62b880fa1f in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) () at /usr/lib64/libQt5Core.so.5
#27 0x7f62b88659f3 in  () at /usr/lib64/libQt5Core.so.5
#28 0x7f62b46e6a04 in g_main_context_dispatch () at 
/usr/lib64/libglib-2.0.so.0
#29 0x7f62b46e6c48 in  () at /usr/lib64/libglib-2.0.so.0
#30 0x7f62b46e6cec in g_main_context_iteration () at 
/usr/lib64/libglib-2.0.so.0
#31 0x7f62b8864e6c in 
QEventDispatcherGlib::processEvents(QFlags) () 
at /usr/lib64/libQt5Core.so.5
#32 0x7f62b880baeb in 
QEventLoop::exec(QFlags) () at 
/usr/lib64/libQt5Core.so.5
#33 0x7f62b8813156 in QCoreApplication::exec() () at 
/usr/lib64/libQt5Core.so.5
#34 0x00432024 in main ()


-- 
Luca Beltrame - KDE Forums team
KDE Science supporter
GPG key ID: 6E1A4E79


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121244: Remove workarounds we had for the nested event loops

[Marco Martin]

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

Ship it!



CMakeLists.txt


unrelated commit?


- Marco Martin


On Nov. 25, 2014, 6:33 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121244/
> ---
> 
> (Updated Nov. 25, 2014, 6:33 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Instead of keeping the state, expect the code to follow the order it's 
> expected from it.
> 
> Needs to bump the KF5 requirement to current KDeclarative (master), or it can 
> run in problems.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 7856833 
>   shell/shellcorona.h 37f8b0e 
>   shell/shellcorona.cpp fd8e9b7 
> 
> Diff: https://git.reviewboard.kde.org/r/121244/diff/
> 
> 
> Testing
> ---
> 
> Been running it for the last week.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Review Request 121244: Remove workarounds we had for the nested event loops

[Aleix Pol Gonzalez]

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

Review request for Plasma.


Repository: plasma-workspace


Description
---

Instead of keeping the state, expect the code to follow the order it's expected 
from it.

Needs to bump the KF5 requirement to current KDeclarative (master), or it can 
run in problems.


Diffs
-

  CMakeLists.txt 7856833 
  shell/shellcorona.h 37f8b0e 
  shell/shellcorona.cpp fd8e9b7 

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


Testing
---

Been running it for the last week.


Thanks,

Aleix Pol Gonzalez

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

Re: Review Request 121201: KRunner: Do not detect anything with a '.' as a NetworkLocation

[Vishesh Handa]

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


ping.

It would be nice if someone could comment on this. I cannot use Qt 5.4 right 
now.

- Vishesh Handa


On Nov. 21, 2014, 6:10 p.m., Vishesh Handa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121201/
> ---
> 
> (Updated Nov. 21, 2014, 6:10 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 340140
> https://bugs.kde.org/show_bug.cgi?id=340140
> 
> 
> Repository: krunner
> 
> 
> Description
> ---
> 
> One can also uses a decimal point in a calculator.
> 
> 
> Diffs
> -
> 
>   autotests/runnercontexttest.cpp ba5f6a1 
>   src/runnercontext.cpp 2d6177d 
> 
> Diff: https://git.reviewboard.kde.org/r/121201/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>

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

Change in plasma-framework[master]: use PlasmaCore.ColorScope when suitable

[Marco Martin (Code Review)]

Marco Martin has uploaded a new change for review.

  https://gerrit.vesnicky.cesnet.cz/r/177

Change subject: use PlasmaCore.ColorScope when suitable
..

use PlasmaCore.ColorScope when suitable

It is possible to put a PlasmaCore.ColorScope element, to automatically
change the colors:
if for instance the complementary scope will be set, all labels
descendent of such element would flip their color

Change-Id: I2214aca522eb094cf067d8726c5bf2a7ecbf36b3
---
M src/declarativeimports/plasmacomponents/qml/Label.qml
M src/declarativeimports/plasmacomponents/qml/styles/TextAreaStyle.qml
M src/declarativeimports/plasmacomponents/qml/styles/ToolButtonStyle.qml
3 files changed, 5 insertions(+), 5 deletions(-)


  git pull ssh://gerrit.vesnicky.cesnet.cz:29418/plasma-framework 
refs/changes/77/177/1

diff --git a/src/declarativeimports/plasmacomponents/qml/Label.qml 
b/src/declarativeimports/plasmacomponents/qml/Label.qml
index 1243ca6..a22efb6 100644
--- a/src/declarativeimports/plasmacomponents/qml/Label.qml
+++ b/src/declarativeimports/plasmacomponents/qml/Label.qml
@@ -50,7 +50,7 @@
 font.underline: theme.defaultFont.underline
 font.weight: theme.defaultFont.weight
 font.wordSpacing: theme.defaultFont.wordSpacing
-color: theme.textColor
+color: PlasmaCore.ColorScope.textColor
 
 opacity: enabled? 1 : 0.6
 
diff --git 
a/src/declarativeimports/plasmacomponents/qml/styles/TextAreaStyle.qml 
b/src/declarativeimports/plasmacomponents/qml/styles/TextAreaStyle.qml
index 68f1a8b..90af0c5 100644
--- a/src/declarativeimports/plasmacomponents/qml/styles/TextAreaStyle.qml
+++ b/src/declarativeimports/plasmacomponents/qml/styles/TextAreaStyle.qml
@@ -36,9 +36,9 @@
 
 font: theme.defaultFont
 backgroundColor: "transparent"
-textColor: theme.viewTextColor
-selectionColor: theme.viewFocusColor
-selectedTextColor: theme.viewBackgroundColor
+textColor: control.backgroundVisible ? theme.viewTextColor : 
PlasmaCore.ColorScope.textColor
+selectionColor: control.backgroundVisible ? theme.viewFocusColor : 
PlasmaCore.ColorScope.highlightColor
+selectedTextColor: control.backgroundVisible ? theme.viewBackgroundColor : 
PlasmaCore.ColorScope.backgroundColor
 
 renderType: Text.NativeRendering
 
diff --git 
a/src/declarativeimports/plasmacomponents/qml/styles/ToolButtonStyle.qml 
b/src/declarativeimports/plasmacomponents/qml/styles/ToolButtonStyle.qml
index af04469..cf19524 100644
--- a/src/declarativeimports/plasmacomponents/qml/styles/ToolButtonStyle.qml
+++ b/src/declarativeimports/plasmacomponents/qml/styles/ToolButtonStyle.qml
@@ -87,7 +87,7 @@
 visible: control.text != ""
 Layout.fillWidth: true
 height: parent.height
-color: control.hovered || !control.flat ? 
theme.buttonTextColor : theme.textColor
+color: control.hovered || !control.flat ? 
theme.buttonTextColor : PlasmaCore.ColorScope.textColor
 horizontalAlignment: icon.valid ? Text.AlignLeft : 
Text.AlignHCenter
 verticalAlignment: Text.AlignVCenter
 elide: Text.ElideRight

-- 
To view, visit https://gerrit.vesnicky.cesnet.cz/r/177
To unsubscribe, visit https://gerrit.vesnicky.cesnet.cz/r/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I2214aca522eb094cf067d8726c5bf2a7ecbf36b3
Gerrit-PatchSet: 1
Gerrit-Project: plasma-framework
Gerrit-Branch: master
Gerrit-Owner: Marco Martin 
Gerrit-Reviewer: David Edmundson 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 120777: Plasma Active: Initial commit for Baloo Cloud Component

[Marco Martin]

> On Nov. 25, 2014, 3:39 p.m., Vishesh Handa wrote:
> > components/timelinemodel/timelinemodel.cpp, line 144
> > 
> >
> > Just my opinion -
> > 
> > An assert would be better since m_level is an enum and should NEVER be 
> > any other value apart from those 3.

+1


> On Nov. 25, 2014, 3:39 p.m., Vishesh Handa wrote:
> > components/timelinemodel/timelinemodel.cpp, line 103
> > 
> >
> > I'm a little confused. Where is this value being used?

yeah, this doesn't look right.

the query should be constructed in a way that only results within dates between 
startDate and endDate are considered.
right now those values don't seem used at all?


- Marco


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


On Nov. 25, 2014, 3:11 p.m., Antonis Tsiapaliokas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120777/
> ---
> 
> (Updated Nov. 25, 2014, 3:11 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-mobile
> 
> 
> Description
> ---
> 
> At the moment, Baloo doesn't provide a timeline, which is something that we 
> need for the activefilebrowser.
> So this new component, is introducing support for the timeline.
> 
> Notes
> ===
> 
> * Baloocloud component contains the org.kde.baloo component inside it.The 
> reason behind that, is that the implementation for the timeline is kind of 
> terible because of its perfomance.
> * I have put the new component inside the plasma-mobile repository, for the 
> above reason. But if the Baloo team, wants it inside the baloo repo then i 
> can move it. I am fine with both approaches (keep it here or in the baloo 
> repository.
> * If someone has a better idea about the implementation, the pls shoot :)
>   
> 
> 
> Diffs
> -
> 
>   components/CMakeLists.txt 536b60e 
>   components/timelinemodel/CMakeLists.txt PRE-CREATION 
>   components/timelinemodel/qmldir PRE-CREATION 
>   components/timelinemodel/timelinemodel.h PRE-CREATION 
>   components/timelinemodel/timelinemodel.cpp PRE-CREATION 
>   components/timelinemodel/timelineplugin.h PRE-CREATION 
>   components/timelinemodel/timelineplugin.cpp PRE-CREATION 
>   CMakeLists.txt 9466447 
> 
> Diff: https://git.reviewboard.kde.org/r/120777/diff/
> 
> 
> Testing
> ---
> 
> Everything looks ok. The performance is not bad, except from the fact that 
> the implementation is a bit of hackish...
> 
> 
> Thanks,
> 
> Antonis Tsiapaliokas
> 
>

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

Re: Review Request 120777: Plasma Active: Initial commit for Baloo Cloud Component

[Vishesh Handa]

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



components/timelinemodel/qmldir


I would prefer the module not having the word "baloo" in it.



components/timelinemodel/timelinemodel.cpp


How about makinng generateTimeLine a SLOT as well. This way you can just 
hook it up directly?



components/timelinemodel/timelinemodel.cpp


I'm a little confused. Where is this value being used?



components/timelinemodel/timelinemodel.cpp


Just my opinion -

An assert would be better since m_level is an enum and should NEVER be any 
other value apart from those 3.


- Vishesh Handa


On Nov. 25, 2014, 3:11 p.m., Antonis Tsiapaliokas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120777/
> ---
> 
> (Updated Nov. 25, 2014, 3:11 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-mobile
> 
> 
> Description
> ---
> 
> At the moment, Baloo doesn't provide a timeline, which is something that we 
> need for the activefilebrowser.
> So this new component, is introducing support for the timeline.
> 
> Notes
> ===
> 
> * Baloocloud component contains the org.kde.baloo component inside it.The 
> reason behind that, is that the implementation for the timeline is kind of 
> terible because of its perfomance.
> * I have put the new component inside the plasma-mobile repository, for the 
> above reason. But if the Baloo team, wants it inside the baloo repo then i 
> can move it. I am fine with both approaches (keep it here or in the baloo 
> repository.
> * If someone has a better idea about the implementation, the pls shoot :)
>   
> 
> 
> Diffs
> -
> 
>   components/CMakeLists.txt 536b60e 
>   components/timelinemodel/CMakeLists.txt PRE-CREATION 
>   components/timelinemodel/qmldir PRE-CREATION 
>   components/timelinemodel/timelinemodel.h PRE-CREATION 
>   components/timelinemodel/timelinemodel.cpp PRE-CREATION 
>   components/timelinemodel/timelineplugin.h PRE-CREATION 
>   components/timelinemodel/timelineplugin.cpp PRE-CREATION 
>   CMakeLists.txt 9466447 
> 
> Diff: https://git.reviewboard.kde.org/r/120777/diff/
> 
> 
> Testing
> ---
> 
> Everything looks ok. The performance is not bad, except from the fact that 
> the implementation is a bit of hackish...
> 
> 
> Thanks,
> 
> Antonis Tsiapaliokas
> 
>

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

Re: Stress testing KWin's screen handling

[Daniel Vrátil]

On Tuesday 25 of November 2014 13:17:28 Martin Gräßlin wrote:
> Hi all,
> 
> I spent some time on screen management in KWin today and got it to the point
> where it doesn't fail any more no matter what I try. So please everyone
> using multiple screens and especially dynamically plug in and out, please
> give a try to the patch set in [1]. Please ensure to have latest master as
> it contains a crash fix for a crash triggered by the patch set.
> 
> Short summary of the changes in the patch set:
> * uses XRandR instead of QDesktopWidget
> * uses KWin internal information about overall screen geometry instead of
> relying on the information in the X11 screen structure.
> 
> The second part is the code I added today. My testing showed that unplugging
> a screen gives us proper XRandR events so KWin's internal is up to date,
> but the X11 screen information is wrong. So when we partially used the one
> and partially the other the rendering was just horribly broken. Now it's
> all based on the KWin internal information and I couldn't get the rendering
> broken any more.
> 
> When changing screens please be patient. It takes time to settle the
> changes. Especially plasmashell takes quite some time on my system to
> render correctly again.

Coincidentally, I just merged my KScreen redesign, which should make this 
faster.

> 
> I hope that it doesn't fail for others and we can get the changes in to
> improve the situation.

So far it's much better than before, but still it sometimes happens, that 
after screen reshuffle, window decorations get detached from the windows and 
moved elsewhere. It just happened to me, after plugging in the 3rd screen:
http://pub.dvratil.cz/kwin-bug.ogv, but I'm not able to reliably reproduce 
this.

Dan


> 
> Cheers
> Martin
> 
> [1] https://git.reviewboard.kde.org/r/117614/

-- 
Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi
Software Engineer - KDE Desktop Team, Red Hat Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 120777: Plasma Active: Initial commit for Baloo Cloud Component

[Antonis Tsiapaliokas]

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

(Updated Nov. 25, 2014, 3:11 p.m.)


Review request for Plasma.


Changes
---

I have updated the review request.
As it has been discussed, the timeline will get its data from the 
QueryResultsModel
(which lives inside the Baloo repo.) and it will generate the timeline.


Repository: plasma-mobile


Description
---

At the moment, Baloo doesn't provide a timeline, which is something that we 
need for the activefilebrowser.
So this new component, is introducing support for the timeline.

Notes
===

* Baloocloud component contains the org.kde.baloo component inside it.The 
reason behind that, is that the implementation for the timeline is kind of 
terible because of its perfomance.
* I have put the new component inside the plasma-mobile repository, for the 
above reason. But if the Baloo team, wants it inside the baloo repo then i can 
move it. I am fine with both approaches (keep it here or in the baloo 
repository.
* If someone has a better idea about the implementation, the pls shoot :)
  


Diffs (updated)
-

  components/CMakeLists.txt 536b60e 
  components/timelinemodel/CMakeLists.txt PRE-CREATION 
  components/timelinemodel/qmldir PRE-CREATION 
  components/timelinemodel/timelinemodel.h PRE-CREATION 
  components/timelinemodel/timelinemodel.cpp PRE-CREATION 
  components/timelinemodel/timelineplugin.h PRE-CREATION 
  components/timelinemodel/timelineplugin.cpp PRE-CREATION 
  CMakeLists.txt 9466447 

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


Testing
---

Everything looks ok. The performance is not bad, except from the fact that the 
implementation is a bit of hackish...


Thanks,

Antonis Tsiapaliokas

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

Re: Review Request 121240: Port to new KScreen API

[Daniel Vrátil]

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

(Updated Nov. 25, 2014, 2:13 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: plasma-workspace


Description
---

This patch ports ShellCorona and PanelView to new KScreen API. The new API is 
completely asynchronous and is using shared pointers. The internals have also 
undergone some major changes, but they don't directly affect Plasma.

Additionally to the port, this patch also changes the way ShellCorona reacts to 
primary screen changes: instead of listening to Output::isPrimaryChanged on 
each output, it listens now to Config::primaryOutputChanged. The reason is that 
when some output is set as primary, the signal is emitted right away. This can 
happen before the old primary is unset though, which then causes crashes in 
screenInvariants() in some situations/configurations. Listening to 
Config::primaryOutputChanges ensures that Plasma reacts only once, and only 
when the Config is consistent.

The new KScreen API is available in dev/redesign branches in libkscreen.git. 
I'll merge the branch to "frameworks" branch once this review is approved in 
order not to break build.


Diffs
-

  shell/panelview.cpp 0dc5740 
  shell/shellcorona.h 5e97e02 
  shell/shellcorona.cpp 0da789f 

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


Testing
---

Been using this patch and the new KScreen for couple weeks now, works better 
than the old one.


Thanks,

Daniel Vrátil

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

Re: Review Request 121234: [Kickoff] Use latest X11 user time for creating StartupInfoId

[Sebastian Kügler]

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

Ship it!


Ship It!

- Sebastian Kügler


On Nov. 24, 2014, 7:05 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121234/
> ---
> 
> (Updated Nov. 24, 2014, 7:05 p.m.)
> 
> 
> Review request for Plasma, Eike Hein and Vishesh Handa.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> The StartupInfoId is supposed to contain information about the
> process and event which triggered the startup of the application.
> E.g. in the case of Kickoff it should be the last input event and
> the pid of Plasma. By creating the StartupInfoId directly in Kickoff
> and passing it to KRun we can ensure that this information is
> correct.
> 
> The code so far lost this information and the launch information
> was not correct. The timestamp is set to a "random" timestamp after
> the event and the pid is set to the one of the klauncher process.
> Furthermore this saves a roundtrip to the X Server from klauncher.
> 
> 
> @Eike and Vishesh: I'd suggest to add the same change to Kicker and KRunner.
> 
> 
> Diffs
> -
> 
>   applets/kickoff/CMakeLists.txt 817c7e41f4454aab66db5ad84e4b494395e5484f 
>   applets/kickoff/core/urlitemlauncher.cpp 
> 2ed074709c88ed10cdd72bae7d2b6bf2879183ae 
> 
> Diff: https://git.reviewboard.kde.org/r/121234/diff/
> 
> 
> Testing
> ---
> 
> started applications through plasmoidviewer and inspected the /proc/x/environ 
> to check the DESKTOP_STARTUP_ID env variable.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 121240: Port to new KScreen API

[Aleix Pol Gonzalez]

> On Nov. 25, 2014, 11:56 a.m., Aleix Pol Gonzalez wrote:
> > shell/shellcorona.cpp, line 328
> > 
> >
> > Are you sure this is correct?
> > 
> > This was done because at some point Configuration::primaryOutput and 
> > Output::isPrimary were not consistent and this was a way to make it 
> > consistent.
> 
> Daniel Vrátil wrote:
> The behaviour has changed a little with the new API (mostly because the 
> way Outputs are updated have changed). Now Configuration::primaryOutput is 
> changed after all Outputs have been updated. That's why this patch also 
> switches from listening to Output::isPrimaryChanged to 
> Configuration::primaryOutputChanged.
> 
> The problem with reacting to Output::isPrimaryChanged is, that you will 
> get the signal always twice: once for the output that is set to be primary, 
> and once for the output where primary flag is unset. If the order is first 
> unset, then set, then everything is OK, but if the order happens to be that 
> first you get signal from the output that was set a primary and then from the 
> one that was unset from primary, stuff gets broken and you start hitting 
> various asserts in the codepath.
> 
> By reacting to Config::primaryOutputChanged, you are sure that all the 
> changes have already been applied (including primary), and that calling 
> Config::primaryOutput gives you what you expect.

Ok, merge the patch, I'll keep an eye for regressions.


- Aleix


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


On Nov. 25, 2014, 9:18 a.m., Daniel Vrátil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121240/
> ---
> 
> (Updated Nov. 25, 2014, 9:18 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This patch ports ShellCorona and PanelView to new KScreen API. The new API is 
> completely asynchronous and is using shared pointers. The internals have also 
> undergone some major changes, but they don't directly affect Plasma.
> 
> Additionally to the port, this patch also changes the way ShellCorona reacts 
> to primary screen changes: instead of listening to Output::isPrimaryChanged 
> on each output, it listens now to Config::primaryOutputChanged. The reason is 
> that when some output is set as primary, the signal is emitted right away. 
> This can happen before the old primary is unset though, which then causes 
> crashes in screenInvariants() in some situations/configurations. Listening to 
> Config::primaryOutputChanges ensures that Plasma reacts only once, and only 
> when the Config is consistent.
> 
> The new KScreen API is available in dev/redesign branches in libkscreen.git. 
> I'll merge the branch to "frameworks" branch once this review is approved in 
> order not to break build.
> 
> 
> Diffs
> -
> 
>   shell/panelview.cpp 0dc5740 
>   shell/shellcorona.h 5e97e02 
>   shell/shellcorona.cpp 0da789f 
> 
> Diff: https://git.reviewboard.kde.org/r/121240/diff/
> 
> 
> Testing
> ---
> 
> Been using this patch and the new KScreen for couple weeks now, works better 
> than the old one.
> 
> 
> Thanks,
> 
> Daniel Vrátil
> 
>

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

Re: Some issues with porting KDE4 plasmoid to Plasma5

[Evgeniy Alekseev]

At Tuesday 25 November 2014 10:23:37 Marco Martin wrote:
> On Sunday 16 November 2014, Evgeniy Alekseev wrote:
> > Hello,
> > 
> > Some time ago I've started a porting of my plasmoids and dataengines to
> > the
> > newest Plasma and found some problems with it. I've ported a DataEngine
> > w\o
> > any problem, but I have issues about a Plasmoid. I've read API reference
> > and look at examples from plasma-next and didn't find solutions.
> > 
> > First of all I want say that I don't plan to use QML/JS now and plan to
> > develop of my plasmoids in pure C++. Firstly it is related to other
> > project
> 
> in Plasma5 pure C++ plasmoids are not possible anymore, the c++ api was for
> QGraphicsView (since plasma was based on top of it) plasma5 is based on top
> of scene graph, so the only way to write an UI is trough QML.
> You can still use C++ in a dataengine or a private QML import.
> 
> > parts which is in C++/Qt and I don't want to use additional languages w\o
> > any special necessity. Also as far as I understand the core plasmoid part
> > (on which I have issue too) still shoul be written in C++. Also I try to
> > avoid using deprecated functions.
> > 
> > My questions are:
> > 
> > 1. Is there any alternative to Plasma::PopupApplet? If there is not, is
> > there a plan to implement it?
> 
> all applets are popupapplets now.
> see
> http://notmart.org/blog/2014/02/making-plasmoids-qml-api-better/
> 
> especially the section "Compact and full representations"
> 
> > 2. Is there a possibility to paint complex UI w\o using QML (in C++ code)?
> > For example, I didn't find old Applet::setLayout() and
> > PopupApplet::setWidget() methods.
> 
> no, only QML is allowed, and subclassing Applet doesn't really work anymore.
> If you have a complex QWidget ui in theory you could still have it by
> implementing it in a QML import, then making ti show from a slot invoked by
> qml.
> 
> > 3. How can I connect DataEngine to my Plasmoid? The old method which I
> > used
> > was dataEnigne(), some new applets use this method too, but it doesn't
> > exist in the newest Plasma headers. Some new widgets such as nm-applet use
> > Plasma::DataEngineManager::self()->engine() constuction, but
> > Plasma::DataEngineManager class doesn't exist in the Plasma too =(
> 
> see the QML bindings:
> https://techbase.kde.org/Development/Tutorials/Plasma2/QML2/API#Data_Engines

Thank you for the answer and the links! 

Seems all my questions are QML porting retaled, so I'll look on it and hope 
will port own KDE stuff successfully =) Thank you again.
-- 
Sincerely yours,
Evgeniy Alekseev

email: darkarca...@mail.ru
ICQ: 407-398-235
Jabber: arca...@jabber.ru

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins build is still unstable: plasma-desktop_stable_qt5 #10

[KDE CI System]

See 

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

Re: Review Request 121240: Port to new KScreen API

[Daniel Vrátil]

> On Nov. 25, 2014, 12:56 p.m., Aleix Pol Gonzalez wrote:
> > shell/shellcorona.cpp, line 328
> > 
> >
> > Are you sure this is correct?
> > 
> > This was done because at some point Configuration::primaryOutput and 
> > Output::isPrimary were not consistent and this was a way to make it 
> > consistent.

The behaviour has changed a little with the new API (mostly because the way 
Outputs are updated have changed). Now Configuration::primaryOutput is changed 
after all Outputs have been updated. That's why this patch also switches from 
listening to Output::isPrimaryChanged to Configuration::primaryOutputChanged.

The problem with reacting to Output::isPrimaryChanged is, that you will get the 
signal always twice: once for the output that is set to be primary, and once 
for the output where primary flag is unset. If the order is first unset, then 
set, then everything is OK, but if the order happens to be that first you get 
signal from the output that was set a primary and then from the one that was 
unset from primary, stuff gets broken and you start hitting various asserts in 
the codepath.

By reacting to Config::primaryOutputChanged, you are sure that all the changes 
have already been applied (including primary), and that calling 
Config::primaryOutput gives you what you expect.


- Daniel


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


On Nov. 25, 2014, 10:18 a.m., Daniel Vrátil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121240/
> ---
> 
> (Updated Nov. 25, 2014, 10:18 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This patch ports ShellCorona and PanelView to new KScreen API. The new API is 
> completely asynchronous and is using shared pointers. The internals have also 
> undergone some major changes, but they don't directly affect Plasma.
> 
> Additionally to the port, this patch also changes the way ShellCorona reacts 
> to primary screen changes: instead of listening to Output::isPrimaryChanged 
> on each output, it listens now to Config::primaryOutputChanged. The reason is 
> that when some output is set as primary, the signal is emitted right away. 
> This can happen before the old primary is unset though, which then causes 
> crashes in screenInvariants() in some situations/configurations. Listening to 
> Config::primaryOutputChanges ensures that Plasma reacts only once, and only 
> when the Config is consistent.
> 
> The new KScreen API is available in dev/redesign branches in libkscreen.git. 
> I'll merge the branch to "frameworks" branch once this review is approved in 
> order not to break build.
> 
> 
> Diffs
> -
> 
>   shell/panelview.cpp 0dc5740 
>   shell/shellcorona.h 5e97e02 
>   shell/shellcorona.cpp 0da789f 
> 
> Diff: https://git.reviewboard.kde.org/r/121240/diff/
> 
> 
> Testing
> ---
> 
> Been using this patch and the new KScreen for couple weeks now, works better 
> than the old one.
> 
> 
> Thanks,
> 
> Daniel Vrátil
> 
>

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

Re: Review Request 121229: Highlight first entry when searching

[Kai Uwe Broulik]

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

(Updated Nov. 25, 2014, 12:50 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma and Sebastian Kügler.


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


Repository: plasma-desktop


Description
---

Since pressing enter invokes the first entry it should be highlighted.


Diffs
-

  applets/kickoff/package/contents/ui/SearchView.qml 9fc8d40 

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


Testing
---

Works as expected.


Thanks,

Kai Uwe Broulik

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

Re: Review Request 121234: [Kickoff] Use latest X11 user time for creating StartupInfoId

[Eike Hein]

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

Ship it!


Ship It!

- Eike Hein


On Nov. 24, 2014, 7:05 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121234/
> ---
> 
> (Updated Nov. 24, 2014, 7:05 p.m.)
> 
> 
> Review request for Plasma, Eike Hein and Vishesh Handa.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> The StartupInfoId is supposed to contain information about the
> process and event which triggered the startup of the application.
> E.g. in the case of Kickoff it should be the last input event and
> the pid of Plasma. By creating the StartupInfoId directly in Kickoff
> and passing it to KRun we can ensure that this information is
> correct.
> 
> The code so far lost this information and the launch information
> was not correct. The timestamp is set to a "random" timestamp after
> the event and the pid is set to the one of the klauncher process.
> Furthermore this saves a roundtrip to the X Server from klauncher.
> 
> 
> @Eike and Vishesh: I'd suggest to add the same change to Kicker and KRunner.
> 
> 
> Diffs
> -
> 
>   applets/kickoff/CMakeLists.txt 817c7e41f4454aab66db5ad84e4b494395e5484f 
>   applets/kickoff/core/urlitemlauncher.cpp 
> 2ed074709c88ed10cdd72bae7d2b6bf2879183ae 
> 
> Diff: https://git.reviewboard.kde.org/r/121234/diff/
> 
> 
> Testing
> ---
> 
> started applications through plasmoidviewer and inspected the /proc/x/environ 
> to check the DESKTOP_STARTUP_ID env variable.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Stress testing KWin's screen handling

[Aleix Pol]

On Tue, Nov 25, 2014 at 1:17 PM, Martin Gräßlin  wrote:

> Hi all,
>
> I spent some time on screen management in KWin today and got it to the
> point
> where it doesn't fail any more no matter what I try. So please everyone
> using
> multiple screens and especially dynamically plug in and out, please give a
> try
> to the patch set in [1]. Please ensure to have latest master as it
> contains a
> crash fix for a crash triggered by the patch set.
>
> Short summary of the changes in the patch set:
> * uses XRandR instead of QDesktopWidget
> * uses KWin internal information about overall screen geometry instead of
> relying on the information in the X11 screen structure.
>
> The second part is the code I added today. My testing showed that
> unplugging a
> screen gives us proper XRandR events so KWin's internal is up to date, but
> the
> X11 screen information is wrong. So when we partially used the one and
> partially the other the rendering was just horribly broken. Now it's all
> based
> on the KWin internal information and I couldn't get the rendering broken
> any
> more.
>
> When changing screens please be patient. It takes time to settle the
> changes.
> Especially plasmashell takes quite some time on my system to render
> correctly
> again.
>
> I hope that it doesn't fail for others and we can get the changes in to
> improve the situation.
>
> Cheers
> Martin
>
> [1] https://git.reviewboard.kde.org/r/117614/


Hi Martin,
I just applied your patch, seems to work so far. I'll tell you if it breaks
:D.

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

Re: Review Request 121229: Highlight first entry when searching

[Sebastian Kügler]

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

Ship it!


nice!

- Sebastian Kügler


On Nov. 24, 2014, 5:27 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121229/
> ---
> 
> (Updated Nov. 24, 2014, 5:27 p.m.)
> 
> 
> Review request for Plasma and Sebastian Kügler.
> 
> 
> Bugs: 340067
> https://bugs.kde.org/show_bug.cgi?id=340067
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> Since pressing enter invokes the first entry it should be highlighted.
> 
> 
> Diffs
> -
> 
>   applets/kickoff/package/contents/ui/SearchView.qml 9fc8d40 
> 
> Diff: https://git.reviewboard.kde.org/r/121229/diff/
> 
> 
> Testing
> ---
> 
> Works as expected.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

Stress testing KWin's screen handling

[Martin Gräßlin]

Hi all,

I spent some time on screen management in KWin today and got it to the point 
where it doesn't fail any more no matter what I try. So please everyone using 
multiple screens and especially dynamically plug in and out, please give a try 
to the patch set in [1]. Please ensure to have latest master as it contains a 
crash fix for a crash triggered by the patch set.

Short summary of the changes in the patch set:
* uses XRandR instead of QDesktopWidget
* uses KWin internal information about overall screen geometry instead of 
relying on the information in the X11 screen structure.

The second part is the code I added today. My testing showed that unplugging a 
screen gives us proper XRandR events so KWin's internal is up to date, but the 
X11 screen information is wrong. So when we partially used the one and 
partially the other the rendering was just horribly broken. Now it's all based 
on the KWin internal information and I couldn't get the rendering broken any 
more.

When changing screens please be patient. It takes time to settle the changes. 
Especially plasmashell takes quite some time on my system to render correctly 
again.

I hope that it doesn't fail for others and we can get the changes in to 
improve the situation.

Cheers
Martin

[1] https://git.reviewboard.kde.org/r/117614/

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Different calendars in Plasma 5

[Eike Hein]

On 11/25/2014 11:49 AM, Martin Gräßlin wrote:

so for the time being that sounds like option a. It's at least another half a
year till we get Qt 5.5. I'd say that is reason enough to temporarily depend
on kdelibs4 support.


+1. At the risk of bringing emotion into a technical topic,
KDE's super-impressive support for international calender
systems (check out jlayt's blogs on this -- some of my
favorite reads on Planet KDE) has rightfully been a point
of pride for us and not exposing it any more would be
really sad.


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

Re: Review Request 121240: Port to new KScreen API

[Marco Martin]

> On Nov. 25, 2014, 11:04 a.m., Aleix Pol Gonzalez wrote:
> > shell/shellcorona.cpp, line 851
> > 
> >
> > Are you sure this is not needed anymore?
> 
> Daniel Vrátil wrote:
> ShellCorona is not a public class, so nothing outside plasma-workspace 
> needs it, and the rest of plasma-workspace compiles just fine without it.

should be fine removing it, yes


- Marco


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


On Nov. 25, 2014, 9:18 a.m., Daniel Vrátil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121240/
> ---
> 
> (Updated Nov. 25, 2014, 9:18 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This patch ports ShellCorona and PanelView to new KScreen API. The new API is 
> completely asynchronous and is using shared pointers. The internals have also 
> undergone some major changes, but they don't directly affect Plasma.
> 
> Additionally to the port, this patch also changes the way ShellCorona reacts 
> to primary screen changes: instead of listening to Output::isPrimaryChanged 
> on each output, it listens now to Config::primaryOutputChanged. The reason is 
> that when some output is set as primary, the signal is emitted right away. 
> This can happen before the old primary is unset though, which then causes 
> crashes in screenInvariants() in some situations/configurations. Listening to 
> Config::primaryOutputChanges ensures that Plasma reacts only once, and only 
> when the Config is consistent.
> 
> The new KScreen API is available in dev/redesign branches in libkscreen.git. 
> I'll merge the branch to "frameworks" branch once this review is approved in 
> order not to break build.
> 
> 
> Diffs
> -
> 
>   shell/panelview.cpp 0dc5740 
>   shell/shellcorona.h 5e97e02 
>   shell/shellcorona.cpp 0da789f 
> 
> Diff: https://git.reviewboard.kde.org/r/121240/diff/
> 
> 
> Testing
> ---
> 
> Been using this patch and the new KScreen for couple weeks now, works better 
> than the old one.
> 
> 
> Thanks,
> 
> Daniel Vrátil
> 
>

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

Re: Review Request 121240: Port to new KScreen API

[Aleix Pol Gonzalez]

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



shell/shellcorona.cpp


Are you sure this is correct?

This was done because at some point Configuration::primaryOutput and 
Output::isPrimary were not consistent and this was a way to make it consistent.


- Aleix Pol Gonzalez


On Nov. 25, 2014, 9:18 a.m., Daniel Vrátil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121240/
> ---
> 
> (Updated Nov. 25, 2014, 9:18 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This patch ports ShellCorona and PanelView to new KScreen API. The new API is 
> completely asynchronous and is using shared pointers. The internals have also 
> undergone some major changes, but they don't directly affect Plasma.
> 
> Additionally to the port, this patch also changes the way ShellCorona reacts 
> to primary screen changes: instead of listening to Output::isPrimaryChanged 
> on each output, it listens now to Config::primaryOutputChanged. The reason is 
> that when some output is set as primary, the signal is emitted right away. 
> This can happen before the old primary is unset though, which then causes 
> crashes in screenInvariants() in some situations/configurations. Listening to 
> Config::primaryOutputChanges ensures that Plasma reacts only once, and only 
> when the Config is consistent.
> 
> The new KScreen API is available in dev/redesign branches in libkscreen.git. 
> I'll merge the branch to "frameworks" branch once this review is approved in 
> order not to break build.
> 
> 
> Diffs
> -
> 
>   shell/panelview.cpp 0dc5740 
>   shell/shellcorona.h 5e97e02 
>   shell/shellcorona.cpp 0da789f 
> 
> Diff: https://git.reviewboard.kde.org/r/121240/diff/
> 
> 
> Testing
> ---
> 
> Been using this patch and the new KScreen for couple weeks now, works better 
> than the old one.
> 
> 
> Thanks,
> 
> Daniel Vrátil
> 
>

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

Re: Review Request 121240: Port to new KScreen API

[Daniel Vrátil]

> On Nov. 25, 2014, 12:04 p.m., Aleix Pol Gonzalez wrote:
> > shell/shellcorona.cpp, line 851
> > 
> >
> > Are you sure this is not needed anymore?

ShellCorona is not a public class, so nothing outside plasma-workspace needs 
it, and the rest of plasma-workspace compiles just fine without it.


- Daniel


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


On Nov. 25, 2014, 10:18 a.m., Daniel Vrátil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121240/
> ---
> 
> (Updated Nov. 25, 2014, 10:18 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This patch ports ShellCorona and PanelView to new KScreen API. The new API is 
> completely asynchronous and is using shared pointers. The internals have also 
> undergone some major changes, but they don't directly affect Plasma.
> 
> Additionally to the port, this patch also changes the way ShellCorona reacts 
> to primary screen changes: instead of listening to Output::isPrimaryChanged 
> on each output, it listens now to Config::primaryOutputChanged. The reason is 
> that when some output is set as primary, the signal is emitted right away. 
> This can happen before the old primary is unset though, which then causes 
> crashes in screenInvariants() in some situations/configurations. Listening to 
> Config::primaryOutputChanges ensures that Plasma reacts only once, and only 
> when the Config is consistent.
> 
> The new KScreen API is available in dev/redesign branches in libkscreen.git. 
> I'll merge the branch to "frameworks" branch once this review is approved in 
> order not to break build.
> 
> 
> Diffs
> -
> 
>   shell/panelview.cpp 0dc5740 
>   shell/shellcorona.h 5e97e02 
>   shell/shellcorona.cpp 0da789f 
> 
> Diff: https://git.reviewboard.kde.org/r/121240/diff/
> 
> 
> Testing
> ---
> 
> Been using this patch and the new KScreen for couple weeks now, works better 
> than the old one.
> 
> 
> Thanks,
> 
> Daniel Vrátil
> 
>

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

Re: Review Request 121228: Fix minimum height in notifications

[Kai Uwe Broulik]

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

(Updated Nov. 25, 2014, 11:04 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma, Martin Klapetek and Vishesh Handa.


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


Repository: plasma-workspace


Description
---

This changes the bahavior from Math.max(icon, text + margins) to Math.max(icon, 
text) + margins which should fix the layout in case the notification has no 
bodytext.


Diffs
-

  applets/notifications/package/contents/ui/NotificationItem.qml 1074e63 

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


Testing
---

Nope, no 5 here, hence the RR :)


Thanks,

Kai Uwe Broulik

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

Re: Review Request 121240: Port to new KScreen API

[Aleix Pol Gonzalez]

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



shell/shellcorona.cpp


remove debug?



shell/shellcorona.cpp


Are you sure this is not needed anymore?


- Aleix Pol Gonzalez


On Nov. 25, 2014, 9:18 a.m., Daniel Vrátil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121240/
> ---
> 
> (Updated Nov. 25, 2014, 9:18 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This patch ports ShellCorona and PanelView to new KScreen API. The new API is 
> completely asynchronous and is using shared pointers. The internals have also 
> undergone some major changes, but they don't directly affect Plasma.
> 
> Additionally to the port, this patch also changes the way ShellCorona reacts 
> to primary screen changes: instead of listening to Output::isPrimaryChanged 
> on each output, it listens now to Config::primaryOutputChanged. The reason is 
> that when some output is set as primary, the signal is emitted right away. 
> This can happen before the old primary is unset though, which then causes 
> crashes in screenInvariants() in some situations/configurations. Listening to 
> Config::primaryOutputChanges ensures that Plasma reacts only once, and only 
> when the Config is consistent.
> 
> The new KScreen API is available in dev/redesign branches in libkscreen.git. 
> I'll merge the branch to "frameworks" branch once this review is approved in 
> order not to break build.
> 
> 
> Diffs
> -
> 
>   shell/panelview.cpp 0dc5740 
>   shell/shellcorona.h 5e97e02 
>   shell/shellcorona.cpp 0da789f 
> 
> Diff: https://git.reviewboard.kde.org/r/121240/diff/
> 
> 
> Testing
> ---
> 
> Been using this patch and the new KScreen for couple weeks now, works better 
> than the old one.
> 
> 
> Thanks,
> 
> Daniel Vrátil
> 
>

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

Re: Review Request 121228: Fix minimum height in notifications

[Martin Klapetek]

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

Ship it!


Ship It!

- Martin Klapetek


On Nov. 24, 2014, 4:29 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121228/
> ---
> 
> (Updated Nov. 24, 2014, 4:29 p.m.)
> 
> 
> Review request for Plasma, Martin Klapetek and Vishesh Handa.
> 
> 
> Bugs: 341218
> https://bugs.kde.org/show_bug.cgi?id=341218
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This changes the bahavior from Math.max(icon, text + margins) to 
> Math.max(icon, text) + margins which should fix the layout in case the 
> notification has no bodytext.
> 
> 
> Diffs
> -
> 
>   applets/notifications/package/contents/ui/NotificationItem.qml 1074e63 
> 
> Diff: https://git.reviewboard.kde.org/r/121228/diff/
> 
> 
> Testing
> ---
> 
> Nope, no 5 here, hence the RR :)
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

Re: Re: Different calendars in Plasma 5

[Martin Gräßlin]

On Tuesday 25 November 2014 11:38:56 Martin Klapetek wrote:
> On Tue, Nov 25, 2014 at 1:03 AM, Aleix Pol  wrote:
> > Hi,
> > I went through some bug reports earlier today and found this one, that
> > looks quite important in principle:
> > https://bugs.kde.org/show_bug.cgi?id=340558
> > 
> > Apparently it's not possible to change Plasma's calendar type anymore. Can
> > somebody who has worked on the plasmoid shed some light? Martin, Sebas?
> 
> We need
> 
> a) KCalendarSystem
> 
> OR
> 
> b) QCalendarSystem
> 
> Now a) would mean depending on kdelibs4support, which mayyy be fine for the
> moment (maybe we even do in all the places needed). As for b), this is
> supposed to be part of the Qt's ICU stuff and was originally targeted for
> Qt 5.4, but I don't see it there so I guess it didn't make it. I do not
> know what the current plan/status is, John might know. Perhaps it could get
> into Qt 5.5.
> 
> Then the applet's backend (a model) would have to be rewritten on top of
> either of those. Then just a kcm with the setting and it should just
> work(tm).

so for the time being that sounds like option a. It's at least another half a 
year till we get Qt 5.5. I'd say that is reason enough to temporarily depend 
on kdelibs4 support.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: OSD and Notification Window Type

[Martin Gräßlin]

On Tuesday 25 November 2014 10:09:42 Marco Martin wrote:
> On Tuesday 25 November 2014, Martin Gräßlin wrote:
> > > plasma tooltips are override redirect yes
> > 
> > did that change recently? If yes, Kai Uwe could you please try again?
> 
> Qt::BypassWindowManagerHint is set since 27th may, in tooltipdialog.cpp
> constructor (note that the first time it shows up there is the usual qt xcb
> problem in which the window is shown an instant before the flags can really
> be set)

aha, so the first time it's not an override redirect, because changing this 
flag is not possible after the window got created.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Different calendars in Plasma 5

[Martin Klapetek]

On Tue, Nov 25, 2014 at 1:03 AM, Aleix Pol  wrote:

> Hi,
> I went through some bug reports earlier today and found this one, that
> looks quite important in principle:
> https://bugs.kde.org/show_bug.cgi?id=340558
>
> Apparently it's not possible to change Plasma's calendar type anymore. Can
> somebody who has worked on the plasmoid shed some light? Martin, Sebas?
>

We need

a) KCalendarSystem

OR

b) QCalendarSystem

Now a) would mean depending on kdelibs4support, which mayyy be fine for the
moment (maybe we even do in all the places needed). As for b), this is
supposed to be part of the Qt's ICU stuff and was originally targeted for
Qt 5.4, but I don't see it there so I guess it didn't make it. I do not
know what the current plan/status is, John might know. Perhaps it could get
into Qt 5.5.

Then the applet's backend (a model) would have to be rewritten on top of
either of those. Then just a kcm with the setting and it should just
work(tm).

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

Re: QtQuick Controls Calendar

[Martin Klapetek]

On Mon, Nov 24, 2014 at 8:09 PM, Aleix Pol  wrote:

> On Sat, Nov 8, 2014 at 6:20 PM, Kai Uwe Broulik 
> wrote:
>
>> Hi all,
>>
>> I was looking into migrating the Plasma Calendar to QtQuick Controls
>> Calendar.
>>
>> However, we went through so much work making this thing efficient and fast
>> using Canvas but the QtQuick Controls Calendar again uses one item per day
>> (which potentially contains a Label and Rects for the borders). I do not
>> know
>> whether it re-uses the items when switching through months (which is a bit
>> laggy with the Canvas calendar), though. One advantage is that it would
>> give
>> us week numbers for free.
>>
>> Suggestions?
>>
>> Cheers,
>> Kai Uwe
>
>
> Would it maybe help with calendars l10n?
> https://bugs.kde.org/show_bug.cgi?id=340558
>

Most probably not, the multi-calendar support is still missing in Qt afaik
(QCalendarSystem).

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

Re: Review Request 121240: Port to new KScreen API

[Marco Martin]

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

Ship it!


Ship It!

- Marco Martin


On Nov. 25, 2014, 9:18 a.m., Daniel Vrátil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121240/
> ---
> 
> (Updated Nov. 25, 2014, 9:18 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This patch ports ShellCorona and PanelView to new KScreen API. The new API is 
> completely asynchronous and is using shared pointers. The internals have also 
> undergone some major changes, but they don't directly affect Plasma.
> 
> Additionally to the port, this patch also changes the way ShellCorona reacts 
> to primary screen changes: instead of listening to Output::isPrimaryChanged 
> on each output, it listens now to Config::primaryOutputChanged. The reason is 
> that when some output is set as primary, the signal is emitted right away. 
> This can happen before the old primary is unset though, which then causes 
> crashes in screenInvariants() in some situations/configurations. Listening to 
> Config::primaryOutputChanges ensures that Plasma reacts only once, and only 
> when the Config is consistent.
> 
> The new KScreen API is available in dev/redesign branches in libkscreen.git. 
> I'll merge the branch to "frameworks" branch once this review is approved in 
> order not to break build.
> 
> 
> Diffs
> -
> 
>   shell/panelview.cpp 0dc5740 
>   shell/shellcorona.h 5e97e02 
>   shell/shellcorona.cpp 0da789f 
> 
> Diff: https://git.reviewboard.kde.org/r/121240/diff/
> 
> 
> Testing
> ---
> 
> Been using this patch and the new KScreen for couple weeks now, works better 
> than the old one.
> 
> 
> Thanks,
> 
> Daniel Vrátil
> 
>

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

Jenkins build is back to normal : plasma-workspace_master_qt5 #1095

[KDE CI System]

See 

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

Re: Review Request 121236: Minimize overdraw in Desktop view

[Kai Uwe Broulik]

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

(Updated Nov. 25, 2014, 9:37 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: plasma-desktop


Description
---

This changes the root item to be Item and only shows a black Rectangle when 
dashboard is shown. Together with Review 121162 there is only ever one 
full-sized root item (used to be three and more).


Diffs
-

  desktoppackage/contents/views/Desktop.qml 73698f6 

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


Testing
---

Should look like it did before, however, when the dashboard is shown ontop of a 
light maximized window (browser) the contrast is too low imho (don't remember 
if that was the case before that). Plasmoidviewer also looks normal (eg. no 
transparent spots when resizing the window)

Also, when switching wallpaper plugins (like from image to color) the 
transparency in the dashboard is gone. Afaics this has been the case without 
this patch as well but I failed to fix it.


Thanks,

Kai Uwe Broulik

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

Re: Review Request 121162: Some ideas for the image wallpaper

[Kai Uwe Broulik]

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

(Updated Nov. 25, 2014, 9:35 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: plasma-workspace


Description
---

This is just a bunch of stuff I played around with I'd like to get comments on


Diffs
-

  wallpapers/image/imagepackage/contents/ui/main.qml d81bd29 

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


Testing
---

QSG_VISUALIZE=overdraw and a bit of playing around


Thanks,

Kai Uwe Broulik

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

Re: Delay in Kickoff Application Launcher

[David Edmundson]

> There must be a config file where I can set the delay time to zero.
>

There isn't, sorry.
See FullRepresentation.qml:72 for the relevant code.

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

Re: Some issues with porting KDE4 plasmoid to Plasma5

[Marco Martin]

On Sunday 16 November 2014, Evgeniy Alekseev wrote:
> Hello,
> 
> Some time ago I've started a porting of my plasmoids and dataengines to the
> newest Plasma and found some problems with it. I've ported a DataEngine w\o
> any problem, but I have issues about a Plasmoid. I've read API reference
> and look at examples from plasma-next and didn't find solutions.
> 
> First of all I want say that I don't plan to use QML/JS now and plan to
> develop of my plasmoids in pure C++. Firstly it is related to other project

in Plasma5 pure C++ plasmoids are not possible anymore, the c++ api was for 
QGraphicsView (since plasma was based on top of it) plasma5 is based on top of 
scene graph, so the only way to write an UI is trough QML.
You can still use C++ in a dataengine or a private QML import.

> parts which is in C++/Qt and I don't want to use additional languages w\o
> any special necessity. Also as far as I understand the core plasmoid part
> (on which I have issue too) still shoul be written in C++. Also I try to
> avoid using deprecated functions.
> 
> My questions are:
> 
> 1. Is there any alternative to Plasma::PopupApplet? If there is not, is
> there a plan to implement it?

all applets are popupapplets now.
see
http://notmart.org/blog/2014/02/making-plasmoids-qml-api-better/

especially the section "Compact and full representations"

> 2. Is there a possibility to paint complex UI w\o using QML (in C++ code)?
> For example, I didn't find old Applet::setLayout() and
> PopupApplet::setWidget() methods.

no, only QML is allowed, and subclassing Applet doesn't really work anymore.
If you have a complex QWidget ui in theory you could still have it by 
implementing it in a QML import, then making ti show from a slot invoked by 
qml.

> 3. How can I connect DataEngine to my Plasmoid? The old method which I used
> was dataEnigne(), some new applets use this method too, but it doesn't
> exist in the newest Plasma headers. Some new widgets such as nm-applet use
> Plasma::DataEngineManager::self()->engine() constuction, but
> Plasma::DataEngineManager class doesn't exist in the Plasma too =(

see the QML bindings:
https://techbase.kde.org/Development/Tutorials/Plasma2/QML2/API#Data_Engines

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

Review Request 121240: Port to new KScreen API

[Daniel Vrátil]

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

Review request for Plasma.


Repository: plasma-workspace


Description
---

This patch ports ShellCorona and PanelView to new KScreen API. The new API is 
completely asynchronous and is using shared pointers. The internals have also 
undergone some major changes, but they don't directly affect Plasma.

Additionally to the port, this patch also changes the way ShellCorona reacts to 
primary screen changes: instead of listening to Output::isPrimaryChanged on 
each output, it listens now to Config::primaryOutputChanged. The reason is that 
when some output is set as primary, the signal is emitted right away. This can 
happen before the old primary is unset though, which then causes crashes in 
screenInvariants() in some situations/configurations. Listening to 
Config::primaryOutputChanges ensures that Plasma reacts only once, and only 
when the Config is consistent.

The new KScreen API is available in dev/redesign branches in libkscreen.git. 
I'll merge the branch to "frameworks" branch once this review is approved in 
order not to break build.


Diffs
-

  shell/panelview.cpp 0dc5740 
  shell/shellcorona.h 5e97e02 
  shell/shellcorona.cpp 0da789f 

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


Testing
---

Been using this patch and the new KScreen for couple weeks now, works better 
than the old one.


Thanks,

Daniel Vrátil

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

Delay in Kickoff Application Launcher

[Harangozo Sandor]

 Hi,

I'd like to know how can I remove the delay in Kickoff Application Launcher
I mean the delay for opening submenus when the mouse hovers over a folder item.
There must be a config file where I can set the delay time to zero.
Thanks,
Sandor Harangozo

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

Re: Muon and kde-gtk-config moved to kde/workspace - was - Re: Moving repositories in the module structure

[Daniel Nicoletti]

2014-11-13 13:03 GMT-02:00 Aleix Pol :
> On Thu, Nov 13, 2014 at 3:50 PM, Albert Astals Cid  wrote:
>>
>> Aleix, can you please explain to us why Mion Discover and Apper are two
>> different things in principle?
>>
>> Seems the Apper guys disagree.
>>
>> Cheers,
>>   Albert
>>
>
> There's 2 main differences:
> 1. Muon Discover has historically used OS metadata to define what are
> applications an what's relevant to the users (AKA end-user applications).
> Although they claim it will be done eventually on Apper as well. In any case
> Muon Discover doesn't aim to manage packages, it aims to provide a library
> of resources for the user to enhance his KDE/Plasma experience.
Apper uses metadata to define application for years now, it also provided
Plasma integration for removing applictions directly from kickoff thanks
to PackageKit session interface.
However on the point of managing packages Apper doesn't tries to merge
the two things in a way you don' t need to open another application to install
a package...

> 2. Muon has different backends, so we're not solely relying on PackageKit
> which means it can act as a frontend to different technologies other than
> packagekit, currently bodega, KNS/OCS and Apt (the last one for historic and
> practical reasons).
Support for different technologies could also be added to Apper but no
one ever stepped up to give a hand, and I myself don't like much these others
to do it...

>
> Aleix



-- 
Daniel Nicoletti

KDE Developer - http://dantti.wordpress.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Some issues with porting KDE4 plasmoid to Plasma5

[Evgeniy Alekseev]

Hello,

Some time ago I've started a porting of my plasmoids and dataengines to the 
newest Plasma and found some problems with it. I've ported a DataEngine w\o 
any problem, but I have issues about a Plasmoid. I've read API reference and 
look at examples from plasma-next and didn't find solutions.

First of all I want say that I don't plan to use QML/JS now and plan to 
develop of my plasmoids in pure C++. Firstly it is related to other project 
parts which is in C++/Qt and I don't want to use additional languages w\o any 
special necessity. Also as far as I understand the core plasmoid part (on 
which I have issue too) still shoul be written in C++. Also I try to avoid 
using deprecated functions.

My questions are:

1. Is there any alternative to Plasma::PopupApplet? If there is not, is there 
a plan to implement it?

2. Is there a possibility to paint complex UI w\o using QML (in C++ code)? For 
example, I didn't find old Applet::setLayout() and PopupApplet::setWidget() 
methods.

3. How can I connect DataEngine to my Plasmoid? The old method which I used 
was dataEnigne(), some new applets use this method too, but it doesn't exist 
in the newest Plasma headers. Some new widgets such as nm-applet use 
Plasma::DataEngineManager::self()->engine() constuction, but 
Plasma::DataEngineManager class doesn't exist in the Plasma too =(

If you need a reference to my plasmoid, example on which I'm working now may 
be found here [1] (it is more simple than the second one).

1. https://github.com/arcan1s/netctl-gui
-- 
Sincerely yours, 
Evgeniy Alekseev

e-mail: darkarca...@mail.ru
ICQ: 407-398-235
Jabber: arca...@jabber.ru

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: OSD and Notification Window Type

[Marco Martin]

On Tuesday 25 November 2014, Martin Gräßlin wrote:
> 
> > plasma tooltips are override redirect yes
> 
> did that change recently? If yes, Kai Uwe could you please try again?

Qt::BypassWindowManagerHint is set since 27th may, in tooltipdialog.cpp 
constructor (note that the first time it shows up there is the usual qt xcb 
problem in which the window is shown an instant before the flags can really be 
set)


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

Re: Review Request 121162: Some ideas for the image wallpaper

[Marco Martin]

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

Ship it!


Ship It!

- Marco Martin


On Nov. 24, 2014, 9:19 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121162/
> ---
> 
> (Updated Nov. 24, 2014, 9:19 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This is just a bunch of stuff I played around with I'd like to get comments on
> 
> 
> Diffs
> -
> 
>   wallpapers/image/imagepackage/contents/ui/main.qml d81bd29 
> 
> Diff: https://git.reviewboard.kde.org/r/121162/diff/
> 
> 
> Testing
> ---
> 
> QSG_VISUALIZE=overdraw and a bit of playing around
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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