Re: Review Request 114260: Port mouse dataengine
On Dec. 8, 2013, 1:08 p.m., Bhushan Shah wrote: plasma/generic/dataengines/mouse/mouseengine.cpp, line 34 https://git.reviewboard.kde.org/r/114260/diff/2/?file=222312#file222312line34 You should call init() here. Have a look at http://community.kde.org/Plasma/PortingTolibplasma2#DataEngine for changes in API. Alex Merry wrote: Any update on this? Oh, I totally forgot about this. I can't fix it ATM, but I'll. - Andrea --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114260/#review45349 --- On Dec. 3, 2013, 10:51 a.m., Andrea Scarpino wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114260/ --- (Updated Dec. 3, 2013, 10:51 a.m.) Review request for KDE Frameworks and Plasma. Repository: kde-workspace Description --- = subject. I commented the lines about scheduleSourcesUpdated(). What to do with them? Diffs - plasma/generic/dataengines/CMakeLists.txt 3e94325 plasma/generic/dataengines/mouse/CMakeLists.txt 29cab87 plasma/generic/dataengines/mouse/cursornotificationhandler.h 3b571f8 plasma/generic/dataengines/mouse/cursornotificationhandler.cpp 3cb9add plasma/generic/dataengines/mouse/mouseengine.h d55565d plasma/generic/dataengines/mouse/mouseengine.cpp 19a7fb7 Diff: https://git.reviewboard.kde.org/r/114260/diff/ Testing --- Builds Thanks, Andrea Scarpino ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Compiling plasma-framework and KDE5
Hi
I'm trying to build KDE5, but I get stuck while compiling plasma-framework,
kdewebkit, and a few other packages. I'm following instructions given here:
http://community.kde.org/Frameworks/Building
I even tried manually building the individual packages, and that's when i
found out that plasma-framework is not building. I'm getting errors related
to cmake.
Here's the output (while building plasma-framework)
rishav@rishav-laptop:~/plasma-framework/build$ cmake
-DCMAKE_INSTALL_PREFIX=$KF5 -DCMAKE_PREFIX_PATH=$KF5 ..
CMake Error at CMakeLists.txt:52 (find_package):
Could not find a package configuration file provided by KActivities
(requested version 5.0.0) with any of the following names:
KActivitiesConfig.cmake
kactivities-config.cmake
Add the installation prefix of KActivities to CMAKE_PREFIX_PATH or set
KActivities_DIR to a directory containing one of the above files. If
KActivities provides a separate development package or SDK, be sure it
has been installed.
-- Configuring incomplete, errors occurred!
See also /home/rishav/plasma-framework/build/CMakeFiles/CMakeOutput.log.
rishav@rishav-laptop:~/plasma-framework/build$
In the case of kdewebkit, here's the output:
rishav@rishav-laptop:~/kdewebkit/build$ cmake -DCMAKE_INSTALL_PREFIX=$KF5
-DCMAKE_PREFIX_PATH=$KF5 ..
CMake Error at /home/rishav/qt5/qtbase/lib/cmake/Qt5/Qt5Config.cmake:26
(find_package):
Could not find a package configuration file provided by Qt5WebKitWidgets
with any of the following names:
Qt5WebKitWidgetsConfig.cmake
qt5webkitwidgets-config.cmake
Add the installation prefix of Qt5WebKitWidgets to CMAKE_PREFIX_PATH or
set Qt5WebKitWidgets_DIR to a directory containing one of the above
files. If Qt5WebKitWidgets provides a separate development package or
SDK, be sure it has been installed.
Call Stack (most recent call first):
CMakeLists.txt:10 (find_package)
-- Configuring incomplete, errors occurred!
See also /home/rishav/kdewebkit/build/CMakeFiles/CMakeOutput.log.
rishav@rishav-laptop:~/kdewebkit/build$
Here are the environment variables I set before running anything:
export KF5=/home/rishav/KF5
export QTDIR=/home/rishav/qt5/qtbase
export XDG_DATA_DIRS=$KF5/share:$XDG_DATA_DIRS:/usr/share
export XDG_CONFIG_DIRS=$KF5/etc/xdg:$XDG_CONFIG_DIRS:/etc/xdg
export PATH=$KF5/bin:$QTDIR/bin:$PATH
export
QT_PLUGIN_PATH=$KF5/lib/plugins:$KF5/lib64/plugins:$KF5/lib/x86_64-linux-gnu/plugins:$QTDIR/plugins:$QT_PLUGIN_PATH
export
QML2_IMPORT_PATH=$KF5/lib/qml:$KF5/lib64/qml:$KF5/lib/x86_64-linux-gnu/qml:$QTDIR/qml
export KDE_SESSION_VERSION=5
export KDE_FULL_SESSION=true
export XDG_DATA_HOME=$HOME/.local5
export XDG_CONFIG_HOME=$HOME/.config5
export XDG_CACHE_HOME=$HOME/.cache5
export CMAKE_PREFIX_PATH=$KF5:$CMAKE_PREFIX_PATH
export QT_MESSAGE_PATTERN='%{appname}(%{pid})/%{category} %{function}:
%{message}'
c=`echo -e \033`
export QT_MESSAGE_PATTERN=%{appname}(%{pid})/(%{category})
$c[31m%{if-debug}$c[34m%{endif}%{function}$c[0m: %{message}
unset c
I don't know where to find the files cmake needs to run.
Any help would be appreciated, Thanks!
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Compiling plasma-framework and KDE5
have you updated Qt5?
On Fri, Jan 31, 2014 at 12:59 PM, Rishav Thakker
thakker.ris...@gmail.comwrote:
Hi
I'm trying to build KDE5, but I get stuck while compiling
plasma-framework, kdewebkit, and a few other packages. I'm following
instructions given here:
http://community.kde.org/Frameworks/Building
I even tried manually building the individual packages, and that's when i
found out that plasma-framework is not building. I'm getting errors related
to cmake.
Here's the output (while building plasma-framework)
rishav@rishav-laptop:~/plasma-framework/build$ cmake
-DCMAKE_INSTALL_PREFIX=$KF5 -DCMAKE_PREFIX_PATH=$KF5 ..
CMake Error at CMakeLists.txt:52 (find_package):
Could not find a package configuration file provided by KActivities
(requested version 5.0.0) with any of the following names:
KActivitiesConfig.cmake
kactivities-config.cmake
Add the installation prefix of KActivities to CMAKE_PREFIX_PATH or set
KActivities_DIR to a directory containing one of the above files. If
KActivities provides a separate development package or SDK, be sure it
has been installed.
-- Configuring incomplete, errors occurred!
See also /home/rishav/plasma-framework/build/CMakeFiles/CMakeOutput.log.
rishav@rishav-laptop:~/plasma-framework/build$
In the case of kdewebkit, here's the output:
rishav@rishav-laptop:~/kdewebkit/build$ cmake -DCMAKE_INSTALL_PREFIX=$KF5
-DCMAKE_PREFIX_PATH=$KF5 ..
CMake Error at /home/rishav/qt5/qtbase/lib/cmake/Qt5/Qt5Config.cmake:26
(find_package):
Could not find a package configuration file provided by
Qt5WebKitWidgets
with any of the following names:
Qt5WebKitWidgetsConfig.cmake
qt5webkitwidgets-config.cmake
Add the installation prefix of Qt5WebKitWidgets to CMAKE_PREFIX_PATH
or
set Qt5WebKitWidgets_DIR to a directory containing one of the above
files. If Qt5WebKitWidgets provides a separate development package or
SDK, be sure it has been installed.
Call Stack (most recent call first):
CMakeLists.txt:10 (find_package)
-- Configuring incomplete, errors occurred!
See also /home/rishav/kdewebkit/build/CMakeFiles/CMakeOutput.log.
rishav@rishav-laptop:~/kdewebkit/build$
Here are the environment variables I set before running anything:
export KF5=/home/rishav/KF5
export QTDIR=/home/rishav/qt5/qtbase
export XDG_DATA_DIRS=$KF5/share:$XDG_DATA_DIRS:/usr/share
export XDG_CONFIG_DIRS=$KF5/etc/xdg:$XDG_CONFIG_DIRS:/etc/xdg
export PATH=$KF5/bin:$QTDIR/bin:$PATH
export
QT_PLUGIN_PATH=$KF5/lib/plugins:$KF5/lib64/plugins:$KF5/lib/x86_64-linux-gnu/plugins:$QTDIR/plugins:$QT_PLUGIN_PATH
export
QML2_IMPORT_PATH=$KF5/lib/qml:$KF5/lib64/qml:$KF5/lib/x86_64-linux-gnu/qml:$QTDIR/qml
export KDE_SESSION_VERSION=5
export KDE_FULL_SESSION=true
export XDG_DATA_HOME=$HOME/.local5
export XDG_CONFIG_HOME=$HOME/.config5
export XDG_CACHE_HOME=$HOME/.cache5
export CMAKE_PREFIX_PATH=$KF5:$CMAKE_PREFIX_PATH
export QT_MESSAGE_PATTERN='%{appname}(%{pid})/%{category} %{function}:
%{message}'
c=`echo -e \033`
export QT_MESSAGE_PATTERN=%{appname}(%{pid})/(%{category})
$c[31m%{if-debug}$c[34m%{endif}%{function}$c[0m: %{message}
unset c
I don't know where to find the files cmake needs to run.
Any help would be appreciated, Thanks!
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
--
-Heena
Season of kde'12 participant
Google Summer of Code 2013
Delhi College of Engineering(COE),India
http://about.me/heena.mahour
http://heenamahour.blogspot.in
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Compiling plasma-framework and KDE5
Hello, On Fri, Jan 31, 2014 at 12:59 PM, Rishav Thakker thakker.ris...@gmail.com wrote: rishav@rishav-laptop:~/plasma-framework/build$ cmake -DCMAKE_INSTALL_PREFIX=$KF5 -DCMAKE_PREFIX_PATH=$KF5 .. CMake Error at CMakeLists.txt:52 (find_package): Could not find a package configuration file provided by KActivities (requested version 5.0.0) with any of the following names: KActivitiesConfig.cmake kactivities-config.cmake Add the installation prefix of KActivities to CMAKE_PREFIX_PATH or set KActivities_DIR to a directory containing one of the above files. If KActivities provides a separate development package or SDK, be sure it has been installed. -- Configuring incomplete, errors occurred! See also /home/rishav/plasma-framework/build/CMakeFiles/CMakeOutput.log. rishav@rishav-laptop:~/plasma-framework/build$ You need to build and install frameworks branch of kactivities first. And about failure in kdewebkit, have you installed Qt5 webkit widgets package? check with your distribution to install correct package? Instead of building manually I suggest to use kdesrc-build. And if you want to build every framework manually, here is list. http://community.kde.org/Frameworks/Building/Details -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] Plasma Next Naming - Take 2
On Tuesday 28 January 2014 12:06:27 Martin Gräßlin wrote: On Tuesday 28 January 2014 11:50:34 Martin Klapetek wrote: On Tue, Jan 28, 2014 at 9:39 AM, Martin Gräßlin mgraess...@kde.org wrote: What we should consider when using such a numbering scheme is that it also works with beta releases of Plasma Next. If we kind of stick to what we use today it could be. 2014.06-90 for the beta release of Plasma Next with the last stable release having been in June 2014. How about simply adding beta1? Eg. 2014.06-beta1 or 2014.06.rc1 Plain and simple. Is it? It makes everything more difficult as it's alpha-numeric instead of just numeric and with such a scheme I would assume that it is the beta for June 2014 release. Thus the release 2014.06 would have a smaller version number than the beta release. 2014.06 2014.06-rc3 2014.06-0 2014.06-rc3 2014.06-final 2014.06-rc3 etc. And as already discussed using the date of the final release in pre-releases is dangerous. Whatever you guys decide to use. It would be nice if it would be compatible to http://semver.org/ This is the only attempt to standardize versions i know of. And remember. I said NICE. Mike -- Michael Jansen http://michael-jansen.biz ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Compiling plasma-framework and KDE5
Hi Rishav, On Friday, January 31, 2014 12:59:06 Rishav Thakker wrote: Hi I'm trying to build KDE5, but I get stuck while compiling plasma-framework, kdewebkit, and a few other packages. I'm following instructions given here: http://community.kde.org/Frameworks/Building I even tried manually building the individual packages, and that's when i found out that plasma-framework is not building. I'm getting errors related to cmake. As others have mentioned: - Make sure you have the frameworks branch of the kactivities repository installed - Make sure QtWebKit is installed (it sometimes fails when building because it needs ungodly amounts of memory during linking), but other Qt modules will build after that -- it's easy to miss. One tip: Use kdesrc-build, at least the kactivities problem would not have happened, since kdesrc-build knows the dependencies. 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
Re: Release schedule for Plasma Next
Hey, I've let the ideas in this thread sink in for a bit, and have now formed an opinion. On Friday, January 31, 2014 15:57:19 Martin Gräßlin wrote: On Friday 31 January 2014 14:34:59 Eike Hein wrote: On Thursday 30 January 2014 18:23:41 Martin Graesslin wrote: Is Alpha unstable code? A release that contains known critical bugs? why do we release them? Are distros going to package Alphas? Is Beta unstable code? A release that contains known critical bugs? why do we release them? Are distros going to package Betas? I'm sure that the answer to those questions depends on the user, and no matter what communication effort we do people will continue having their definitions of betas and alphas. Personally I think we should do a number of pre-releases without any special name, and the moment we think Plasma2 is stable we tag RC1. I like this idea! +1 I don't, personally. I think that words have meanings between people, and that names are an opportunity to communicate. Alpha and Beta, while perhaps not the most strictly defined words in the language, have a lot of associated meaning among the members our audience. It gives them utility, e.g. for mana- ging expectations and communicating the relative position of a release in its release cycle. Isn't it better to communicate the meaning through our release announcements than through the implied meanings of words like alpha and beta? I just read the wikipedia article [1] for it and from that I assume that everybody in our audience has a different expectation and thus we cannot meat the expectation if we rely on the meaning. I prefer that we are verbose and explain what the current development snapshot means. Whether we call it beta, tech preview, snapshot or goal doesn't matter to me. If people complain that the software is insertrandominsultweheardabout4.0, we can point to the release announcement and show that it holds what we promised. This might or might not work for development, but for the release team, and even more so for the promo team, this sucks. Releases need preparation, and in the case of Plasma Next, this is no small amount of work, having no firm schedule doesn't help with this at all. Also, it makes it harder to reach out since some journalist actually keep an agenda and plan, doing an ad-hoc release means we'll simply get less coverage. Lastly, I think we really need a firm schedule to keep ourselves in check. We're really good at finding infinite amounts of tinkering work, something can always be improved, and we're never fully happy. Having a firm release date, which we only change with very good reason and prior discussion prevents all these issues. That's why I think it's necessary to nail down a clear schedule, and not go for when it's ready. 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
Re: [kde-promo] Plasma Next Naming - Take 2
On Saturday 01 February 2014 15:19:57 Michael Jansen wrote: On Tuesday 28 January 2014 12:06:27 Martin Gräßlin wrote: On Tuesday 28 January 2014 11:50:34 Martin Klapetek wrote: On Tue, Jan 28, 2014 at 9:39 AM, Martin Gräßlin mgraess...@kde.org wrote: What we should consider when using such a numbering scheme is that it also works with beta releases of Plasma Next. If we kind of stick to what we use today it could be. 2014.06-90 for the beta release of Plasma Next with the last stable release having been in June 2014. How about simply adding beta1? Eg. 2014.06-beta1 or 2014.06.rc1 Plain and simple. Is it? It makes everything more difficult as it's alpha-numeric instead of just numeric and with such a scheme I would assume that it is the beta for June 2014 release. Thus the release 2014.06 would have a smaller version number than the beta release. 2014.06 2014.06-rc3 2014.06-0 2014.06-rc3 2014.06-final 2014.06-rc3 etc. And as already discussed using the date of the final release in pre-releases is dangerous. Whatever you guys decide to use. It would be nice if it would be compatible to http://semver.org/ This is the only attempt to standardize versions i know of. And remember. I said NICE. I'm not sure whether that applies to us as we don't provide API (all API we provide is in frameworks (or should be in frameworks) and thus is properly versioned as 5.x.y). Also I expect that we will continue to version our .so in the frameworks way. 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: [kde-promo] Plasma Next Naming - Take 2
And as already discussed using the date of the final release in pre-releases is dangerous. Whatever you guys decide to use. It would be nice if it would be compatible to http://semver.org/ This is the only attempt to standardize versions i know of. And remember. I said NICE. I'm not sure whether that applies to us as we don't provide API (all API we provide is in frameworks (or should be in frameworks) and thus is properly versioned as 5.x.y). Also I expect that we will continue to version our .so in the frameworks way. They talk about semantic a lot there too. And i think it would be nice if all of kde somehow uses version numbers one can understand without further reading. The worst thing that can happen is if two kde version numbers use different semantic meanings. Cheers Martin -- Michael Jansen http://michael-jansen.biz ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] Plasma Next Naming - Take 2
On Saturday, February 01, 2014 19:33:31 Michael Jansen wrote: And as already discussed using the date of the final release in pre-releases is dangerous. Whatever you guys decide to use. It would be nice if it would be compatible to http://semver.org/ This is the only attempt to standardize versions i know of. And remember. I said NICE. I'm not sure whether that applies to us as we don't provide API (all API we provide is in frameworks (or should be in frameworks) and thus is properly versioned as 5.x.y). Also I expect that we will continue to version our .so in the frameworks way. They talk about semantic a lot there too. And i think it would be nice if all of kde somehow uses version numbers one can understand without further reading. The worst thing that can happen is if two kde version numbers use different semantic meanings. The KDE frameworks follow this scheme, anyway. For the workspace bits, I think the same scheme makes sense, and would be in line with how we've been doing it. -- 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
[KDE Bugtracking System] REMINDER: current Plasma regressions
Please find below a list of the current regressions reported for Plasma. This is a weekly reminder. This search was scheduled by myr...@kde.org. Plasma regressions -- Bug 301424: https://bugs.kde.org/show_bug.cgi?id=301424 Priority: NOR Severity: normal Platform: openSUSE RPMs Assignee: plasma-b...@kde.org Status: REOPENED Summary: Cannot open battery monitor applet if set to hidden in systray ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
