date:20141211


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

Ship it!


Ship It!

- Martin Gräßlin


On Dec. 10, 2014, 3:47 p.m., David Edmundson wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121402/
 ---
 
 (Updated Dec. 10, 2014, 3:47 p.m.)
 
 
 Review request for Plasma.
 
 
 Repository: plasma-workspace
 
 
 Description
 ---
 
 Allow user to customise wallpaper used in the lock screen.
 
 Nothing very fancy it's the same plain image approach we use in SDDM. 
 Default behaviour is unchanged. We can always expand it later.
 
 
 Diffs
 -
 
   lookandfeel/contents/lockscreen/LockScreen.qml ca9beb2 
   ksmserver/screenlocker/kcm/kcm.cpp 0f74c45 
   ksmserver/screenlocker/kcm/kcm.ui c891cc9 
   ksmserver/screenlocker/kcm/selectimagebutton.h PRE-CREATION 
   ksmserver/screenlocker/kcm/selectimagebutton.cpp PRE-CREATION 
   ksmserver/screenlocker/greeter/greeterapp.cpp 60bd347 
   ksmserver/screenlocker/kcfg/kscreenlockersettings.kcfg 5207615 
   ksmserver/screenlocker/kcm/CMakeLists.txt a23a0fc 
 
 Diff: https://git.reviewboard.kde.org/r/121402/diff/
 
 
 Testing
 ---
 
 Opened lockscreen.
 Most code is tried and tested in the SDDM KCM.
 
 
 Thanks,
 
 David Edmundson
 


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

Change in plasma-framework[master]: Different themes between desktop and dialogs

2014-12-11 Thread Marco Martin (Code Review)

Marco Martin has uploaded a new change for review.

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

Change subject: Different  themes between desktop and dialogs
..

Different  themes between desktop and dialogs

different themes between QtControl themes in applets
and in config dialogs: this allows QtQuickControls
to be freely usable in applets without worrying how they
will integrate

Change-Id: I696bdcbd78eb2e4df708367ac0d70d13c5d6cf12
---
M src/plasmaquick/appletquickitem.cpp
M src/plasmaquick/view.cpp
2 files changed, 24 insertions(+), 0 deletions(-)


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

diff --git a/src/plasmaquick/appletquickitem.cpp 
b/src/plasmaquick/appletquickitem.cpp
index 6ec12b9..06406a4 100644
--- a/src/plasmaquick/appletquickitem.cpp
+++ b/src/plasmaquick/appletquickitem.cpp
@@ -435,6 +435,18 @@
 engine-setUrlInterceptor(interceptor);
 }
 
+QQmlComponent c(engine);
+c.setData(import QtQuick 2.1\n\
+import QtQuick.Controls 1.0\n\
+import QtQuick.Controls.Private 1.0\n \
+Item {\
+  Component.onCompleted: {\
+Settings.styleName = \Base\;\
+  }\
+}, QUrl());
+QObject *o = c.create();
+o-deleteLater();
+
 
d-qmlObject-setSource(QUrl::fromLocalFile(d-applet-package().filePath(mainscript)));
 
 if (!engine || !engine-rootContext() || !engine-rootContext()-isValid() 
|| !d-qmlObject-mainComponent() || d-qmlObject-mainComponent()-isError()) {
diff --git a/src/plasmaquick/view.cpp b/src/plasmaquick/view.cpp
index 1d1b506..1c981ae 100644
--- a/src/plasmaquick/view.cpp
+++ b/src/plasmaquick/view.cpp
@@ -196,6 +196,18 @@
 qWarning()  Invalid home screen package;
 }
 
+QQmlComponent c(engine());
+c.setData(import QtQuick 2.1\n\
+import QtQuick.Controls 1.0\n\
+import QtQuick.Controls.Private 1.0\n \
+Item {\
+  Component.onCompleted: {\
+Settings.styleName = \Base\;\
+  }\
+}, QUrl());
+QObject *o = c.create();
+o-deleteLater();
+
 setResizeMode(View::SizeRootObjectToView);
 }
 

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

Gerrit-MessageType: newchange
Gerrit-Change-Id: I696bdcbd78eb2e4df708367ac0d70d13c5d6cf12
Gerrit-PatchSet: 1
Gerrit-Project: plasma-framework
Gerrit-Branch: master
Gerrit-Owner: Marco Martin notm...@gmail.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121439: systemtrayicon: pass icon’s name(), not themeName() to showMessage


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

Ship it!


Ship It!

- Marco Martin


On Dec. 11, 2014, 8:26 a.m., Dmitry Shachnev wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121439/
 ---
 
 (Updated Dec. 11, 2014, 8:26 a.m.)
 
 
 Review request for Plasma and Martin Gräßlin.
 
 
 Repository: frameworkintegration
 
 
 Description
 ---
 
 Documentation of KStatusNotifierItem::showMessage() says:
 
 const QString icon | icon to be shown to the user
 
 So we need name of the icon here, not name of the theme.
 
 
 Diffs
 -
 
   src/platformtheme/kdeplatformsystemtrayicon.cpp 51f31ad 
 
 Diff: https://git.reviewboard.kde.org/r/121439/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Dmitry Shachnev
 


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

Re: Review Request 121411: Don't trigger animation if size changed.


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

Ship it!


Ship It!

- Marco Martin


On Dec. 11, 2014, 3:55 a.m., Xuetian Weng wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121411/
 ---
 
 (Updated Dec. 11, 2014, 3:55 a.m.)
 
 
 Review request for KDE Frameworks, Plasma, Aleix Pol Gonzalez, and Kai Uwe 
 Broulik.
 
 
 Repository: plasma-framework
 
 
 Description
 ---
 
 Making transition between two different size doesn't make much sense, since 
 repainting is usually happens at that time and it could take some time to 
 finish. And animation need to be stopped if m_animValue is set manually.
 
 
 Diffs
 -
 
   src/declarativeimports/core/iconitem.cpp 145a7cd 
 
 Diff: https://git.reviewboard.kde.org/r/121411/diff/
 
 
 Testing
 ---
 
 Looks fine on tray icon and lock screen, less blurry transition.
 
 
 Thanks,
 
 Xuetian Weng
 


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

Re: Review Request 120276: Initial port to frameworks for the comic dataengine.


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


what's the status of this?

- Marco Martin


On Oct. 17, 2014, 12:08 a.m., Andrei Amuraritei wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120276/
 ---
 
 (Updated Oct. 17, 2014, 12:08 a.m.)
 
 
 Review request for Plasma, David Edmundson, Marco Martin, Martin Klapetek, 
 and Sebastian Kügler.
 
 
 Repository: kdeplasma-addons
 
 
 Description
 ---
 
 comic DataEngine initial port to frameworks.
 
 
 Diffs
 -
 
   dataengines/CMakeLists.txt 04c7985 
   dataengines/comic/CMakeLists.txt 8e382e6 
   dataengines/comic/cachedprovider.h baac8a9 
   dataengines/comic/cachedprovider.cpp caca25e 
   dataengines/comic/comic.h 8cc3969 
   dataengines/comic/comic.cpp 7130f44 
   dataengines/comic/comic_package.h 32be381 
   dataengines/comic/comic_package.cpp 6d2ff0b 
   dataengines/comic/comic_package_plugin.cpp d997947 
   dataengines/comic/comicprovider.h 630ee8d 
   dataengines/comic/comicprovider.cpp ab248a5 
   dataengines/comic/comicproviderkross.h 46a9072 
   dataengines/comic/comicproviderkross.cpp 9820f05 
   dataengines/comic/comicproviderwrapper.h 81eee68 
   dataengines/comic/comicproviderwrapper.cpp 48ced42 
 
 Diff: https://git.reviewboard.kde.org/r/120276/diff/
 
 
 Testing
 ---
 
 Building from source, compiles 100%, some deprecated warnings. DataEngine 
 shows up in plasmaengineexplorer and detects installed .comic packages.
 This is the initial port, still need to review code to fix issues like 
 whitespaces around ( or the deprecated parts.
 Thanks notmart, d_ed, sebas, bshas etc for helping.
 
 Update: Engine is working...still need to port away from Solid and KService 
 to remove KDELibs4Support, that is still wip. 
 
 
 Thanks,
 
 Andrei Amuraritei
 


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

Re: Review Request 121439: systemtrayicon: pass icon’s name(), not themeName() to showMessage


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


Btw. do you have an actual bug where this can be seen/tested? Good spot 
otherwise!

- Martin Klapetek


On Dec. 11, 2014, 9:26 a.m., Dmitry Shachnev wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121439/
 ---
 
 (Updated Dec. 11, 2014, 9:26 a.m.)
 
 
 Review request for Plasma and Martin Gräßlin.
 
 
 Repository: frameworkintegration
 
 
 Description
 ---
 
 Documentation of KStatusNotifierItem::showMessage() says:
 
 const QString icon | icon to be shown to the user
 
 So we need name of the icon here, not name of the theme.
 
 
 Diffs
 -
 
   src/platformtheme/kdeplatformsystemtrayicon.cpp 51f31ad 
 
 Diff: https://git.reviewboard.kde.org/r/121439/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Dmitry Shachnev
 


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

Re: Review Request 121439: systemtrayicon: pass icon’s name(), not themeName() to showMessage



 On Dec. 11, 2014, 1:18 p.m., Martin Klapetek wrote:
  Btw. do you have an actual bug where this can be seen/tested? Good spot 
  otherwise!

I had seen something which I did not understand in the past: owncloud sync 
client was for a short time Qt 5.3 based and the icon was just broken and I 
didn't understand it.


- Martin


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


On Dec. 11, 2014, 9:26 a.m., Dmitry Shachnev wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121439/
 ---
 
 (Updated Dec. 11, 2014, 9:26 a.m.)
 
 
 Review request for Plasma and Martin Gräßlin.
 
 
 Repository: frameworkintegration
 
 
 Description
 ---
 
 Documentation of KStatusNotifierItem::showMessage() says:
 
 const QString icon | icon to be shown to the user
 
 So we need name of the icon here, not name of the theme.
 
 
 Diffs
 -
 
   src/platformtheme/kdeplatformsystemtrayicon.cpp 51f31ad 
 
 Diff: https://git.reviewboard.kde.org/r/121439/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Dmitry Shachnev
 


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

Re: Review Request 121439: systemtrayicon: pass icon’s name(), not themeName() to showMessage

2014-12-11 Thread Dmitry Shachnev



 On Dez. 11, 2014, 12:18 nachm., Martin Klapetek wrote:
  Btw. do you have an actual bug where this can be seen/tested? Good spot 
  otherwise!
 
 Martin Gräßlin wrote:
 I had seen something which I did not understand in the past: owncloud 
 sync client was for a short time Qt 5.3 based and the icon was just broken 
 and I didn't understand it.

No bug. I was just playing with my own QPlatformSystemTrayIcon implementation, 
looked at your code and spotted it.


- Dmitry


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


On Dez. 11, 2014, 8:26 vorm., Dmitry Shachnev wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121439/
 ---
 
 (Updated Dez. 11, 2014, 8:26 vorm.)
 
 
 Review request for Plasma and Martin Gräßlin.
 
 
 Repository: frameworkintegration
 
 
 Description
 ---
 
 Documentation of KStatusNotifierItem::showMessage() says:
 
 const QString icon | icon to be shown to the user
 
 So we need name of the icon here, not name of the theme.
 
 
 Diffs
 -
 
   src/platformtheme/kdeplatformsystemtrayicon.cpp 51f31ad 
 
 Diff: https://git.reviewboard.kde.org/r/121439/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Dmitry Shachnev
 


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

Re: Review Request 121439: systemtrayicon: pass icon’s name(), not themeName() to showMessage

2014-12-11 Thread Dmitry Shachnev


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

(Updated Dec. 11, 2014, 12:32 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma and Martin Gräßlin.


Repository: frameworkintegration


Description
---

Documentation of KStatusNotifierItem::showMessage() says:

const QString icon | icon to be shown to the user

So we need name of the icon here, not name of the theme.


Diffs
-

  src/platformtheme/kdeplatformsystemtrayicon.cpp 51f31ad 

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


Testing
---


Thanks,

Dmitry Shachnev

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

PlasmaCore::Dialog and QQuickRenderControl

Hi,

I'm currently hitting a problem where I don't know what to do about it. In 
KWin we use PlasmaCore::Dialog a lot (e.g. in Alt+Tab). Now with Qt 5.4 I 
would like to get all QQuickWindows to use QQuickRenderControl. The reason for 
this is that it would allow us the following:
* make KWin's OpenGL context and Qt's OpenGL context sharing. Advantage: we 
can bypass X completely when rendering a Quick scene and we can get KWin's 
textures into Quick (e.g. thumbnails without hacks).
* control the rendering from KWin's side: we should get better performance if 
we do not have multiple OpenGL contexts which perform swapBuffers in the same 
thread

Unfortunately one can only use the QQuickRenderControl if one creates the 
QQuickWindow with the ctor taking a QQuickRenderControl* argument. So for all 
cases where a PlasmaCore.Dialog is instantiated in QML this cannot work.

Any ideas how we could solve this problem? Could we make Dialog wrapping a 
QQuickWindow instead of inheriting it? Or are there better solutions?

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: PlasmaCore::Dialog and QQuickRenderControl

On Thursday 11 December 2014, Martin Gräßlin wrote:
 Unfortunately one can only use the QQuickRenderControl if one creates the
 QQuickWindow with the ctor taking a QQuickRenderControl* argument. So for
 all cases where a PlasmaCore.Dialog is instantiated in QML this cannot
 work.

you mean it would still be possible to use qwindows as dialogs, but just 
create them in a different way?

 Any ideas how we could solve this problem? Could we make Dialog wrapping a
 QQuickWindow instead of inheriting it? Or are there better solutions?

this may work, but could be a bit problematic since i guess a lot of qml code 
expects it to expose the full qquickwindow api/properties, that would all have 
to be wrapped


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

Re: Re: PlasmaCore::Dialog and QQuickRenderControl

On Thursday 11 December 2014 13:51:06 Marco Martin wrote:
 On Thursday 11 December 2014, Martin Gräßlin wrote:
  Unfortunately one can only use the QQuickRenderControl if one creates the
  QQuickWindow with the ctor taking a QQuickRenderControl* argument. So for
  all cases where a PlasmaCore.Dialog is instantiated in QML this cannot
  work.
 
 you mean it would still be possible to use qwindows as dialogs, but just
 create them in a different way?

yes

 
  Any ideas how we could solve this problem? Could we make Dialog wrapping a
  QQuickWindow instead of inheriting it? Or are there better solutions?
 
 this may work, but could be a bit problematic since i guess a lot of qml
 code expects it to expose the full qquickwindow api/properties, that would
 all have to be wrapped

That's what I would fear, too. It's certainly a lot of work and rather 
dangerous (hell we know all the problems dialog had)

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

Re: PlasmaCore::Dialog and QQuickRenderControl

On Thursday 11 December 2014, Martin Gräßlin wrote:
  you mean it would still be possible to use qwindows as dialogs, but just
  create them in a different way?
 
 yes

ah, internal api... splendid

   Any ideas how we could solve this problem? Could we make Dialog
   wrapping a QQuickWindow instead of inheriting it? Or are there better
   solutions?
  
  this may work, but could be a bit problematic since i guess a lot of qml
  code expects it to expose the full qquickwindow api/properties, that
  would all have to be wrapped
 
 That's what I would fear, too. It's certainly a lot of work and rather
 dangerous (hell we know all the problems dialog had)

has kwin a single QQuickRenderControl ?
could the following be done?
* register the QQuickRenderControl (or multiple ones by engine, if necessary) 
in a some kind of singleton
* then Dialog would either call the normal superclass ctor or the one with 
QQuickRenderControl if any was set

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

Re: Re: PlasmaCore::Dialog and QQuickRenderControl

On Thursday 11 December 2014 14:07:30 Marco Martin wrote:
 On Thursday 11 December 2014, Martin Gräßlin wrote:
   you mean it would still be possible to use qwindows as dialogs, but just
   create them in a different way?
  
  yes
 
 ah, internal api... splendid
 
Any ideas how we could solve this problem? Could we make Dialog
wrapping a QQuickWindow instead of inheriting it? Or are there better
solutions?
   
   this may work, but could be a bit problematic since i guess a lot of qml
   code expects it to expose the full qquickwindow api/properties, that
   would all have to be wrapped
  
  That's what I would fear, too. It's certainly a lot of work and rather
  dangerous (hell we know all the problems dialog had)
 
 has kwin a single QQuickRenderControl ?

I'm not 100 % sure whether one can use one QQuickRenderControl for multiple 
windows. The API documentation is not clear about it, but there are signals 
like QQuickRenderControl::sync which do not carry for which scene it is, so I 
assume one needs to have one QQuickRenderControl per QQuickWindow.

 could the following be done?
 * register the QQuickRenderControl (or multiple ones by engine, if
 necessary) in a some kind of singleton
 * then Dialog would either call the normal superclass ctor or the one with
 QQuickRenderControl if any was set

That could work even if we need one QQuickRenderControl per window. It could 
be set as a magic context property __org_kde_plasma_dialog_render_control

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 121402: Allow user to customise wallpaper used in the lock screen.


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

(Updated Dec. 11, 2014, 1:24 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: plasma-workspace


Description
---

Allow user to customise wallpaper used in the lock screen.

Nothing very fancy it's the same plain image approach we use in SDDM. 
Default behaviour is unchanged. We can always expand it later.


Diffs
-

  lookandfeel/contents/lockscreen/LockScreen.qml ca9beb2 
  ksmserver/screenlocker/kcm/kcm.cpp 0f74c45 
  ksmserver/screenlocker/kcm/kcm.ui c891cc9 
  ksmserver/screenlocker/kcm/selectimagebutton.h PRE-CREATION 
  ksmserver/screenlocker/kcm/selectimagebutton.cpp PRE-CREATION 
  ksmserver/screenlocker/greeter/greeterapp.cpp 60bd347 
  ksmserver/screenlocker/kcfg/kscreenlockersettings.kcfg 5207615 
  ksmserver/screenlocker/kcm/CMakeLists.txt a23a0fc 

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


Testing
---

Opened lockscreen.
Most code is tried and tested in the SDDM KCM.


Thanks,

David Edmundson

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

Re: [plasma-devel] Qt 5.4


No objections to this so I'll switch it over

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

Change in plasma-framework[master]: Use the same text colour for comboboxes as buttons

2014-12-11 Thread David Edmundson (Code Review)

David Edmundson has uploaded a new change for review.

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

Change subject: Use the same text colour for comboboxes as buttons
..

Use the same text colour for comboboxes as buttons

Given comboboxes use the same background as buttons they should use the
same text colour too.

This prevents a situation in Breeze where a ComboBox could get white
text on a white background when using a colourscope with complementary
colours.

Change-Id: I21502186178a32ce480cd3e838335451bf644c3e
---
M src/declarativeimports/plasmastyle/ComboBoxStyle.qml
A tests/components/combobox.qml
2 files changed, 42 insertions(+), 0 deletions(-)


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

diff --git a/src/declarativeimports/plasmastyle/ComboBoxStyle.qml 
b/src/declarativeimports/plasmastyle/ComboBoxStyle.qml
index e73d0da..501efed 100644
--- a/src/declarativeimports/plasmastyle/ComboBoxStyle.qml
+++ b/src/declarativeimports/plasmastyle/ComboBoxStyle.qml
@@ -31,6 +31,7 @@
 label: PlasmaComponents.Label {
 text: control.currentText
 elide: Text.ElideRight
+color: theme.buttonTextColor
 verticalAlignment: Text.AlignTop
 }
 
diff --git a/tests/components/combobox.qml b/tests/components/combobox.qml
new file mode 100644
index 000..76510f3
--- /dev/null
+++ b/tests/components/combobox.qml
@@ -0,0 +1,41 @@
+import QtQuick 2.0
+
+import org.kde.plasma.components 2.0
+import org.kde.plasma.core 2.0 as PlasmaCore
+
+Rectangle {
+id: root
+color: white
+width: 800
+height: 300
+
+ListModel {
+id: demoModel
+ListElement { text: Banana; color: Yellow }
+ListElement { text: Apple; color: Green }
+ListElement { text: Coconut; color: Brown }
+}
+
+Flow {
+anchors.fill: parent
+anchors.margins: 20
+spacing: 20
+
+ComboBox {
+model:demoModel
+}
+ComboBox {
+editable: true
+model: demoModel
+}
+PlasmaCore.ColorScope {
+implicitWidth: childrenRect.width
+implicitHeight: childrenRect.width
+
+colorGroup: PlasmaCore.Theme.ComplementaryColorGroup
+ComboBox {
+model:demoModel
+}
+}
+}
+}
\ No newline at end of file

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

Gerrit-MessageType: newchange
Gerrit-Change-Id: I21502186178a32ce480cd3e838335451bf644c3e
Gerrit-PatchSet: 1
Gerrit-Project: plasma-framework
Gerrit-Branch: master
Gerrit-Owner: David Edmundson da...@davidedmundson.co.uk
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5.2 parts

2014-12-11 Thread Daniel Vrátil

On Thursday, December 11, 2014 03:07:04 PM Jonathan Riddell wrote:
 5.1.2 tars are made so it's time to be thinking about what needs included
 in Plasma 5.2
 
 New in will be Muon package manager and gtk-config, these have already gone
 through review.
 
 polkit-kde is currently going through review and if nobody objects can go
 into kde-workspace next week.  Please review it
 http://thread.gmane.org/gmane.comp.kde.devel.general/68224/focus=85357
 
 There's some other parts which are missing from a Plasma 5 desktop and
 might make sense to ship with it..
 
 Bluedevil has a frameworks port, David Rosca seems to be the person who did
 that, do you think it would be suitable to include with Plasma 5.2?
 
 User-manager has had a port by Vishesh, it compiles and runs, shall we
 include it?
 
 kscreen has been ported by Dan Vrátil, can that be included?

Yes. I'll submit kscreen and libkscreen for review and move it to workspace, 
as we discussed.

 
 print-manager has been ported with Lukas and Jan being the dudes there, can
 that be included?
 
 Anyone know the kcm touchpad author? I feel that is a candidate for
 inclusion.
 
 And what's to be removed?
 
 Baloo is becoming a framework, is that all to move?  Presumably Milou still
 one of ours?
 
 Are libnm-qt and libmm-qt moving to frameworks?  Presumably plasma-nm still
 part of Plasma?
 
 Jonathan

-- 
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: Plasma 5.2 parts

2014-12-11 Thread Jan Grulich

Hi,

On Thursday 11 of December 2014 15:07 Jonathan Riddell wrote:
 5.1.2 tars are made so it's time to be thinking about what needs included
 in Plasma 5.2
 
 New in will be Muon package manager and gtk-config, these have already gone
 through review.
 
 polkit-kde is currently going through review and if nobody objects can go
 into kde-workspace next week.  Please review it
 http://thread.gmane.org/gmane.comp.kde.devel.general/68224/focus=85357
 
 There's some other parts which are missing from a Plasma 5 desktop and
 might make sense to ship with it..
 
 Bluedevil has a frameworks port, David Rosca seems to be the person who did
 that, do you think it would be suitable to include with Plasma 5.2?
 
 User-manager has had a port by Vishesh, it compiles and runs, shall we
 include it?
 
 kscreen has been ported by Dan Vrátil, can that be included?
 
 print-manager has been ported with Lukas and Jan being the dudes there, can
 that be included?
 

I think print-manager can be included, it works and I didn't notice any 
problem yet, at least with the applet.

 Anyone know the kcm touchpad author? I feel that is a candidate for
 inclusion.
 
 And what's to be removed?
 
 Baloo is becoming a framework, is that all to move?  Presumably Milou still
 one of ours?
 
 Are libnm-qt and libmm-qt moving to frameworks?  Presumably plasma-nm still
 part of Plasma?
 

I'm trying to push libnm-qt as a framework, but so far it looks that nobody 
cares about it. Not sure about libmm-qt, we don't have even unit tests and I'm 
afraid we won't make it as a framework before Plasma 5.2 gets released.

Regards,
Jan
-- 
Jan Grulich 
Red Hat Czech, s.r.o
jgrul...@redhat.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5.2 parts

On Thu, Dec 11, 2014 at 03:09:10PM +0100, Daniel Vrátil wrote:
 Yes. I'll submit kscreen and libkscreen for review and move it to workspace, 
 as we discussed.

libkscreen is in already, just kscreen to review/move

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

kcm-touchpad in plasma 5.2?

Morning, I'm looking at the requirements for Plasma to become a
complete desktop and touchpad configuration is currently missing.
You've done the port of kcm-touchpad to KF5, do you think it should be
included with Plasma 5.2 ?

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

Review Request 121449: Rename Human Input Devices to just Input Devices


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

Review request for Plasma and KDE Usability.


Repository: systemsettings


Description
---

The Human part feels strange (even though technically correct). Putting just 
Input devices is stil correct and feels more natural


Diffs
-

  categories/settings-hardware-input.desktop ddc3204 

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


Testing
---


Thanks,

Martin Klapetek

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

Re: Review Request 121449: Rename Human Input Devices to just Input Devices


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


+1

- David Edmundson


On Dec. 11, 2014, 2:43 p.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121449/
 ---
 
 (Updated Dec. 11, 2014, 2:43 p.m.)
 
 
 Review request for Plasma and KDE Usability.
 
 
 Repository: systemsettings
 
 
 Description
 ---
 
 The Human part feels strange (even though technically correct). Putting 
 just Input devices is stil correct and feels more natural
 
 
 Diffs
 -
 
   categories/settings-hardware-input.desktop ddc3204 
 
 Diff: https://git.reviewboard.kde.org/r/121449/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Martin Klapetek
 


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

Fwd: Re: kcm-touchpad in plasma 5.2?

- Forwarded message from Alexander Mezin mezin.alexan...@gmail.com -

Date: Thu, 11 Dec 2014 21:15:53 +0600
Subject: Re: kcm-touchpad in plasma 5.2?
From: Alexander Mezin mezin.alexan...@gmail.com
To: Jonathan Riddell j...@jriddell.org
Cc: Rajeesh K Nambiar rajeeshknamb...@gmail.com

Hi.

I had plans on rewriting kcm-touchpad from scratch, but now it seems I
won't have time for it, at least in near future.

Of course, I'm not against moving it to plasma. Though there are many
things I don't like, many mistakes in kcm-touchpad (not the frameworks
port, but the entire application). Current solution is better than
nothing, at least.

Also I think somebody else should become a maintainer of kcm-touchpad,
as I don't have time even for that now.

2014-12-11 20:50 GMT+06:00 Jonathan Riddell j...@jriddell.org:
 On Thu, Dec 11, 2014 at 03:33:03PM +0100, Rajeesh K Nambiar wrote:
 Hi Jonathan,

 On Thu, Dec 11, 2014 at 3:28 PM, Jonathan Riddell j...@jriddell.org wrote:
  Morning, I'm looking at the requirements for Plasma to become a
  complete desktop and touchpad configuration is currently missing.
  You've done the port of kcm-touchpad to KF5, do you think it should be
  included with Plasma 5.2 ?

 By all means, please. It's currently in the 'frameworks' branch, and
 if maintainers are okay. I could update it if needed (in case if api
 changes occurred).

 Great, David Edmundson says he'll review and look at moving it to 
 plasma-desktop.

 Adding in Alexander Mezin as original author who may also have an opinion.

 Jonathan

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

Re: Review Request 121449: Rename Human Input Devices to just Input Devices


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


-1: there was probably a good reason to name it like that as the renaming 
process was done by our usability experts. We shouldn't dismiss their feedback 
just because we think it sounds strange.

- Martin Gräßlin


On Dec. 11, 2014, 3:43 p.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121449/
 ---
 
 (Updated Dec. 11, 2014, 3:43 p.m.)
 
 
 Review request for Plasma and KDE Usability.
 
 
 Repository: systemsettings
 
 
 Description
 ---
 
 The Human part feels strange (even though technically correct). Putting 
 just Input devices is stil correct and feels more natural
 
 
 Diffs
 -
 
   categories/settings-hardware-input.desktop ddc3204 
 
 Diff: https://git.reviewboard.kde.org/r/121449/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Martin Klapetek
 


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

Re: Review Request 121449: Rename Human Input Devices to just Input Devices

2014-12-11 Thread Eike Hein



 On Dec. 11, 2014, 3:19 p.m., Martin Gräßlin wrote:
  -1: there was probably a good reason to name it like that as the renaming 
  process was done by our usability experts. We shouldn't dismiss their 
  feedback just because we think it sounds strange.

At the same time it's clear that KDE is too cis-species'd and this is offensive 
to both our alien user community and pets on keyboards.


- Eike


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


On Dec. 11, 2014, 2:43 p.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121449/
 ---
 
 (Updated Dec. 11, 2014, 2:43 p.m.)
 
 
 Review request for Plasma and KDE Usability.
 
 
 Repository: systemsettings
 
 
 Description
 ---
 
 The Human part feels strange (even though technically correct). Putting 
 just Input devices is stil correct and feels more natural
 
 
 Diffs
 -
 
   categories/settings-hardware-input.desktop ddc3204 
 
 Diff: https://git.reviewboard.kde.org/r/121449/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Martin Klapetek
 


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

Re: Re: kcm-touchpad in plasma 5.2?

In general this looks OK, there's some useful features and I can see myself
using this. I'd very much like it to become part of Plasma.

I gave it a review and made some notes below.

kded.cpp
The touchpad backend leaks?

There are blocking calls in the constructor using isServiceRegistered
combined with the dataengine querying this kded module in a blocking way in
init we have a strong potential to deadlock the two applications
For KDED modules we have to be a lot more strict to never block as others
will be querying us.

I don't understand why we're watching for plasmashell/kglobalaccel anyway.
Could you explain the rationale here.

applet:
The applet is completely not ported.

Applet translations need to go into a differnet .po file with a specific
name
Copy a Messages.sh from one of the other plasmoids

KCM:
reverse scrolling doesn't seem to work
disabled taps and scrolling only -- The HIG says to avoid negated
checkbox descriptions.

The translation_domain doesn't seem to be set, so kded/kcm won't load
anything

touchpad backend.h:
This class shouldn't be instantiated directly, don't make the constructor
public.

The X backend:
This looked scary so I didn't review it at all.

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

Re: Review Request 121449: Rename Human Input Devices to just Input Devices

2014-12-11 Thread Lukáš Tinkl


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


+1 

And I actually wonder how the thing is translated in other languages because in 
Czech, I omitted the word Human on purpose as there is no way I could make it 
meaningful w/o looking like an alien word.

- Lukáš Tinkl


On Pro. 11, 2014, 3:43 odp., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121449/
 ---
 
 (Updated Pro. 11, 2014, 3:43 odp.)
 
 
 Review request for Plasma and KDE Usability.
 
 
 Repository: systemsettings
 
 
 Description
 ---
 
 The Human part feels strange (even though technically correct). Putting 
 just Input devices is stil correct and feels more natural
 
 
 Diffs
 -
 
   categories/settings-hardware-input.desktop ddc3204 
 
 Diff: https://git.reviewboard.kde.org/r/121449/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Martin Klapetek
 


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

Re: Review Request 121449: Rename Human Input Devices to just Input Devices

2014-12-11 Thread Eike Hein



 On Dec. 11, 2014, 3:25 p.m., Lukáš Tinkl wrote:
  +1 
  
  And I actually wonder how the thing is translated in other languages 
  because in Czech, I omitted the word Human on purpose as there is no way 
  I could make it meaningful w/o looking like an alien word.

Looking at the .desktop, most of the translations drop the Human.


- Eike


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


On Dec. 11, 2014, 2:43 p.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121449/
 ---
 
 (Updated Dec. 11, 2014, 2:43 p.m.)
 
 
 Review request for Plasma and KDE Usability.
 
 
 Repository: systemsettings
 
 
 Description
 ---
 
 The Human part feels strange (even though technically correct). Putting 
 just Input devices is stil correct and feels more natural
 
 
 Diffs
 -
 
   categories/settings-hardware-input.desktop ddc3204 
 
 Diff: https://git.reviewboard.kde.org/r/121449/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Martin Klapetek
 


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

Re: Plasma 5.2 parts

2014-12-11 Thread Jeremy Whiting

Also possibly ksshaskpass, which has been in kdereview since early november.

On Thu, Dec 11, 2014 at 7:11 AM, Jonathan Riddell j...@jriddell.org wrote:

 On Thu, Dec 11, 2014 at 03:09:10PM +0100, Daniel Vrátil wrote:
  Yes. I'll submit kscreen and libkscreen for review and move it to
 workspace,
  as we discussed.

 libkscreen is in already, just kscreen to review/move

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

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

Re: Review Request 121449: Rename Human Input Devices to just Input Devices



 On Dec. 11, 2014, 4:19 p.m., Martin Gräßlin wrote:
  -1: there was probably a good reason to name it like that as the renaming 
  process was done by our usability experts. We shouldn't dismiss their 
  feedback just because we think it sounds strange.
 
 Eike Hein wrote:
 At the same time it's clear that KDE is too cis-species'd and this is 
 offensive to both our alien user community and pets on keyboards.

Martin: fair enough, that's precisely why I put the usability group here too. 
It's not dismissing, it's iterating ;)


- Martin


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


On Dec. 11, 2014, 3:43 p.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121449/
 ---
 
 (Updated Dec. 11, 2014, 3:43 p.m.)
 
 
 Review request for Plasma and KDE Usability.
 
 
 Repository: systemsettings
 
 
 Description
 ---
 
 The Human part feels strange (even though technically correct). Putting 
 just Input devices is stil correct and feels more natural
 
 
 Diffs
 -
 
   categories/settings-hardware-input.desktop ddc3204 
 
 Diff: https://git.reviewboard.kde.org/r/121449/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Martin Klapetek
 


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

Re: Review Request 121449: Rename Human Input Devices to just Input Devices



 On Dec. 11, 2014, 4:19 p.m., Martin Gräßlin wrote:
  -1: there was probably a good reason to name it like that as the renaming 
  process was done by our usability experts. We shouldn't dismiss their 
  feedback just because we think it sounds strange.
 
 Eike Hein wrote:
 At the same time it's clear that KDE is too cis-species'd and this is 
 offensive to both our alien user community and pets on keyboards.
 
 Martin Klapetek wrote:
 Martin: fair enough, that's precisely why I put the usability group here 
 too. It's not dismissing, it's iterating ;)

 pets on keyboards.

back in the days of my student flat-sharing community I came back from a week 
long trip and found my computer to be on. It turned out that my flatmate's cat 
jumped on the keyboard and turned it on. So I'm very happy to discrimenate 
against pets using input devices!!!

@Martin: fair enough, I must have missed the usability group in the review 
section.


- Martin


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


On Dec. 11, 2014, 3:43 p.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121449/
 ---
 
 (Updated Dec. 11, 2014, 3:43 p.m.)
 
 
 Review request for Plasma and KDE Usability.
 
 
 Repository: systemsettings
 
 
 Description
 ---
 
 The Human part feels strange (even though technically correct). Putting 
 just Input devices is stil correct and feels more natural
 
 
 Diffs
 -
 
   categories/settings-hardware-input.desktop ddc3204 
 
 Diff: https://git.reviewboard.kde.org/r/121449/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Martin Klapetek
 


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

Re: Review Request 121449: Rename Human Input Devices to just Input Devices

2014-12-11 Thread Thomas Pfeiffer


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


I'll just comment here to let you know that you're not being ignored.
From my perspective, just Input Devices - while less precise - would work as 
well. I'd like to give Heiko, who came up with the Human in the name, the 
chance to comment as well before giving it a Ship it from our group, though.

- Thomas Pfeiffer


On Dez. 11, 2014, 2:43 nachm., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121449/
 ---
 
 (Updated Dez. 11, 2014, 2:43 nachm.)
 
 
 Review request for Plasma and KDE Usability.
 
 
 Repository: systemsettings
 
 
 Description
 ---
 
 The Human part feels strange (even though technically correct). Putting 
 just Input devices is stil correct and feels more natural
 
 
 Diffs
 -
 
   categories/settings-hardware-input.desktop ddc3204 
 
 Diff: https://git.reviewboard.kde.org/r/121449/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Martin Klapetek
 


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

[Powerdevil] [Bug 341775] New: Powerdevil kded triggers kded5 loop

2014-12-11 Thread Hrvoje Senjan

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

Bug ID: 341775
   Summary: Powerdevil kded triggers kded5 loop
   Product: Powerdevil
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: grave
  Priority: NOR
 Component: general
  Assignee: plasma-devel@kde.org
  Reporter: hrvoje.sen...@gmail.com

Since 697e505f37b9128d68ef2b0ce5c9d7f80ca422ff - Emit signal when maximum
brightness changes, i am getting kded5 killing the CPU... obtained backtrace:

Thread 1 (Thread 0x7f79784fb780 (LWP 23601)):
#0  0x7f7973df7a80 in  () at /usr/lib64/libglib-2.0.so.0
#1  0x7f7973df7cec in g_main_context_iteration () at
/usr/lib64/libglib-2.0.so.0
#2  0x7f7975c26f9c in
QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) ()
at /usr/lib64/libQt5Core.so.5
#3  0x7f7975bcdbbb in
QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () at
/usr/lib64/libQt5Core.so.5
#4  0x7f7976fdaa6e in KJob::exec() () at /usr/lib64/libKF5CoreAddons.so.5
#5  0x7f795d87cb94 in
PowerDevilUPowerBackend::brightnessValueMax(PowerDevil::BackendInterface::BrightnessControlType)
const (this=optimized out, type=optimized out) at
/usr/src/debug/powerdevil-5.1.90git/daemon/backends/upower/powerdevilupowerbackend.cpp:384
#6  0x7f795d442a92 in
BrightnessControlAdaptor::qt_static_metacall(QObject*, QMetaObject::Call, int,
void**) (this=0x15417e0)
---Type return to continue, or q return to quit---
at
/usr/src/debug/powerdevil-5.1.90git/build/daemon/brightnesscontroladaptor.cpp:63
#7  0x7f795d442a92 in
BrightnessControlAdaptor::qt_static_metacall(QObject*, QMetaObject::Call, int,
void**) (_o=_o@entry=0x15417e0, _c=_c@entry=QMetaObject::InvokeMetaMethod,
_id=_id@entry=8, _a=_a@entry=0x7fff181aa440)
at
/usr/src/debug/powerdevil-5.1.90git/build/daemon/brightnesscontroladaptor.moc:153
#8  0x7f795d442ce3 in
BrightnessControlAdaptor::qt_metacall(QMetaObject::Call, int, void**)
(this=0x15417e0, _c=QMetaObject::InvokeMetaMethod, _id=8, _a=0x7fff181aa440) at
/usr/src/debug/powerdevil-5.1.90git/build/daemon/brightnesscontroladaptor.moc:216
#9  0x7f797749d67f in QDBusConnectionPrivate::deliverCall(QObject*, int,
QDBusMessage const, QVectorint const, int) (this=this@entry=
0x1117010, object=object@entry=0x15417e0, msg=..., metaTypes=...,
slotIdx=13) at qdbusintegrator.cpp:990
#10 0x7f79774a1dac in QDBusConnectionPrivate::activateCall(QObject*, int,
QDBusMessage const) (this=this@entry=0x1117010, object=0x15417e0,
flags=flags@entry=273, msg=...) at qdbusintegrator.cpp:902
#11 0x7f79774a2823 in
QDBusConnectionPrivate::activateObject(QDBusConnectionPrivate::ObjectTreeNode,
QDBusMessage const, int) (this=0x1117010, node=..., msg=...,
pathStartPos=optimized out) at qdbusintegrator.cpp:1463
#12 0x7f79774a426e in QDBusActivateObjectEvent::placeMetaCall(QObject*)
(this=0x17f58c0) at qdbusintegrator.cpp:1577
#13 0x7f7975c002b6 in QObject::event(QEvent*) () at
/usr/lib64/libQt5Core.so.5
#14 0x7f797688da9c in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() at /usr/lib64/libQt5Widgets.so.5
#15 0x7f7976892b00 in QApplication::notify(QObject*, QEvent*) () at
/usr/lib64/libQt5Widgets.so.5
#16 0x7f7975bcfc55 in QCoreApplication::notifyInternal(QObject*, QEvent*)
() at /usr/lib64/libQt5Core.so.5
#17 0x7f7975bd1aef in QCoreApplicationPrivate::sendPostedEvents(QObject*,
int, QThreadData*) () at /usr/lib64/libQt5Core.so.5
#18 0x7f7975c27b23 in  () at /usr/lib64/libQt5Core.so.5
#19 0x7f7973df7a04 in g_main_context_dispatch () at
/usr/lib64/libglib-2.0.so.0
#20 0x7f7973df7c48 in  () at /usr/lib64/libglib-2.0.so.0
#21 0x7f7973df7cec in g_main_context_iteration () at
/usr/lib64/libglib-2.0.so.0
#22 0x7f7975c26f9c in
QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) ()
at /usr/lib64/libQt5Core.so.5
---Type return to continue, or q return to quit---
#23 0x7f7975bcdbbb in
QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () at
/usr/lib64/libQt5Core.so.5
#24 0x7f7976fdaa6e in KJob::exec() () at /usr/lib64/libKF5CoreAddons.so.5
#25 0x7f795d87d196 in
PowerDevilUPowerBackend::brightnessValue(PowerDevil::BackendInterface::BrightnessControlType)
const (this=
0x153a620, type=optimized out) at
/usr/src/debug/powerdevil-5.1.90git/daemon/backends/upower/powerdevilupowerbackend.cpp:354
#26 0x7f795d442a62 in
BrightnessControlAdaptor::qt_static_metacall(QObject*, QMetaObject::Call, int,
void**) (this=0x15417e0)
at
/usr/src/debug/powerdevil-5.1.90git/build/daemon/brightnesscontroladaptor.cpp:57
#27 0x7f795d442a62 in
BrightnessControlAdaptor::qt_static_metacall(QObject*, QMetaObject::Call, int,
void**) (_o=_o@entry=0x15417e0, _c=_c@entry=QMetaObject::InvokeMetaMethod,
_id=_id@entry=7, _a=_a@entry=0x7fff181aaec0)
at

Plasma 5.1.2 tars up


Plasma 5.1.2 tars are up

 http://starsky.19inch.net/~jr/tmp/plasma-5.1.2/

and coming soon to depot.  Please check them for sanity.

Release is due on Tuesday.

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

Re: Review Request 121449: Rename Human Input Devices to just Input Devices

2014-12-11 Thread Heiko Tietze


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


Isn't the term HID very common? Human interface device (or input) to 
distinguish it from network cable, or the like, that are rather for the pets to 
play with. But I don't stick to the name.

- Heiko Tietze


On Dez. 11, 2014, 2:43 nachm., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121449/
 ---
 
 (Updated Dez. 11, 2014, 2:43 nachm.)
 
 
 Review request for Plasma and KDE Usability.
 
 
 Repository: systemsettings
 
 
 Description
 ---
 
 The Human part feels strange (even though technically correct). Putting 
 just Input devices is stil correct and feels more natural
 
 
 Diffs
 -
 
   categories/settings-hardware-input.desktop ddc3204 
 
 Diff: https://git.reviewboard.kde.org/r/121449/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Martin Klapetek
 


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

Re: Qt 5.4

2014-12-11 Thread Aleix Pol

On Wed, Dec 10, 2014 at 4:26 PM, Eike Hein h...@kde.org wrote:


 On 12/10/2014 04:14 PM, Aleix Pol wrote:

 On Wed, Dec 10, 2014 at 4:10 PM, Eike Hein h...@kde.org
 mailto:h...@kde.org wrote:


 There's a bunch of unsolved new regressions (e.g. DND of files is
 broken on 5.4) but nothing out of the ordinary breakage level I
 guess.


 Cheers,
 Eike


 I wasn't aware, I've worked on that code, if you can provide a test case
 I'll give it a go.


 Basically, KDE file managers use KDirModel::mimeData(QModelIndexList)
 to generate MIME payload for QDrags they initiate, which means a
 text/uri-list of file URLs. These are intact before QDrag::exec() but
 wind up not making it to the other side - formats() has text/uri-list
 and hasUrls() is true, but urls() is an empty QList. It's most likely
 an encode/decode issue, i.e. the raw data is in the drop but urls()
 fails to decode them. I'm guessing it's related to QTBUG-42285.


 Aleix


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

Hi Eike,
I've been looking into this and it seems to work, at least the
dropsite example [1] works great here both with dolphin and
folderview.

Aleix

[1] qtbase/examples/widgets/draganddrop/dropsite
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5.2 parts

On Thu, Dec 11, 2014 at 03:10:46PM +0100, Jan Grulich wrote:
 I think print-manager can be included, it works and I didn't notice any 
 problem yet, at least with the applet.

I just tried it, all good except for one bug I filed
 https://bugs.kde.org/show_bug.cgi?id=341780

CCing dantii incase he has an opinion

Should it be part of Plasma Desktop or its own tar?

Should it go through the review process?

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

Re: Review Request 121449: Rename Human Input Devices to just Input Devices

2014-12-11 Thread Aleix Pol Gonzalez



 On Dec. 11, 2014, 5:01 p.m., Heiko Tietze wrote:
  Isn't the term HID very common? Human interface device (or input) to 
  distinguish it from network cable, or the like, that are rather for the 
  pets to play with. But I don't stick to the name.

To me HID is mostly a technical term. As a user, I only expect the input 
devices the devices I use myself for input.


- Aleix


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


On Dec. 11, 2014, 2:43 p.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121449/
 ---
 
 (Updated Dec. 11, 2014, 2:43 p.m.)
 
 
 Review request for Plasma and KDE Usability.
 
 
 Repository: systemsettings
 
 
 Description
 ---
 
 The Human part feels strange (even though technically correct). Putting 
 just Input devices is stil correct and feels more natural
 
 
 Diffs
 -
 
   categories/settings-hardware-input.desktop ddc3204 
 
 Diff: https://git.reviewboard.kde.org/r/121449/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Martin Klapetek
 


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

Re: Review Request 121449: Rename Human Input Devices to just Input Devices

2014-12-11 Thread Lukáš Tinkl



 On Pro. 11, 2014, 6:01 odp., Heiko Tietze wrote:
  Isn't the term HID very common? Human interface device (or input) to 
  distinguish it from network cable, or the like, that are rather for the 
  pets to play with. But I don't stick to the name.
 
 Aleix Pol Gonzalez wrote:
 To me HID is mostly a technical term. As a user, I only expect the input 
 devices the devices I use myself for input.

Yes, according to wikipedia, it's 
http://en.wikipedia.org/wiki/Human_interface_device

But here we talk about Human _Input_ Devices, see the confusion? :)


- Lukáš


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


On Pro. 11, 2014, 3:43 odp., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121449/
 ---
 
 (Updated Pro. 11, 2014, 3:43 odp.)
 
 
 Review request for Plasma and KDE Usability.
 
 
 Repository: systemsettings
 
 
 Description
 ---
 
 The Human part feels strange (even though technically correct). Putting 
 just Input devices is stil correct and feels more natural
 
 
 Diffs
 -
 
   categories/settings-hardware-input.desktop ddc3204 
 
 Diff: https://git.reviewboard.kde.org/r/121449/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Martin Klapetek
 


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

Re: Plasma 5.2 parts

It was poinsted out that sddm-kcm is to be added, it's gone through
kdereview and I've filed a ticket with sysadmin to move to kde/workspace

https://sysadmin.kde.org/tickets/index.php?page=ticketsact=doadd

http://thread.gmane.org/gmane.comp.kde.devel.core/84629

Jonathan


On 11 December 2014 at 15:07, Jonathan Riddell j...@jriddell.org wrote:

 5.1.2 tars are made so it's time to be thinking about what needs included
 in Plasma 5.2

 New in will be Muon package manager and gtk-config, these have already
 gone through review.

 polkit-kde is currently going through review and if nobody objects can go
 into kde-workspace next week.  Please review it
 http://thread.gmane.org/gmane.comp.kde.devel.general/68224/focus=85357

 There's some other parts which are missing from a Plasma 5 desktop and
 might make sense to ship with it..

 Bluedevil has a frameworks port, David Rosca seems to be the person who
 did that, do you think it would be suitable to include with Plasma 5.2?

 User-manager has had a port by Vishesh, it compiles and runs, shall we
 include it?

 kscreen has been ported by Dan Vrátil, can that be included?

 print-manager has been ported with Lukas and Jan being the dudes there,
 can that be included?

 Anyone know the kcm touchpad author? I feel that is a candidate for
 inclusion.

 And what's to be removed?

 Baloo is becoming a framework, is that all to move?  Presumably Milou
 still one of ours?

 Are libnm-qt and libmm-qt moving to frameworks?  Presumably plasma-nm
 still part of Plasma?

 Jonathan


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

Re: Review Request 121411: Don't trigger animation if size changed.

2014-12-11 Thread Xuetian Weng


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

(Updated Dec. 11, 2014, 7:49 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Plasma, Aleix Pol Gonzalez, and Kai Uwe 
Broulik.


Repository: plasma-framework


Description
---

Making transition between two different size doesn't make much sense, since 
repainting is usually happens at that time and it could take some time to 
finish. And animation need to be stopped if m_animValue is set manually.


Diffs
-

  src/declarativeimports/core/iconitem.cpp 145a7cd 

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


Testing
---

Looks fine on tray icon and lock screen, less blurry transition.


Thanks,

Xuetian Weng

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

Re: Review Request 121411: Don't trigger animation if size changed.

On Dec. 9, 2014, 6:11 p.m., Kai Uwe Broulik wrote:
Wasn't that part of the idea? Having it scale up the pixmap first when
resizing and then re-rendering it later?

Xuetian Weng wrote:
1. icon size (the widget size) doesn't change frequently. Usually it only
happens when user resize the UI or changes the settings.
2. the animation IMHO is for smooth transition between different
icons/different icon effect (check volume icon, media player play/pause,
hovering with opacity changes), I don't see we need to have animated
transition from a scaled icon to the actual correct size icon.

David Edmundson wrote:
Icon size changes may be infrequent but they do happen. It's important
that when we resize the panel we don't re-render a tonne of SVGs constantly,
we need resizing applets to be smooth.

I don't understand where this blurriness is coming from; that implies
we're loading it at a wrong size then resizing; if that's the case, lets fix
that rather than hide it.

Sebastian Kügler wrote:
During resize, we're rescaling a pixmap instead of re-rendering the SVG
for every frame. That can induce blur.

Also, rendering an SVG at random sizes van induce blur, since not
everything can be aligned to pixels all the time, our SVGs are optimized for
standard sizes.

Xuetian Weng wrote:
The problem is not loading it at wrong size. It is the widget is not
resized to correct size yet.
The most significant one on plasma here is Device Notifier (When it's
popped up at the first time), I print out some debug message at
::geometryChanged
ICON QSizeF(1, 86) QSizeF(1, 1) QVariant(QString, device-notifier)
ICON QSizeF(129, 86) QSizeF(1, 86) QVariant(QString, device-notifier)

As you can see, the size changed from 1x1 to 1x86 then to 129x86. So they
are valid size, and the blurriness is exposed by the transition animation.

David Edmundson wrote:
Thanks. I can reproduce with the Device Notifier + debug

What I'm trying to argue is that it should go directly to 129x86. (or at
least be an invalid size till then)

Otherwise we're loading an SVG 3 times and not using two of them this
patch will hide the visual artifacts of that, but we'll still be wasting a
lot of CPU cycles doing something silly.

Xuetian Weng wrote:
emm, seems the 1x1 size comes from lines 67 and 68:
http://quickgit.kde.org/?p=plasma-workspace.gita=blobh=071705a85aee9ee00a3c88657c93d20544eb5c0fhb=8b670015582e6b501a2a81a23f38eb5772a36e85f=applets%2Fsystemtray%2Fplugin%2Fprotocols%2Fplasmoid%2Fplasmoidtask.cpp

from current code I don't see an easy way to avoid that... I think
there's one resize event can be avoided by call setSize(), but anyway there
need to one extra resize.

Good find. We could try setting that to 0x0 and see what happens. We'll save a
load of cycles on all sorts of other code that way.

if it goes from 0 to something sensible, it wont' animate as the old
m_oldIconPixmap will be null

- David

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

On Dec. 11, 2014, 7:49 p.m., Xuetian Weng wrote:

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

(Updated Dec. 11, 2014, 7:49 p.m.)

Review request for KDE Frameworks, Plasma, Aleix Pol Gonzalez, and Kai Uwe
Broulik.

Repository: plasma-framework

Description
---

Making transition between two different size doesn't make much sense, since
repainting is usually happens at that time and it could take some time to
finish. And animation need to be stopped if m_animValue is set manually.

Diffs
-

src/declarativeimports/core/iconitem.cpp 145a7cd

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

Testing
---

Looks fine on tray icon and lock screen, less blurry transition.

Thanks,

Xuetian Weng

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

Review Request 121452: Call matchSessionComplete of RunnerManager in milou

2014-12-11 Thread Xuetian Weng


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

Review request for Plasma and Vishesh Handa.


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


Repository: milou


Description
---

RunnerManager requires matchSessionComplete to be called when it needs to be 
cleaned up. Thus prepare and tear signal for runner plugin can be triggered 
correctly.


Diffs
-

  lib/sourcesmodel.cpp cae6f06 

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


Testing
---

window runner can work properly.


Thanks,

Xuetian Weng

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

Re: Review Request 121424: [GCI2014]Porting Accessibility Config Module away from KDELibs4Support

2014-12-11 Thread Toby Chen


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

(Updated Dec. 11, 2014, 3:51 p.m.)


Review request for Plasma and David Edmundson.


Repository: plasma-desktop


Description (updated)
---

Remove the depencence on KDELibs4Support form KCMAccess


Diffs
-

  kcms/access/main.cpp 09864fc 
  kcms/access/CMakeLists.txt 64b1cc9 
  kcms/access/kaccess.h 716bfcf 
  kcms/access/kaccess.cpp aea6f86 
  kcms/access/kcmaccess.h d3cb40f 
  kcms/access/kcmaccess.cpp 6c8bc65 

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


Testing
---

I have ran kcmshell5 kcmaccess, did see no problem.


Thanks,

Toby Chen

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

Re: Review Request 121424: [GCI2014]Porting Accessibility Config Module away from KDELibs4Support

2014-12-11 Thread Toby Chen


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

(Updated Dec. 11, 2014, 3:52 p.m.)


Review request for Plasma and David Edmundson.


Repository: plasma-desktop


Description
---

Remove the depencence on KDELibs4Support form KCMAccess


Diffs
-

  kcms/access/main.cpp 09864fc 
  kcms/access/CMakeLists.txt 64b1cc9 
  kcms/access/kaccess.h 716bfcf 
  kcms/access/kaccess.cpp aea6f86 
  kcms/access/kcmaccess.h d3cb40f 
  kcms/access/kcmaccess.cpp 6c8bc65 

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


Testing (updated)
---

I have ran kcmshell5 kcmaccess, did see no problem.
Accessiblity features work fine.


Thanks,

Toby Chen

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

Re: Review Request 121424: [GCI2014]Porting Accessibility Config Module away from KDELibs4Support


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

Ship it!


- David Edmundson


On Dec. 11, 2014, 8:52 p.m., Toby Chen wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121424/
 ---
 
 (Updated Dec. 11, 2014, 8:52 p.m.)
 
 
 Review request for Plasma and David Edmundson.
 
 
 Repository: plasma-desktop
 
 
 Description
 ---
 
 Remove the depencence on KDELibs4Support form KCMAccess
 
 
 Diffs
 -
 
   kcms/access/main.cpp 09864fc 
   kcms/access/CMakeLists.txt 64b1cc9 
   kcms/access/kaccess.h 716bfcf 
   kcms/access/kaccess.cpp aea6f86 
   kcms/access/kcmaccess.h d3cb40f 
   kcms/access/kcmaccess.cpp 6c8bc65 
 
 Diff: https://git.reviewboard.kde.org/r/121424/diff/
 
 
 Testing
 ---
 
 I have ran kcmshell5 kcmaccess, did see no problem.
 Accessiblity features work fine.
 
 
 Thanks,
 
 Toby Chen
 


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

Re: Review Request 121424: [GCI2014]Porting Accessibility Config Module away from KDELibs4Support

2014-12-11 Thread Jeremy Whiting


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

Ship it!


Ship It!

- Jeremy Whiting


On Dec. 11, 2014, 1:52 p.m., Toby Chen wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121424/
 ---
 
 (Updated Dec. 11, 2014, 1:52 p.m.)
 
 
 Review request for Plasma and David Edmundson.
 
 
 Repository: plasma-desktop
 
 
 Description
 ---
 
 Remove the depencence on KDELibs4Support form KCMAccess
 
 
 Diffs
 -
 
   kcms/access/main.cpp 09864fc 
   kcms/access/CMakeLists.txt 64b1cc9 
   kcms/access/kaccess.h 716bfcf 
   kcms/access/kaccess.cpp aea6f86 
   kcms/access/kcmaccess.h d3cb40f 
   kcms/access/kcmaccess.cpp 6c8bc65 
 
 Diff: https://git.reviewboard.kde.org/r/121424/diff/
 
 
 Testing
 ---
 
 I have ran kcmshell5 kcmaccess, did see no problem.
 Accessiblity features work fine.
 
 
 Thanks,
 
 Toby Chen
 


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

Review Request 121453: Cache QTimeZone for the lifespan of the TimeSource don't recreate every minute


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

Review request for Plasma.


Repository: plasma-workspace


Description
---

cache QTimeZone for the lifespan of the TimeSource don't recreate every minute

QTimeZone::systemTimeZoneId() will open /etc/localtime every single time it is 
called.

We are calling this in ::updateTime which happens every single minute.


Diffs
-

  dataengines/time/timesource.h 5ee1ef6 
  dataengines/time/timesource.cpp 934ed49 

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


Testing
---


Thanks,

David Edmundson

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

Re: Review Request 121453: Cache QTimeZone for the lifespan of the TimeSource don't recreate every minute


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

(Updated Dec. 11, 2014, 9:30 p.m.)


Review request for Plasma.


Repository: plasma-workspace


Description
---

cache QTimeZone for the lifespan of the TimeSource don't recreate every minute

QTimeZone::systemTimeZoneId() will open /etc/localtime every single time it is 
called.

We are calling this in ::updateTime which happens every single minute.


Diffs
-

  dataengines/time/timesource.h 5ee1ef6 
  dataengines/time/timesource.cpp 934ed49 

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


Testing (updated)
---

Ran strace -e open plasmashell without crying

Selected a few zones and mouse-wheeled between them.


Thanks,

David Edmundson

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

Re: Review Request 121453: Cache QTimeZone for the lifespan of the TimeSource don't recreate every minute

2014-12-11 Thread Jeremy Whiting


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

Ship it!


Ship It!

- Jeremy Whiting


On Dec. 11, 2014, 2:30 p.m., David Edmundson wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121453/
 ---
 
 (Updated Dec. 11, 2014, 2:30 p.m.)
 
 
 Review request for Plasma.
 
 
 Repository: plasma-workspace
 
 
 Description
 ---
 
 cache QTimeZone for the lifespan of the TimeSource don't recreate every minute
 
 QTimeZone::systemTimeZoneId() will open /etc/localtime every single time it 
 is called.
 
 We are calling this in ::updateTime which happens every single minute.
 
 
 Diffs
 -
 
   dataengines/time/timesource.h 5ee1ef6 
   dataengines/time/timesource.cpp 934ed49 
 
 Diff: https://git.reviewboard.kde.org/r/121453/diff/
 
 
 Testing
 ---
 
 Ran strace -e open plasmashell without crying
 
 Selected a few zones and mouse-wheeled between them.
 
 
 Thanks,
 
 David Edmundson
 


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

Re: Review Request 121453: Cache QTimeZone for the lifespan of the TimeSource don't recreate every minute


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

Ship it!


Even worse when seconds are on...

- Martin Klapetek


On Dec. 11, 2014, 10:30 p.m., David Edmundson wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121453/
 ---
 
 (Updated Dec. 11, 2014, 10:30 p.m.)
 
 
 Review request for Plasma.
 
 
 Repository: plasma-workspace
 
 
 Description
 ---
 
 cache QTimeZone for the lifespan of the TimeSource don't recreate every minute
 
 QTimeZone::systemTimeZoneId() will open /etc/localtime every single time it 
 is called.
 
 We are calling this in ::updateTime which happens every single minute.
 
 
 Diffs
 -
 
   dataengines/time/timesource.h 5ee1ef6 
   dataengines/time/timesource.cpp 934ed49 
 
 Diff: https://git.reviewboard.kde.org/r/121453/diff/
 
 
 Testing
 ---
 
 Ran strace -e open plasmashell without crying
 
 Selected a few zones and mouse-wheeled between them.
 
 
 Thanks,
 
 David Edmundson
 


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

Re: Review Request 121449: Rename Human Input Devices to just Input Devices