Review Request 122475: Fix bug 343906 - Unable to handle plain directory paths as QUrl
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122475/ --- Review request for KDE Base Apps. Bugs: 343906 http://bugs.kde.org/show_bug.cgi?id=343906 Repository: kde-baseapps Description --- URLs passed as commandline arguments should be constructed using `QUrl::fromUserInput()` Diffs - dolphin/src/main.cpp 094402f Diff: https://git.reviewboard.kde.org/r/122475/diff/ Testing --- dolphin /tmp dolphin ftp.debian.org Thanks, Arjun AK
KDiagram libs (KChart, KGantt) in KDE Review
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 :) That repo is named "kdiagram" and has just been moved into "kdereview". Final destination is "extragear/graphics", as other charting/diagram software also is located there. After the initial code dump in the repo, work has been done to convert the buildsystem from qmake to cmake/ECM and KDE-fy the code in general. But no real changes besides renaming/rebranding have been done to the codebase, so this should be quickly usable by all FLOSS programs with their own copy of KDChart so far, and just need a few s/KDChart/KChart/ etc. for adaption. KDChart actually consists of two libraries, "kdchart" and "kdgantt", which have been made explicitly separate libs in KDiagram, and named "kchart" and "kgantt" there (and thus the repo "kdiagram" instead of "kchart", to not hide the gantt lib). Not yet clear if those libs would be merged more one day, so for now staying with a single repo, like the original, instead of splitting up into two repos by the two libs. Ideally a first release of kdiagram (libs kchart, kgantt) is done before the porting work of Calligra to Qt5 starts somewhen end of February, so that port can rely on the then external libs from the start. For that the schedule now is: tagging first release: February 16th moving to "Extragear/Graphics": February 22th release first release: February 22th Please do a git clone kde:kdiagram and give the libs some build testing (also go for all the compiled example and test apps) and review, especially the buildsystem. And perhaps prepare your FLOSS apps to use it already. This should give you KChart resp. KGantt in your CMakeLists.txt file: find_package(KChart "2.6.0" REQUIRED) target_link_libraries(myflossapp KChart) find_package(KGantt "2.6.0" REQUIRED) target_link_libraries(myflossapp KGantt) Cheers Friedrich
Review Request 122471: Enable Compilation of about Protocol
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122471/ --- Review request for kde-workspace and David Faure. Repository: kio-extras Description --- Basically porting away from QUrl and KDE_EXPORT Diffs - CMakeLists.txt 3379ce7 about/kio_about.h 620d6aa about/kio_about.cpp d7396d8 Diff: https://git.reviewboard.kde.org/r/122471/diff/ Testing --- Tested compilation and installation: $ find /home/david/kio-install/ -name "*about*" /home/david/kio-install/lib64/plugins/kio_about.so /home/david/kio-install/share/kservices5/about.protocol Thanks, David Narváez
Re: Review Request 122341: Port Thumbnail KIO Slave Away from KDELibs4Support
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122341/#review75577 --- http://quickgit.kde.org/?p=kio-extras.git&a=commit&h=a5d223221e802b057833e780cdca7cca65c06b52 - David Narváez On Feb. 7, 2015, 8:56 p.m., David Narváez wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122341/ > --- > > (Updated Feb. 7, 2015, 8:56 p.m.) > > > Review request for kde-workspace, Bhushan Shah and David Faure. > > > Repository: kio-extras > > > Description > --- > > Only major difference would be the lack of fallback to KFMI. Maybe we could > implement thumbnail features in KFileMetadata? > > > Diffs > - > > thumbnail/thumbnail.cpp 39e8de5 > > Diff: https://git.reviewboard.kde.org/r/122341/diff/ > > > Testing > --- > > Only tested compilation. > > > Thanks, > > David Narváez > >
Re: Review Request 122341: Port Thumbnail KIO Slave Away from KDELibs4Support
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122341/ --- (Updated Feb. 7, 2015, 8:56 p.m.) Status -- This change has been marked as submitted. Review request for kde-workspace, Bhushan Shah and David Faure. Repository: kio-extras Description --- Only major difference would be the lack of fallback to KFMI. Maybe we could implement thumbnail features in KFileMetadata? Diffs - thumbnail/thumbnail.cpp 39e8de5 Diff: https://git.reviewboard.kde.org/r/122341/diff/ Testing --- Only tested compilation. Thanks, David Narváez
Re: Moving KDE Telepathy to kdenetwork
El Divendres, 6 de febrer de 2015, a les 11:46:08, Martin Klapetek va escriure: > On Thu, Feb 5, 2015 at 11:33 PM, Albert Astals Cid wrote: > > El Dijous, 5 de febrer de 2015, a les 21:24:10, Sune Vuorela va escriure: > > > On 2015-02-02, Martin Klapetek wrote: > > > > Another part that KDE Telepathy needs is KAccounts and we'd like > > > > to move that one too, probably to kde-runtime but there seems to be > > > > some disagreements of the purpose of kde-runtime. KAccounts is > > > > > > I'm pretty sure that everything in kde-runtime is only for kdelibs. in > > > Frameworks, everything has been moved into the framework it is a part > > > of. > > > > > > KAccounts sounds mostly like a network thing to me, at least so far. If > > > it becomes more than a network accounts thing, maybe it should become a > > > framework ? > > > > > > > [1] KDE Telepathy repos are: > > > > ktp-accounts-kcm > > > > ktp-approver > > > > ktp-auth-handler > > > > ktp-call-ui* > > > > ktp-common-internals > > > > ktp-contact-list > > > > ktp-contact-runner > > > > ktp-desktop-applets > > > > ktp-filetransfer-handler > > > > ktp-kded-module > > > > ktp-send-file > > > > ktp-text-ui > > > > > > would this also be a time to maybe reconsider if one went a bit > > > overboard with the original repository splitting? Having a > > > libkdetelepathyinternalsprivate as a *public* available library somehow > > > smells like a bit wrong to me. > > > > +1 all that many ktp repositories always seemed more a hassle than a > > benefit > > to me. What's the benefit of such high granularity? > > As responded to Sune, this follow the upstream philosophy/hierarchy. And > also what frameworks does. Each of these components can work fully > standalone > (just with ktp-common-internals) and allows anyone to take that component > without dragging all 200k LOC, much of they don't need. > > I don't think it's a hassle really...possibly for packagers, I could see > that. > But as a developer...all you need is kdesrc-build, releasing is also > scripted... Speaking of releases, you guys understand you'll be in a bigger release schedule and will have to follow its rules, right? Cheers, Albert > > Cheers
Re: Review Request 122341: Port Thumbnail KIO Slave Away from KDELibs4Support
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122341/#review75567 --- Ship it! Nice :) - David Faure On Feb. 6, 2015, 3:50 p.m., David Narváez wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122341/ > --- > > (Updated Feb. 6, 2015, 3:50 p.m.) > > > Review request for kde-workspace, Bhushan Shah and David Faure. > > > Repository: kio-extras > > > Description > --- > > Only major difference would be the lack of fallback to KFMI. Maybe we could > implement thumbnail features in KFileMetadata? > > > Diffs > - > > thumbnail/thumbnail.cpp 39e8de5 > > Diff: https://git.reviewboard.kde.org/r/122341/diff/ > > > Testing > --- > > Only tested compilation. > > > Thanks, > > David Narváez > >
Re: Build dependency issues with kdesrc-build
On Friday 06 February 2015 19:46:28 Michael Pyne wrote: > On Fri, February 6, 2015 15:11:22 Kevin Funk wrote: > > On Thursday 05 February 2015 22:16:54 Michael Pyne wrote: > > > However as of now it only reorders modules you pull into the build list, > > > so > > > you still need to specify dependencies somehow. E.g. if you only asked > > > to > > > build plasmate, kdesrc-build wouldn't pull kdevplatform for you, but if > > > you > > > asked to build both kdesrc-build would do it in the right order. > > > > Question: Can't we add an option that does exactly that? Anything that'd > > prevent us to do so? > > I've been meaning to forever now. :-/ > > The only real catch is that you'd probably want to have a way to specify > dependencies not to include, and what to do with "soft" deps. These are all additional features. Just start off with "no way to filter deps", and "don't build soft deps", rest could be implemented later. > > > > Please note that the kf5-*-build-include files with kdesrc-build are not > > > authoritative information about what depends on what, they are very > > > coarse > > > groupings intended to help with high-level organization. > > > > Hm, but in fact it gives you the information about the actual package > > dependencies pretty precisely, no? (Otherwise the whole CI infrastructure > > wouldn't work -- Our CI scripts can figure out the exact dependency set > > needed for a build) > > We're talking about two different things. The CI scripts (and kdesrc-build) > use data from the kde-build-metadata git module, which *is* authoritative > regarding which modules depend on which. Thanks for the clarification, in fact I was thinking about kde-build-metadata for dependency information, which kdesrc-build takes advantage of. > The kf5-*-build-include files come with kdesrc-build itself, and are > generally used with a sample kdesrc-buildrc to tell kdesrc-build which KF5 > modules to build. These files don't include dependencies per se (though the > order that modules are listed is used as a hint in the absence of any other > dependency information). Rather they are used to get kdesrc-build to bother > with building those specific KF5 modules in the first place. Ah, okay. Didn't know that. > Regards, > - Michael Pyne -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
