Re: Moving KDE Telepathy to kdenetwork
On Thu, Feb 5, 2015 at 11:31 PM, Albert Astals Cid wrote: > El Dimecres, 4 de febrer de 2015, a les 10:52:59, Pali Rohár va escriure: >> On Wednesday 04 February 2015 01:51:49 Albert Astals Cid wrote: >> > El Dimarts, 3 de febrer de 2015, a les 00:49:17, Martin >> >> Klapetek va escriure: >> > > Hi, >> > > >> > > so we decided with KDE Telepathy to join the big guys and >> > > become part of KDE Applications 15.04. So I'd like to >> > > request a move of KDE Telepathy repos[1] to kdenetwork/. >> > > This is also a mail to Urs Wolfer asking for approval as >> > > per the policies. >> > >> > KTP is all KF5 based at the moment, right? >> > >> > Not being a IM user myself, how does KTP compare to kopete >> > feature wise? >> > >> > Kopete mailing list: is there any work happening in kopete? >> > Are you even thinking on a port to KF5? >> >> I do not have time right now to port Kopete to KF5. I'm still >> using Kopete and if I catch some crash/bug I will try to fix it. >> But in last months I did not have time to work on any new feature >> due to finishing my university study... >> >> Anyway, if there are some students interested in Kopete and KDE >> will be in next Google Summer of Code and could help & mentor >> some Kopete project... > > The question is, what do you miss in Kopete that KTP doesn't provide, and > won't it be easier to make KTP provide that over having to port kopete all > over KF5? > > I'm asking this because i feel at un-ease by shipping in our main modules two > things that as far as i know "do the same", i'll be much happier if we're > doing this because kopete is on maintaince mode for those still using kdelibs4 > apps but we're converge in KTP for KF5. > > What do you guys think? > > Cheers, > Albert Hi, After having been an avid user of both projects, and admittedly collaborated much more with KTp although not exclusively, I think that KTp is a clear evolution forward. Telepathy is an interesting proof of successful collaboration between many different free software projects (much further than the typical Gnome&KDE) and I think we should strive to make it a solution for all of us. Getting more pragmatic, I think the clear distinction between Kopete and KTp is that Kopete is a KDE application by the book (kxmlgui, a main window, integrates on the system tray etc.) and KTp will blend in your Plasma, which is a feature I value very positively. Aleix
Re: KDiagram libs (KChart, KGantt) in KDE Review
On Mon, Feb 9, 2015 at 1:50 AM, Friedrich W. H. Kossebau wrote: > Am Montag, 9. Februar 2015, 00:23:58 schrieb Albert Astals Cid: >> El Diumenge, 8 de febrer de 2015, a les 00:29:26, Friedrich W. H. Kossebau >> va >> escriure: >> > Hi, >> > >> > Calligra, Massif-Visualizer, KMyMoney (and perhaps more) make use of >> > KDAB's >> > nice offer of their KDChart in the GPLv2 licensing variant. But as there >> > are no real public releases of KDChart, all the projects have copied a >> > dump of KDChart into their code repositories, updating now and then to >> > newer versions of KDChart. Which is anything but perfect. >> > >> > To improve things, after some talk with KDABians it was decided to create >> > a >> > KDE repo with a KDE-fied fork of KDChart, based on their latest Qt5ied >> > version. So all FLOSS Qt5-based projects have a single place to-go-to for >> > nice charting. Which would be centrally updated now and then. Still not >> > perfect, but an improvement over the current situation. >> > To meet the KDE repo requirements, KDAB has also extended the license to >> > GPLv2+ for this dump :) >> >> Thanks KDABians for this. >> >> If this is basically a copy&paste from the existing code we're already >> shipping i have no objection, > > > Yes, nearly copy&paste: the copies of KDChart in Calligra & KMyMoney are older > (2.4.1, based on Qt4) versions, while the copy of KDChart in Massif-Visualizer > matches the version of the KChart lib in KDiagram. > >> though you should probably get someone with >> CMake knowledge to review (and kill that autogen.py and g++.pri?) > > Yes, any volunteers here for reviewing the CMake parts? :) Code should be > similar to that of a KF5 tier1 lib. > > Cheers > Friedrich > Hi, I just went through the cmake code. Let's see: - I see this, what does need to be fixed? > # TODO: fix ecm_generate_headers to support camelcase .h files - Library targets are usually called KF5*, see KF5Parts or KF5Gantt - Is this really needed? add_definitions(-DKDAB_NO_UNIT_TESTS). It's not very good to compile differently things if there's unit tests and not. - some of the definitions in the root CMakeLists.txt files are already being defined by KDEFrameworkCompilerSettings. You might want to clean them up. - misses a .reviewboardrc file. I created a small review request you also want to look into: https://git.reviewboard.kde.org/r/122495/ Aleix
Re: KDiagram libs (KChart, KGantt) in KDE Review
On Mon, Feb 9, 2015 at 11:35 AM, Inge Wallin wrote: > On Monday, February 09, 2015 04:09:59 Aleix Pol wrote: >> On Mon, Feb 9, 2015 at 1:50 AM, Friedrich W. H. Kossebau >> >> wrote: >> > Am Montag, 9. Februar 2015, 00:23:58 schrieb Albert Astals Cid: >> >> El Diumenge, 8 de febrer de 2015, a les 00:29:26, Friedrich W. H. >> >> Kossebau >> >> va >> >> >> >> escriure: >> >> > Hi, >> >> > >> >> > Calligra, Massif-Visualizer, KMyMoney (and perhaps more) make use of >> >> > KDAB's >> >> > nice offer of their KDChart in the GPLv2 licensing variant. But as >> >> > there >> >> > are no real public releases of KDChart, all the projects have copied a >> >> > dump of KDChart into their code repositories, updating now and then to >> >> > newer versions of KDChart. Which is anything but perfect. >> >> > >> >> > To improve things, after some talk with KDABians it was decided to >> >> > create >> >> > a >> >> > KDE repo with a KDE-fied fork of KDChart, based on their latest Qt5ied >> >> > version. So all FLOSS Qt5-based projects have a single place to-go-to >> >> > for >> >> > nice charting. Which would be centrally updated now and then. Still not >> >> > perfect, but an improvement over the current situation. >> >> > To meet the KDE repo requirements, KDAB has also extended the license >> >> > to >> >> > GPLv2+ for this dump :) >> >> >> >> Thanks KDABians for this. >> >> >> >> If this is basically a copy&paste from the existing code we're already >> >> shipping i have no objection, >> > >> > Yes, nearly copy&paste: the copies of KDChart in Calligra & KMyMoney are >> > older (2.4.1, based on Qt4) versions, while the copy of KDChart in >> > Massif-Visualizer matches the version of the KChart lib in KDiagram. >> > >> >> though you should probably get someone with >> >> CMake knowledge to review (and kill that autogen.py and g++.pri?) >> > >> > Yes, any volunteers here for reviewing the CMake parts? :) Code should be >> > similar to that of a KF5 tier1 lib. >> > >> > Cheers >> > Friedrich >> >> Hi, >> I just went through the cmake code. Let's see: >> - I see this, what does need to be fixed? > # TODO: fix >> ecm_generate_headers to support camelcase .h files >> - Library targets are usually called KF5*, see KF5Parts or KF5Gantt > > KDiagram is not a framework and cannot become one until the library is release > under the LGPL license (right?). So a name starting with KF5 sounds strange to > me at this point. > >> - Is this really needed? add_definitions(-DKDAB_NO_UNIT_TESTS). It's >> not very good to compile differently things if there's unit tests and >> not. >> - some of the definitions in the root CMakeLists.txt files are already >> being defined by KDEFrameworkCompilerSettings. You might want to clean >> them up. >> - misses a .reviewboardrc file. >> >> I created a small review request you also want to look into: >> https://git.reviewboard.kde.org/r/122495/ >> >> Aleix Correct, my apologies, I was thinking it might become a framework. Aleix
KPeople part of KDE Frameworks
Hi, I would like to submit KPeople for review process so it can join the KF5 family in the next 5.8 release. KPeople is a tier 3 framework (because of KService, which will be dropped eventually, without breaking ABI) and it offers cross-source contact aggregation. More information about it can be read on the README [1]. Your reviews will be welcome. Thanks! Aleix [1] https://projects.kde.org/projects/playground/network/kpeople/repository/revisions/master/entry/README.md
Re: KPeople part of KDE Frameworks
On Fri, Feb 13, 2015 at 2:25 PM, Aleix Pol wrote: > Hi, > I would like to submit KPeople for review process so it can join the > KF5 family in the next 5.8 release. > > KPeople is a tier 3 framework (because of KService, which will be > dropped eventually, without breaking ABI) and it offers cross-source > contact aggregation. More information about it can be read on the > README [1]. > > Your reviews will be welcome. > > Thanks! > Aleix > > [1] > https://projects.kde.org/projects/playground/network/kpeople/repository/revisions/master/entry/README.md Hi, Somebody requested generated API documentation for easier review, I just ran kapidox on kpeople, hope this helps: http://proli.net/meu/kpeople/apidocs/html/ Aleix
Re: KPeople part of KDE Frameworks
On Tue, Feb 17, 2015 at 7:56 PM, Albert Astals Cid wrote:
> El Divendres, 13 de febrer de 2015, a les 14:25:33, Aleix Pol va escriure:
>> Hi,
>> I would like to submit KPeople for review process so it can join the
>> KF5 family in the next 5.8 release.
>>
>> KPeople is a tier 3 framework (because of KService, which will be
>> dropped eventually, without breaking ABI) and it offers cross-source
>> contact aggregation. More information about it can be read on the
>> README [1].
>>
>> Your reviews will be welcome.
>
> Please fix
>
> ./src/widgets/plugins/emaildetailswidget.cpp:50:return i18n("Email");
> ./src/match.cpp:55:ret += i18n("E-mail");
>
> Also add context to make it clear if it's an action or a noun.
I think I fixed it now, I also added a couple other i18nc's.
Thanks!
Aleix
Re: KDE Telepathy has an unreleased dependency
On Wed, Feb 25, 2015 at 9:15 AM, David Faure wrote: > On Wednesday 25 February 2015 02:04:58 Albert Astals Cid wrote: >> El Dimarts, 24 de febrer de 2015, a les 11:52:55, Martin Klapetek va > escriure: >> > I just realized that one of the main dependencies, KPeople, will be >> > released only after KDE Applications Beta 2 as it's targeting KF 5.8 >> > (released 12th March >> > while KDE Apps Beta 2 is released 11th March). >> > >> > I'm not sure what should be done in this case; we could perhaps move the >> > 5.8 release two days earlier, but this would still miss Beta 1. >> > >> > So uhh...what should we do? >> >> I can see three options: >> a) Do not release KPeople as part of frameworks but as part of KDE >> Applications 15.04 (and move it later to frameworks) >> b) Do not release KDE Telepathy as part of KDE Applications 15.04 >> c) Give KDE Telepathy an exception to only join on Beta 3 of KDE >> Applications 15.04 > > I see a fourth option: > d) make a KPeople 5.7 release NOW > > If it's ready, I can make that happen with two commands or so. > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > Makes sense to me. +2 Aleix
Re: KDE Telepathy has an unreleased dependency
On Wed, Feb 25, 2015 at 2:04 AM, Albert Astals Cid wrote: > El Dimarts, 24 de febrer de 2015, a les 11:52:55, Martin Klapetek va escriure: >> I just realized that one of the main dependencies, KPeople, will be released >> only after KDE Applications Beta 2 as it's targeting KF 5.8 (released 12th >> March >> while KDE Apps Beta 2 is released 11th March). >> >> I'm not sure what should be done in this case; we could perhaps move the 5.8 >> release two days earlier, but this would still miss Beta 1. >> >> So uhh...what should we do? > > I can see three options: > a) Do not release KPeople as part of frameworks but as part of KDE > Applications 15.04 (and move it later to frameworks) > b) Do not release KDE Telepathy as part of KDE Applications 15.04 > c) Give KDE Telepathy an exception to only join on Beta 3 of KDE Applications > 15.04 > > a) will make packagers unhappy because we'd move something around again, > creating more friction and confusion > > b) is bad since KDE Telepathy fills a hole in our KF5-based series of apps > > So i'd say let's go c) even if it makes me very unhappy that we have to resort > to that. > > Other opinions? > > Cheers, > Albert > >> >> Cheers > At the moment KPeople is an optional dependency, there's still the possibility to use it without KPeople. This shouldn't be a show-stopper, even less for the Beta versions. Aleix
Re: Multiplatform frameworks
On Thu, Feb 26, 2015 at 3:10 AM, Jeremy Whiting wrote:
> Hello core developers,
>
> In the past few months some effort has been made to get the frameworks (kf5)
> to work on other platforms such as OS X and Windows. Together with Marko I
> focused primarily on OS X since there was already a patch for QStandardPaths
> there that worked pretty well. In discussion with the Qt developers I began
> to think that we maybe should be installing our data files in the places
> that QStandardPaths expect to find them, rather than get QStandardPaths to
> find files in linuxy paths.
>
> Yesterday I did a test to see if I could get our data files to install to
> the places that QStandardPaths looks for them. All I had to do was pass
> -DCMAKE_INSTALL_DATADIR="/Users/jeremy/Library/Application Support/" to
> cmake (I added it in my .kdesrc-buildrc actually) and most of the frameworks
> built just fine with vanilla Qt 5.4.1. Actually even kanagram and khangman
> which required the QSP patch to run ran fine after I built kde with that one
> change.
>
> One issue I found however is that some frameworks (maybe all?) have a
> KF5FooConfig.cmake.in with ${PACKAGE_PREFIX_PATH}/@KDE_INSTALL_DATADIR@ in
> them to specify where to find the data files. On my OS X install that was
> getting filled in as "/usr/local/Users/jeremy/Library/Application Support"
> which is incorrect. It seems on linux KDE_INSTALL_DATADIR is a subpath of
> the prefix, but that doesn't work if we are installing data files outside
> the prefix. So how should/could this be solved? I can think of three ideas:
>
> 1. Add another .cmake.in specifically for platforms that install data files
> outside the prefix such as KF5FooMacConfig.cmake.in which is used on OS X to
> generate the KF5FooConfig.cmake and doesn't include ${PACKAGE_PREFIX_PATH}
> 2. Inside KF5FooConfig.cmake.in have platform detection to define whether to
> use the prefix or not.
> 3. Use absolute paths for KDE_INSTALL_DATADIR everywhere and remove
> ${PACKAGE_PREFIX_PATH} completely.
>
> I'm not sure which approach would be best, but any would be a step closer to
> working better on other platforms.
>
> BR,
> Jeremy
>
Hi Jeremy,
Thanks a lot for looking into this, I think it's very interesting!
So what CMAKE_INSTALL_PREFIX are you setting on your applications?
That's /usr/local? Maybe that doesn't make sense in OS X?
I'd suggest you to play a bit with
modules/ECMPackageConfigHelpers.cmake so we can find what's exactly
the odd part...
Aleix
Re: [KDE/Mac] Multiplatform frameworks
On Thu, Feb 26, 2015 at 10:45 AM, René J.V. wrote: > On Wednesday February 25 2015 19:10:08 Jeremy Whiting wrote: > >>QStandardPaths there that worked pretty well. In discussion with the Qt >>developers I began to think that we maybe should be installing our data >>files in the places that QStandardPaths expect to find them, rather than >>get QStandardPaths to find files in linuxy paths. > > Even if that were the easy way out, I don't think it's the proper solution if > not only because OS X and MS Windows are multi-user machines and are maybe > more often used like that than Linux desktop installs. Installing stuff in > $HOME/Library/Application Support is thus not an option (besides, there's > that obnoxious space in the filename that's bound to cause issues). > > If we can't find a best-of-both-worlds solution that we all agree on and can > go into Qt, we'll just have to roll our own (which might be incorporated > after all once it's proved its value ;)) > > Reminder to self: add my views to wherever we decided to continue the stalled > discussion from gerrit. > > R IIRC, the solution is using /Library instead, although my OS X knowledge is rusty. Aleix
Re: KPeople part of KDE Frameworks
On Fri, Feb 13, 2015 at 2:25 PM, Aleix Pol wrote: > Hi, > I would like to submit KPeople for review process so it can join the > KF5 family in the next 5.8 release. > > KPeople is a tier 3 framework (because of KService, which will be > dropped eventually, without breaking ABI) and it offers cross-source > contact aggregation. More information about it can be read on the > README [1]. > > Your reviews will be welcome. > > Thanks! > Aleix > > [1] > https://projects.kde.org/projects/playground/network/kpeople/repository/revisions/master/entry/README.md Today it's been 2 weeks after the review process. I'll proceed to request the move into kde/frameworks. Aleix
Re: Help please with some builds in the new jenkins-ci for KDE
On Wed, Apr 8, 2015 at 7:34 PM, Scarlett Clark wrote: > Hello all, > I am to the point now with my ci that I just need help with some of these > builds. While I am learning fast, > some of these failures are stumpers. > > qoauth - google leads me to believe that qt5 uses qca and not and > that I should pass > CONFIG += crypto to qmake. alas that did not work and it still wants > QtCrypto. Has anyone built this > for qt5? Can you tell me what flags I need to pass? Editing files in our > system is not an option. It feels weird what you are saying. - QtCrypto is the header that qca installs, don't ask me why it's not all called QtCrypto. - QOAuth uses QCA, not Qt5. Can you please show the error you are getting? > > dragon - I added kdbusaddons to the deps list but it fails mid compile at > #include and > I notice > > KF5DBusAddons > > is not on the find_packages list so I need to know... am I on the right > track that adding it there will make everything happy and can I do that?, or > someone related to the project? Correct, just pushed the required change. > > packagekit-qt - wants a much newer version than what is available in ubuntu > 14.10 (or even 15.04) (compile error on a function not available > in the version we have). Thoughts? ppa maybe? Correct, it's really old. I'd suggest talking to the Kubuntu packagers, if what you need is an ubuntu package. > > More coming as I work all this out.. > Thanks so much for any help that you all can provide me. > Scarlett Thanks a lot for your work, Scarlett!! Aleix
Re: Help please with some builds in the new jenkins-ci for KDE Cont.. again
On Thu, Apr 9, 2015 at 7:06 AM, Ben Cooksley wrote: > On Thu, Apr 9, 2015 at 11:06 AM, Aleix Pol wrote: >> On Wed, Apr 8, 2015 at 10:53 PM, Scarlett Clark wrote: >>> Hello all, >>> I am to the point now with my ci that I just need help with some of >>> these builds. While I am learning fast, >>> some of these failures are stumpers. >>> >>> kde-runtime kf5 configures and pulls in all depends fine. But the build >>> never >>> happens... >>> 20:34:24 == Commencing the Build >>> 20:34:24 >>> 20:34:24 >>> 20:34:24 == Installing the Build >>> 20:34:24 >>> 20:34:24 make: *** No rule to make target 'install'. Stop. >> >> It shouldn't be built anymore. I just pushed a commit so it's clear >> what happened. > > Please ensure kde-build-metadata is updated to reflect that > kde-runtime does not have a kf5-qt5 / stable-kf5-qt5 entry anymore. That's the case, no project is pointing to kde-runtime. Aleix
Re: Help please with some builds in the new jenkins-ci for KDE Cont.. again
On Wed, Apr 8, 2015 at 10:53 PM, Scarlett Clark wrote: > Hello all, > I am to the point now with my ci that I just need help with some of > these builds. While I am learning fast, > some of these failures are stumpers. > > kde-runtime kf5 configures and pulls in all depends fine. But the build never > happens... > 20:34:24 == Commencing the Build > 20:34:24 > 20:34:24 > 20:34:24 == Installing the Build > 20:34:24 > 20:34:24 make: *** No rule to make target 'install'. Stop. It shouldn't be built anymore. I just pushed a commit so it's clear what happened. > > > libkface - I finally got opencv + opencv-contrib modules to build, which got > rid of some missing opencv module errors, but now a pile of: > 0:49:46 In file included from /home/jenkins/builds/libkface/src/recognition- > opencv-lbph/lbphfacemodel.h:35:0, > 20:49:46 from /home/jenkins/builds/libkface/src/recognition- > opencv-lbph/lbphfacemodel.cpp:30: > 20:49:46 /home/jenkins/builds/libkface/build/src/libopencv.h:55:37: fatal > error: opencv2/core/internal.hpp: No such file or directory > 20:49:46 #include > 20:49:46 ^ > 20:49:46 compilation terminated. > 20:49:46 In file included from > /home/jenkins/builds/libkface/src/detection/opencvfacedetector.h:40:0, > 20:49:46 from > /home/jenkins/builds/libkface/src/detection/opencvfacedetector.cpp:41: > 20:49:46 /home/jenkins/builds/libkface/build/src/libopencv.h:55:37: fatal > error: opencv2/core/internal.hpp: No such file or directory > 20:49:46 #include > 20:49:46 ^ > 20:49:46 compilation terminated. > This goes on for several. Looking at opencv the file does not exist at all. We > have to use master to achieve a qt5 build... so I am at a loss here. > This another one I have been fighting with too long... > > More coming as I work all this out.. > Thanks so much for any help that you all can provide me. > Scarlett > > ___ > Kde-frameworks-devel mailing list > kde-frameworks-de...@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel I don't know about libkface, sorry :/ Aleix
Re: KF5-QT5 branchgroup - jobs that need developeer attention
On Wed, Apr 15, 2015 at 9:44 AM, Scarlett Clark wrote: > Here is a list of mostly compile failures and other tid bits that need to be > resolved by the respective developers. If you know the developer of a project > and they are not on this list please forward this. All jobs can be viewed at : > https://build-sandbox.kde.org/ > Most of these are osx failures. If osx is not to be supported, I need to know > that too. Questions - concerns - just ask. > Thanks, > Scarlett > > > apper - kf5 does not appear to be complete. Nothing to deploy. > > qt-gstreamer/libaccount-qt - osx - can't find gstreamer and glib2 and > pkgconfig breaks: analitza, artikulate,kaccounts-integration, > ktp*, kalgebra, > > step - needs eigen3 3.2.2 (has to be backported to utopic) > > choqok - qoauth installs to lib64 and choqok can't find them. > > libkface - opencv2/core/internal.hpp: No such file or directory breaks digikam > > calligra - All - compile fail. > > kcachegrind - osx - compile failure > > qca broken osx - breaks: kdeconnect-kde,ksirk > > kdenlive osx - compile failure > > kdepimlibs - osx - compile failure breaks: kalarmcal, kdepim, kmailtransport > > kdeplasma-addons - osx - compile failure > > kdevplatform - osx - compile failure - breaks kdevelop*, plasma-sdk > > kgamma - osx - missing Qt5X11ExtrasConfig.cmake not sure this would be > available in osx? > > kget - all - wants qca and kf5gpgmepp - pulled in as deps and not found. > > khotkeys,powerdevil - osx - baloo not supported? remove dep on milou? > > kio-mtp - osx - package 'libmtp' not found > > kmenuedit - osx - needs libkscreen - disabled by Marko - reason? > > kmix - osx - compile failure > > knights - all - compile failure - depends on kspeech needs changed to qtspeech > for kf5. > > konversation - osx - compile failure > > kstars - osx - missing Eigen3 > > ktp-common-internals -Linux compile failure breaks: ktp* > > libechonest - all - qjson depend and qt5 has its own internal json now > > marble - all - fails at configure - can't get it to find phonon - > (qextserialport - need help(this is an external depend and it installs into > strange places) but all these claim to be optional so it should at least build > without features - but will not proceed to build. Breaks: libkgeomap > > libksysguard - osx - compile failure > > libringclient - all - compile failure > > partitionmanager - osx - need help satisfying the depends (Marko?) > > purpose: CMake Error at src/plugins/CMakeLists.txt:17 (add_subdirectory): >add_subdirectory given source "kdeconnect" which is not an existing >directory. > I tried to add kdeconnect as depend and that did not seem to help, not sure > what it wants here. breaks: kamoso Should be fixed, my bad. > > pyqt5 - linux - needs sip 4.16.4 (needs backport to utopic) > > sddm-kcm - osx - Qt5X11ExtrasConfig.cmake (not sure sddm would even be useful > on osx) > > skanlite - all - wants a framework KF5Sane (does this exist?) Yes it does: http://quickgit.kde.org/?p=libksane.git > > tellico - compile failure > > wacomtablet - configure incomplete - xinput does not exist on debian/ubuntu > > Regarding build/test failures, I guess we'll get to check them over at build.kde.org eventually... ;) Thanks! Aleix
Re: Alternative to QDateTime::isDateOnly ?
On Mon, Apr 27, 2015 at 10:17 PM, Christian Mollekopf wrote: > Hey, > > KDateTime used to have a date-only functionality, that QDateTime is > lacking. The problem with that is that we need to find a new solution > for interfaces that allow to set/get either QDate or QDateTime. > > One such interface is KCalCore::Event::start(). For the sake of > discussion getters are more interesting, because a simple overload is > not possible. I see the following possible solutions: > > 1. add isDateOnly functionality to QDateTime > 2. Overloads with different names: QDate startDate(), QDateTime > startDateTime() > 3. Overloads using templates: T start() > 4. QVariant that can contain either QDateTime or QDate: QVariant start() > 5. boost::variant that can contain either QDateTime or QDate: > boost::variant start() > > Given that this should be a fairly common porting problem (at least in > the PIM realm), it would be nice to have a standard solution for it. > > Opinions following: > 1. I'm not sure whether it semantically makes sense to have a QDateTime > without a time. It would make sense to have a PointInTime with higher or > lower accuracy though. > 2. Not a solution, but a workaround. > 3. Better than 2., but not by much. > 4. Would be pretty good IMO, but unfortunately leads to an unexpressive > interface (because QVariant can't be parametrized with valid values). > 5. boost::variant solves the problem of 4., and is header-only, but I'm > not sure to what extent boost is accepted in interfaces? > > I think the variant solutions are actually not that bad, semantically, > but QVariant seems a bit useless for a case like this. > > Any ideas or opinions? > > Cheers, > Christian What about considering the port to be like: QDateTime().time().isNull()? Even QDateTime::isValid documentation mentions that the date and the time need to be valid, therefore the time can be invalid. With that assumption, I'd say we could even implement QDateTime::isDateOnly() or similar. I would most certainly not go into template stuff (i.e. 3, 4 and 5) 2 looks ok but if we get to add the API in Qt, we'll get to port things much more easily. Aleix
Re: Alternative to QDateTime::isDateOnly ?
On Tue, Apr 28, 2015 at 8:47 PM, John Layt wrote: > On 27 April 2015 at 21:17, Christian Mollekopf wrote: > >> 1. add isDateOnly functionality to QDateTime > ... >> Opinions following: >> 1. I'm not sure whether it semantically makes sense to have a QDateTime >> without a time. > > Adding it to QDateTime was not an option Thiago was happy with so it > didn't make it, It is something only used inside PIM so there's no > wide use-case for it. I do think I could add it fairly easily as a new > internal attribute flag, but it could complicate the code a lot and > I'm also not sure it's possible to do with a backwards compatible > behaviour either. > > Using a QDate in the api is probably not an option for PIM though as > it doesn't have a QTimeZone attached which you will certainly always > need (and yes, that is a reason for doing it in QDateTime). > > One option is the invalid QTime that Aleix mentions. I did have that > in the back of my mind while re-writing QDateTime internals and so > whatever QDate, Qtime and QTimeZone you set should persist in spite of > the QDateTIme overall being invalid. However it's not really a > solution as how would you know when it was really invalid or when it > was Date Only? Well, it would only be invalid if the date is also invalid then. It would require to change the semantics of ::isValid though, which is probably not accepted at this point anymore. > > Personally, I suspect relying on the QDateTime to tell you it is Date > Only is perhaps the wrong approach? Perhaps it's actually an attribute > of the Event that it is Date Only and not an attribute of the > QDateTime? Rather than checking the QDateTime you've received from a > call to start() to see if it is Date Only, you should be checking if > the Event itself is Date Only? Your setter could have an enum for > choosing, or separate setters for QDate and QDateTime, and then have a > getter for QDateTIme and another for the enum. While this may seem > like a little more work for PIM, it's not used in many places so I > think this may be a better option, and easier to achieve too in the > required timeframe as it's all in your own control. > >> It would make sense to have a PointInTime with higher or >> lower accuracy though. > > I had pondered for a while having that, but with QDateTime internals > now entirely held as milliseconds relative to the Unix epoch and > translated into the QDate and QTime relative to the QTimeZone on the > fly, that's effectively what QDateTime has become. Now, a QDuration > class, or duration mode for QDateTime, could be useful though... > > Cheers! > > John.
Re: Alternative to QDateTime::isDateOnly ?
On Tue, Apr 28, 2015 at 10:11 PM, Christian Mollekopf
wrote:
> Hey Aleix,
>
>>
>> What about considering the port to be like:
>> QDateTime().time().isNull()?
>>
>> Even QDateTime::isValid documentation mentions that the date and the
>> time need to be valid, therefore the time can be invalid.
>>
>> With that assumption, I'd say we could even implement
>> QDateTime::isDateOnly() or similar.
>>
>
> I appreciate the pragmatism of that approach, but I just consider an
> interface
> that returns an invalid QDateTime fundamentally broken (tm).
> I mean, that would be like the first thing I'd check in a unittest, and
> the behaviour would IMO be completely unexpected.
Rock and roll! \\nn//
Let's not do it then. :)
>
> I may be a bit extreme that way, but QDateTime::isValid() would be a
> blocker
> for the isDateOnly() functionality IMO.
>
>> I would most certainly not go into template stuff (i.e. 3, 4 and 5) 2
>> looks ok but if we get to add the API in Qt, we'll get to port things
>> much more easily.
>
> I agree that the Qt solution would be the easiest, but why would you not
> use the template solutions?
> They actually seem to be the cleanest to me.
- value
Using templates when you know the 2 types it will have is not better
than just making both methods.
- variant/QPair<>
It's hard to read the code afterwards.
What about having a new class (In KCoreAddons? KCalCore?) to replace
KDateTime in PIM?
Something like:
class Occasion
{
QDateTime dateTime() const;
QDate date() const;
bool isAllDay() const;
}
HTH,
Aleix
Re: Extended handling of magnet links
On Sat, May 16, 2015 at 1:31 PM, Vladimir Perepechin wrote: > Hi everyone :) > > I was thinking about implementing my idea > https://forum.kde.org/viewtopic.php?f=83&t=126352 . > While digging sources i've understand that my idea was incorrect, and there > is nothing to do with kio_magnet. > > My second thought was to store any additional info in mimeinfo while > detecting it from url, but after more digging i came to mime subclasses. > In fact, i understand that x-scheme-handler is very simple in the way how > it determines, but i've tried to add subclass for it ad it works like for > any other mime-types. > > The only problem is: KRun dosn't looking into mime-database when working > with x-scheme-handlers. So i came here with the following proposition. > > Extend schemeHandler function of KRun. > 1) we are looking for all mime-types that statrs with x-scheme-handler and > has base handler in a parentMimeTypes. > 2)If we found such mime-type - check url against globPatterns of found > mime-type. > > 3) So, if we found subclassed mime-type for our url - try to find preferred > service for it. if no preferred service was found - looking for preferred > service for our base mime-type (as it was done before) > > So, it will be something like this: http://pastebin.com/Wgni5iBP > I'm not a c++ coder, so this isn't most optimized solution, but it shows the > idea. > > > Next step: > Just ship xml with magnet url subclass with ktorrent: > http://pastebin.com/4crCJRLZ > > And add x-scheme-handler/x-magnet-btih to ktorrent.desktop MimeType list. > > Doing similar with other magnet handlers (like dcpp) will allow us to > separate magnet handling by appropriate application. > > > So, what do u think? Is this idea wrong? Any other ideas? Maybe you'd like to work on the kio-magnet? I think it could be a really cool thing to have. Aleix
Re: KDE Applications Versioning
On Mon, Jun 8, 2015 at 8:25 PM, Christoph Cullmann wrote: > Hi, > > for frameworks, it is all very nice and automatic, the version in the > CMakeLists.txt get auto-updated on each KF 5.x release. > > It seems to me, for the "applications" collection, something similar might > make sense. > > E.g. I missed to ever update the Kate version since 5.0 and other > applications like Dolphin and Konsole seem to have similar problems. > > Would it make sense to have some "we auto-define some version CMake var" to > KDE Application release number? > For e.g. bug reports that would make all things easier. > Or do I miss some magic already in place (e.g. the opensuse packages seems to > have patched release numbers, at least for Konsole). > > Greetings > Christoph > > -- > - Dr.-Ing. Christoph Cullmann - > AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com > Science Park 1 Tel: +49-681-38360-22 > 66123 Saarbrücken Fax: +49-681-38360-20 > GERMANYWWW: http://www.AbsInt.com > > Geschäftsführung: Dr.-Ing. Christian Ferdinand > Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 I'd welcome such feature. I always forget to update my applications' version. Maybe it would be best to ask the release-t...@kde.org? Aleix
Re: Frameworks compiler and Qt requirements after Qt 5.7?
On Fri, Jun 26, 2015 at 4:24 PM, Mark Gaiser wrote: > Hi, > > If Qt's plans progress according to what they post on the mailinglist then > Qt 5.6 will be LTS, 5.7 will up the compiler requirements to the following: > > GCC 4.7 > Clang 3.2 > MSVC 2012 > > Framework currently requires: > GCC 4.5 > Clang 3.1 > MSVC 2012 > > When frameworks started it had slightly less strict compiler requirements > then Qt had. But now that Qt is upping the compiler requirement, we should > follow as well. In fact, we should probably also update the Qt version > requirement which right now is at 5.2. > > I have no clue when Qt 5.7 will be released, but i'm guessing around this > time next year. Frameworks currently is at version 5.11 (5.12 coming up). If > we add a year to that then frameworks is at version 5.24 when Qt 5.7 is > released (big guess!). So why don't we change our requirements starting with > frameworks 5.25 (nice number as well)? I'd propose changing it to the > following: > > Qt 5.7 minimal requirement > GCC 5.1 (or somewhere in 5.x) > Clang 3.6.1 (or perhaps even 3.7) > MSVC 2015 > > We then have full C++11 support across the board and much of C++14 supported > as well. MSVC clearly being the limiting one in that area for the C++14 > support, but still quite decent. > > Regarding the above version numbers for the compilers. They would now be > considered "cutting edge" but in a year time most distributions will be at > those versions or even newer. > > What's your opinion on this? > > Cheers, > Mark I agree with most of the comments. I'm unsure bumping the dependencies would buy us that much. In fact it might be even interesting to consider bumping to Qt 5.3 even. Thinking about Qt 5.7, when Qt 5.5 is not even released, is premature. Aleix
Re: KDE Applications Versioning
On Wed, Jul 8, 2015 at 11:43 AM, Martin Klapetek wrote: > As the KDE Apps release is getting near, is this being considered/deployed? > Should we be setting some CMake variables? > > Cheers > -- > Martin Klapetek | KDE Developer Yes, that's why Albert was asking for a blog/wiki documentation. Aleix
Re: Using nullptr instead of Q_NULLPTR
On Thu, Aug 13, 2015 at 10:46 AM, Sergio Martins wrote: > Hi, > > > https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 > states gcc 4.5 as the minimum version, meaning we can't use nullptr. > > However, since some time now, kf5 libraries are full of nullptr (~400 > occurrences) and nobody noticed. > > We can either: > - Bump the requirement to gcc 4.6 and allow nullptr > - Fix kf5 and s/nullptr/Q_NULLPTR > > > I prefer the first option, it's the way forward and if someone was using an > old > gcc he would have complained by now. > > > Btw, what are the c++98/c++11 requirements for applications ? I could only > find > the page for frameworks. > > > Regards, > -- > Sérgio Martins > I'd say that requiring a newer gcc just like that would go against the nature of the KF5 project. Let's fix it for now, even increase the testing to make sure that what we promise is going to work, will, and then we can decide to bump the gcc dependencies together with Qt, eventually. Aleix
Re: Moving KDE Connect out of playground
On Thu, Sep 10, 2015 at 2:20 PM, Luigi Toscano wrote: > On Thursday 10 of September 2015 02:33:55 Albert Vaca wrote: >> +kde-core-devel >> >> Hi, >> >> With the latest changes we are making to KDE Connect as part of the sprint >> in Randa, I think that the project is becoming mature enough to be moved >> out of playground. Not only that, but Kubuntu and other distros are already >> installing KDE Connect by default, regardless of it being in playground. >> >> I think that extragear/network is the best place for KDE Connect to be in, >> as we don't want to be tied to external release schedules for now. >> >> Any thoughts? > > Nothing against moving it outside playground, it should have been done long > time ago. > > From a technical point of view, shouldn't we follow the usual procedure with a > moving to kdereview? > > Ciao > -- > Luigi > > >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << The move to kdereview has been requested this afternoon by Albert. I'd say the review itself can start already, I'm unsure it makes a big difference. Aleix
Re: Moving KDE Connect out of playground
On Sat, Sep 12, 2015 at 1:03 AM, Albert Astals Cid wrote: > El Divendres, 11 de setembre de 2015, a les 07:52:34, Albert Vaca va escriure: >> Our awesome sysadmins already moved the two repos (kdeconnect-android and >> kdeconnect-kde) to Review. > > In LoopbackDeviceLink::sendPackageEncrypted and > LoopbackDeviceLink::sendPackage you probably want to return false instead of > (or at least in addition to) those Q_ASSERTS ? > > Do you want to do something with the success bool in FindMyPhonePlugin::ring ? > Like send a notication to the user that it failed or something? > > PauseMusicPlugin::isKMixMuted returns a bool as an int? > > In DevicesSortProxyModel::sourceDataChanged you probably want to drop the two > params, Qt is smart enough to do a connection if the receiving side is a > subset of the send one; or at least make the params const & > > I think it may make sense to change the connects() to new style connects, > there's an automation tool in kde-dev-scripts/kf/convert-to-new-signal-slot- > signal.pl > > In case you're interested here's the clazy warnings: > * function-args-by-ref https://paste.kde.org/pw85h9xgh > * detaching-temporary https://paste.kde.org/py99b8dp1 > > I did not include inefficient-qlist nor qstring-uneeded-heap-allocations but > they also have lots of warnings > > These all just small things to improve, fine to "ignore" if you want :) > > Cheers, > Albert Fixed. Good morning! :) Aleix
Re: Moving KDE Connect out of playground
On Mon, Sep 14, 2015 at 12:52 AM, Jeremy Whiting wrote: > As shown here: http://developer.kde.org/~cfeck/portingstatus.html > (under Extragear base) It is missing a manual. Needs a Feature_summary > added to CMakeLists.txt and some .desktop files should be renamed to > org.kde.foo.desktop. > > I just tried it out and it seems to work here, though I'm not seeing > sms notifications in the desktop like I expected (I am able to control > cantata from my phone though, which is handy). Yes I installed the > beta on the play store. > > BR, > Jeremy > > > On Sat, Sep 12, 2015 at 6:29 AM, Albert Vaca wrote: >>> I moved the translations for both repositories. Please update the >>> translations >>> branches for kdeconnect-android so that trunk_kf5 is master and trunk is >>> none; >>> yes, it's android and it does not matter, but it's easier for us. >> >> >> Done. >> >>> >>> Translation branches for kdeconnect-kde are fine (translations moved few >>> months ago). In addition to master, we track also the 'kde4' branch. Do >>> you >>> plan to release additional versions from there, or can we drop that >>> branch? >> >> >> Removed kde4. >> Hi Jeremy, We just fixed the desktop naming issue and added the feature summary. Regarding the documentation, we discussed it briefly during the sprint and we have the feeling that the documentation for such a project would look more like a simple placeholder or something easily outdated than anything. Furthermore, since there isn't a clear main window of the application, it would be unintuitive to get there. We're convinced nobody would ever end up there. Aleix
Re: qca-qt5 (qt5 branch) merge into qca (master branch)
On Thu, Sep 24, 2015 at 11:02 AM, Harald Sitter wrote: > ahoy ahoy > > qca-qt5 as a "thing" is a build time switch on the same source as qca > (qt4). so, it is the same source base but depending on how you run > cmake you either get the qt5 or the qt4 build. > > originally various adjustments had to be made to qca-qt5 to make it > work reliably without conflicting with qca (qt4), there was however a > very long discussion on whether or not that is the right thing to do > which eventually ended in the maintainer stepping down [anyone wanna > maintain qca? it's like phonon but for crypto :)]. at the time qca-qt5 > as a tarball was released which had the changes and could co-exist > with the regular qca tarball. > > now, since qca essentially has no lead authority we could do what was > the original intention here. i.e. make the qca source base build two > distinct libraries for qt4 and qt5 that do not conflict in any form or > fashion. this would be a simple `git merge qt5` and then we can > release a qca tarball that replaces the old qca-qt5 tarball. > > Q: any objections to merging qca's qt5 branch into master and > replacing the qt5 tarball with a new release that supports both qt4 > and qt5? > > HS It's the only branch I've been testing. I'd love to be able to use master instead. Aleix
Re: Please review Snorenotify (Finish Incubating)
On Wed, Nov 18, 2015 at 11:48 PM, Hannah von Reth wrote: > Hi there, > > Mario guided me until now through the incubation process and we think it is > time to move Snorenotify from playground to extragear. > Snorenotify is a notification framework supporting Linux, Windows and Mac > OSX. > It is not meant to replace Knotifications, it is more targeted on Qt > applications without dependency to the plasma desktop, so it might become a > backend for Knotifications. > > I guess you can find the most important information here > https://community.kde.org/Incubator/Projects/Snorenotify. > > Besides Snorenotify there is also Snoretoast, a sub project of Snorenotify, > https://quickgit.kde.org/?p=snoretoast.git. > Snoretoast is a command line application and used within Snorenotify for > the Windows Toast notifications. > The application can only be build using the Microsoft compiler. > > So it would be great if Snorenotify could become a official KDE library and > maybe even a framework someday. > Currently it is used by Quassel and Tomahawk but hopefully more will start > to use it soon. > > So please review Snorenotify. > > If you find the idea of Snorenotify useful or you fancy notifications, like > I do, feel free to contribute ;) or start to use Snorenotify. Hi Hannah, I'm happy that you're decided to push this forward, I think it's a framework that could be definitely useful. In KDE Connect we'd like to be able to use it instead of KNotifications because it's leaner and more straightforward to our notifications use-case. As I said before, I already ported KDE Connect to use snore, nevertheless there's some issues like the API that I would suggest to review before committing to API and ABI stability. Here's some thoughts: - It feels overly complex that the Notification object is passed around by value rather than by reference. For starters, being able to connect to the notification would be very handy. I work-arounded it by setting a hint with the relevant information, but I have the feeling the API would be slightly smoother. - There's a hard dependency on QtWidgets from the very core of the framework. This requires applications that would use it to use QApplication. In the case of KDE Connect, for instance, the plan was to make it possible to have it in a QCoreApplication (or QGuiApplication at least). It's a daemon from which we consider that it's acceptable to show notifications but we don't really plan to open a dialog from there. Do you think it could/should be worked out? - There's a daemon. We're kind of trying to get rid of daemons. When is it needed? - enum values are all-caps joined by underscore (e.g. GLOBAL_SETTING). Camel-case would be more Qt-friendly. - Some methods use wid as a windows id. Please use QWindow whenever possible, it's being an issue in Plasma nowadays already. - Maybe we can port the internal logging infrastructure to just use QLoggingCategory? Cheers! :) Aleix
Policy regarding QtWebKit and QtScript
Hi, Soon Qt 5.6 will be released and with it, 2 quite widely used frameworks will disappear: QtWebKit and QtScript. Also QtQuick 1, but I think this is much less of a problem. I'd say we need a plan to figure out what to do with these dependencies. I don't think assuming that they will stay around is very wise, so I'd suggest to come up collectively or specifically on each project how to deal with those. I'd say it's especially pressing on KDE Frameworks where Qt5::Script is still quite widely used (kio, ki18n, ktexteditor, plasma-framework). Aleix
Re: Minuet (music education software) moved to kdereview
On Mon, Feb 1, 2016 at 12:30 AM, Albert Astals Cid wrote: > El Tuesday 26 January 2016, a les 10:15:47, Andreas Cord-Landwehr va escriure: >> On Monday 25 January 2016 21:48:27 Albert Astals Cid wrote: >> > El Sunday 24 January 2016, a les 16:50:18, Andreas Cord-Landwehr va >> >> escriure: >> > > * it looks strange to me that in minuet/cmake/ there are Config-files >> > > for >> > > the 3rd-party library drumstick. My understanding was that such Config >> > > files should only be shipped with the respective library (maybe someone >> > > with a deeper CMake-knowledge can comment?) >> > >> > If upstream ships a cmake file awesome, but if not then we have to find it >> > having our own cmake file. >> >> Absolutely, but shouldn't that be find-files then instead of config-files? >> I always had the perception that those are quite different. > > Right, it most probably be a Find file not a Config file, as far as I > understand it Config files are mostly for projects that ship the cmake file as > part of their install. > > Can someone with more cmake knowledge comment? Yes, the idea is that *Config.cmake files should be distributed by the framework itself, otherwise you need to find it. It probably works though, because such things are seldom checked within cmake though. I suggest turning it into a normal Find*.cmake file. Or get Drumstick to provide a cmake file, which is always more convenient. Aleix
Re: KDE file dialog
On Sun, Feb 28, 2016 at 8:01 PM, Riccardo Iaconelli wrote: > On 28 February 2016 at 15:58, Luigi Toscano wrote: >> >> This is what I use: >> export QT_QPA_PLATFORMTHEME=kde > > (btw, shouldn't this be "plasma"?) The string is in Qt, AFAIR. It probably can't be changed until Qt 6 if we don't want to mess with existing installations. Aleix
Re: build.kde.org What have you done to it!?!?! Serious explanation inside.
On Wed, Mar 23, 2016 at 11:02 PM, Scarlett Clark wrote: > Ok, so we are migrating to docker builds tomorrow, (Ben's available time) > Rather than continually mess with two set of builds I am only working on > sandbox in preparation. The good news is many unstable builds have gone > green, but will not be seen until we are live :) So I am hereby giving > NOTICE of disruption in service for build.kde.org We hope for a swift and > smooth transition. > Thanks!! > Scarlett Looking forward to it! And looking forward to the docs. :) Good luck! Aleix
Re: Generating QtScript bindings for Qt5
On Mon, Jul 25, 2016 at 11:37 PM, R.Harish Navnit wrote: > Hi, > > In Qt4, we had qtscriptgenerator which helped in generating Qt > bindings, which are needed to import qt extensions to QScriptEngine > etc. However, AFAIK this hasn't made it to Qt5 or at least there, is > no official release yet. > > Can anyone point me to or show me how one can generate Qt script > bindings in Qt5 ? > > I have considered using some unofficial Qt5 ports[1][2] of > qscriptgenerator, but I faced errors while compiling/building them > from source and they seem to be unmaintained too, since quite some > time now. I have duly reported them as issues against the relevant > repos.[3] > > What's the best fix/workaround to this ? Any suggestions ? > > [1] https://github.com/svalaskevicius/qtscriptgenerator > [2] https://github.com/svalaskevicius/qtjs-generator > [3] https://github.com/svalaskevicius/qtjs-generator/issues/24 > > Regards, > Harish Hi Harish, What are you trying to do? What do you need it for? I'd recommend against adopting anything using QtScript, as it's deprecated. Aleix
Re: Snappy sprint reporty musing
On Tue, Jul 26, 2016 at 2:07 PM, Sebastian Kügler wrote: > On Tuesday, July 26, 2016 1:08:28 PM CEST Harald Sitter wrote: >> - a store REST API (of which the reference version is the ubuntu store) > > So something like this exists for flatpaks as well, and it's open source? Note for Flatpak it's ostree repositories, not REST API's. It's similar to flatpak repositories but not entirely. I'd assume that the Ubuntu Store will be a tad more complex than a flatpak repository, as they plan to have a big one for all the stuff (with a big asterisk). For example, on the Ubuntu Store, you'd be able to have 5 firefoxes. > For snappy, we'd either have to use the ubuntu store (non-free, right?) or > write our own from scratch? 2 things: - it's seems that they want to set up stores within their instance, so it's possible to have a custom one with some parameters. - also it should be possible to set up a separate one. > Could you expand on the distribution mechanism? I don't understand the question. Aleix
Can't release applications
Hi, There's a major blocker when trying to release applications nowadays. To update the stable branch one needs to commit to the kde:sysadmin/repo-metadata.git repository, which can't be accessed by KDE Project maintainers. How can we solve this? Aleix
Re: Can't release applications
On Wed, Jul 27, 2016 at 12:57 PM, Boudhayan Gupta wrote: > Hi, > > On 27 July 2016 at 16:00, Harald Sitter wrote: >> On Wed, Jul 27, 2016 at 12:27 PM, Luigi Toscano >> wrote: >>> On Wednesday, 27 July 2016 12:22:45 CEST Aleix Pol wrote: >>>> Hi, >>>> There's a major blocker when trying to release applications nowadays. >>>> To update the stable branch one needs to commit to the >>>> kde:sysadmin/repo-metadata.git repository, which can't be accessed by >>>> KDE Project maintainers. >>>> >>>> How can we solve this? > > Note that we can give individual people RWC access to the repo. Just > file a ticket with the identity usernames of people who want that > right. But why? Why not make it a normal KDE repository? I know I can request it, but the next one will come with the same problem. In fact, I still have no idea what this has to do with sysadmin. Aleix
Re: Can't release applications
On Thu, Jul 28, 2016 at 9:25 AM, Ben Cooksley wrote: > On Thu, Jul 28, 2016 at 10:34 AM, Aleix Pol wrote: >> On Wed, Jul 27, 2016 at 12:57 PM, Boudhayan Gupta wrote: >>> Hi, >>> >>> On 27 July 2016 at 16:00, Harald Sitter wrote: >>>> On Wed, Jul 27, 2016 at 12:27 PM, Luigi Toscano >>>> wrote: >>>>> On Wednesday, 27 July 2016 12:22:45 CEST Aleix Pol wrote: >>>>>> Hi, >>>>>> There's a major blocker when trying to release applications nowadays. >>>>>> To update the stable branch one needs to commit to the >>>>>> kde:sysadmin/repo-metadata.git repository, which can't be accessed by >>>>>> KDE Project maintainers. >>>>>> >>>>>> How can we solve this? >>> >>> Note that we can give individual people RWC access to the repo. Just >>> file a ticket with the identity usernames of people who want that >>> right. >> >> But why? Why not make it a normal KDE repository? I know I can request >> it, but the next one will come with the same problem. >> In fact, I still have no idea what this has to do with sysadmin. > > The repository lives in the sysadmin/ namespace because it is not a > product developed by KDE - it is a Infrastructural Management > repository only (and yes, setting the l10n branches is a > infrastructural matter, because the translators don't [directly at > least] care what the branches are - it is scripty that cares and sets > everything up for them). > > This is much like the repository sysadmin/irc-notifications and > sysadmin/dns repositories. > repo-management is a relic of an era before the sysadmin/ namespace existed. > > I'm not sure at this point if the repository should be open push or > not - due to the potential to break updates to kde_projects.xml (which > has all sorts of impacts) as well as our current repository creation > workflow. So I guess we should have maintainers request write access? Aleix
Re: What's kde-core-devel for?
On Mon, Dec 19, 2016 at 10:48 PM, Albert Astals Cid wrote: > El dilluns, 19 de desembre de 2016, a les 17:42:17 CET, Alexander Neundorf va > escriure: >> On 2016 M12 19, Mon 10:24:29 CET Jan Kundrát wrote: >> > KDE has expanded over the last few years to include projects which are not >> > based on kdelibs or kf5 (or even Qt). >> >> I have heard that several times. Which are those beside Wiki2Learn ? > > Please let's try to stay focused on topic. > > Cheers, > Albert > > P.S: took me like 4 minutes > > PHP- https://cgit.kde.org/websites/capacity.git/ > Java - https://cgit.kde.org/kdeconnect-android.git/ > Python - https://websvn.kde.org/trunk/l10n-support/pology/ > PHP- https://cgit.kde.org/websites/paste-kde-org.git/ > CMake - https://cgit.kde.org/extra-cmake-modules.git/ > PHP- https://cgit.kde.org/websites/identity-kde-org.git/tree/ What Jan meant was Qt-only projects like Trojitá, I think. Aleix
Re: Application usage statistics and targeted user surveys
On Sun, Apr 23, 2017 at 12:52 PM, Volker Krause wrote: > Hi, > > we have talked about the above topics a couple of times in the past, from what > I remember usually agreeing it would be nice to have some more statistical > information about our users, so we know what our applications are used for, > and to measure impact of changes. Similarly, it would be nice to be able to > actually ask our users questions without statistical bias by using out-of-band > channels like blogs or social media. This can be obviously addressed by adding > this into application code, but that raises some valid privacy concerns. > > Wanting this for GammaRay I attempted to implement a generic framework for > this, with the goal to make this fully transparent, and give the user full > control over what data is shared, and how often they want to participate in > surveys, ie. make this solid enough on the privacy side that even I would > enable it myself. You'll find the code in Git (kde:kuserfeedback). > > Feature-wise it so far contains: > - a set of built-in data sources (app version, Qt version, platform, > application usage time, screen setup, etc) that applications can choose to > enable > - generic data sources for tracking the time ratio a Q_PROPERTY has a specific > value, allowing to track e.g. which application view is used how much > - the ability to add custom/application-specific data sources > - reference widgets for customizing what data you want to share, and showing > exactly what that means, in human readable translated text and if you insists > also all the way down to the raw JSON sent to the server. > - survey targeting using simple C++/JS-like expressions that can access all > the data sources (ie. you can target e.g. only users with high DPI multi- > screen setups) > - configurable encouragement of users to contribute (ie. after X starts and/or > Y hours of usage, repeated after Z months, suggest the user to participate if > they aren't already doing so). > - a management and analytic tool that allows you to manage products and survey > campaigns, and view recorded data using configurable aggregations > - the entire thing works without unique user ids. Fingerprinting can still be > an issue on too small user sets and/or when using too much detail in the data. > - by default all of this is opt-in of course, although technically the API > doesn't prevent applications to change this > - it can deal with multiple products, each product can have different data > sources and survey campaigns > > Technically, this consists of the following parts: > - a library that goes into the target application, backward compatible all the > way to Qt4.8/MSVC2010 (needed for my GammaRay use-case), depending only on > QtGui > - a library with the reference widgets, also with extended backward > compatibility > - the server, written in PHP5 and supporting sqlite/mysql/postgresql. Not the > most fun technology, but that stuff is available almost anywhere, and easy to > deploy and maintain > - the management tool, recent Qt5/recent C++, using QtCharts for the data > analysis > - a command line tool for data import/export, useful for eg. automated backups > > All of this is LGPLv2+ licensed. > > Feedback obviously very welcome, in particular around privacy concerns, or > reasons that would make you enable/disable such a feature. > > Regards, > Volker Hi Volker, This is really cool and necessary! I'd really like to see it adopted in our applications, hoping Krita can be the first of many. ;) WRT the code, it depends needs Qt4, we can live with it, but isn't it a bit weird that we have several ECM files forked in it? :/ is it really that tough of a depenendency? (if so, maybe we should rethink the whole KF5 approach x'D) Aleix
Re: kdereview - xdg-desktop-portal-kde
On Tue, May 2, 2017 at 12:15 PM, Albert Astals Cid wrote: > El dimarts, 2 de maig de 2017, a les 7:22:04 CEST, Jan Grulich va escriure: >> On pondělí 1. května 2017 22:59:44 CEST Albert Astals Cid wrote: >> > El divendres, 21 d’abril de 2017, a les 8:10:36 CEST, Jan Grulich va >> >> escriure: >> > > Hi, >> > > >> > > I would like to request review of xdg-desktop-portal-kde [1]. We would >> > > like >> > > to make it part of Plasma releases, see [2]. >> > > >> > > What is xdg-desktop-portal-kde: >> > > It's a KDE implementation of Flatpak portals backend [3], currently with >> > > support of AppChooser, FileChooser, Notification and Print portals. >> > > >> > > One mentioned issue on plasma-devel mailing list was usage of Qt's >> > > private >> > > print API. This will most likely go away if I find out it's useless, >> > > otherwise I'll have to keep it as it's used to set CUPS properties which >> > > are not available to the outside world. >> > >> > Since you have copied some code from Okular maybe you can add some other >> > (C) there other than RedHat's? >> >> Added. >> >> > What about the unusued QVariantMap &results in the print.cpp file? What >> > are >> > you supposed to return there? >> >> Seems not to be used at this moment or the portal frontend doesn't expect >> something to be returned with "results". I guess it's just reserved for >> future usage, given how complex the print API is. >> >> > I've no idea how to use this so can't really test it :/ >> >> You can test it with this [1]. You just go to flapak-build folder and run >> build.sh which will generate you a flatpak repo, you add it and install >> using flatpak, but you also need to have xdg-desktop-portal installed. > > Got stuck trying to figure out what to install from that local flatpak repo > > $ flatpak remote-ls mylocalrepo > error: GPG verification enabled, but no summary signatures found (use gpg- > verify-summary=false in remote config to disable) > > And couldn't figure out how to do that, seems like the hint is only half there > :D Hi, Here it's explained how to use a local repo: https://community.kde.org/Guidelines_and_HOWTOs/Flatpak#Compile_your_application The catch is --no-gpg-verify. Aleix
Re: Fwd: KF5 CMake usage question
On Sat, May 20, 2017 at 7:41 PM, Shaheed Haque wrote: > Actually, there is one thing about "target CMake"-based KF5 that I > don't quite understand: is there a way to get to the C++ compile flags > needed from CMake? That is, the modern equivalent of Foo_COMPILE_FLAGS > but for target Foo? Even if the general answer is "no", I'm interested > in at least the CMake variables/properties/commands needed to get to > "-fPIC" and "-std=gnu++14". > > I'm aware of the target properties > COMPILE_FLAGS/OPTIONS/DEFINITIONS/OPTIONS as well as > POSITION_INDEPENDENT_CODE and CXX_STANDARD but none of these seem to > be set on targets I have tried. > > Perhaps these are only set if somehow the compiler name etc. is specified? > > Thanks, Shaheed > > On 18 May 2017 at 18:04, Shaheed Haque wrote: >> Hi, >> >> On 18 May 2017 at 12:51, Andreas Hartmetz wrote: >>> On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote: Hi, On 13 May 2017 at 22:04, Sven Brauch wrote: > Hi, > > On 05/13/2017 06:06 PM, Shaheed Haque wrote: >> The printed output shows that the variable KF5KIO_INCLUDE_DIRS is >> not >> set. In poking around, I see references to a (new-to-me) >> target-based > >> system, and using that like this: > The question is, why do you need to do that? >>> The idea with the target based system aka "Modern CMake" is that you say >>> you want to compile against a library, and that is all you have to do. A >>> library requires you to add an include path for its own headers, include >>> paths for headers of one of its dependencies, and link against a bunch >>> of libraries? All covered by target properties. >>> If for some reason (e.g. handover to an external tool) you need those >>> properties, you can still query them. Under enforced names nonetheless, >>> unlike FOO_INCLUDE_DIR or was it FOO_INCLUDE_DIRS? >> >> Ack. The problem from the point of view of an automated tool which starts >> with a component called Foo arises ONLY because the target(s) of Foo are >> called FooFoo and FooBar. CMake does not - AFAICS - allow one to query Foo >> and somehow find FooFoo and FooBar inorder to look up FooFoo_INCLUDE_DIRS >> etc. >> >> I'm continuing to experiment with trying to build Python bindings for KF5. As part of that, the SIP tooling creates C++ wrapper code which must be compiled for each framework, and for that I need to know the header file directories. So far, I have simply been hardcoding the needed paths on my own system, but I now want to move to using standard CMake-based logic instead. (In some sense, this might be seen as similar to the stuff that was added to ECM, but I'm trying for a significantly more automated approach). Also, I am trying to feel my way towards a Pythonic build system for the KF5 bindings (as, roughly speaking, PyQt seems to be doing): in other words I'm interested in using CMake as a stepping stone, not the actual build system. >>> I would recommend against that unless you really need to have heavy >>> logic in the build system. A build system's main job is to "solve" a >>> dependency tree - that is the difference between a build system and a >>> script that runs the compiler. The dependency tree enables cheap >>> incremental builds and correct parallel builds. Maybe not that important >>> for bindings, admittedly. >>> Your advantage from using Python must be larger than the overhead from >>> doing your own dependency resolution plus the overhead from the CMake- >>> Python interfacing plus the build-related facilities that CMake has and >>> Python doesn't. Or were you considering scons? >>> PyQt may have chosen Python because qmake sucks, and it needs Python >>> anyway, so it avoids any extra dependencies. I know from experience that >>> you really want to avoid extra dependencies in commercial products. >> >> /me nods vigourosly. >> >> I'm not (yet) familair with all the intricacies of the Python build system >> (or CMake for that matter!), but I do see that PyQt has to work quite hard >> to keep its build system working as a Python user might expect. Further, the >> system I am seeking to build has to support more than KF5 (or even KDE). So, >> roughly speaking, the split I am going for is: >> >> - Keep all platform and system independent code in Python >> - Isolate all platform and system independent logic in CMake >> >> As I say, I am feeling my way a bit here, but this seems like a >> philosophically justifiable separation. Oh, and to solve the problem of >> finding the targets, I resorted to parsing the CMake files (!!). I can live >> with that hack precisely because by having the split, users of this code who >> are not using it against KF5 will need to replace this CMake part with their >> own anyway. >> >> (At this point, abstracting CMake away entirely is a minor detail). >> >> Thanks for the helpful remarks. >> >> Shaheed >> >> >> >
Re: Fwd: KF5 CMake usage question
On Thu, May 18, 2017 at 7:04 PM, Shaheed Haque wrote: > Hi, > > On 18 May 2017 at 12:51, Andreas Hartmetz wrote: >> On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote: >>> Hi, >>> >>> On 13 May 2017 at 22:04, Sven Brauch wrote: >>> > Hi, >>> > >>> > On 05/13/2017 06:06 PM, Shaheed Haque wrote: >>> >> The printed output shows that the variable KF5KIO_INCLUDE_DIRS is >>> >> not >>> >> set. In poking around, I see references to a (new-to-me) >>> >> target-based >>> > >>> >> system, and using that like this: >>> > The question is, why do you need to do that? >>> >> The idea with the target based system aka "Modern CMake" is that you say >> you want to compile against a library, and that is all you have to do. A >> library requires you to add an include path for its own headers, include >> paths for headers of one of its dependencies, and link against a bunch >> of libraries? All covered by target properties. >> If for some reason (e.g. handover to an external tool) you need those >> properties, you can still query them. Under enforced names nonetheless, >> unlike FOO_INCLUDE_DIR or was it FOO_INCLUDE_DIRS? > > Ack. The problem from the point of view of an automated tool which starts > with a component called Foo arises ONLY because the target(s) of Foo are > called FooFoo and FooBar. CMake does not - AFAICS - allow one to query Foo > and somehow find FooFoo and FooBar inorder to look up FooFoo_INCLUDE_DIRS > etc. > > >>> I'm continuing to experiment with trying to build Python bindings for >>> KF5. As part of that, the SIP tooling creates C++ wrapper code which >>> must be compiled for each framework, and for that I need to know the >>> header file directories. So far, I have simply been hardcoding the >>> needed paths on my own system, but I now want to move to using >>> standard CMake-based logic instead. >>> >>> (In some sense, this might be seen as similar to the stuff that was >>> added to ECM, but I'm trying for a significantly more automated >>> approach). >>> >>> Also, I am trying to feel my way towards a Pythonic build system for >>> the KF5 bindings (as, roughly speaking, PyQt seems to be doing): in >>> other words I'm interested in using CMake as a stepping stone, not the >>> actual build system. >>> >> I would recommend against that unless you really need to have heavy >> logic in the build system. A build system's main job is to "solve" a >> dependency tree - that is the difference between a build system and a >> script that runs the compiler. The dependency tree enables cheap >> incremental builds and correct parallel builds. Maybe not that important >> for bindings, admittedly. >> Your advantage from using Python must be larger than the overhead from >> doing your own dependency resolution plus the overhead from the CMake- >> Python interfacing plus the build-related facilities that CMake has and >> Python doesn't. Or were you considering scons? >> PyQt may have chosen Python because qmake sucks, and it needs Python >> anyway, so it avoids any extra dependencies. I know from experience that >> you really want to avoid extra dependencies in commercial products. > > /me nods vigourosly. > > I'm not (yet) familair with all the intricacies of the Python build system > (or CMake for that matter!), but I do see that PyQt has to work quite hard > to keep its build system working as a Python user might expect. Further, the > system I am seeking to build has to support more than KF5 (or even KDE). So, > roughly speaking, the split I am going for is: > > - Keep all platform and system independent code in Python > - Isolate all platform and system independent logic in CMake > > As I say, I am feeling my way a bit here, but this seems like a > philosophically justifiable separation. Oh, and to solve the problem of > finding the targets, I resorted to parsing the CMake files (!!). I can live > with that hack precisely because by having the split, users of this code who > are not using it against KF5 will need to replace this CMake part with their > own anyway. > > (At this point, abstracting CMake away entirely is a minor detail). > > Thanks for the helpful remarks. > > Shaheed > > > >>> Thus, I'm after the moral equivalents of: >>> >>> Foo_INCLUDE_DIRS >>> Foo_COMPILE_FLAGS >>> >>> Thanks, Shaheed >>> >>> > The usual way is to simply call >>> > >>> > target_link_libraries(mybinary KF5::KIOCore) >>> > >>> > and include paths etc. will be set up for your target automatically. >>> > >>> > Best, >>> > Sven >> >> Cheers, >> Andreas M9 BTW you don't need to do the parsing, you can run cmake in server mode and query it: "cmake -E server...".
Re: Fwd: KF5 CMake usage question
On Mon, May 22, 2017 at 7:54 PM, Shaheed Haque wrote: > On 21 May 2017 at 22:27, Aleix Pol wrote: >> On Sat, May 20, 2017 at 7:41 PM, Shaheed Haque wrote: >>> Actually, there is one thing about "target CMake"-based KF5 that I >>> don't quite understand: is there a way to get to the C++ compile flags >>> needed from CMake? That is, the modern equivalent of Foo_COMPILE_FLAGS >>> but for target Foo? Even if the general answer is "no", I'm interested >>> in at least the CMake variables/properties/commands needed to get to >>> "-fPIC" and "-std=gnu++14". >>> >>> I'm aware of the target properties >>> COMPILE_FLAGS/OPTIONS/DEFINITIONS/OPTIONS as well as >>> POSITION_INDEPENDENT_CODE and CXX_STANDARD but none of these seem to >>> be set on targets I have tried. >>> >>> Perhaps these are only set if somehow the compiler name etc. is specified? >>> >>> Thanks, Shaheed >>> >>> On 18 May 2017 at 18:04, Shaheed Haque wrote: >>>> Hi, >>>> >>>> On 18 May 2017 at 12:51, Andreas Hartmetz wrote: >>>>> On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote: >>>>>> Hi, >>>>>> >>>>>> On 13 May 2017 at 22:04, Sven Brauch wrote: >>>>>> > Hi, >>>>>> > >>>>>> > On 05/13/2017 06:06 PM, Shaheed Haque wrote: >>>>>> >> The printed output shows that the variable KF5KIO_INCLUDE_DIRS is >>>>>> >> not >>>>>> >> set. In poking around, I see references to a (new-to-me) >>>>>> >> target-based >>>>>> > >>>>>> >> system, and using that like this: >>>>>> > The question is, why do you need to do that? >>>>>> >>>>> The idea with the target based system aka "Modern CMake" is that you say >>>>> you want to compile against a library, and that is all you have to do. A >>>>> library requires you to add an include path for its own headers, include >>>>> paths for headers of one of its dependencies, and link against a bunch >>>>> of libraries? All covered by target properties. >>>>> If for some reason (e.g. handover to an external tool) you need those >>>>> properties, you can still query them. Under enforced names nonetheless, >>>>> unlike FOO_INCLUDE_DIR or was it FOO_INCLUDE_DIRS? >>>> >>>> Ack. The problem from the point of view of an automated tool which starts >>>> with a component called Foo arises ONLY because the target(s) of Foo are >>>> called FooFoo and FooBar. CMake does not - AFAICS - allow one to query Foo >>>> and somehow find FooFoo and FooBar inorder to look up FooFoo_INCLUDE_DIRS >>>> etc. >>>> >>>> >>>>>> I'm continuing to experiment with trying to build Python bindings for >>>>>> KF5. As part of that, the SIP tooling creates C++ wrapper code which >>>>>> must be compiled for each framework, and for that I need to know the >>>>>> header file directories. So far, I have simply been hardcoding the >>>>>> needed paths on my own system, but I now want to move to using >>>>>> standard CMake-based logic instead. >>>>>> >>>>>> (In some sense, this might be seen as similar to the stuff that was >>>>>> added to ECM, but I'm trying for a significantly more automated >>>>>> approach). >>>>>> >>>>>> Also, I am trying to feel my way towards a Pythonic build system for >>>>>> the KF5 bindings (as, roughly speaking, PyQt seems to be doing): in >>>>>> other words I'm interested in using CMake as a stepping stone, not the >>>>>> actual build system. >>>>>> >>>>> I would recommend against that unless you really need to have heavy >>>>> logic in the build system. A build system's main job is to "solve" a >>>>> dependency tree - that is the difference between a build system and a >>>>> script that runs the compiler. The dependency tree enables cheap >>>>> incremental builds and correct parallel builds. Maybe not that important >>>>> for bindings, admittedly. >>>>> Your advantage from using Python must be larger than the overhead from >>>
Re: Application usage statistics and targeted user surveys
On Sun, Apr 23, 2017 at 12:52 PM, Volker Krause wrote: > Hi, > > we have talked about the above topics a couple of times in the past, from what > I remember usually agreeing it would be nice to have some more statistical > information about our users, so we know what our applications are used for, > and to measure impact of changes. Similarly, it would be nice to be able to > actually ask our users questions without statistical bias by using out-of-band > channels like blogs or social media. This can be obviously addressed by adding > this into application code, but that raises some valid privacy concerns. > > Wanting this for GammaRay I attempted to implement a generic framework for > this, with the goal to make this fully transparent, and give the user full > control over what data is shared, and how often they want to participate in > surveys, ie. make this solid enough on the privacy side that even I would > enable it myself. You'll find the code in Git (kde:kuserfeedback). > > Feature-wise it so far contains: > - a set of built-in data sources (app version, Qt version, platform, > application usage time, screen setup, etc) that applications can choose to > enable > - generic data sources for tracking the time ratio a Q_PROPERTY has a specific > value, allowing to track e.g. which application view is used how much > - the ability to add custom/application-specific data sources > - reference widgets for customizing what data you want to share, and showing > exactly what that means, in human readable translated text and if you insists > also all the way down to the raw JSON sent to the server. > - survey targeting using simple C++/JS-like expressions that can access all > the data sources (ie. you can target e.g. only users with high DPI multi- > screen setups) > - configurable encouragement of users to contribute (ie. after X starts and/or > Y hours of usage, repeated after Z months, suggest the user to participate if > they aren't already doing so). > - a management and analytic tool that allows you to manage products and survey > campaigns, and view recorded data using configurable aggregations > - the entire thing works without unique user ids. Fingerprinting can still be > an issue on too small user sets and/or when using too much detail in the data. > - by default all of this is opt-in of course, although technically the API > doesn't prevent applications to change this > - it can deal with multiple products, each product can have different data > sources and survey campaigns > > Technically, this consists of the following parts: > - a library that goes into the target application, backward compatible all the > way to Qt4.8/MSVC2010 (needed for my GammaRay use-case), depending only on > QtGui > - a library with the reference widgets, also with extended backward > compatibility > - the server, written in PHP5 and supporting sqlite/mysql/postgresql. Not the > most fun technology, but that stuff is available almost anywhere, and easy to > deploy and maintain > - the management tool, recent Qt5/recent C++, using QtCharts for the data > analysis > - a command line tool for data import/export, useful for eg. automated backups > > All of this is LGPLv2+ licensed. > > Feedback obviously very welcome, in particular around privacy concerns, or > reasons that would make you enable/disable such a feature. > > Regards, > Volker Hi volker, I've been looking into how it works, I wanted to test the tests/orwell application but I keep getting this error: ./bin/orwell: symbol lookup error: ./bin/orwell: undefined symbol: _ZN12UserFeedback18CompilerInfoSourceC1Ev I'm seeing a similar error when running autotests: * Start testing of DataSourceTest * Config: Using QtTest library 5.9.0, Qt 5.9.0 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 6.3.1 20170306) PASS : DataSourceTest::initTestCase() PASS : DataSourceTest::testPlatformInfoSource() PASS : DataSourceTest::testScreenInfoSource() PASS : DataSourceTest::testPropertyRatioSource() PASS : DataSourceTest::testMultiPropertyRatioSource() PASS : DataSourceTest::testApplicationVersionSource() PASS : DataSourceTest::testQtVersionSource() PASS : DataSourceTest::testStartCountSource() PASS : DataSourceTest::testUsageTimeSource() PASS : DataSourceTest::testCpuInfoSource() PASS : DataSourceTest::testLocaleInfoSource() ./bin/datasourcetest: symbol lookup error: ./bin/datasourcetest: undefined symbol: _ZN12UserFeedback16OpenGLInfoSourceC1Ev I would have looked into fixing it, but I'm not sure I understand why there's all the RPATH logic in place, so I'd prefer to hear from you first. A good next step would also be to get it running on build.kde.org, so we can identify these issues. Aleix
Re: Application usage statistics and targeted user surveys
On Tue, May 23, 2017 at 6:31 PM, Aleix Pol wrote: > On Sun, Apr 23, 2017 at 12:52 PM, Volker Krause wrote: >> Hi, >> >> we have talked about the above topics a couple of times in the past, from >> what >> I remember usually agreeing it would be nice to have some more statistical >> information about our users, so we know what our applications are used for, >> and to measure impact of changes. Similarly, it would be nice to be able to >> actually ask our users questions without statistical bias by using >> out-of-band >> channels like blogs or social media. This can be obviously addressed by >> adding >> this into application code, but that raises some valid privacy concerns. >> >> Wanting this for GammaRay I attempted to implement a generic framework for >> this, with the goal to make this fully transparent, and give the user full >> control over what data is shared, and how often they want to participate in >> surveys, ie. make this solid enough on the privacy side that even I would >> enable it myself. You'll find the code in Git (kde:kuserfeedback). >> >> Feature-wise it so far contains: >> - a set of built-in data sources (app version, Qt version, platform, >> application usage time, screen setup, etc) that applications can choose to >> enable >> - generic data sources for tracking the time ratio a Q_PROPERTY has a >> specific >> value, allowing to track e.g. which application view is used how much >> - the ability to add custom/application-specific data sources >> - reference widgets for customizing what data you want to share, and showing >> exactly what that means, in human readable translated text and if you insists >> also all the way down to the raw JSON sent to the server. >> - survey targeting using simple C++/JS-like expressions that can access all >> the data sources (ie. you can target e.g. only users with high DPI multi- >> screen setups) >> - configurable encouragement of users to contribute (ie. after X starts >> and/or >> Y hours of usage, repeated after Z months, suggest the user to participate if >> they aren't already doing so). >> - a management and analytic tool that allows you to manage products and >> survey >> campaigns, and view recorded data using configurable aggregations >> - the entire thing works without unique user ids. Fingerprinting can still be >> an issue on too small user sets and/or when using too much detail in the >> data. >> - by default all of this is opt-in of course, although technically the API >> doesn't prevent applications to change this >> - it can deal with multiple products, each product can have different data >> sources and survey campaigns >> >> Technically, this consists of the following parts: >> - a library that goes into the target application, backward compatible all >> the >> way to Qt4.8/MSVC2010 (needed for my GammaRay use-case), depending only on >> QtGui >> - a library with the reference widgets, also with extended backward >> compatibility >> - the server, written in PHP5 and supporting sqlite/mysql/postgresql. Not the >> most fun technology, but that stuff is available almost anywhere, and easy to >> deploy and maintain >> - the management tool, recent Qt5/recent C++, using QtCharts for the data >> analysis >> - a command line tool for data import/export, useful for eg. automated >> backups >> >> All of this is LGPLv2+ licensed. >> >> Feedback obviously very welcome, in particular around privacy concerns, or >> reasons that would make you enable/disable such a feature. >> >> Regards, >> Volker > > Hi volker, > I've been looking into how it works, I wanted to test the tests/orwell > application but I keep getting this error: > ./bin/orwell: symbol lookup error: ./bin/orwell: undefined symbol: > _ZN12UserFeedback18CompilerInfoSourceC1Ev > > I'm seeing a similar error when running autotests: > * Start testing of DataSourceTest * > Config: Using QtTest library 5.9.0, Qt 5.9.0 > (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC > 6.3.1 20170306) > PASS : DataSourceTest::initTestCase() > PASS : DataSourceTest::testPlatformInfoSource() > PASS : DataSourceTest::testScreenInfoSource() > PASS : DataSourceTest::testPropertyRatioSource() > PASS : DataSourceTest::testMultiPropertyRatioSource() > PASS : DataSourceTest::testApplicationVersionSource() > PASS : DataSourceTest::testQtVersionSource() > PASS : DataSourceTest::testStartCountSource() > PASS : DataSourceTest::testUsageTimeSource
Re: Application usage statistics and targeted user surveys
On Sat, Jun 3, 2017 at 11:49 AM, Volker Krause wrote: > On Thursday, 25 May 2017 12:33:49 CEST Volker Krause wrote: >> On Tuesday, 23 May 2017 18:31:35 CEST Aleix Pol wrote: >> > I would have looked into fixing it, but I'm not sure I understand why >> > there's all the RPATH logic in place, so I'd prefer to hear from you >> > first. >> >> I have removed the remains of the pre-ECM rpath handling. This also changed >> binary output directories on Linux to follow KDE standards, so you might >> want to do a clean build to avoid issues with outdated binaries in the >> build dir. >> > A good next step would also be to get it running on build.kde.org, so >> > we can identify these issues. >> >> Indeed, I've requested CI coverage now. > > Looks like in order to get CI coverage we need to move to kdereview (which is > fine, I think it's ready for that), but that requires to know where this > should end up afterwards. > > I guess the candidates are extragear/libs or frameworks? frameworks seems > conceptually like the right place, but putting something there that is still > fairly new and has seen little field testing seems sub-optimal. Opinions? +1 Since we're still introducing it to projects maybe it could make sense to have a couple of releases with it in extragear so people will be less angry if we needed to break ABI (it's what we did for kirigami, and I'd say it's worked reasonably well). At Akademy we can discuss to get it in frameworks if it works for everyone? Aleix
Re: zanshin for kdereview
On Sat, Jun 3, 2017 at 9:01 AM, Kevin Ottens wrote: > Hello, > > Zanshin has been around for a while and I should have requested it to move to > Extragear a long time ago but somehow forgot. The discussion regarding the > next gen CI reminded me of that. > > I hereby request Zanshin to be moved out of playground and into kdereview so > that it gets the usual review period. The aim is to have in in extragear/pim > in the end. Hi Kevin, I'm pretty sure moving to kdereview is something to ask to sysadmin. https://phabricator.kde.org/u/systickets Then once it's there you request the move here saying it's in kdereview, waiting to go to extragear/pim. Aleix PS: ah, bureaucracy! :D
Re: Application usage statistics and targeted user surveys
On Thu, May 25, 2017 at 4:42 PM, Volker Krause wrote: > On Wednesday, 24 May 2017 17:38:22 CEST Aleix Pol wrote: >> On Tue, May 23, 2017 at 6:31 PM, Aleix Pol wrote: >> Hey Volker, I figured out this one. Never mind. >> >> I've done a proof of concept integrating it in Discover, here's 2 patches: >> https://phabricator.kde.org/D5960 >> https://phabricator.kde.org/D5961 > > There's still two aspects missing in the integration: > - configure Provider to actually submit (see productIdentifier, feedbackServer > and submissionInterval properties) > - probably add some data sources (in the current form you only get an > indication on how many users you have, and untargeted surveys, nothing more) > > The second point will need some more QML wrapper API. I'll look into adding a > QML plugin to KUserFeedback directly for this. > >> Now to proceed I'd like to give a try to whole system including the >> server. Do you have documented how to set it up anywhere? Would make >> it easier. > > INSTALL contains the deployment documentation, both for the full setup with > authentication on an Apache server, and locally for unsecured testing using > the built-in PHP server. > > I've also got a playground server on my own infrastructure now that I can > provide accounts for. And Jan has published his ongoing work on creating a > Docker image for the server here: https://github.com/KDAB/kuserfeedbackdocker > > Regards, > Volker Hi Volker, More noob feedback: I set up a local system I could tinkle with using your colleague's docker. Worked quite well. But, I was getting an issue, possibly fixed by this patch: https://phabricator.kde.org/D6117 Now I get to see things being sent on the UserFeedbackConsole application, but I only see timestamps. I added debug information to see what is being sent and (after updating the discover patch above) and I see all sort of data, being delivered. Is it being lost in the internets? Or am I not looking into it correctly? If I export the product using UserFeedbackConsole I also only get timestamps :(. HTH, Aleix
Re: Plasma Browser Integration is in kdereview
On Mon, Jun 5, 2017 at 4:42 PM, David Edmundson wrote: > Hey all, > > We'd like to add project plasma-browser-integration into KDE[0]. > > The goal is to make chrome and firefox integrate better into a Plasma > desktop environment through browser extensions. > > How?: > Firefox and chrome (and potentially others) allow plugins to talk to a > native binary host [1]. This binary host is launched by the the browser and > has a socket to a conventional browser extension. This project consists of > both parts allowing a chrome extension to make normal DBus calls to services > just like other apps. > > Integrating what?: > This gives us the following features: > - Finding open tabs via krunner > - Download progress in the task bar > - Showing now playing information with shortcuts (if the website supports > it) > - "Send to KDE Connect" context menu on links > - Loading windows on the correct activity (WIP) > - An SNI if incognito windows are open with action to close them. > > And potentially more in the future. There is a config to enable/disable > parts as appropriate. > > Deployment: > This repo consists of two parts. The binary host which should be > distributed by normal distro means, and the browser extension which is going > to be different. > > The browser extension can be deployed in one of 3 ways. > - manually by the user from the code (useful for devs) > > - through the webstore [2][3] > - chrome also has a feature where we can ship a text file on the distro > side that will make the browser automatically fetch an extension from their > store. > > Ideally we want the extension available on the store from an official KDE > channel. > > - potentially it could also be done by the distro, but it seems like FF > might be removing that possibility and the digital signing is an issue. > > [0] https://cgit.kde.org/plasma-browser-integration.git/ > [1] https://developer.chrome.com/extensions/nativeMessaging > [2] > https://chrome.google.com/webstore/detail/plasma-integration/cimiefiiaegbelhefglklhhakcgmhkai > [3] > https://addons.mozilla.org/en-US/android/addon/plasma-integration/?src=cb-dl-updated > > Regards > > David and Kai General +1 to the features. Really awesome. :) Do we have any documentation on how to test it? Aleix
Re: Plasma Browser Integration is in kdereview
On Wed, Jun 7, 2017 at 12:23 AM, David Edmundson wrote: > Install the host part with the normal cmake && make. > The bit that tries to install into /etc/ does need to go into /etc > > Easiest thing then is to then install the extension part from one of the > links in my original email. Yes, you are right, it's pretty easy. That said, a wiki or a README.md would be nice too. I'm having a crash on Chrome [1], on Chromium it's working perfectly fine though. Impressive! Aleix [1] https://bugs.kde.org/show_bug.cgi?id=380186
Re: Application usage statistics and targeted user surveys
On Thu, Jun 8, 2017 at 12:27 AM, Albert Astals Cid wrote: > El dissabte, 3 de juny de 2017, a les 11:49:00 CEST, Volker Krause va > escriure: >> On Thursday, 25 May 2017 12:33:49 CEST Volker Krause wrote: >> > On Tuesday, 23 May 2017 18:31:35 CEST Aleix Pol wrote: >> > > I would have looked into fixing it, but I'm not sure I understand why >> > > there's all the RPATH logic in place, so I'd prefer to hear from you >> > > first. >> > >> > I have removed the remains of the pre-ECM rpath handling. This also >> > changed >> > binary output directories on Linux to follow KDE standards, so you might >> > want to do a clean build to avoid issues with outdated binaries in the >> > build dir. >> > >> > > A good next step would also be to get it running on build.kde.org, so >> > > we can identify these issues. >> > >> > Indeed, I've requested CI coverage now. >> >> Looks like in order to get CI coverage we need to move to kdereview (which >> is fine, I think it's ready for that), but that requires to know where this >> should end up afterwards. >> >> I guess the candidates are extragear/libs or frameworks? frameworks seems >> conceptually like the right place, but putting something there that is still >> fairly new and has seen little field testing seems sub-optimal. Opinions? > > To me it seems a few releases from extragear would make sense before moving to > frameworks and promise full API/ABI compatibility. > > OTOH when moving from extreagear to frameworks we may have to rename library > (to have the KF5 suffix) which would break also API (at least at the cmake > level). > > How do people feel having libs in extreager having the KF5 "cmake naming" in > the understanding that we're stabilizing them to be part of frameworks > eventually? IMO it's a bit weird and unsettling. But then, we're already doing it for many pim libraries (not in extragear but in applications, still not part of KF5). Aleix
Re: Application usage statistics and targeted user surveys
On Sat, Jun 10, 2017 at 10:22 AM, Volker Krause wrote:
> On Tuesday, 6 June 2017 15:01:57 CEST Aleix Pol wrote:
>> On Thu, May 25, 2017 at 4:42 PM, Volker Krause wrote:
>> > On Wednesday, 24 May 2017 17:38:22 CEST Aleix Pol wrote:
>> >> On Tue, May 23, 2017 at 6:31 PM, Aleix Pol wrote:
>> >> Hey Volker, I figured out this one. Never mind.
>> >>
>> >> I've done a proof of concept integrating it in Discover, here's 2
>> >> patches:
>> >> https://phabricator.kde.org/D5960
>> >> https://phabricator.kde.org/D5961
>> >
>> > There's still two aspects missing in the integration:
>> > - configure Provider to actually submit (see productIdentifier,
>> > feedbackServer and submissionInterval properties)
>> > - probably add some data sources (in the current form you only get an
>> > indication on how many users you have, and untargeted surveys, nothing
>> > more)
>> >
>> > The second point will need some more QML wrapper API. I'll look into
>> > adding a QML plugin to KUserFeedback directly for this.
>> >
>> >> Now to proceed I'd like to give a try to whole system including the
>> >> server. Do you have documented how to set it up anywhere? Would make
>> >> it easier.
>> >
>> > INSTALL contains the deployment documentation, both for the full setup
>> > with
>> > authentication on an Apache server, and locally for unsecured testing
>> > using
>> > the built-in PHP server.
>> >
>> > I've also got a playground server on my own infrastructure now that I can
>> > provide accounts for. And Jan has published his ongoing work on creating a
>> > Docker image for the server here:
>> > https://github.com/KDAB/kuserfeedbackdocker
>> >
>> > Regards,
>> > Volker
>>
>> Hi Volker,
>> More noob feedback:
>> I set up a local system I could tinkle with using your colleague's
>> docker. Worked quite well. But, I was getting an issue, possibly fixed
>> by this patch:
>> https://phabricator.kde.org/D6117
>
> This looks good, I'll try to get that path unit-tested to make sure this works
> with sqlite too. However, you should not actually hit this path in the first
> place, which is probably also why you are not seeing any data.
>
>> Now I get to see things being sent on the UserFeedbackConsole
>> application, but I only see timestamps. I added debug information to
>> see what is being sent and (after updating the discover patch above)
>> and I see all sort of data, being delivered. Is it being lost in the
>> internets? Or am I not looking into it correctly? If I export the
>> product using UserFeedbackConsole I also only get timestamps :(.
>
> Do you see the empty columns for the other data in UserFeedbackConsole, or do
> you only see the Timestamp column? In the former case the data is either not
> transmitted, or rejected by the server for some reason, we'd need to look at
> the JSON payload sent to the server in that case. In the other case, you
> probably need to set up a product schema first with UserFeedbackConsole
> (easiest via Schema -> Source Templates in the Schema view).
Here's what I'm seeing: https://imgur.com/a/BmH2B
I've seen the schema view, I haven't pushed it much. I see I can add
stuff but I'm not sure what it's for. I expected the system to
integrate all data offered, but maybe I need to set the expectations
on the server side?
Either way, this is the information being sent at the moment (I copied
your orwell.qml example sources so far).
{
"applicationVersion": { "value": "5.10.90" },
"compiler": { "type": "Clang", "version": "4.0" },
"platform": { "os": "linux", "version": "arch-unknown" },
"qtVersion": { "value": "5.9.0" },
"startCount": { "value": 76 },
"usageTime": { "value": 34132 }
}
> I'll also try your Discover patches here to see if I can reproduce this, the
> QML bindings haven't gotten any real use yet, quite possible some stuff
> doesn't work there correctly yet.
I'll update the patch to adapt to changes in kuserfeedback.
Aleix
Re: Application usage statistics and targeted user surveys
On Tue, Jun 13, 2017 at 6:56 PM, Volker Krause wrote: > On Monday, 12 June 2017 01:56:21 CEST Aleix Pol wrote: >> On Sat, Jun 10, 2017 at 10:22 AM, Volker Krause wrote: >> > On Tuesday, 6 June 2017 15:01:57 CEST Aleix Pol wrote: >> >> On Thu, May 25, 2017 at 4:42 PM, Volker Krause wrote: >> >> > On Wednesday, 24 May 2017 17:38:22 CEST Aleix Pol wrote: >> >> >> On Tue, May 23, 2017 at 6:31 PM, Aleix Pol wrote: >> >> >> Hey Volker, I figured out this one. Never mind. >> >> >> >> >> >> I've done a proof of concept integrating it in Discover, here's 2 >> >> >> patches: >> >> >> https://phabricator.kde.org/D5960 >> >> >> https://phabricator.kde.org/D5961 >> >> > >> >> > There's still two aspects missing in the integration: >> >> > - configure Provider to actually submit (see productIdentifier, >> >> > feedbackServer and submissionInterval properties) >> >> > - probably add some data sources (in the current form you only get an >> >> > indication on how many users you have, and untargeted surveys, nothing >> >> > more) >> >> > >> >> > The second point will need some more QML wrapper API. I'll look into >> >> > adding a QML plugin to KUserFeedback directly for this. >> >> > >> >> >> Now to proceed I'd like to give a try to whole system including the >> >> >> server. Do you have documented how to set it up anywhere? Would make >> >> >> it easier. >> >> > >> >> > INSTALL contains the deployment documentation, both for the full setup >> >> > with >> >> > authentication on an Apache server, and locally for unsecured testing >> >> > using >> >> > the built-in PHP server. >> >> > >> >> > I've also got a playground server on my own infrastructure now that I >> >> > can >> >> > provide accounts for. And Jan has published his ongoing work on >> >> > creating a >> >> > Docker image for the server here: >> >> > https://github.com/KDAB/kuserfeedbackdocker >> >> > >> >> > Regards, >> >> > Volker >> >> >> >> Hi Volker, >> >> More noob feedback: >> >> I set up a local system I could tinkle with using your colleague's >> >> docker. Worked quite well. But, I was getting an issue, possibly fixed >> >> by this patch: >> >> https://phabricator.kde.org/D6117 >> > >> > This looks good, I'll try to get that path unit-tested to make sure this >> > works with sqlite too. However, you should not actually hit this path in >> > the first place, which is probably also why you are not seeing any data. >> > >> >> Now I get to see things being sent on the UserFeedbackConsole >> >> application, but I only see timestamps. I added debug information to >> >> see what is being sent and (after updating the discover patch above) >> >> and I see all sort of data, being delivered. Is it being lost in the >> >> internets? Or am I not looking into it correctly? If I export the >> >> product using UserFeedbackConsole I also only get timestamps :(. >> > >> > Do you see the empty columns for the other data in UserFeedbackConsole, or >> > do you only see the Timestamp column? In the former case the data is >> > either not transmitted, or rejected by the server for some reason, we'd >> > need to look at the JSON payload sent to the server in that case. In the >> > other case, you probably need to set up a product schema first with >> > UserFeedbackConsole (easiest via Schema -> Source Templates in the Schema >> > view). >> >> Here's what I'm seeing: https://imgur.com/a/BmH2B >> I've seen the schema view, I haven't pushed it much. I see I can add >> stuff but I'm not sure what it's for. I expected the system to >> integrate all data offered, but maybe I need to set the expectations >> on the server side? > > Yes, exactly, that's what the schema does. Easiest way to get started is > probably to just import the orwell example schema there, that contains all > existing data sources, or you just create sources from their corresponding > templates. > > That is, in the schema view chose schema -> import schema... or schema -> >
Re: Application usage statistics and targeted user surveys
On Thu, Jun 15, 2017 at 10:22 PM, Ben Cooksley wrote: > On Fri, Jun 16, 2017 at 1:42 AM, Aleix Pol wrote: >> On Tue, Jun 13, 2017 at 6:56 PM, Volker Krause wrote: >>> On Monday, 12 June 2017 01:56:21 CEST Aleix Pol wrote: >>>> On Sat, Jun 10, 2017 at 10:22 AM, Volker Krause wrote: >>>> > On Tuesday, 6 June 2017 15:01:57 CEST Aleix Pol wrote: >>>> >> On Thu, May 25, 2017 at 4:42 PM, Volker Krause wrote: >>>> >> > On Wednesday, 24 May 2017 17:38:22 CEST Aleix Pol wrote: >>>> >> >> On Tue, May 23, 2017 at 6:31 PM, Aleix Pol wrote: >>>> >> >> Hey Volker, I figured out this one. Never mind. >>>> >> >> >>>> >> >> I've done a proof of concept integrating it in Discover, here's 2 >>>> >> >> patches: >>>> >> >> https://phabricator.kde.org/D5960 >>>> >> >> https://phabricator.kde.org/D5961 >>>> >> > >>>> >> > There's still two aspects missing in the integration: >>>> >> > - configure Provider to actually submit (see productIdentifier, >>>> >> > feedbackServer and submissionInterval properties) >>>> >> > - probably add some data sources (in the current form you only get an >>>> >> > indication on how many users you have, and untargeted surveys, nothing >>>> >> > more) >>>> >> > >>>> >> > The second point will need some more QML wrapper API. I'll look into >>>> >> > adding a QML plugin to KUserFeedback directly for this. >>>> >> > >>>> >> >> Now to proceed I'd like to give a try to whole system including the >>>> >> >> server. Do you have documented how to set it up anywhere? Would make >>>> >> >> it easier. >>>> >> > >>>> >> > INSTALL contains the deployment documentation, both for the full setup >>>> >> > with >>>> >> > authentication on an Apache server, and locally for unsecured testing >>>> >> > using >>>> >> > the built-in PHP server. >>>> >> > >>>> >> > I've also got a playground server on my own infrastructure now that I >>>> >> > can >>>> >> > provide accounts for. And Jan has published his ongoing work on >>>> >> > creating a >>>> >> > Docker image for the server here: >>>> >> > https://github.com/KDAB/kuserfeedbackdocker >>>> >> > >>>> >> > Regards, >>>> >> > Volker >>>> >> >>>> >> Hi Volker, >>>> >> More noob feedback: >>>> >> I set up a local system I could tinkle with using your colleague's >>>> >> docker. Worked quite well. But, I was getting an issue, possibly fixed >>>> >> by this patch: >>>> >> https://phabricator.kde.org/D6117 >>>> > >>>> > This looks good, I'll try to get that path unit-tested to make sure this >>>> > works with sqlite too. However, you should not actually hit this path in >>>> > the first place, which is probably also why you are not seeing any data. >>>> > >>>> >> Now I get to see things being sent on the UserFeedbackConsole >>>> >> application, but I only see timestamps. I added debug information to >>>> >> see what is being sent and (after updating the discover patch above) >>>> >> and I see all sort of data, being delivered. Is it being lost in the >>>> >> internets? Or am I not looking into it correctly? If I export the >>>> >> product using UserFeedbackConsole I also only get timestamps :(. >>>> > >>>> > Do you see the empty columns for the other data in UserFeedbackConsole, >>>> > or >>>> > do you only see the Timestamp column? In the former case the data is >>>> > either not transmitted, or rejected by the server for some reason, we'd >>>> > need to look at the JSON payload sent to the server in that case. In the >>>> > other case, you probably need to set up a product schema first with >>>> > UserFeedbackConsole (easiest via Schema -> Source Templates in the Schema >>>> > view). >>>> >>&g
Re: Plasma Browser Integration is in kdereview
On Tue, Jul 11, 2017 at 1:08 AM, David Edmundson wrote: > Do you know if you can me it be a bit more quiet and only output errors on >> >> failure? > > > I changed that a few weeks ago, I assume it's fine now? > > > If there are no complaints I'll move this to Plasma. +1 \o/ Aleix
Re: liquidshell in kdereview
On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller wrote: > Hi all, > > I'd like to announce an application I've implemented over the last few weeks > - liquidshell > > liquidshell is a replacement for plasmashell > > It does not use QtQuick but instead relies on QtWidgets, > therefore no hardware graphics acceleration is needed. > > Main Features: > - Wallpaper per virtual desktop > - No animations, no CPU hogging, low Memory footprint > - Instant startup > - No use of activities (I never used nor needed them) > - QtWidgets based, therefore follows widget style from systemsettings > - Icons are used from your globally defined icon theme from systemsettings > - Colors are used from your globally defined color theme from systemsettings > - Can additionally be styled with css by passing the commandline option > -stylesheet filename.css > (see included example stylesheet.css) > - uses existing KDE dialogs for most configurations, e.g. StartMenu, Virtual > Desktops, Bluetooth, Network > - Just one bottom DesktopPanel, containing: > StartMenu (allowing drag of entries into konqueror/dolphin to configure > QuickLaunch or AppMenu entries) > QuickLaunch (showing icons for .desktop files from a configurable folder) > AppMenu (showing .desktop files in a menu from a configurable folder, > defaults to users desktop folder) > Pager (for switching virtual desktops) > WindowList (Popup showing all open windows on all desktops) > TaskBar (showing windows on the current desktop, allowing drag of an entry > onto the Pager to move to a different desktop) > LockLogout > SysLoad widget including CPU, Memory, Swap and Network bars, live updated > tooltip > SysTray with integrated Network-, Notifications-, Device Notifier-, > Bluetooth-, Battery- display. > Display of StatusNotifier items from other applications (no legacy > embedded icons yet). > Notifications kept in a history list for some minutes, including > timestamp and text selectable per mouse > (very handy for copy/paste of TAC numbers from online banking received > via SMS and transferred to KDE >via kdeconnect) > Clock widget (with calendar popup, tooltip for selected cities) > - Desktop can contain applets (there's currently only a weather applet) > > The main motivation was to have a reliable desktop shell which does not hog > the CPU or RAM. > (CPU usage and stability were the things driving me mad with plasmashell) > It should be slick and have just the features I need in my daily > work. No need having all the bells and whistles anyone can think of. > Just have a plain, solid, fast workhorse. > > I think the final place should be extragear. > > Today I put it into openSuse's OBS and 2 packages for tumbleweed and factory > are already in place > and ready to be installed. > > Screenshots: > light color theme: > http://members.aon.at/m.koller/liquidshell_20171103_174650.png > dark color theme: > http://members.aon.at/m.koller/liquidshell_20171103_174944.png > > -- > Best regards/Schöne Grüße > > Martin > A: Because it breaks the logical sequence of discussion > Q: Why is top posting bad? > > () ascii ribbon campaign - against html e-mail > /\- against proprietary attachments > > Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at > > Hi Martin, I'm a bit confused, who is liquidshell for? Aleix
Re: Importing kdiff3 - was - Re: Aw: Re: KDE inclusion
Hi Michael, If you are interested in having the incubation happen, please get in touch. I'll be glad to help. Aleix On Wed, Jan 17, 2018 at 9:40 PM, Michael Reeves wrote: > Yes I use this myself so I won't simply abandon it. That said I work in > mostly in Unix world and could use help with the windows specific testing > although I should be able to setup a build envirionment to do basic > functionality testing. I'll have look at what needs done. Currently working > on getting merging in changes from Thomas as needed. Just got through > bringing it up to date with Joachim's code. Real fun since it's still kde4. > > > On Jan 15, 2018 5:47 PM, "Albert Astals Cid" wrote: > > El dimarts, 9 de gener de 2018, a les 20:06:36 CET, Michael Reeves va > escriure: >> I have a version of kdiff3 that I ported to kf5. I like to what build >> requirements kf5 as a whole has. Also what would be the process for being >> considered for inclusion in kde? > > So now that we have Joachim's blessing to use the name, the process is > basically outlined at https://community.kde.org/Incubator/Incubation_Process > but it's basically importing the project into our git and then making sure > it > generally follows our rules & procedures. > > I understand you want to continue maintaining the new kdiff3 and you are not > just "dumping it" into us, right? > > > Cheers, > Albert > > El divendres, 12 de gener de 2018, a les 1:21:02 CET, Joachim Eibl va > escriure: >> Hi, > >> You have my blessing to use the name KDiff3. > >
Re: Installing qml caches
On Fri, Jun 1, 2018 at 1:10 PM, Alexander Volkov wrote:
> Hi all,
>
> It would be nice to install .qmlc files in addition to .qml files to reduce
> start-up time of applications.
> They are generated with qmlcachegen. For Qt 5.11:
> qmlcachegen -o example.qmlc qxample.qml
>
> Currently qml files are usually installed the following way:
> install(DIRECTORY qml/ DESTINATION ${KDE_INSTALL_QMLDIR}/org/kde/kcm)
>
> So this could be changed to something like
> ecm_install_qml(qml org/kde/kcm)
>
> I wonder whether someone already working on this or want to implement such a
> function?
> If not, I'll try to do it myself.
>
> Cheers,
> Alexander.
>
I'm not sure this makes sense, as far as I know it's not a
binary-compatible format, so distros would have to recompile every
application with qmlc files upon Qt update.
Aleix
Re: Kde CI setup
On Mon, May 14, 2018 at 8:19 PM, Michael Reeves wrote: > How does one use kde's ci system? Is there a way to test a projects setup > before going live with it? Hi Michael, Define "going live with it". You can run your project locally using the same images the CI will for linux, but then the CI will also do other OS and configurations. If you're concerned with adding it and getting a red light. Don't worry, just get your project on the CI and if there's any issues, you can investigate and fix them. That's what the CI is for. :) Aleix
Re: Adding Kirigami Gallery to kde-sdk
On Mon, Jun 18, 2018 at 12:21 PM Marco Martin wrote: > > Hi all, > in the kirigami framework repo, there is a little gallery application which > outgrew the point of being a small example. > It's now becoming a tutorial app: on each page an example and documentation on > how to use a particular component and when with links on the relevant source > code and HIG page about such component (if available) becoming a developing > aide while writing a Kirigami application. > > Also, since it's planned to add more graphics and heavy media files, makes it > not particularly ideal to still use the framework repository. > If no objections, it will be moved as a standalone repo as part of kde-sdk as > developing aide. > > -- > Marco Martin +1 makes sense to me. Aleix
Re: Move pulseaudio-qt to Extragear
On Sun, Nov 4, 2018 at 5:43 PM Nicolas Fella wrote: > > Hi, > > together with David Rosca and Aleix Pol I have worked on extracting the > libpulse abstraction from plasma-pa into a library [0][1]. It is > currently optionally required by KDE Connect. plasma-pa and > libtaskmanager will use it at some point in the future. Long-term plan > is to move it to Frameworks, but until the required documentation and > testing is done I'd like to move it to Extragear and make an initial > release. > > Cheers > > Nicolas > > [0] https://phabricator.kde.org/T7994 > > [1] https://cgit.kde.org/pulseaudio-qt.git > +1
Re: Fwd: Kexi_flatpax fix and question
On Sat, Jan 26, 2019 at 1:43 AM Albert Astals Cid wrote: > As far as i know: > * The infrastructure we have at this point in KDE is more targeted to > provide nightlies. > * If you want to provide stable flatpak, the current recommended solution > is do it via flathub (like we do for several of our apps already). > > Cheers, > Albert > > El dijous, 24 de gener de 2019, a les 11:17:06 CET, Jaroslaw Staniek va > escriure: > > Hi > > Can anyone approve it or confirm we can ship flatpacks for (stable) KDE > > software? > > We're close to release and Aleix seems to be silent. > > > > > > -- Forwarded message - > > From: Jaroslaw Staniek > > Date: Wed, 23 Jan 2019 at 11:40 > > Subject: Kexi_flatpax fix and question > > To: Aleix Pol > > > > > > Hello Aleix! > > > > I'd like to ask for a review: https://phabricator.kde.org/T10377 > > .and have actual problem with lack of the stable software flatpacks (e.g. > > for KEXI it's 3.2 now). More than nigtly unstables me and I guess some > > other projects need stable flatpack packages to address the release > problem > > on Linux. What can we do to have them? We have resources for that. > > Thanks. > > > > > > > > > Sorry I was AFK. I'll reply in the phabricator ticket. Aleix
Re: freedesktop.org meeting again?
On Sat, Feb 9, 2019 at 1:32 PM David Faure wrote: > Is anyone interested in participating in a technical meeting with other > desktop environments? > > I did that years ago and this is how we came up with various shared > specifications, but at this point it might be more useful for people > working > on other things to attend. > > Cheers, > David. > > -- Forwarded Message -- > > Subject: freedesktop.org meeting again? > Date: mercredi 6 février 2019, 15:27:32 CET > From: Agustin Benito Bethencourt > To: Lennart Poettering , David Faure < > fa...@kde.org>, > de...@desrt.ca > > Dear Allison, David and Lennart, > > this mail has as a goal to evaluate the interest you would have in meeting > again like you guys did in 2013 and 2014 in Nuremberg, Germany, hosted > again > by SUSE, this time during the openSUSE Conference[1], that will take > place > from May 24th to May 26th. > > If the dates, location matches your availability and there is interest in > having this working sessions, I would be happy to coordinate the logistics > and > invite those who you think it should be present.. SUSE and openSUSE > representatives are very interested in hosting this activity once again. > > What do you think? Who else should be at the event? > > [1] https://events.opensuse.org/conference/oSC19 > > It could be an interesting event to have indeed. Maybe it would make sense to piggy-back on something more on-topic like XDC or LAS? Or is SUSE especially interested? Aleix
Re: Kdiff3 renovation
On Thu, May 9, 2019 at 5:19 PM Michael Reeves wrote: > > > Just a heads up kdiff3 is about to go through some major renovation. > Currently file processing is extremely in efficient. Hi Michael, I guess you meant "inefficient"? ^^' Good luck and don't forget to add lots of tests! :) Aleix
We can't properly parse standard Desktop files
Hey, Last week I was debugging an issue where I realised that we were not splitting properly a StringList field in a desktop file coming from Flatpak. I notice then that we are using a coma to split desktop files instead of a ; as the standard requests. The multiple values should be separated by a semicolon and the value of the key may be optionally terminated by a semicolon. Trailing empty strings must always be terminated with a semicolon. Semicolons in these values need to be escaped using \;. https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html I suggested this patch, I'm not sure it's the best we can do given we'll have to deal with quite a bit of legacy code but I'd say it's the right thing to do. https://phabricator.kde.org/D23381 Any thoughts? Aleix
Re: Proposing Quick Charts as a new framework
On Thu, Sep 5, 2019 at 10:53 PM Arjen Hiemstra wrote: > > On 02-09-2019 19:26, Luigi Toscano wrote: > > Arjen Hiemstra ha scritto: > >> Hi, > >> > >> I have been working on a library the past few months that provides a > >> QtQuick > >> module for rendering gpu-accelerated charts. It currently lives in a > >> playground > >> repository, here: https://invent.kde.org/kde/kf5quickcharts . I would > >> like for > >> this library to be included as a Tier 1 Framework. > > > > Hi, > > I've noticed that some time ago (I didn't enable the translations yet, > > but > > maybe it's not needed). > > There are only user-visible strings in the example application. I > haven't marked them > to be translated since it is only an example. > > > I have a question and a comment: > > > > - what is the difference between this one and the existing > > kqtquickcharts, > > part of the KDE Applications bundle, from the KDEEdu project? At least > > their > > description overlaps. Is there any transition path? Having two > > duplicate > > libraries with the exact same goal may not be the best scenario. > > The main difference is in the rendering methods: kqtquickcharts uses > QPainter for > rendering, Quick Charts uses a technique called Signed Distance Fields > to render > certain charts with GPU acceleration and others use pure QtQuick > scenegraph. I > don't know if it would have been possible to retrofit that on to > kqtquickcharts, > but my guess is it would have been a major overhaul of that library > anyway. > > An additional issue is that kqtquickcharts seems to be unmaintained, > with the last > major feature work having been done several years ago. So my personal > opinion is > that when Quick Charts is accepted as part of Frameworks, we deprecate > kqtquickcharts as well as some other bits like the plotter item from > kdeclarative. Does it really have the same features? Otherwise it doesn't make sense to deprecate anything. It will just frustrate the users of the framework. > > - I don't think that "5" should be part of the name; in two years from > > now we > > may have a Frameworks 6, and having a kf5quickchart as part of it may > > be > > confusing. > > That's actually a good point, though the kf5 is only in the repository > name, I > name it "Quick Charts" everywhere else. Which is probably a good reason > to have > the repo name changed in the first place. :) Originally, I put kf5 in > the repo > name because that's what is used once installed as part of Frameworks, > but I > agree that it can lead to confusing things. It should be called kquickchart (which indeed is far too similar to kqtquickcharts). Much like you use KF5CoreAddons, but the repository is called kcoreaddons. Aleix
Re: Taking over maintainership of the kaccounts-* repos
On Fri, Sep 13, 2019 at 10:35 AM Bhushan Shah wrote: > > Hello! > > At akademy we talked about the KAccounts and realized that kaccounts is > unmaintained and/or Martin is not active. > > So I propose to take over maintainership of the following repositories. > > - kaccounts-integration > - kaccounts-providers > - kaccounts-mobile > > If you have any concerns/objections with this, let me know. > > Thanks > > -- > Bhushan Shah > http://blog.bshah.in > IRC Nick : bshah on Freenode > GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D :) thanks Bhushan! Aleix
Re: Update on Status of Gitlab Migration
On Mon, Apr 13, 2020 at 8:30 PM Ben Cooksley wrote: > > On Tue, Apr 14, 2020 at 3:35 AM Nate Graham wrote: > > > > On 4/13/20 4:44 AM, Albert Vaca Cintora wrote: > > > Regarding this: is the subdomain going to stay invent.kde.org once we > > > have officially moved? I find it's a bit confusing to use that instead > > > of gitlab.kde.org > > > > I agree. gitlab.kde.org would make more sense to me, mirroring > > phabricator.kde.org. > > > > There is no intention to change the name from invent.kde.org. > > We have a long precedent of not using the name of the software for the > name in DNS, and Gitlab is continuing with this, for example: > - bugs.kde.org is run by Bugzilla > - dot.kde.org is run by Drupal > - techbase.kde.org is run by Mediawiki > - conf.kde.org is run by Frab > - reimbursements.kde.org is run by travel-support-program > - websvn.kde.org is run by ViewVC > - build.kde.org and binary-factory.kde.org are both run by Jenkins > - stats.kde.org is run by Matomo (formerly Piwik) > - survey.kde.org is run by Limesurvey > > For essentially all of the above, calling it after the software > running it makes no sense, and given that in some cases we have > multiple instances would have made things more confusing > (jenkins1.kde.org and jenkins2.kde.org anyone?) > > Phabricator and Reviewboard were the only ones to not follow this > rule, and that was an error on our part. > > Given that there is a popular instance at Gitlab.com, referring to > ours as "KDE Invent" is more likely to ensure newcomers are not > confused (as they may not be aware that you can setup an instance of > Gitlab on your own systems) > > Regards, > Ben We also use git.kde.org and svn.kde.org. It would too mimic what others are doing at gitlab.gnome.org and gitlab.freedesktop.org. So at the very least we'll want a redirect. Aleix
Re: Type=FSDevice desktop files
On Sun, Apr 26, 2020 at 11:45 PM David Faure wrote: > > Would it be OK if we dropped support for desktop files that represent devices? > This was a KDE1/KDE2/KDE3? feature, you'd write/ship a desktop file with > Type=FSDevice and Dev=/dev/sdc > and this would give you Mount and Unmount in the context menu. > > This was useful back then, for USB keys and CDROMs (kids, ask your parents > what that was), before Solid, before the plasma device notification popup... > > But has anyone been using this in the last 10 years? I kind of doubt it. > > Since I'm refactoring KRun and KDesktopFileActions to be asynchronous and > independent from QtWidgets, I need to know what to do with this IMHO very dead > code. Of course these classes will keep providing the feature, but once I > write a KIO::OpenUrlJob as a replacement for KRun and we port the code to > that, we'll lose the feature from a user's point of view. > Not sure this is really a loss though ;) I don't think anyone I've ever discussed OSs would miss it. CCing plasma-devel since people there might know more about different use cases. Aleix
Re: Information regarding upcoming Gitlab Migration
On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah wrote: > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for > replies] > > Hello Community members, > > In view of upcoming Gitlab migration, we sysadmin team wants to share > the recommended structuring for the repositories on Gitlab. > > We had multiple options, > > - Flat structure: In this option we would have everything under one > single namespace/group: https://invent.kde.org/kde/knetwalk > - Subgroups under top-level group: In this option we would have a groups > under KDE namespace: https://invent.kde.org/kde/games/knetwalk > - Groups at top level: In this option we would establish a series of > groups at the top level, e.g. https://invent.kde.org/games/knetwalk > > We have discussed this with small but representative group of > contributors or maintainers, and based on their suggestions, we > recommend that we go with option 3. Having sub-groups at top level will > allow us to, > > - Provides good visibility on all reviews, tasks and other items within > the groups/modules we define > - Provides improvements to discoverability of projects > - Makes it possible for groups of projects to establish a group level > task board should it fit their needs (for tracking a release for > instance) > - Makes the most semantic sense, as the ‘KDE’ top level group suggested > in option 2 is duplicative considering the Gitlab instance is under > kde.org. > - The discoverability of projects is maximised, as there is no need to > open the top level ‘KDE’ group before going into the subgroup. > > I've worked on draft "move" of the current set of the repositories in > their respective subgroups at the repo-metadata project's branch [1]. > You can browse the directory structure to get idea of how final > structure on Gitlab would look like. > > If we don't have any objections we would like to implement this next > week and move projects to https://invent.kde.org. > > Thanks! > Bhushan for sysadmin team > > [1] > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent Does this mean that to clone it we'll have to go "git clone kde:games/knetwalk" or something along the lines? If that's the case I'd much prefer if we didn't do this, at the moment it's already uncomfortable for me to remember the URL for some of the repos (e.g. is it sysadmin/ or not?), this will only increase the problem and I personally don't see the advantage. e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is krita graphics or its own thing? I really prefer when I don't have to guess this kind of things when fetching a repository. Aleix
Re: Information regarding upcoming Gitlab Migration
On Mon, Apr 27, 2020 at 12:55 PM Ben Cooksley wrote: > > On Mon, Apr 27, 2020 at 10:39 PM Aleix Pol wrote: > > > > On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah wrote: > > > > > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for > > > replies] > > > > > > Hello Community members, > > > > > > In view of upcoming Gitlab migration, we sysadmin team wants to share > > > the recommended structuring for the repositories on Gitlab. > > > > > > We had multiple options, > > > > > > - Flat structure: In this option we would have everything under one > > > single namespace/group: https://invent.kde.org/kde/knetwalk > > > - Subgroups under top-level group: In this option we would have a groups > > > under KDE namespace: https://invent.kde.org/kde/games/knetwalk > > > - Groups at top level: In this option we would establish a series of > > > groups at the top level, e.g. https://invent.kde.org/games/knetwalk > > > > > > We have discussed this with small but representative group of > > > contributors or maintainers, and based on their suggestions, we > > > recommend that we go with option 3. Having sub-groups at top level will > > > allow us to, > > > > > > - Provides good visibility on all reviews, tasks and other items within > > > the groups/modules we define > > > - Provides improvements to discoverability of projects > > > - Makes it possible for groups of projects to establish a group level > > > task board should it fit their needs (for tracking a release for > > > instance) > > > - Makes the most semantic sense, as the ‘KDE’ top level group suggested > > > in option 2 is duplicative considering the Gitlab instance is under > > > kde.org. > > > - The discoverability of projects is maximised, as there is no need to > > > open the top level ‘KDE’ group before going into the subgroup. > > > > > > I've worked on draft "move" of the current set of the repositories in > > > their respective subgroups at the repo-metadata project's branch [1]. > > > You can browse the directory structure to get idea of how final > > > structure on Gitlab would look like. > > > > > > If we don't have any objections we would like to implement this next > > > week and move projects to https://invent.kde.org. > > > > > > Thanks! > > > Bhushan for sysadmin team > > > > > > [1] > > > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent > > > > Does this mean that to clone it we'll have to go "git clone > > kde:games/knetwalk" or something along the lines? > > Yes. > > > > > If that's the case I'd much prefer if we didn't do this, at the moment > > it's already uncomfortable for me to remember the URL for some of the > > repos (e.g. is it sysadmin/ or not?), this will only increase the > > problem and I personally don't see the advantage. > > So you'd rather that we have no way to easily see a list of just > Plasma / Frameworks / PIM / etc reviews? > (See https://invent.kde.org/groups/kde/-/merge_requests for an example > of the problem) > > Not to mention the fact that there will be several hundred > repositories all in one group, so they will be completely > undiscoverable to anyone outside of our community. > > > > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is > > krita graphics or its own thing? > > > > I really prefer when I don't have to guess this kind of things when > > fetching a repository. > > There is always the search on Gitlab, and you can keep a checkout of > sysadmin/repo-metadata for grepping on. I don't know, I've always felt that the nesting we have nowadays stemmed from svn's tree structure more than convenience. I don't have the feeling I'd use that feature and I'm happy to convinced otherwise. While discoverability would be an incentive, I don't know if it will make a difference since it would be especially useful to see how repositories relate one to another, but it's something we generally split explicitly through frameworks so I don't see that will help much, other than for the very big suites (kdepim, plasma, etc). I know you don't like it when I do this, but: https://gitlab.gnome.org/explore/groups < gnome kept all the programs under the same group https://gitlab.freedesktop.org/explore/groups < didn't, but they have projects that have very little overlap of contributors Aleix
Re: Information regarding upcoming Gitlab Migration: clarifications
On Wed, Apr 29, 2020 at 12:25 PM Bhushan Shah wrote: > > Good afternoon, > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for > replies] > > I want to clarify some bits for which we have gotten a questions about, > > - Non unique naming: There's some teams which prefer if we dropped the > namespace- part from their name which we have added. While currently > this does not result in the naming conflict right away, we realize > this will cause it at one point, for example, > > maui-dialer -> maui/dialer > plasma-dialer -> plasma-mobile/dialer > > To minimize the impact of the Gitlab move we won't be doing such > renames which introduce non-unique names right away. But we would > prefer if the existing tooling or infrastructure is ready for this > kind of cases at later point. Only way to enforce non-unique naming is > one big KDE/ subgroup which we want to avoid. > > Current naming in the repo-metadata branch[1] I've pointed does not > reflect those renames, as we are not planning to do those renames > right away during gitlab move, but at a later stage. We have made a big fuss in the past about having different projects that do the same thing and now we'll have that but also we'll have several projects with the same name? It really feels off to me and I wonder if this is related to the move to gitlab. > - Existing configurations: we want to reduce impact on existing release > schedule, and existing developer workflow, therefore we will continue > to privide the existing anongit.kde.org and git.kde.org (although this > will be read-only) with current flat structuring for 3 weeks after > actual migration, which will keep the existing scripts/clones working > enough to give developers time to change to the new structure. > > We will also try to provide a script which allows you to migrate your > existing clones to new repo paths and as mentioned by Ben in other > message, potentially a git-kde script which would allow you to clone > individual repository without knowing it's namespace (provided that > there is no conflict of it's name). like "git kde karchive" IMHO needing tools ad-hoc to KDE development can be a barrier of entrance. I feel like these things make us look distant, it's important that people's skills translate automatically when they want to get started. > - Translations: we will co-ordinate with the translations team to let > them adapt their tooling to updated structure as this requires changes > on their side how translations are stored in svn repository Thanks! :)
Re: Information regarding upcoming Gitlab Migration: clarifications
On Fri, May 1, 2020 at 1:08 AM Nicolás Alvarez wrote: > > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid > (aa...@kde.org) escribió: > > > > El dijous, 30 d’abril de 2020, a les 21:31:02 CEST, Ben Cooksley va > > escriure: > > > On Fri, May 1, 2020 at 6:04 AM Ivan Čukić wrote: > > > > > > > > > We have made a big fuss in the past about having different projects > > > > > that do the same thing and now we'll have that but also we'll have > > > > > several projects with the same name? > > > > > It really feels off to me and I wonder if this is related to the move > > > > > to > > > > > gitlab. > > > > > > > > +1 to both sentiments - that projects should have different names and > > > > that > > > > this is a bit off topic for the gitlab migration. > > > > > > The projects *DO* have very different names. That *HAS NOT* changed. > > > To use the example Bhushan gave above, one is called Plasma Mobile > > > Dialer and the other one is called Maui Dialer. > > > > > > With the current git.kde.org setup, we have a flat namespace, so all > > > repositories if the name appears to be generic (as dialer is) have to > > > be namespaced by prefixing of the repository name. > > > > > > With Gitlab however we will now namespaces that group repositories, > > > making the prefixing unnecessary and as some projects have complained > > > about, duplicative. > > > > > > Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your > > > path, which just looks silly. > > > > Am I the only person that just has all the repos on the same folder? I > > thought it was the common thing to do :? I do too > Oh, your local path could be anywhere. It doesn't even need the same > name, you can put it in the same folder as the rest and call it > dial-thingy :) And then you'll have to have a modified build script to account for thingy because KDE can't stay consistent at naming. I suggest not to use the gitlab transition to make such an important change. Aleix
Re: Information regarding upcoming Gitlab Migration: clarifications
On Fri, May 1, 2020 at 7:18 AM Ben Cooksley wrote: > > On Fri, May 1, 2020 at 4:38 PM Nate Graham wrote: > > > > > > > > On 4/30/20 5:59 PM, Aleix Pol wrote: > > > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid > > >> Am I the only person that just has all the repos on the same folder? I > > >> thought it was the common thing to do :? > > > > > > I do too > > > > Same here. kdesrc-build's default settings do this, and download all > > repos into ~/kde/src without any of the levels of hierarchy. This would > > seem to require unique repo names, no? > > Not necessarily. > > Git allows you to override the name that the local folder is called > when cloning, so there is no reason why we can't specify something in > the metadata to override the local name that the folder gets called in > your local checkout folder. > This would allow for example: > > - frameworks/kcoreaddons on Gitlab continues to be called > 'kcoreaddons' in your local checkout folder > - maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout > folder > > This allows for the URLs on Gitlab to make sense, while simultaneously > allowing your local source checkout folders to continue to work in the > manner in which they do currently. > Note that we do not expect people to hit this in many cases - this is > about giving us the flexibility for the long term without imposing > unnecessary bureaucracy and limits on projects within the KDE > umbrella. > > Automated tooling such as kdesrc-build and the proposed clone script > (that searches in namespaces) should be able to handle this without > much issue. > In the case of manually done clones, it is reasonable to expect people > to know what they're doing with their clones, and name them > appropriately in the event they have a collision. > > Does this sound acceptable? Okay, if that's necessary, we'll have to do it. We'll appreciate simpler bureaucracy. Aleix
Re: QML-using app developers: use private.* imports
On Wed, Sep 25, 2013 at 3:51 PM, Sebastian Kügler wrote: > Hey all, > > In Plasma, we've been looking into privatizing parts of the QML API we > offer. > With Qt5, we rely less on setContextProperty() and friends, and use imports > more. That's a technical necessity that makes one problem more evident: > It's > unclear what QML-facing API is reliable and stable, and what is private and > internal API. As there are no restrictions (right now) which imports may be > loaded by a piece of QML, we need another solution. > > Our approach hooks into the import loader, and will disallow loading > certain > plugins. This is not implemented yet, but we would like to prepare this by > having streamlined import names, which can eventually be enforced. > > We would like to introduce this as good practice for not-just-plasma, so it > would be nice if applications could use the same patterns: Only install > into > org.kde.* what you consider stable API. For internal imports, use > private.*, > for example private.org.kde.yourapplication.module. > > Thanks, > -- > sebas > > http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 > Reducing API to maintain is a good thing, at least for complexity sake. But of course there will be always the case where somebody needs (part of) the private API. The question would be then, why is it that there's some API that's only needed for internal usage? If it's needed internally, it will be most likely needed externally, at some point. The fact that you decide to label it as private makes frustrated developers. Either way, I have no idea of what we're talking about here. :D Cheers! Aleix
Re: Can we make api.kde.org search better?
On Sat, Nov 2, 2013 at 5:59 PM, Allen Winter wrote: > On Saturday, November 02, 2013 12:15:15 AM Albert Astals Cid wrote: > > Hi, yesterday i was talking with someone about the desktop file class we > have > > in KDE, he tried to find its api by going to > > api.kde.org > > and typing > > desktop > > in the Search bar. > > > > If you do that > > http://api.kde.org/index.php?miss=1&class=desktop > > all you get is > >No results found! > > > > Do you guys know if we can make the search better? > > > A PHP person could fix the attached program so that we can search for > ".*foo.*" (where foo is the user-specified search string) instead of > simply "foo". > > that's one idea. > > currently foo must exactly match what's in the map files. > > I can provide an example map file if someone takes this on. > > -Allen > > Could we maybe make a GCI task out of it? Aleix
Re: KClasses vs. Qt5Classes
On Tue, Dec 31, 2013 at 12:42 PM, Martin Graesslin wrote: > On Tuesday 31 December 2013 12:15:09 David Faure wrote: > > > QSystemTrayIcon => KNotificationItem > > > > No clue. I can't even find KNotificationItem in KF5 anywhere !?!? > > In fact it doesn't exist in kdelibs4 either. > > > > I think it got replaced with KStatusNotifierItem since 4.4 ? > > That one is still valid in KF5 (framework "knotifications"). > > I have no idea if/why it means QSystemTrayIcon is bad though. > QSystemTrayIcon uses XEmbed which is bad by definition ;-) > > We have discussed this in the plasma team and think that the best solution > would be to extend QSystemTrayIcon to use the status notifier API if > available. > Might need some hooks into the QPA as we probably cannot depend on D-Bus on > that level. But as that doesn't exist yet, at the moment the proper > suggestion > should be to use KStatusNotifierItem. > > Cheers > Martin FWIW, our QPA (or QPT, actually) already depends on QtDBus. Aleix
Re: Qt 5.3 to log all debug/warning/error messages to journald on systemd systems
On Mon, Jan 20, 2014 at 11:40 PM, Thiago Macieira wrote: > See subject. We're trying to decide whether we should enable journald by > default on Linux distributions that carry it. If we do, it means any > application that is not launched from a terminal would automatically write > to > journald instead. > > KDE applications are the largest users of qDebug today. > > If we changed the default, it would mean ~/.xsession-errors would probably > become rather empty. Is that ok for KDE? > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org >Software Architect - Intel Open Source Technology Center > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > I certainly would welcome it, output is not manageable in the current state. +1 Aleix
Re: KDE Review - Moving Artikulate to KDE Edu
On Sun, Jan 26, 2014 at 5:24 PM, Albert Astals Cid wrote: > El Diumenge, 26 de gener de 2014, a les 17:01:39, Christoph Feck va > escriure: > > On Sunday 26 January 2014 16:39:08 Albert Astals Cid wrote: > > > So I did have a look at Artikulate yesterday and just found some > > > minor nagging user flow issues that I told Andreas and he says he > > > would be fixing. > > > > > > Other than that, looks good to me to move to kdeedu *but* we need > > > to decide what to do with kqmlgraphplugin first, since we can't > > > have a kdeedu app depending on a playground lib. > > > > Are there technical reasons why we cannot? > > You can't compile something against something that is unreleased. > > Cheers, > Albert > > > > > Christoph Feck (kdepepo) > > Well, technically kqmlgraphplugin is a fork of something already in KDE SC. On the other hand, going through KDE Review is not that much trouble, so maybe we can just have it as well? Aleix
Re: Qt 5.3 to log all debug/warning/error messages to journald on systemd systems
On Tue, Jan 21, 2014 at 12:54 PM, Kevin Krammer wrote: > On Monday, 2014-01-20, 14:40:17, Thiago Macieira wrote: > > See subject. We're trying to decide whether we should enable journald by > > default on Linux distributions that carry it. If we do, it means any > > application that is not launched from a terminal would automatically > write > > to journald instead. > > What does "that carry it" mean? Is that a runtime detect or does the > distribution have to build Qt with a certain dependency? > > I.e. if a distribution has journald (probably as part of a systemd > package), > does Qt depend on that package or is that something Qt will discover during > runtime? > > > KDE applications are the largest users of qDebug today. > > This does not affect kDebug() or does it? > > Cheers, > Kevin > -- > Kevin Krammer, KDE developer, xdg-utils developer > KDE user support, developer mentoring > KDebug is gone for KF5 (or deprecated in KDE4Support). Aleix
Re: Lokalization for KDE AppStream AppData files
On Thu, Feb 20, 2014 at 6:54 PM, Matthias Klumpp wrote: > Hi! > I am working on bringing AppData to KDE. AppData is a XML-based > metadata format to enhance information displayed about applications in > software-centers. It, for example, includes long descriptions of an > application, homepage links, donation-links, screenshot-info and some > other information about the application. > AppStream is a Freedesktop project enabling us to build cross-distro > software centers. GNOME is already making heavy use of it for their > GNOME-Software application, and KDE also uses it already in Apper and > probably Muon soon. > One challenge for KDE is how to handle localizations for AppData > information. > I would propose the following: > * KDE applications ship an .appdata.xml.in file, containing the > raw, untranslated data. > * We extend messages.sh to scan the XML file and return the found > strings to the generic pot file, which is then translated by our > localization teams as usual. > * At build-time, we use intltool[1] to merge the translation with the > AppData file, then install it into it's target directory. > This is basically it. The only thing KDE projects need to do is to > edit their Messages.sh and depend on intltool to merge localization. I > could also provide a cmake macro for doing that to > extra-cmake-modules, if needed. > Do you have comments or suggestions on this? > I would later add it to the wiki page I'm doing to describe how KDE > projects which want to use AppData can easily use it. > Kind regards, > Matthias > > Links: > [1]: http://freedesktop.org/wiki/Software/intltool/ > AppStream: http://www.freedesktop.org/wiki/Distributions/AppStream/ > AppData: http://people.freedesktop.org/~hughsient/appdata/ > greetings to people who watched my FOSDEM talk ;-) > > -- > Debian Developer | Freedesktop-Developer > I welcome VSRE emails. See http://vsre.info/ > Hi Matthias! I'm very happy to see you pushing this forward. Muon will be supporting this format from the next released version (to some extent) and I'm sure this will increase over time. Regarding localization, Albert is the man here. If he says it's done in a way, you do it this way. ;-) More seriously though, I agree that it's doesn't make much sense to have it generated at build time, since this would require having all translations installed. Maybe we can figure out a mechanism appdata -> po -> appdata like in the desktop files. It works great there for desktop files, and it's the exact same use-case. Aleix
Re: Lokalization for KDE AppStream AppData files
On Fri, Feb 21, 2014 at 4:48 PM, Matthias Klumpp wrote: > 2014-02-21 2:02 GMT+01:00 Aleix Pol : > > [...] > > > > I'm very happy to see you pushing this forward. Muon will be supporting > this > > format from the next released version (to some extent) and I'm sure this > > will increase over time. > Great! Please keep in mind that the format is not meant to be > processed directly, but instead an intermediate Xapian database is > used. GNOME does not use it because the library for accessing the db > was not ready in time and it only had to run on Fedora anyway at that > time. > I will hopefully have time to work on the database stuff this weekend. > I'm aware of that library, but I don't really see the need yet. Maybe I will when we're actually using those. > > > Regarding localization, Albert is the man here. If he says it's done in a > > way, you do it this way. ;-) > > More seriously though, I agree that it's doesn't make much sense to have > it > > generated at build time, since this would require having all translations > > installed. Maybe we can figure out a mechanism appdata -> po -> appdata > like > > in the desktop files. It works great there for desktop files, and it's > the > > exact same use-case. > I have a compromise to offer, which will be necessary anyway in a way, > since to-be-localized entries in our XML files would have to be > prefixed with an underscore, so merging stuff back into the original > file does not work (unless we duplicate data there, which is ugly). > So, new suggestion: > * Project author creates file project.appdata.xml.in, containing the > raw data which has to be translated. > * Scripty processes that file and commits a project.appdata.xml file > in the same directory where the previous one was, containing all > localizations. If one is already there, the file is updated. > * We simply install the localized file and keep the other one as template > That solution would work, I would be happy with it and hopefully > Albert as well :-) If not, please make an alternative suggestion. > Cheers, > Matthias > > -- > Debian Developer | Freedesktop-Developer > I welcome VSRE emails. See http://vsre.info/ > Aleix
Re: Final kde-runtime splitting plan
On Wed, Mar 26, 2014 at 12:37 PM, Carlos De Maine wrote: > On Wed, 26 Mar 2014 11:28:24 AM Àlex Fiestas wrote: > > > On Wednesday 26 March 2014 09:52:08 Carlos De Maine wrote: > > > > On Tue, 25 Mar 2014 04:18:22 PM Àlex Fiestas wrote: > > > > > Hi there > > > > > > > > > > Today Aleix and I are starting to split kde-runtime so we have gone > > > > > through > > > > > all the components again making sure that everything has a suitable > > > > > destination. The result is this [1] wiki. > > > > > > > > > > Please, check that you are ok with the destination of each component > and > > > > > also check the things that have been targeted as **REMOVE** should be > > > > > really removed (we believe so). > > > > > > > > Kio-network works on 4.13 for me. > > > > http://wstaw.org/w/2ADU/[1] > > > > Does have a weird issue that it has to be refreshed twice to show any > > > > content for the first time, but works perfectly after that. > > > > Would be a pity to remove the only network browser. > > > > > > You can't actually execute anything from it can you? It is basically a > > > browser that lets you list things but little more which is quite useless > > > imho. > > > > > > I'm good on moving it elsewhere but what I would like to avoid is > shipping > > > this not finished kio as part of the official release which servers only > a > > > use (browser and discovery) that most people do not need by itself. > > > > > It opens fish/sftp, smb, afc kioslaves in dolphin, launches krdc for rfb > and vnc, opens konsole (at password entry stage) for ssh. In the past when > the upnp kioslave was still compiling i was able to access my upnp shares > around the network as well. > > > > I agree its not fully functional but in it's present state it is still > incredibly useful in the file dialog for accessing the network transparency > of kde's kioslaves. With a bit of polish (such as linking ktp to > *.presence, fish kioslave for *.udisks-ssh) it would be perfect. > > > > Cheers > > > Cheers. > > > It is a pity indeed. I just tried it myself on KDE4 and it seems like it wants to work but it doesn't quite. I wouldn't want this to prolongue, this project couldn't go through kdereview at the moment successfully, so there's little reason for it to stay in. Instead of removing, we can put it differently and move it to a little farm where kioslaves go die, but if somebody doesn't commit to it, it has to go. Also there's many other kioslaves in need for love: ** Adopt your kioslave ** Aleix
Re: Help splitting kde-workspace
On Sun, Mar 30, 2014 at 1:24 PM, Àlex Fiestas wrote: > Hi there > > It was requested by the maintainers of some of the projects that live in > the > kde-workspace repo that they would love to keep the whole history after the > split. Doing such thing is easy for projects that have not been moved > (kwin, > powerdevil) but otherwise it requires git-fu that we clearly lack. > > The following folders (to be split) are the ones that need to be split > keeping > all the history and where a simple git filter-branch won't cut it: > plasma-workspace > plasma-desktop > oxygen > libksysguard > > So we need help to split those while keeping the whole history. Could you > lend > us a hand? > > Alternatively we could use grafts like we have done with frameworks. > > Cheers. > Hi, I've been looking into the issue with Nicolás (aka PovAddict) and we managed to figure out all repositories history except for plasma-workspace and plasma-desktop. The problem was that not only they were moved now, but they were moved back in the day from kde-base when kde-workspace was created. It seems like something possible to solve but it didn't look like something that would pay off, so I decided to graft those. If somebody has great problems, I'd suggest to use the occasion and suggest a sane solution before we all start working on it, otherwise I think that grafts are a good solution (you can use the time I'm sending this e-mail as a proof we tried otherwise). Other than that, the rest of repositories have been pushed with full history (AFAIK) and it seems to work well. If there's any left-over issue, there will "always" be the kde-workspace repository for reference. I just pushed as well changes in the dependency-data-kf5-qt5 file so that when one tries to compile "plasma-desktop" gets the correct dependencies; note that you shouldn't be building kde-workspace anymore. It worked on my system, I hope it will work on most systems. I hope this doesn't distort your workflow too much and that we can soon start to take advantage of the new, leaner, organization of the project. Good night! Aleix
Re: Kronometer now in KDE Review
On Tue, Apr 15, 2014 at 10:27 PM, Albert Astals Cid wrote: > El Dilluns, 14 d'abril de 2014, a les 11:35:02, Elvis Angelaccio va > escriure: > > 2014-04-14 1:06 GMT+02:00 Albert Astals Cid : > > > * Your choice of splitters to separate hours/minutes/seconds seems a > bit > > > > > > weird do you think that anyone will use it to have something like very > > > wide > > > minutes and narrow the rest? > > > > I see your point, probably the splitters are unnecessary UI components > for > > this use case. > > What do you think about an option in "Interface settings"? I could > display > > by default a single QFrame (without splitters) and leave to the user an > > opt-in to allow the splitters. > > In this way I can reuse the existing code without too much refactoring. > > I just don't see the need for the splitters, why would someone want to have > them? > > Cheers, > Albert > FWIW, the first time I saw a screenshot of this application, these splitters shocked me too a bit. I guess the design will iterate anyway, no? Aleix
Re: KDE applications 4.14 LTS or 4.15?
On Fri, Apr 25, 2014 at 9:09 PM, Mario Fux wrote: > Morning gals and guys > > First: there are several mailing lists in the "TO:" above but please just > write to the kde-devel mailing list for this discussion. > > As the release schedule for our KDE applications in the version 4.14 [1] > were > finalized at the beginning of this week it's time to discuss if 4.14 should > become a LTS release (e.g. until August 2015 like KDE Workspaces 4.11) or > if > we need (at least) another features release and thus 4.15? > > So what do you think? And most important, what do you, the KDE apps > developers, think? Do you plan to develop new features with Qt4 and the KDE > Platform 4 or do you plan to port your application to the KDE Frameworks 5 > as > soon as they have a stable release (like this June ;-). > > Best regards > Mario > I would like to see applications starting to use KF5 more and more. I agree it can be a special case, but the 3 oldest projects I maintain (KDevelop which is not in SC, KAlgebra and Kamoso) are mostly ready for action. On the other hand, I don't see a reason for waiting more to adopt Qt5 on our projects. Aleix
Re: Question about currencies
On Tue, May 6, 2014 at 12:03 AM, Alvaro Soliverez wrote: > Hi all, > I have a question about the currency features. In KLocale, you can get > KCurrencyCode for the current locale, which is fine. > Now, for KMyMoney we need to get the list of all currencies for all > countries (since a user usually deals with multiple currencies). > > I haven't found an API for this, only the KLocale one for current > locale. Is there any other way to access the list of currencies? > > Thanks! > > Regards, > Alvaro > I don't really know much about the issue, but after having gone through similar code I think that your best bet is on using KStandardDirs (or QStandardPaths) to find the currencies directory and use QDir to list them. Aleix PS: I think KCurrencyCode is being deprecated for KF5, you might want to see what's the alternatives too.
Re: Compatibility problems with latest GTK+ applications
On Wed, May 7, 2014 at 10:11 AM, Martin Gräßlin wrote: > Hi all, > > I need some advice. The new GTK+ release introduced and enforces > client-side- > decorations (CSD) and that is causing severe compatibility problems with > Plasma Workspaces (especially the stable release which we cannot adjust any > more). I'll give a list of issues below. > > I'm not sure what we can do about it. I think we need to do something about > it, because this looks like a road back to "GTK apps can only be used in > GNOME > Shell" resulting in "KDE apps can only be used in Plasma". Because of that > I > think the compatibility problems matters to everyone also our application > developers. I think the right thing is to contact the GTK+ developers and > point out the problems, but I am probably the wrong person for it as I'm a > known opponent of CSD and fear that my feedback would be ignored. As a > fallback strategy we could enforce server-side-decorations (SSD) for all > GTK+ > applications which would look strange [4] but at least no loss in > functionality. > > Of course there are things we can do in KWin to improve compatibility, but > 4.11 is feature frozen and these would require new code and we have > certainly > more important things to do than to fix client breakage (we don't do that > in > general). > > It would be way easier if GTK+ would detect whether the environment > supports > CSD and use a normal application design if that's not supported. This would > not only be relevant for us, but especially for tiling window managers. > > List of issues I noticed: > * A hung window can no longer be closed or moved. Technical explanation: > there > is a ping protocol to detect hung applications. KWin only sends ping > requests > when the window is being closed from the window manager (e.g. decoration > close > button or Alt+F4). > * quick tiling broken, see [1]. It includes the shadow in calculation. > * black shadows around window if compositing gets disabled after the window > got opened [2]. Technical explanation: GTK+ doesn't detect that compositing > gets enabled/disabled. Other direction is broken, too. > * double borders if window gets opened when compositing is disabled [3]. > Technical explanation: GTK+ uses the Motif Window Manager Hints to tell how > the decoration should look like. KWin is not the Motif Window Manager and > does > not fully support the hints. Fun fact our code has a comment that we follow > Metacity to only support those hints which are not stupid. > * double border if decorations on KWin side are enforced [4] (Alt+F3 -> > More > Actions -> No Border). Technical explanation: GTK+ doesn't detect the re- > parenting and doesn't hide it's own deco and shadow > * Wrong resize cursor is shown on edges [6] > * Windows don't have a maximize and minimize button although configured in > the > decoration settings > * Incorrect drag delay: KWin uses either a drag delay on distance or on > time > for starting move or resize. GTK+ only has a drag delay on distance for > moving > and none for resizing. That's an important accessibility feature to have > that > globally configurable > * Windows can no longer be shaded > * Windows can no longer be put into window tabs > * Dialogs don't have a close button [5] (unless run without compositing) > * Ignores the configured mouse actions, uses (hard coded?) actions. > Defaulting > to lower window on middle click while we use window tab drag on middle > click > * no visual distinction between active and inactive application > * Broken window snapping: window snaps to shadow [7] > * Mismatching application window menu [8]. Note our menu could be invoked > through DBus. I consider this as a big problem as that's the only way to > e.g. > add windows to activities (which is also broken now) or to access the > advanced > window manager features GNOME doesn't know of. > > That list I figured out in less than 10 min usage of a new GTK+ > application. I > assume and fear that the list is much longer. > > Any advice on how to handle this situation is appreciated. > > Cheers > Martin > > [1] > > https://picasaweb.google.com/lh/photo/_q8BS4WN91ZvjEGSsiUkqtMTjNZETYmyPJy0liipFm0?feat=directlink > [2] > > https://picasaweb.google.com/lh/photo/hGjW0RLjGF3UVw5wFnPMqdMTjNZETYmyPJy0liipFm0?feat=directlink > [3] > > https://picasaweb.google.com/lh/photo/hriAb8OI1Yh8BtxtAg5bG9MTjNZETYmyPJy0liipFm0?feat=directlink > [4] > https://picasaweb.google.com/lh/photo/9LLTICdSJhcHl-SCBWc_i9MTjNZETYmyPJy0liipFm0?feat=directlink > [5] > https://picasaweb.google.com/lh/photo/-krx0xvGFjq9TwkEC4Bh_tMTjNZETYmyPJy0liipFm0?feat=directlink > [6] > https://picasaweb.google.com/lh/photo/BfuvOcm0_v_BG-SkoxXJ29MTjNZETYmyPJy0liipFm0?feat=directlink > [7] > > https://picasaweb.google.com/lh/photo/Vya50RqaVq1ij6sMDHEnbdMTjNZETYmyPJy0liipFm0?feat=directlink > [8] > https://picasaweb.google.com/lh/photo/2Xa5xNqDmjGL-bXwFzmPWdMTjNZETYmyPJy0liipFm0?feat=directlink Personally, I don't think we want to even try
Re: Moving plasma-nm to extragear
On Tue, May 27, 2014 at 8:41 PM, Jan Grulich wrote: > Hi, > > we would like to move plasma-nm to extragear/base and ask you for a review. > > Plasma-nm is a new applet written in QML for managing network connections > and > contains a few parts: > > 1) applet - plasma applet which allows you to connect/disconnect your > connections > 2) editor - application allows you to edit your network connections > 3) kded module - this is a secret agent managing passwords and > notifications > 4) libs - plasma-nm libraries, like editor widgets, models and so on > 5) settings - KCMs for applet configuration > 6) vpn - contains all VPN plugins > > You can find it here: > https://projects.kde.org/projects/kdereview/plasma-nm > > Please review 0.9.3 branch, which is the current version for KDE 4. > Frameworks > branch was merged to master today, so if you want to take a look at > KF5/Plasma > Next port, use master branch then. > > Thanks a lot. > > Cheers, > Jan > > -- > Jan Grulich > Red Hat Czech, s.r.o > jgrul...@redhat.com > Don't we want this in kde/workspace? Aleix
Re: KDE_DEFAULT_DEBUG_AREA
On Sun, Jun 8, 2014 at 5:53 PM, Maciej Poleski < d82ks8djf82msd83hf8sc02lqb5...@gmail.com> wrote: > Hello, > > May I have KDE_DEFAULT_DEBUG_AREA number assigned for Plugin to > KDevPlatform > (Baazar VCS integration)? > > Best Regards Maciej Poleski > Sure, you can add one in kdelibs, see kdelibs/kdecore/kdebug.areas. Note that kdebug is deprecated in KF5, though. Aleix
Re: Move of KXStitch to Extragear/Graphics
On Mon, Jun 23, 2014 at 6:40 PM, Steve Allewell wrote: > Hi all > > The KXStitch application has been in review for a few weeks now. Albert > identified a few minor issues that have now been fixed. > > If there is no more feedback, I would like to request KXStitch is moved to > Extragear/Graphics. I'll submit a ticket in a couple of days but if anyone > would like more time to review, please say so and I'll delay it. > > Best regards > > Steve > Go for it! Good luck Steve! :) Aleix
Re: [kde-community] Closing the kde-core-devel mailing list
On Tue, Aug 5, 2014 at 1:17 AM, Milian Wolff wrote: > On Monday 04 August 2014 20:36:44 Vishesh Handa wrote: > > Hello people > > > > Random Idea: How about we close the k-c-d mailing list? It's main purpose > > used to be to discuss kdelibs changes, but now since we have > > kde-frameworks, the mailing list seems less useful. We already have > > kde-devel for other generic kde stuff. > > So far, kdelibs is still open for patches, no? So I'd say let's keep it > until > we stop accepting patches for kdelibs. > > Bye > > Well, we can use the kde-frameworks mailing list for those reviews I'd say. Anything that is committed to kdelibs should be forward-ported to KF5 anyway, or it gets lost. It's not like it's 2 different projects, kdelibs and kde frameworks. Aleix
Re: [qca] /: Revert "Fix plugins lookup when not building in the Qt prefix"
On Sat, Aug 9, 2014 at 2:07 PM, Ben Cooksley wrote:
> Git commit c8b445b04a0efe66e491a6f0a06ca4ef312fdc91 by Ben Cooksley.
> Committed on 09/08/2014 at 12:00.
> Pushed by bcooksley into branch 'master'.
>
> Revert "Fix plugins lookup when not building in the Qt prefix"
>
> This reverts commit 38e0665127650b3db5676c1dd5f0ffeb8cdb176f.
>
> This change is incorrect, as Qt/QCA does not look within
> $pluginDir/qca/crypto when loading it's plugins.
> Instead, it expects to find them within the $pluginDir/crypto/
> subdirectory which no longer exists with this change.
>
> While the use of lib/qca/ is non-standard for plugins, existing code
> within the CI scripts is able to handle this abnormality.
> Normal Qt libraries which use plugins also function normally on the CI
> system.
>
> The change as it stands does not work with Qt 4 and breaks all tests which
> are reliant upon QCA on the CI system.
> As it appears a decision needs to be made on where QCA plugins should live
> and how they should be loaded i'm reverting this change to allow the tests
> to pass again.
>
> CCMAIL: aleix...@kde.org
> CCMAIL: dr...@land.ru
> CCMAIL: steph...@mankowski.fr
> CCMAIL: kde-core-devel@kde.org
> CCMAIL: kde-frameworks-de...@kde.org
>
> M +1-1CMakeLists.txt
>
> http://commits.kde.org/qca/c8b445b04a0efe66e491a6f0a06ca4ef312fdc91
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index a4dc6de..24d8ab3 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -158,7 +158,7 @@ else( QCA_INSTALL_IN_QT_PREFIX )
>set(LIB_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/lib${LIB_SUFFIX}" CACHE
> PATH "Directory where lib will install")
>
>set(QCA_PREFIX_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}" CACHE PATH
> "Directory where qca will install")
> - set(QCA_PLUGINS_INSTALL_DIR
> "${LIB_INSTALL_DIR}/plugins/${QCA_LIB_NAME}/crypto" CACHE PATH "Directory
> where qca plugins will install")
> + set(QCA_PLUGINS_INSTALL_DIR "${LIB_INSTALL_DIR}/${QCA_LIB_NAME}/crypto"
> CACHE PATH "Directory where qca plugins will install")
>set(QCA_BINARY_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/bin" CACHE PATH
> "Directory where qca plugins will install")
>set(QCA_LIBRARY_INSTALL_DIR "${LIB_INSTALL_DIR}" CACHE PATH "Directory
> where qca library will install")
>set(QCA_FEATURE_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/mkspecs/features"
> CACHE PATH "Directory where qca feature file will install")
>
My bad, I didn't try on Qt4, only assumed it would be the same as Qt5.
Either way, this breaks Qt5 now.
Aleix
Updated tasks list in todo.kde.org
Hi, We just updated the tasks list about the things we did in the KDE SDK sprint in Randa. [1]. I hope you think it's interesting as I think it is, if somebody has a question please ping any of us who came and I hope we can give it a final push altogether. Cheers! Aleix [1] https://todo.kde.org/?controller=board&action=show&project_id=13
Re: Proposal to improving KDE Software Repository Organization
On Tue, Aug 19, 2014 at 3:54 AM, Michael Pyne wrote: > Hi all, > > Ben Cooksley and I would like to get some feedback on further evolutions to > the organization structure we employ for the repositories at git.kde.org, > to > allow our current usage of CI even as we move farther into the KF5-based > world. > > TL;DR: More indirection in our JSON in kde-build-metadata, not a lot of > end- > user visible change, new org. terms: "Division" and "Track" for multi-repo > organization, tracking inter-repo dependencies would change too (sayonara > dependency-data-$branch_group), less CI servers turned into melting piles > of > slag. +1? > > The proposal follows for those who like reading excessively wordy text. > > Regards, > - Michael Pyne > > Improving KDE Project Organization: A Proposal > == > > 18 Aug 2014 > > Michael Pyne and Ben Cooksley > > This is a proposal to evolve the current method of organizing our mass of > KDE > source code repositories, and their dependencies, as contained in the > `kde-build-metadata` repository and used by kdesrc-build and build.kde.org > (referred to as "CI"). This is needed in order to correct some > deficiencies in > the [current > specification](https://community.kde.org/Infrastructure/Project_Metadata), > and > to help better support changing trends in developer workflow. > > Current Situation > = > > If you're familiar with the current organization of "KDE build metadata" > you > should skip to the next section. > > Currently, the git-based source code repositories that make up KDE.org's > software releases are each given a "project path" that fully specifies the > name > of the module in a virtual hierarchy. For instance, kdesrc-build itself is > really "extragear/utils/kdesrc-build", and KDE 4's kdelibs is > "kde/kdelibs". > > Since many modules support KDE4 and Qt5/KF5 (or may in the future), some > developers associated with KDE source code repositories introduced the > "branch > group" construct, that maps the git repository branch for the majority of > repositories into a few broad groupings, such as "stable-qt4", "latest-qt4" > and > "kf5-qt5". Developers and users using kdesrc-build could then use these > groups > to easily build the appropriate git branch of the many repositories needed > for > current releases of KDE.org software. This also allowed the CI > infrastructure > to support testing the development branches of both software using both > KDE4 and KF5, in addition to the libraries/Frameworks themselves. > > Current Issues > == > > Things have gone fairly well with branch groups, but there have been minor > issues with the construct: > > 1. The existing metadata listing dependencies between git repositories > could >not support multiple branch groups, as the dependencies were not > necessarily >identical for a given repository, for every possible branch group it >belonged to. We worked around this by forking the metadata such that > each >different branch group used a separate dependency file. > > 2. Compounding that issue, different branch groups would have different > sets >of repositories. For instance some repositories will never have a > KF5-based >release due to ongoing reorganization, and many repositories were born > for >KF5. By common agreement, software using `kde-build-metadata` now > recognize >empty git branch names to mean that a repository doesn't actually > belong to >the given branch group. This is still a workaround, however; if we > forget >to manually specify an empty branch, then CI and kdesrc-build will both >try to build that repository as part of that branch group (using a > default >branch). > > Upcoming Problems > = > > A larger concern (and what instigated this effort) is that the KF5 era will > introduce multiple development models that are difficult for the CI > infrastructure to efficiently support. > > For example, testing the KF5-based Plasma 5 Workspace will eventually need > to > test both the stable and development tracks for Plasma 5. Under the branch > group concept, this would lead to branch groups "kf5-qt5" and > "kf5-qt5-stable" > (or similar names). > > However the KF5 repositories that Plasma 5 requires do not have a split > between > stable and devel: They use a review-required process by which there's only > one > development track. In other words, Plasma 5's two development tracks will > only > depend on 1 KF5 track. > > At this time, that means CI will have to build 56 KF5 modules to test > Plasme > 5-stable, and then re-build, re-install, etc. the exact same 56 modules to > then > test Plasma 5-devel. This re-build is required because experience has shown > that built repositories cannot be assumed to be compatible between > different > branch groups (in fact many repositories are significantly different > on-disk > between branch groups). There's simply no data recorde
Re: Splitting kactivities reporitory
On Wed, Aug 13, 2014 at 11:35 AM, Ivan Čukić wrote: > Hi all, > > What do you think about splitting the kactivities repository into these: > - library (would remain in the kactivities repo) > - daemon (kactivities-service) > - workspace stuff (kcm, doplhin file linking, activities:/ kio, something > else?) > > The reason why this came up again is that the library follows the > requirements > for frameworks regarding supported compilers and platforms, while the rest > is > *nix-only. (the trigger for the mail are the attempts Nicolás made to > compile > the service with msvcc which does not like templates that much*) > > This would make kactivities a (sort of) tier1 framework since it would only > depend on Qt, and would have an optional runtime dep (the library behaves > properly when the service is not present). This would allow any > application to > support activities in Plasma, and not taint its code with ifdefs. > > The alternative would be to separate only the library and keep the daemon > and > the workspace stuff together. That would work as well. > > > Cheerio, > Ivan > > * there is a flag which allows building only the library at the moment, but > that seems not enough. > Maybe you can move those to plasma-workspace then and leave only the framework in kactivities. Aleix
Re: Location of Dr Konqi in Frameworks/KF 5
On Fri, Sep 5, 2014 at 8:36 AM, Ian Wadham wrote: > Hi guys, > > I have heard that Dr Konqi source code for Frameworks/KF 5 > has been placed in plasma-workspace. > > Please could you consider keeping it in some location that is > common to all platforms? This includes both Linux platforms and > non-Linux platforms, such as Windows and Apple OS X, where > Plasma is not usually required. > > Dr K used to be in kde-runtime on KDE 4 and is needed on > every platform, along with KCrash. > > Cheers, Ian W. > > It was placed there because it pulls a large bunch of dependencies we don't want for KCrash framework. Some work on it is needed though. Aleix
Re: Location of Dr Konqi in Frameworks/KF 5
On Thu, Sep 11, 2014 at 6:13 AM, Ian Wadham wrote: > Hi Alex, > > On 09/09/2014, at 7:48 PM, Aleix Pol wrote: > > On Fri, Sep 5, 2014 at 8:36 AM, Ian Wadham wrote: > > > > I have heard that Dr Konqi source code for Frameworks/KF 5 > > has been placed in plasma-workspace. > > > > Please could you consider keeping it in some location that is > > common to all platforms? This includes both Linux platforms and > > non-Linux platforms, such as Windows and Apple OS X, where > > Plasma is not usually required. > > > > Dr K used to be in kde-runtime on KDE 4 and is needed on > > every platform, along with KCrash. > > > > > > It was placed there because it pulls a large bunch of dependencies we > > don't want for KCrash framework. Some work on it is needed though. > > > > Aleix > > As mentioned in my other post, I am doing some work on Dr Konqi, > mainly to get it to work properly (and not crash) in KDE 4 on Apple OS X. > > I think my bug fixes and changes to keep up with new versions of > Bugzilla software (on the b-k-o database), will be forward portable > to KF5/Frameworks. > > Re dependencies, I think I can remove a large indirect one: Dr K's > dependence on KCookieJar and kded. Bugzilla is no longer using > cookies. > Good! > > I see Dr K as an app, to be ported to Frameworks just like any other > app, but sooner than most. I am not putting up my hand for that, > because of advancing age and plans to retire from KDE work. > > There are several other apps and utilities in kde-runtime. Have all > of those gone into plasma-workspace? > > Some of them would definitely be needed on all platforms, some would > be peculiar to a KDE desktop and some might be obsolete (e.g. Nepomuk) > or handled another way in KF5. > > Is there a plan to position and port them? > DrKonqi has already been ported and Nepomuk is not used. Dependencies in the frameworks port of DrKonqi are: KF5::I18n KF5::WindowSystem KF5::CoreAddons KF5::Service KF5::ConfigWidgets KF5::JobWidgets KF5::KIOCore KF5::Crash Qt5::DBus KF5::WebKit KF5::WidgetsAddons KF5::Completion KF5::Wallet > > Cheers, Ian W. > Aleix
Re: Moving repositories in the module structure
On Thu, Oct 2, 2014 at 11:34 PM, Ben Cooksley wrote: > Hi all, > > It seems there has been a recent outbreak of repository moves which > have been extremely poorly co-ordinated by those doing the requests. > > In addition, it is actually a requirement that modules moving from > Extragear into (what was at least) the SC need to re-transit through > KDE Review.It is also considered proper practice to at least inform > the translation, documentation and release teams in advance you > intend to make these moves - something which has also been neglected. > > For all further repository structure moves - please ensure you have > received the appropriate consent from the above mentioned teams, and > have announced them on the appropriate mailing lists in advance. > > @Plasma team: plasma-de...@kde.org does not constitute an appropriate > mailing list, as it is not a community wide development mailing list. > Only kde-devel and kde-core-devel qualify for this. > > Thanks, > Ben Cooksley > KDE Sysadmin > My apologies, I shouldn't have rushed into doing such moves and send e-mails to all the interested parties. If someone considers it appropriate, I can roll some of the changes back. Aleix
Re: Moving repositories in the module structure
On Fri, Oct 3, 2014 at 1:52 AM, Albert Astals Cid wrote: > El Divendres, 3 d'octubre de 2014, a les 00:04:42, Aleix Pol va escriure: > > On Thu, Oct 2, 2014 at 11:34 PM, Ben Cooksley wrote: > > > Hi all, > > > > > > It seems there has been a recent outbreak of repository moves which > > > have been extremely poorly co-ordinated by those doing the requests. > > > > > > In addition, it is actually a requirement that modules moving from > > > Extragear into (what was at least) the SC need to re-transit through > > > KDE Review.It is also considered proper practice to at least inform > > > the translation, documentation and release teams in advance you > > > intend to make these moves - something which has also been neglected. > > > > > > For all further repository structure moves - please ensure you have > > > received the appropriate consent from the above mentioned teams, and > > > have announced them on the appropriate mailing lists in advance. > > > > > > @Plasma team: plasma-de...@kde.org does not constitute an appropriate > > > mailing list, as it is not a community wide development mailing list. > > > Only kde-devel and kde-core-devel qualify for this. > > > > > > Thanks, > > > Ben Cooksley > > > KDE Sysadmin > > > > My apologies, I shouldn't have rushed into doing such moves and send > > e-mails to all the interested parties. > > > > If someone considers it appropriate, I can roll some of the changes back. > > Maybe you should explain the changes so people is aware of them :) > > Cheers, > Albert > > > Aleix > > Changes: - kde-gtk-config was moved from extragear/base to kde/workspace. - muon was moved from extragear/sysadmin to kde/workspace. That is, only projects.kde.org structure change. The reasoning is that this way they will be released together with Plasma Workspace. As they've been used they don't really make sense outside Plasma (especially the first) and we want to make sure that distros know these components are designed to work together with Plasma. I didn't notify kde-core-devel because it didn't occur to me that the community would have an opinion regarding whether it's me who releases the packages or Jonathan (who has been doing the Plasma packages). Cheers! Aleix
