Re: Review Request 121718: Allow to compile plasma-workspace without Qt5WebKit installed.

2015-01-06 Thread Kai Uwe Broulik

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



CMakeLists.txt
https://git.reviewboard.kde.org/r/121718/#comment50945

My CMake complains about this:
  Unknown CMake command set_package_properties.


- Kai Uwe Broulik


On Jan. 6, 2015, 7:57 vorm., David Faure wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121718/
 ---
 
 (Updated Jan. 6, 2015, 7:57 vorm.)
 
 
 Review request for Plasma.
 
 
 Repository: plasma-workspace
 
 
 Description
 ---
 
 Only drkonqi and systemmonitor depend on it.
 
 (systemmonitor uses libksysguard's processui lib, which is not installed
 by libksysguard if webkit is not found)
 
 REVIEW: 121718
 
 
 Diffs
 -
 
   CMakeLists.txt c6d89c14b05f5639937aee5692d305fa2faed974 
   drkonqi/CMakeLists.txt a362d7ec651c027d91d0912e84817cd3a2f94d67 
 
 Diff: https://git.reviewboard.kde.org/r/121718/diff/
 
 
 Testing
 ---
 
 Compiling without qt5 webkit.
 
 
 Thanks,
 
 David Faure
 


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


Build failed in Jenkins: plasma-workspace_master_qt5 #1184

2015-01-06 Thread KDE CI System
See http://build.kde.org/job/plasma-workspace_master_qt5/1184/changes

Changes:

[faure] Allow to compile plasma-workspace without Qt5WebKit installed.

--
Started by remote host 2a01:4f8:160:9363::9 with note: Triggered by commit
Building remotely on LinuxSlave - 3 (PACKAGER LINBUILDER) in workspace 
http://build.kde.org/job/plasma-workspace_master_qt5/ws/
Running Prebuild steps
[plasma-workspace_master_qt5] $ /bin/sh -xe /tmp/hudson4490037178354373446.sh
+ /home/jenkins/scripts/setup-env.sh

Preparing to perform KDE Continuous Integration build
== Setting Up Sources

From git://anongit.kde.org/plasma-workspace
   748d22f..ce20679  master - origin/master
Branch jenkins set up to track remote branch master from origin.

== Cleaning Source Tree

HEAD is now at 748d22f Show album art on mediacontroller tooltip
Removing build/
Removing local-inst/
Success build forhudson.tasks.Shell@3d0889c4
  git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
  git config remote.origin.url git://anongit.kde.org/plasma-workspace # 
  timeout=10
Fetching upstream changes from git://anongit.kde.org/plasma-workspace
  git --version # timeout=10
  git fetch --tags --progress git://anongit.kde.org/plasma-workspace 
  +refs/heads/*:refs/remotes/origin/*
  git rev-parse refs/remotes/origin/jenkins^{commit} # timeout=10
  git rev-parse refs/remotes/origin/refs/heads/jenkins^{commit} # timeout=10
  git rev-parse refs/heads/jenkins^{commit} # timeout=10
Checking out Revision ce206793e2212dad88e8da47f19572f775c4683e 
(refs/heads/jenkins)
  git config core.sparsecheckout # timeout=10
  git checkout -f ce206793e2212dad88e8da47f19572f775c4683e
  git rev-list 8de060418e2c13057a443eb0aa997844466330b9 # timeout=10
  git tag -a -f -m Jenkins Build #1184 
  jenkins-plasma-workspace_master_qt5-1184 # timeout=10
[plasma-workspace_master_qt5] $ /bin/sh -xe /tmp/hudson2618546488208918654.sh
+ /home/jenkins/scripts/execute-job.sh

KDE Continuous Integration Build
== Building Project: plasma-workspace - Branch master
== Build Dependencies:
 ktexteditor - Branch master
 krunner - Branch master
 kemoticons - Branch master
 kpty - Branch master
 solid - Branch master
 kparts - Branch master
 knewstuff - Branch master
 kiconthemes - Branch master
 breeze - Branch master
 kactivities - Branch master
 karchive - Branch master
 kjobwidgets - Branch master
 cmake - Branch master
 kcodecs - Branch master
 kcmutils - Branch master
 baloo - Branch master
 kwayland - Branch master
 phonon - Branch master
 libdbusmenu-qt - Branch master
 kfilemetadata - Branch master
 kxmlgui - Branch master
 kio - Branch master
 kdesupport-svn - Branch master
 kguiaddons - Branch master
 kjsembed - Branch master
 kwindowsystem - Branch master
 kwin - Branch master
 kdesu - Branch master
 knotifications - Branch master
 kidletime - Branch master
 ktextwidgets - Branch master
 kplotting - Branch master
 knotifyconfig - Branch master
 khelpcenter - Branch master
 kross - Branch master
 libssh - Branch master
 kde-cli-tools - Branch master
 dogtail - Branch master
 plasma-framework - Branch master
 kpackage - Branch master
 threadweaver - Branch master
 kbookmarks - Branch master
 kwidgetsaddons - Branch master
 polkit-qt-1 - Branch master
 kunitconversion - Branch master
 kdecoration - Branch master
 kio-extras - Branch master
 attica - Branch master
 kdewebkit - Branch master
 qt5 - Branch 5.3.2
 kservice - Branch master
 ki18n - Branch master
 libkscreen - Branch frameworks
 kdelibs4support - Branch master
 extra-cmake-modules - Branch master
 kglobalaccel - Branch master
 kwallet - Branch master
 kdnssd - Branch master
 kdesignerplugin - Branch master
 kitemmodels - Branch master
 libksysguard - Branch master
 kcrash - Branch master
 kinit - Branch master
 kconfigwidgets - Branch master
 kconfig - Branch master
 khtml - Branch master
 kjs - Branch master
 kdbusaddons - Branch master
 kauth - Branch master
 kcoreaddons - Branch master
 kdoctools - Branch master
 libgit2 - Branch master
 kitemviews - Branch master
 frameworkintegration - Branch master
 sonnet - Branch master
 milou - Branch master
 kded - Branch master
 kcompletion - Branch master
 kdeclarative - Branch master

== Applying Patches
=== No patches to apply

== Syncing Dependencies from Master Server


== Configuring Build

-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- Check for working C compiler: /home/jenkins/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C 

Re: Review Request 121856: KWindowSystem import for KDeclarative

2015-01-06 Thread Kai Uwe Broulik

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


Thinking again about it I think methods such as activeWindow and icon 
definitely should be exposed in this import. This would be super handy for the 
window controls widget (you know, that netbook thing in your panel that shows 
the window title and offers close/maximize buttons). It would still need a 
plugin for invoking present windows and closing the window but the rest could 
be done without code duplication:

QWindow *KWindowSystemProxy::activeWindow() {
return QWindow::fromWinId(KWindowSystem::activeWindow());
}
If I understood it correctly, Qt will generate a QWindow representation of that 
window (with title and everything set). Since that QWindow instance won't have 
a parent (I guess) it will be adpoted by the QML engine and thrown away when it 
goes out of scope (eg. you call var activewin = kwindowsystem.activeWindow(); 
console.log(activewin.title); and when that function ends it get collected by 
the GC)

So that shouldn't be too bad of an approach, no? Not sure about QListQWindow 
* though

- Kai Uwe Broulik


On Jan. 5, 2015, 10:49 vorm., Kai Uwe Broulik wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121856/
 ---
 
 (Updated Jan. 5, 2015, 10:49 vorm.)
 
 
 Review request for kwin and Plasma.
 
 
 Repository: kdeclarative
 
 
 Description
 ---
 
 This is a thin proxy around KWindowSystem exposing most of its methods to qml 
 via KWindowSystem item in an org.kde.kwindowsystem import.
 
 It uses QWindow instead of WId parameters so you can just pass a qml Item, 
 such as a Plasma Dialog as parameter for ease of use (and so you cannot mess 
 with others windows without effort, also I don't know what WId would 
 translate to anyway). It omits all those methods that return WId/QWindow as I 
 don't know how expensive QWindow::fromWinId is or who takes ownership of it. 
 We need to decide which methods make sense in this import.
 
 Methods that have signals and don't take parameters are turned into 
 full-fledged properties (like currentDesktop, numberOfDesktops, etc) and the 
 rest stays Q_INVOKABLE.
 
 
 Diffs
 -
 
   src/qmlcontrols/kwindowsystemplugin/qmldir PRE-CREATION 
   src/qmlcontrols/kwindowsystemplugin/kwindowsystemproxy.cpp PRE-CREATION 
   src/qmlcontrols/CMakeLists.txt 39c39a5 
   src/qmlcontrols/kwindowsystemplugin/CMakeLists.txt PRE-CREATION 
   src/qmlcontrols/kwindowsystemplugin/kwindowsystemplugin.h PRE-CREATION 
   src/qmlcontrols/kwindowsystemplugin/kwindowsystemplugin.cpp PRE-CREATION 
   src/qmlcontrols/kwindowsystemplugin/kwindowsystemproxy.h PRE-CREATION 
 
 Diff: https://git.reviewboard.kde.org/r/121856/diff/
 
 
 Testing
 ---
 
 The properties work and change accordingly (compositing active signal doesn't 
 seem to be emitted by KWindowSystem in the first place, at least 
 Ctrl+Shift+F12 doesn't make it change), the forceActivateWindow method works 
 for Review 121807
 
 
 Thanks,
 
 Kai Uwe Broulik
 


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


Build failed in Jenkins: plasma-workspace_master_qt5 #1185

2015-01-06 Thread KDE CI System
See http://build.kde.org/job/plasma-workspace_master_qt5/1185/changes

Changes:

[scripty] SVN_SILENT made messages (.desktop file)

--
Started by remote host 2a01:4f8:160:9363::9 with note: Triggered by commit
Building remotely on LinuxSlave - 4 (PACKAGER LINBUILDER) in workspace 
http://build.kde.org/job/plasma-workspace_master_qt5/ws/
Running Prebuild steps
[plasma-workspace_master_qt5] $ /bin/sh -xe /tmp/hudson2314272490147344359.sh
+ /home/jenkins/scripts/setup-env.sh

Preparing to perform KDE Continuous Integration build
== Setting Up Sources

From git://anongit.kde.org/plasma-workspace
   c141117..765e6a3  master - origin/master
Branch jenkins set up to track remote branch master from origin.

== Cleaning Source Tree

HEAD is now at c141117 SVN_SILENT made messages (.desktop file)
Removing build/
Removing local-inst/
Success build forhudson.tasks.Shell@3d0889c4
  git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
  git config remote.origin.url git://anongit.kde.org/plasma-workspace # 
  timeout=10
Fetching upstream changes from git://anongit.kde.org/plasma-workspace
  git --version # timeout=10
  git fetch --tags --progress git://anongit.kde.org/plasma-workspace 
  +refs/heads/*:refs/remotes/origin/*
  git rev-parse refs/remotes/origin/jenkins^{commit} # timeout=10
  git rev-parse refs/remotes/origin/refs/heads/jenkins^{commit} # timeout=10
  git rev-parse refs/heads/jenkins^{commit} # timeout=10
Checking out Revision 765e6a3c0a17f5df28cb6dff78c9f2d592a921ff 
(refs/heads/jenkins)
  git config core.sparsecheckout # timeout=10
  git checkout -f 765e6a3c0a17f5df28cb6dff78c9f2d592a921ff
  git rev-list ce206793e2212dad88e8da47f19572f775c4683e # timeout=10
  git tag -a -f -m Jenkins Build #1185 
  jenkins-plasma-workspace_master_qt5-1185 # timeout=10
[plasma-workspace_master_qt5] $ /bin/sh -xe /tmp/hudson7438599839260031957.sh
+ /home/jenkins/scripts/execute-job.sh

KDE Continuous Integration Build
== Building Project: plasma-workspace - Branch master
== Build Dependencies:
 kemoticons - Branch master
 krunner - Branch master
 libssh - Branch master
 kpty - Branch master
 solid - Branch master
 kdnssd - Branch master
 plasma-framework - Branch master
 kdecoration - Branch master
 kiconthemes - Branch master
 kdesupport-svn - Branch master
 libdbusmenu-qt - Branch master
 kjobwidgets - Branch master
 kcodecs - Branch master
 kfilemetadata - Branch master
 knotifications - Branch master
 kcmutils - Branch master
 kdoctools - Branch master
 kplotting - Branch master
 kross - Branch master
 frameworkintegration - Branch master
 kio-extras - Branch master
 kservice - Branch master
 kded - Branch master
 milou - Branch master
 kio - Branch master
 attica - Branch master
 phonon - Branch master
 kjsembed - Branch master
 ki18n - Branch master
 kdesignerplugin - Branch master
 kwin - Branch master
 kdesu - Branch master
 kactivities - Branch master
 libgit2 - Branch master
 kidletime - Branch master
 khtml - Branch master
 kguiaddons - Branch master
 knotifyconfig - Branch master
 kglobalaccel - Branch master
 kde-cli-tools - Branch master
 ktextwidgets - Branch master
 knewstuff - Branch master
 kconfig - Branch master
 threadweaver - Branch master
 kinit - Branch master
 kbookmarks - Branch master
 kxmlgui - Branch master
 ktexteditor - Branch master
 kunitconversion - Branch master
 kwidgetsaddons - Branch master
 extra-cmake-modules - Branch master
 cmake - Branch master
 kcrash - Branch master
 kparts - Branch master
 kdewebkit - Branch master
 qt5 - Branch 5.3.2
 kdbusaddons - Branch master
 kauth - Branch master
 libkscreen - Branch frameworks
 kdelibs4support - Branch master
 kwallet - Branch master
 kwayland - Branch master
 sonnet - Branch master
 kdeclarative - Branch master
 kitemmodels - Branch master
 libksysguard - Branch master
 baloo - Branch master
 kconfigwidgets - Branch master
 karchive - Branch master
 kwindowsystem - Branch master
 breeze - Branch master
 kjs - Branch master
 kcoreaddons - Branch master
 kpackage - Branch master
 kitemviews - Branch master
 khelpcenter - Branch master
 polkit-qt-1 - Branch master
 dogtail - Branch master
 kcompletion - Branch master

== Applying Patches
=== No patches to apply

== Syncing Dependencies from Master Server


== Configuring Build

-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- Check for working C compiler: /home/jenkins/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- 

Re: Review Request 121718: Allow to compile plasma-workspace without Qt5WebKit installed.

2015-01-06 Thread Bhushan Shah


 On Jan. 6, 2015, 3:07 p.m., Kai Uwe Broulik wrote:
  CMakeLists.txt, line 13
  https://git.reviewboard.kde.org/r/121718/diff/2/?file=338299#file338299line13
 
  My CMake complains about this:
Unknown CMake command set_package_properties.

Fixed in 
http://commits.kde.org/plasma-workspace/0d354bea0e7bab8ab97896cef68fd1f4ccfb286b


- Bhushan


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


On Jan. 6, 2015, 1:27 p.m., David Faure wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121718/
 ---
 
 (Updated Jan. 6, 2015, 1:27 p.m.)
 
 
 Review request for Plasma.
 
 
 Repository: plasma-workspace
 
 
 Description
 ---
 
 Only drkonqi and systemmonitor depend on it.
 
 (systemmonitor uses libksysguard's processui lib, which is not installed
 by libksysguard if webkit is not found)
 
 REVIEW: 121718
 
 
 Diffs
 -
 
   CMakeLists.txt c6d89c14b05f5639937aee5692d305fa2faed974 
   drkonqi/CMakeLists.txt a362d7ec651c027d91d0912e84817cd3a2f94d67 
 
 Diff: https://git.reviewboard.kde.org/r/121718/diff/
 
 
 Testing
 ---
 
 Compiling without qt5 webkit.
 
 
 Thanks,
 
 David Faure
 


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


Re: Plasma naming scheme

2015-01-06 Thread Sebastian Kügler
On Saturday, January 03, 2015 18:23:07 Thomas Pfeiffer wrote:
 while writing up a vision for Plasma interaction, the VDG noticed that it
 was  unclear exactly what terms to use when referring to Plasma Desktop
 specifically, so we thought it would make sense to clarify this.
 
 Therefore, we went ahead and drafted some communication guidelines I'd like
 to  present for discussion:
 
 - When talking about the the Plasma technology generically, use only
 Plasma,  omitting the 5 as that is just an iteration of Plasma.
 
 - When talking about a particular version of the technology, but not a 
 specific shell, use Plasma [version] e.g. Plasma 5.1.
 
 - When talking about the a specific shell but not about a specific version, 
 use Plasma [shell], e.g. Plasma Desktop
 
 - When talking about a specific shell in a particular version, use  Plasma 
 [version] [shell] e.g. Plasma 5.2 Desktop, Plasma 5.4 Active
 
 For example in release announcement we'd talk about the Plasma 5.2 release
 and  when there are shell specific changes we could write Plasma Desktop
 now has addition X
 
 Does that make sense to everyone? And if so: Where should we publish it and 
 where should we announce it?

This nomenclature sounds fine to my ears. Does this need announcement? I think 
the Dot editors have some wiki pages with these things, but other than that, 
to my biased self, this is common knowledge / common sense?

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
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 #1187

2015-01-06 Thread KDE CI System
See http://build.kde.org/job/plasma-workspace_master_qt5/1187/changes

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


screenlocker focus questions

2015-01-06 Thread Sebastian Kügler
Hey,

So I'm attempting to fix the focus of the screenlocker. When the screenlocker 
is started, the focus should be on the password input, so you can directly 
type after the machine woke up. This worked previously (I had already fixed it 
twice), but broke again recently.

I've tried a few things involving forceActiveFocus(), but they all don't seem 
to work anymore. I can get the locker to work if I click on it, or if I hit 
tab, in the latter case, the focus moves to the userlist, and when selecting a 
different user, it moves to the password field.

I want to move it to the password field initially, but for example calling 
forceActiveFocus() in the password's onCompleted: handler doesn't do that.

I've looked at the git log, and there weren't any changes in those QML files, 
so I assume the problem lies elsewhere. Maybe the window isn't getting focus 
correctly? I know a few things changed around it, so maybe someone (Martin?) 
has an idea where to look?

I'm also working blind here, since I couldn't find out how to get at the 
console output of the screenlocker, any ideas?

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Build failed in Jenkins: plasma-workspace_master_qt5 #1186

2015-01-06 Thread KDE CI System
See http://build.kde.org/job/plasma-workspace_master_qt5/1186/changes

Changes:

[kde] Replace MEL by MouseArea

--
Started by remote host 2a01:4f8:160:9363::9 with note: Triggered by commit
Building remotely on LinuxSlave - 4 (PACKAGER LINBUILDER) in workspace 
http://build.kde.org/job/plasma-workspace_master_qt5/ws/
Running Prebuild steps
[plasma-workspace_master_qt5] $ /bin/sh -xe /tmp/hudson6734211831285307453.sh
+ /home/jenkins/scripts/setup-env.sh

Preparing to perform KDE Continuous Integration build
== Setting Up Sources

From git://anongit.kde.org/plasma-workspace
   81d63cf..230d451  Plasma/5.1 - origin/Plasma/5.1
   765e6a3..8fd3226  master - origin/master
Branch jenkins set up to track remote branch master from origin.

== Cleaning Source Tree

HEAD is now at 765e6a3 SVN_SILENT made messages (.desktop file)
Removing build/
Success build forhudson.tasks.Shell@3d0889c4
  git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
  git config remote.origin.url git://anongit.kde.org/plasma-workspace # 
  timeout=10
Fetching upstream changes from git://anongit.kde.org/plasma-workspace
  git --version # timeout=10
  git fetch --tags --progress git://anongit.kde.org/plasma-workspace 
  +refs/heads/*:refs/remotes/origin/*
  git rev-parse refs/remotes/origin/jenkins^{commit} # timeout=10
  git rev-parse refs/remotes/origin/refs/heads/jenkins^{commit} # timeout=10
  git rev-parse refs/heads/jenkins^{commit} # timeout=10
Checking out Revision 8fd3226b9c0cc6fb74349fda2f6a2603c6f7d166 
(refs/heads/jenkins)
  git config core.sparsecheckout # timeout=10
  git checkout -f 8fd3226b9c0cc6fb74349fda2f6a2603c6f7d166
  git rev-list 765e6a3c0a17f5df28cb6dff78c9f2d592a921ff # timeout=10
  git tag -a -f -m Jenkins Build #1186 
  jenkins-plasma-workspace_master_qt5-1186 # timeout=10
[plasma-workspace_master_qt5] $ /bin/sh -xe /tmp/hudson1016013725708637696.sh
+ /home/jenkins/scripts/execute-job.sh

KDE Continuous Integration Build
== Building Project: plasma-workspace - Branch master
== Build Dependencies:
 kparts - Branch master
 krunner - Branch master
 phonon - Branch master
 kross - Branch master
 solid - Branch master
 kauth - Branch master
 kwindowsystem - Branch master
 plasma-framework - Branch master
 kdeclarative - Branch master
 breeze - Branch master
 kjs - Branch master
 sonnet - Branch master
 libdbusmenu-qt - Branch master
 kguiaddons - Branch master
 kservice - Branch master
 kcodecs - Branch master
 kcrash - Branch master
 attica - Branch master
 kcmutils - Branch master
 kdoctools - Branch master
 kplotting - Branch master
 milou - Branch master
 libgit2 - Branch master
 extra-cmake-modules - Branch master
 kdesignerplugin - Branch master
 ki18n - Branch master
 kxmlgui - Branch master
 kio - Branch master
 polkit-qt-1 - Branch master
 kjsembed - Branch master
 ktextwidgets - Branch master
 kidletime - Branch master
 kdesu - Branch master
 kwin - Branch master
 kinit - Branch master
 knotifyconfig - Branch master
 kjobwidgets - Branch master
 kdnssd - Branch master
 khelpcenter - Branch master
 knewstuff - Branch master
 kconfig - Branch master
 kcoreaddons - Branch master
 threadweaver - Branch master
 frameworkintegration - Branch master
 kbookmarks - Branch master
 kdbusaddons - Branch master
 kactivities - Branch master
 kunitconversion - Branch master
 kio-extras - Branch master
 cmake - Branch master
 kdewebkit - Branch master
 kded - Branch master
 kdesupport-svn - Branch master
 ktexteditor - Branch master
 kpty - Branch master
 libkscreen - Branch frameworks
 baloo - Branch master
 kemoticons - Branch master
 kde-cli-tools - Branch master
 kfilemetadata - Branch master
 libssh - Branch master
 khtml - Branch master
 kitemmodels - Branch master
 libksysguard - Branch master
 knotifications - Branch master
 kconfigwidgets - Branch master
 kwallet - Branch master
 karchive - Branch master
 kiconthemes - Branch master
 kdelibs4support - Branch master
 kwayland - Branch master
 kglobalaccel - Branch master
 kpackage - Branch master
 kitemviews - Branch master
 dogtail - Branch master
 kdecoration - Branch master
 kwidgetsaddons - Branch master
 kcompletion - Branch master
 qt5 - Branch 5.3.2

== Applying Patches
=== No patches to apply

== Syncing Dependencies from Master Server


== Configuring Build

-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- Check for working C compiler: /home/jenkins/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile 

Re: Review Request 121360: Rework Plasma's notification positioning code

2015-01-06 Thread Àlex Fiestas


 On gen. 3, 2015, 8:08 p.m., Kai Uwe Broulik wrote:
  applets/notifications/plugin/notificationshelper.cpp, line 51
  https://git.reviewboard.kde.org/r/121360/diff/2/?file=337844#file337844line51
 
  Use QScopedPointer
 
 Martin Klapetek wrote:
 What's wrong with properly used delete?
 
 David Edmundson wrote:
 better yet, make the mutex on the stack.
 
 one less malloc == faster and less fragmented memory and you dont' have 
 to worry about the memory at all.
 
 Martin Klapetek wrote:
 I had it originally that way, however if you want to make it recursive, 
 you need to pass it to the constructor and the operator=() is private, so it 
 cannot be assigned to stack variable. So I made it a pointer.
 
 But it's not like there's any need of management for it, it's simply 
 created in constructor and deleted in the destructor, nothing else to worry 
 about.
 
 Martin Gräßlin wrote:
  I had it originally that way, however if you want to make it recursive, 
 you need to pass it to the constructor and the operator=() is private, so it 
 cannot be assigned to stack variable.
 
 That's not a problem, just initialize it in the initializer list of the 
 ctor.
 
 Concerning the discussion on the management: I personally prefer 
 QScopedPointer for cases like this as it's just something less to worry about 
 and ideally you can get in a situation where one can use the default dtor 
 which (at least I have read so) is more optimized than a written one.

This this case QScopedPointer is proof for future changes in the code, while 
delete it is easiert to screw it up (new return, move code around, etc).


- Àlex


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


On gen. 6, 2015, 1:32 p.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121360/
 ---
 
 (Updated gen. 6, 2015, 1:32 p.m.)
 
 
 Review request for Plasma and Kai Uwe Broulik.
 
 
 Bugs: 339732
 https://bugs.kde.org/show_bug.cgi?id=339732
 
 
 Repository: plasma-workspace
 
 
 Description
 ---
 
 There can easily be situations where the popups could overlap one another or 
 result in strange animations. This patch rewrites the notifications so that 
 all actions such as show/reposition/hide are handled from a one single place 
 and every action is properly queued and protected around, which makes it more 
 robust, more predictive and less chaotic. There's also a slight delay between 
 every action so it's also visually much more cleaner and easier to see what's 
 going on. 
 
 
 Diffs
 -
 
   applets/notifications/plugin/notificationshelper.h af8f6fa 
   applets/notifications/plugin/notificationshelper.cpp 425f0d6 
   dataengines/notifications/notificationsengine.cpp d4b7f19 
   applets/notifications/package/contents/ui/NotificationPopup.qml 8eb1912 
 
 Diff: https://git.reviewboard.kde.org/r/121360/diff/
 
 
 Testing
 ---
 
 Tested whole day plus stress-tested with something like for i in {1..200}; do 
 notify-send $i - $RANDOM $RANDOM sdf sdf sdfwefhsdjfnskdfbkwefnos igodsfgn 
 sodifgj asodfgnsdlfgdf g; done executed from 4 terminals at once, all works 
 fine and as expected.
 
 
 Thanks,
 
 Martin Klapetek
 


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


Re: Plasma 5.2 bits for kdereview

2015-01-06 Thread David Edmundson
On Tue, Jan 6, 2015 at 3:23 PM, Luigi Toscano luigi.tosc...@tiscali.it
wrote:

 Jonathan Riddell ha scritto:
  Updates on this..
 
  I plan to ask for Bluedevil and libbluedevil, libkscreen and kscreen,
  libmm-qt and ksshaskpass to be moved. I see some comments that the
  libraries may be used outside of Plasma but there's no problem with
  that happening, they don't quality for frameworks and they already get
  released with Plasma so it's just an update in projects.kde.org
 

 That's the same point as baloo, discussed on kde-frameworks-devel right
 now, then.

 I still disagree, from a logical point of view those libraries could be
 needed
 both for Applications and Plasma products. As you said they are not
 frameworks, and I still think we need to investigate how to place this
 kind of
 libraries. If you don't want to depend on libraries on extragear-libs,
 maybe a
 new module? Again, it's the same as the baloo placement problem IMHO.

  polkit-kde is already in and has now been merged so master is KF5.

 Asking again:
 - Is there a final kdelibs4-based branch that can be tracked for the time
 being into the stable kdelibs4 l10n branch? Should this stay as
 extragear-base, given that kde-workspace is frozen in kdelibs4?


I've pushed a branch kdelibs4 that is just a branch of just before we
merged frameworks
I can't update projects.kde.org settings as I don't have enough admin, do
you?

David



 Ciao
 --
 Luigi
 ___
 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 121360: Rework Plasma's notification positioning code

2015-01-06 Thread Martin Klapetek

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

(Updated Jan. 6, 2015, 2:32 p.m.)


Review request for Plasma and Kai Uwe Broulik.


Changes
---

Use lambda slot


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


Repository: plasma-workspace


Description
---

There can easily be situations where the popups could overlap one another or 
result in strange animations. This patch rewrites the notifications so that all 
actions such as show/reposition/hide are handled from a one single place and 
every action is properly queued and protected around, which makes it more 
robust, more predictive and less chaotic. There's also a slight delay between 
every action so it's also visually much more cleaner and easier to see what's 
going on. 


Diffs (updated)
-

  applets/notifications/plugin/notificationshelper.h af8f6fa 
  applets/notifications/plugin/notificationshelper.cpp 425f0d6 
  dataengines/notifications/notificationsengine.cpp d4b7f19 
  applets/notifications/package/contents/ui/NotificationPopup.qml 8eb1912 

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


Testing
---

Tested whole day plus stress-tested with something like for i in {1..200}; do 
notify-send $i - $RANDOM $RANDOM sdf sdf sdfwefhsdjfnskdfbkwefnos igodsfgn 
sodifgj asodfgnsdlfgdf g; done executed from 4 terminals at once, all works 
fine and as expected.


Thanks,

Martin Klapetek

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


Re: Plasma 5.2 bits for kdereview

2015-01-06 Thread Jonathan Riddell
Updates on this..

I plan to ask for Bluedevil and libbluedevil, libkscreen and kscreen,
libmm-qt and ksshaskpass to be moved. I see some comments that the
libraries may be used outside of Plasma but there's no problem with
that happening, they don't quality for frameworks and they already get
released with Plasma so it's just an update in projects.kde.org

user-manager looks like it could do with KConfig::KEMailSettings
ported and then Account Details done away with, I'll keep it in
kdereview for now.

kcm-touchpad needs the feature of the shortcut for ktouchpadenabler
taken and ktouchpadenabler disabled, I'll keep it in kdereview for
now.

polkit-kde is already in and has now been merged so master is KF5.

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


Review Request 121882: Look for kglobalaccel and don't build the internal copy if = 5.7

2015-01-06 Thread Martin Klapetek

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

Review request for Plasma.


Repository: plasma-workspace


Description
---

The daemon was moved to the frameworks, but it will be released only with 
frameworks 5.7, so we need to check for this and disable building the local 
copy with frameworks less than 5.7


Diffs
-

  CMakeLists.txt 834de83 

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


Testing
---


Thanks,

Martin Klapetek

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


Review Request 121887: Replace Q_WS_* macros in kglobalaccel/

2015-01-06 Thread Martin Klapetek

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

Review request for Plasma.


Repository: plasma-workspace


Description
---

as summary


Diffs
-

  kglobalaccel/CMakeLists.txt bdeedaf 
  kglobalaccel/globalshortcutsregistry.cpp af17df2 
  kglobalaccel/kglobalaccel_mac.cpp 3058e0e 
  kglobalaccel/kglobalaccel_win.cpp 7bd39d7 

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


Testing
---


Thanks,

Martin Klapetek

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


Re: Review Request 121882: Look for kglobalaccel and don't build the internal copy if = 5.7

2015-01-06 Thread Martin Klapetek

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

(Updated Jan. 6, 2015, 7:28 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: plasma-workspace


Description
---

The daemon was moved to the frameworks, but it will be released only with 
frameworks 5.7, so we need to check for this and disable building the local 
copy with frameworks less than 5.7


Diffs
-

  CMakeLists.txt 834de83 

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


Testing
---


Thanks,

Martin Klapetek

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


Re: Review Request 121887: Replace Q_WS_* macros in kglobalaccel/

2015-01-06 Thread Lukáš Tinkl

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

Ship it!


Ship It!

- Lukáš Tinkl


On Led. 6, 2015, 8:19 odp., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121887/
 ---
 
 (Updated Led. 6, 2015, 8:19 odp.)
 
 
 Review request for Plasma.
 
 
 Repository: plasma-workspace
 
 
 Description
 ---
 
 as summary
 
 
 Diffs
 -
 
   kglobalaccel/CMakeLists.txt bdeedaf 
   kglobalaccel/globalshortcutsregistry.cpp af17df2 
   kglobalaccel/kglobalaccel_mac.cpp 3058e0e 
   kglobalaccel/kglobalaccel_win.cpp 7bd39d7 
 
 Diff: https://git.reviewboard.kde.org/r/121887/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Martin Klapetek
 


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


Re: Review Request 121887: Replace Q_WS_* macros in kglobalaccel/

2015-01-06 Thread Martin Klapetek

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

(Updated Jan. 6, 2015, 8:04 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: plasma-workspace


Description
---

as summary


Diffs
-

  kglobalaccel/CMakeLists.txt bdeedaf 
  kglobalaccel/globalshortcutsregistry.cpp af17df2 
  kglobalaccel/kglobalaccel_mac.cpp 3058e0e 
  kglobalaccel/kglobalaccel_win.cpp 7bd39d7 

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


Testing
---


Thanks,

Martin Klapetek

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


Re: Review Request 121360: Rework Plasma's notification positioning code

2015-01-06 Thread Martin Klapetek

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


The beta is in two days, can we please get this in?

- Martin Klapetek


On Jan. 6, 2015, 2:32 p.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121360/
 ---
 
 (Updated Jan. 6, 2015, 2:32 p.m.)
 
 
 Review request for Plasma and Kai Uwe Broulik.
 
 
 Bugs: 339732
 https://bugs.kde.org/show_bug.cgi?id=339732
 
 
 Repository: plasma-workspace
 
 
 Description
 ---
 
 There can easily be situations where the popups could overlap one another or 
 result in strange animations. This patch rewrites the notifications so that 
 all actions such as show/reposition/hide are handled from a one single place 
 and every action is properly queued and protected around, which makes it more 
 robust, more predictive and less chaotic. There's also a slight delay between 
 every action so it's also visually much more cleaner and easier to see what's 
 going on. 
 
 
 Diffs
 -
 
   applets/notifications/plugin/notificationshelper.h af8f6fa 
   applets/notifications/plugin/notificationshelper.cpp 425f0d6 
   dataengines/notifications/notificationsengine.cpp d4b7f19 
   applets/notifications/package/contents/ui/NotificationPopup.qml 8eb1912 
 
 Diff: https://git.reviewboard.kde.org/r/121360/diff/
 
 
 Testing
 ---
 
 Tested whole day plus stress-tested with something like for i in {1..200}; do 
 notify-send $i - $RANDOM $RANDOM sdf sdf sdfwefhsdjfnskdfbkwefnos igodsfgn 
 sodifgj asodfgnsdlfgdf g; done executed from 4 terminals at once, all works 
 fine and as expected.
 
 
 Thanks,
 
 Martin Klapetek
 


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


[Breeze] [Bug 342570] New: kde4breeze copies contents of systemwide kdeglobals

2015-01-06 Thread Hrvoje Senjan
https://bugs.kde.org/show_bug.cgi?id=342570

Bug ID: 342570
   Summary: kde4breeze copies contents of systemwide kdeglobals
   Product: Breeze
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: major
  Priority: NOR
 Component: general
  Assignee: plasma-devel@kde.org
  Reporter: hrvoje.sen...@gmail.com

after seeing in bug 340691 the issue is not in kconfig and testing with kconfig
commit 915976c1238be811f169eab1b02f7e8dad6410e0, i have noticed that the fault
lies in kde4breeze.


steps to reproduce are, as written:

have /etc/xdg/kdeglobals
with
[General]
BrowserApplication=firefox
inside;
start a plasma 5 session with a clean user,
change default browser either with kcm, or by hand in ~/.config/kdeglobals,
logout,
login - observe the ~/.config/kdeglobals, it has both firefox and browser
added by user


this *does not* happen after mentioned commit, but if i add Value=5 (iow, so
upd is again valid), the users kdeglobals have written in the systemwide values

Reproducible: Always

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


Re: Review Request 121360: Rework Plasma's notification positioning code

2015-01-06 Thread Martin Gräßlin


 On Jan. 5, 2015, 4:19 p.m., David Edmundson wrote:
  applets/notifications/plugin/notificationshelper.cpp, line 111
  https://git.reviewboard.kde.org/r/121360/diff/2/?file=337844#file337844line111
 
  you're liable to break here.
  
  sometimes you call this directly not via the Qt meta system. (i.e 
  processHide)
  
  what calls processHide? could be the user pressing close, could be a 
  timeout. If so the sender() will be that timer. It's the sender of the last 
  signal we're processing, not the last method call made.
  
  I suggest maybe 
  
  connect(m_dispatchTimer, QTimer::timeout, this, 
  [this]{m_busy=false ; processQueues()}
  
  instead
 
 Martin Klapetek wrote:
 processHide is called just and only from processQueues. Basically 
 processQueues works as sort of dispatcher and processHide just returns the 
 control back to it, it will then simply process next item in the queue. It's 
 perfectly safe as processQueues is ever only called either manually (sender() 
 == 0) or by the timer (sender() == QTimer). The lambda slot is maybe nicer, I 
 just thought that it makes the code a bit harder to read...but I don't care 
 that much.
 
 David Edmundson wrote:
 calling it manually does not set the sender to 0.
 
 Martin Klapetek wrote:
 Yes it does.
 
 Martin Gräßlin wrote:
  Returns a pointer to the object that sent the signal, if called in a 
 slot activated by a signal; otherwise it returns 0.
 
 Martin Klapetek wrote:
 For the record, I've changed it to use the lambda slot and removed this 
 code in question, however reviewboard is rejecting the updated diff with The 
 file dataengines/notifications/notificationsengine.cpp (revision 2df6612) 
 was not found in the repository. So I'll try later.
 
 David Edmundson wrote:
 @Martin G
 
 That's referring to when it's called with QMetaObject::invoke(). If you 
 skip calling it directly and not via the meta object system it'll be the 
 sender of the last slot that was called as a slot in the stack on this 
 thread. 
 
 Given the code has been changed anyway, it would be rather petty and 
 childish to write a small test app just to smugly gloat that I am right.
 Naturally, that's exactly what I've done: 
 http://static.davidedmundson.co.uk/testqobject.zip

 That's referring to when it's called with QMetaObject::invoke().

given the documentation: that is unexpected. Thanks for correcting me and I 
suggest to go for an update to Qt docs.


- Martin


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


On Jan. 6, 2015, 2:32 p.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121360/
 ---
 
 (Updated Jan. 6, 2015, 2:32 p.m.)
 
 
 Review request for Plasma and Kai Uwe Broulik.
 
 
 Bugs: 339732
 https://bugs.kde.org/show_bug.cgi?id=339732
 
 
 Repository: plasma-workspace
 
 
 Description
 ---
 
 There can easily be situations where the popups could overlap one another or 
 result in strange animations. This patch rewrites the notifications so that 
 all actions such as show/reposition/hide are handled from a one single place 
 and every action is properly queued and protected around, which makes it more 
 robust, more predictive and less chaotic. There's also a slight delay between 
 every action so it's also visually much more cleaner and easier to see what's 
 going on. 
 
 
 Diffs
 -
 
   applets/notifications/plugin/notificationshelper.h af8f6fa 
   applets/notifications/plugin/notificationshelper.cpp 425f0d6 
   dataengines/notifications/notificationsengine.cpp d4b7f19 
   applets/notifications/package/contents/ui/NotificationPopup.qml 8eb1912 
 
 Diff: https://git.reviewboard.kde.org/r/121360/diff/
 
 
 Testing
 ---
 
 Tested whole day plus stress-tested with something like for i in {1..200}; do 
 notify-send $i - $RANDOM $RANDOM sdf sdf sdfwefhsdjfnskdfbkwefnos igodsfgn 
 sodifgj asodfgnsdlfgdf g; done executed from 4 terminals at once, all works 
 fine and as expected.
 
 
 Thanks,
 
 Martin Klapetek
 


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


Re: Review Request 121882: Look for kglobalaccel and don't build the internal copy if = 5.7

2015-01-06 Thread Kai Uwe Broulik

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



CMakeLists.txt
https://git.reviewboard.kde.org/r/121882/#comment50961

Wouldn't that fail in  5.7 environment?


- Kai Uwe Broulik


On Jan. 6, 2015, 3:05 nachm., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121882/
 ---
 
 (Updated Jan. 6, 2015, 3:05 nachm.)
 
 
 Review request for Plasma.
 
 
 Repository: plasma-workspace
 
 
 Description
 ---
 
 The daemon was moved to the frameworks, but it will be released only with 
 frameworks 5.7, so we need to check for this and disable building the local 
 copy with frameworks less than 5.7
 
 
 Diffs
 -
 
   CMakeLists.txt 834de83 
 
 Diff: https://git.reviewboard.kde.org/r/121882/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Martin Klapetek
 


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


Re: Review Request 121882: Look for kglobalaccel and don't build the internal copy if = 5.7

2015-01-06 Thread Kai Uwe Broulik


 On Jan. 6, 2015, 5:06 nachm., Kai Uwe Broulik wrote:
  CMakeLists.txt, line 16
  https://git.reviewboard.kde.org/r/121882/diff/1/?file=338640#file338640line16
 
  Wouldn't that fail in  5.7 environment?

Oh, damn. Nevermind. xD


- Kai Uwe


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


On Jan. 6, 2015, 3:05 nachm., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121882/
 ---
 
 (Updated Jan. 6, 2015, 3:05 nachm.)
 
 
 Review request for Plasma.
 
 
 Repository: plasma-workspace
 
 
 Description
 ---
 
 The daemon was moved to the frameworks, but it will be released only with 
 frameworks 5.7, so we need to check for this and disable building the local 
 copy with frameworks less than 5.7
 
 
 Diffs
 -
 
   CMakeLists.txt 834de83 
 
 Diff: https://git.reviewboard.kde.org/r/121882/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Martin Klapetek
 


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


Re: Plasma naming scheme

2015-01-06 Thread Marco Martin
On Monday 05 January 2015, Aleix Pol wrote:
  For example in release announcement we'd talk about the Plasma 5.2
  release and when there are shell specific changes we could write Plasma
  Desktop now has addition X
  
  Does that make sense to everyone? And if so: Where should we publish it
  and where should we announce it?
 
 Well, it's still weird as Plasma is more than a technology. Also note
 there's a Plasma framework.

end user product and library are on a different level of abstraction so an 
implementation detail, relevant only for developers

 To me, the biggest problem with this is that you're just covering part
 of it here, given that Plasma is not only the shell(s) but the entire
 solution as well (kwin, system settings, some of the apps) or maybe
 not.

yes, kindof the thing that we give you that just works, in the end composed 
by a bajillion tiny products but again an implementation detail (and if one of 
such components wants to advertize itself as well, for instance kwin to people 
who know and care what a windowmanager is, that's fine too)


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


Re: Re: kcm-touchpad in plasma 5.2?

2015-01-06 Thread Rajeesh K Nambiar
On Sat, Jan 3, 2015 at 7:56 PM, David Edmundson
da...@davidedmundson.co.uk wrote:


 On Sat, Jan 3, 2015 at 7:07 PM, Rajeesh K Nambiar
 rajeeshknamb...@gmail.com wrote:

 On Thu, Dec 11, 2014 at 4:30 PM, David Edmundson
 da...@davidedmundson.co.uk wrote:
  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.

 Thanks for the review. I cannot answer many of the comments, but some
 queries below:

 
  kded.cpp
  The touchpad backend leaks?

 TouchpadBackend::implementation has static variable, would this still
 cause leak? (especially if there are multiple backends...)

 
  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 couldn't find a way to work around this as there's no async
 alternative to isServiceRegistered. Could Alexander help?


 Ah, it's a bit obscure.

 QDBusPendingCall async =
 QDBusConnection::sessionBus().interface()-asyncCall(QLatin1String(ListNames));
 QDBusPendingCallWatcher *callWatcher = new
 QDBusPendingCallWatcher(async, this);
 connect(callWatcher, SIGNAL(finished(QDBusPendingCallWatcher*)),
 this, SLOT(serviceNameFetchFinished(QDBusPendingCallWatcher*)));


 void serviceNameFetchFinished(QDBusPendingCallWatcher *callWatcher)
 {
 QDBusPendingReplyQStringList reply = *callWatcher;
 callWatcher-deleteLater();

 if (reply.isError()) {
 qDebug()  omg wtf bbq;
 return;
 }

 QStringList allServices = reply.value();
 if (allService.contains(MYSERVICE)) {
   //do stuff
}
 }


Thank you. I have made some changes and tested it - doesn't seem to
break things. Opened a review request here:
https://git.reviewboard.kde.org/r/121825/ .



 
  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

 Top level Messages.sh does put .{h,cpp} file translations to
 kcm_touchpad.pot and {qml,js} file translations to
 plasma_applet_touchpad.pot - could you be more specific if this needs
 to change?

  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.

 But this makes sense to leave it as it is - as users would want to
 'disable' tap+scrolling alone.

 
  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.



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


Re: Re: kcm-touchpad in plasma 5.2?

2015-01-06 Thread Rajeesh K Nambiar
On Thu, Dec 11, 2014 at 4:30 PM, David Edmundson
da...@davidedmundson.co.uk wrote:
 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.

Thanks for the review. I cannot answer many of the comments, but some
queries below:


 kded.cpp
 The touchpad backend leaks?

TouchpadBackend::implementation has static variable, would this still
cause leak? (especially if there are multiple backends...)


 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 couldn't find a way to work around this as there's no async
alternative to isServiceRegistered. Could Alexander help?


 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

Top level Messages.sh does put .{h,cpp} file translations to
kcm_touchpad.pot and {qml,js} file translations to
plasma_applet_touchpad.pot - could you be more specific if this needs
to change?

 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.

But this makes sense to leave it as it is - as users would want to
'disable' tap+scrolling alone.


 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.



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


Re: Plasma naming scheme

2015-01-06 Thread Thomas Pfeiffer
On Tuesday 06 January 2015 14:11:49 Sebastian Kügler wrote:
  Does that make sense to everyone? And if so: Where should we publish it
  and
  where should we announce it?
 
 This nomenclature sounds fine to my ears. Does this need announcement? I
 think the Dot editors have some wiki pages with these things, but other
 than that, to my biased self, this is common knowledge / common sense?

Well, if it were clear to everyone, we wouldn't have taken the effort to 
define a naming scheme in the first place. Maybe the VDG is the only group to 
which this wasn't clear yet (we were not sure whether to call it Plasma 
Desktop 5, Plasma 5 Desktop or the Plasma 5 desktop, for example), but 
maybe it's not 100% clear to others, either. The broad nomenclature is 
probably clear at least to people within KDE by now, but we believe a good 
brand communication should be consistent down to details like the ones 
mentioned above.

It probably doesn't need a public announcement, any maybe sending it to the 
two lists I sent it to was sufficient. I'd also update the KDE Brand Map [1] 
if that's the document which people who do public communication refer to.

Cheers,
Thomas

[1] https://community.kde.org/Promo/Branding/Map


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


Re: [kde-promo] Plasma naming scheme

2015-01-06 Thread Martin Klapetek
On Tue, Jan 6, 2015 at 5:46 PM, Thomas Pfeiffer thomas.pfeif...@kde.org
wrote:

 On Tuesday 06 January 2015 14:11:49 Sebastian Kügler wrote:
   Does that make sense to everyone? And if so: Where should we publish it
   and
   where should we announce it?
 
  This nomenclature sounds fine to my ears. Does this need announcement? I
  think the Dot editors have some wiki pages with these things, but other
  than that, to my biased self, this is common knowledge / common sense?

 Well, if it were clear to everyone, we wouldn't have taken the effort to
 define a naming scheme in the first place. Maybe the VDG is the only group
 to
 which this wasn't clear yet (we were not sure whether to call it Plasma
 Desktop 5, Plasma 5 Desktop or the Plasma 5 desktop, for example), but
 maybe it's not 100% clear to others, either. The broad nomenclature is
 probably clear at least to people within KDE by now, but we believe a good
 brand communication should be consistent down to details like the ones
 mentioned above.

 It probably doesn't need a public announcement, any maybe sending it to the
 two lists I sent it to was sufficient. I'd also update the KDE Brand Map
 [1]
 if that's the document which people who do public communication refer to.


Looking at the wiki, it says KDE Plasma *. Originally we went for Plasma
by KDE format
to get further from the idea that Plasma = KDE and make the rebranding
clearer.
Was that dropped? Or just forgotten?

Imho puts a nicer touch to the name than KDE Plasma (which still supports
the Plasma = KDE)

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


Re: Minutes Monday Plasma Hangout

2015-01-06 Thread Marco Martin
On Monday 05 January 2015, Eike Hein wrote:
 On 01/05/2015 03:46 PM, Sebastian Kügler wrote:
  Get better!
 
 Gute Besserung!
 

we, thanks everybody :)


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


Re: screenlocker focus questions

2015-01-06 Thread Martin Gräßlin
On Tuesday 06 January 2015 13:45:39 Sebastian Kügler wrote:
 Hey,
 
 So I'm attempting to fix the focus of the screenlocker. When the
 screenlocker is started, the focus should be on the password input, so you
 can directly type after the machine woke up. This worked previously (I had
 already fixed it twice), but broke again recently.
 
 I've tried a few things involving forceActiveFocus(), but they all don't
 seem to work anymore. I can get the locker to work if I click on it, or if
 I hit tab, in the latter case, the focus moves to the userlist, and when
 selecting a different user, it moves to the password field.
 
 I want to move it to the password field initially, but for example calling
 forceActiveFocus() in the password's onCompleted: handler doesn't do that.
 
 I've looked at the git log, and there weren't any changes in those QML
 files, so I assume the problem lies elsewhere. Maybe the window isn't
 getting focus correctly? I know a few things changed around it, so maybe
 someone (Martin?) has an idea where to look?

yes, it's not unlikely that the interaction broke and I didn't notice (for me 
focus had been broken a long time on my multi-screen setup and I implemented 
the changes on the multi-screen setup).

In the old setup the window got focus after being mapped. Now that's no longer 
the case. The window gets mapped once the WID has been passed to ksld - which 
according to my testing seems to happen after the window gets mapped. Might be 
that Qt is confused when it gets the additional focus request.

 
 I'm also working blind here, since I couldn't find out how to get at the
 console output of the screenlocker, any ideas?

Which part of the screenlocker? Greeter is really difficult to get at, but 
should end up in xsession-errors. If you want to test the interaction try the 
test application in the build directory.

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 121882: Look for kglobalaccel and don't build the internal copy if = 5.7

2015-01-06 Thread David Faure

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

Ship it!


Ship It!

- David Faure


On Jan. 6, 2015, 3:05 p.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121882/
 ---
 
 (Updated Jan. 6, 2015, 3:05 p.m.)
 
 
 Review request for Plasma.
 
 
 Repository: plasma-workspace
 
 
 Description
 ---
 
 The daemon was moved to the frameworks, but it will be released only with 
 frameworks 5.7, so we need to check for this and disable building the local 
 copy with frameworks less than 5.7
 
 
 Diffs
 -
 
   CMakeLists.txt 834de83 
 
 Diff: https://git.reviewboard.kde.org/r/121882/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Martin Klapetek
 


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


Re: Breeze Window Decoration status

2015-01-06 Thread Andrew Lake
On Sun Jan 04 2015 at 11:00:49 PM Martin Gräßlin wrote:

 I don't want special solutions for compositing disabled any more. It's
 too much a corner case nowadays. Compositing works and becomes more and
 more a requirement. This was a deliberate design decision when drafting
 KDecoration2 as for example it's no longer possible to have round
 borders without Compositing.


Thanks Martin, that helps my understanding. :-)

The vm installations I've encountered, including my current one [1], don't
have compositing enabled. One less thing to worry about. :-)

[1] http://wstaw.org/m/2015/01/06/no-composite-problem.png
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Review Request 121807: Call forceActiveWindow on the sidePanel

2015-01-06 Thread Kai Uwe Broulik


 On Jan. 6, 2015, 5:54 nachm., Marco Martin wrote:
  desktoppackage/contents/views/Desktop.qml, line 102
  https://git.reviewboard.kde.org/r/121807/diff/1/?file=337964#file337964line102
 
  but you are activating.. the desktop window?

That's just confused. I added the forceActiveWindow on the desktop and it gets 
the window to activate as a parameter. But I will create a KWindowSystem import 
instead and drop this review, see the review there.


- Kai Uwe


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


On Jan. 3, 2015, 2:39 nachm., Kai Uwe Broulik wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121807/
 ---
 
 (Updated Jan. 3, 2015, 2:39 nachm.)
 
 
 Review request for Plasma.
 
 
 Repository: plasma-desktop
 
 
 Description
 ---
 
 See Review 121806
 
 
 Diffs
 -
 
   desktoppackage/contents/views/Desktop.qml c2da3b8 
 
 Diff: https://git.reviewboard.kde.org/r/121807/diff/
 
 
 Testing
 ---
 
 Works
 
 
 Thanks,
 
 Kai Uwe Broulik
 


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