Re: Review Request 121718: Allow to compile plasma-workspace without Qt5WebKit installed.
--- 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
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
---
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
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.
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
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
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
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
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
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
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
---
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
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
--- 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/
--- 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
--- 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/
--- 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/
--- 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
---
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
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
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
--- 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
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
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?
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?
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
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
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
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
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
--- 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
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
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
