Re: KDE Builder: request for review
On Mon, Apr 8, 2024 at 10:05 AM wrote: > and deprecating the kdesrc-build. That way we can move forward with new tool. I don't think reviewing or not of kde-builder should have any effect on kdesrc-build. I think also we should be slightly wary of changing a long-running 20y old tool written by long time kde people who are still around with a brand new tool written by a brand new contributor. I wonder if it will have the same shelf life as the ruby version that was done some years ago and abandoned. /Sune
Re: revisiting the sycoca
On 2024-02-13, Harald Sitter wrote: > Do you have a testing plan in mind? Not a dedicated one, no. But assuming your analysis is mostly correct, something along the lines of - What's the plasma startup performance with and without sycoca on a clean user - If much slower, try isolate which of the 3 parts are responsible - What's the startup performance if a user has done modifications like menu changes and user-environment installed apps/desktop files [a] - What happens when a user adds their own mimetype additions ? That could also be loading a folder with such files in dolphin or a 'save /open'-dialog I'm assuming this is mostly disk intensive operations, so a slow disk (spinning metal) is probably a good idea for that. I wonder if we should also try to get David Faure to look at this thread. /Sune [a] Isn't this even more likely in the world of flappacks and snacks and appimages and snaps and flatpaks and such
Re: revisiting the sycoca
On 2024-02-08, Harald Sitter wrote: > It occurs to me that we should ponder sycoca a bit. > > Currently the sycoca contains 3 types of caches: At some point I remember David Faure, iirc as part of his QMimeType work, removed part of sycoca, but left the remaining bits as a per user cache *because* we allow the user to modify things. I don't know how much of it is still relevant, but I do think we should be testing it, both on modern ssd systems, but given our occasional marketing drive about keeping older systems running, especially also on older systems with a spinning metal disk, rather than a bit handwavy "This is probably going to be fine" /Sune
What can we expect from our developers
On 2024-01-29, Jonathan Riddell wrote: > This sort of comment makes me really sad. The All About the Apps goal, > which in principle is still ongoing, was an attempt to get KDE developers > to realise it was important not just to write apps but to actually make > them available to users, I find it astonishing how we still don't have a > culture where making our apps available to users is part of our > responsibility. There's teams in KDE to help with all these formats. > Sorry to complain here as the issue is larger than just this one app but > it's so sad that nobody within KDE wants to help get users using our > software directly. I think this is taking it too far. I think the goal is more about not getting in the way of people who wants to do this. We need to draw a line somewhere about what we expect from *all* of our developers. I don't think that we can expect all of our developers to be great at * c++ * qtquick * cmake * windows weirdness * linux weirdness * freebsd weirdness * osx weirdness * android weirdness * packaging flatpaks, appimages, snaps, debs, rpm, .. for linux * making osx installers * making apk's * making windows installers Beside the domain of the application. Yet it is kind of what we are doing with having gating CI setups for many of these, and adding more. I'm quite a seasoned developer and I know I can't care for all of that. I also don't have the time to care for all of these. We also don't have extra manpower in the teams that knows about these to help everywhere. We might have a goal about this, but this is just far too many thing to be good at everything. I don't think we should shame individual developers for also realizing this. But where should we draw the line ? /Sune
Re: Can my application, which contains dirty code, become an official kde application?
On 2024-01-17, Danilo Agostini wrote: > It allows the user, through the use of a keyboard shortcut or a dolphin > servicemenu, to have a quick preview of the files that are shown in the > folder without having to open the default application. > > Similar applications are Gnome Sushi and Quick Look (Mac os). Isn't this in the similar realm as what we can do with thumbnailers and/or kparts ? > Technical Limitations/Defects: > > 1) The way it integrates with dolphin is not clean due to dolphin's > limitations: I currently use dbus to copy the path of the selected file I'd suggest to fix whatever limitations there is in Dolphin to not have to do workarounds. > 2) The preview of some files (odt,doc,docx,xlsx,etc) is obtained by > converting the documents to pdf using the "libreoffice --headless > --nolockcheck --norestore --convert-to pdf" command. This obviously > requires libreoffice installed on the system and the conversion may fail/be > slow in some cases. I don't think this as such is a bad idea except maybe ... doesn't this negate the whatever speedup you are trying to do with a 'quick preview' instead of launching the app when you now actually launch the app headless in the background ? I just browsed around in the code and I do think there is quite some cleanups to do. I'm sure cppcheck, clazy, clang-tidy and other static analyzers can find a lot. oh. Don't use rand(). And consider using something to create a temporary working directory rather than work directly in tmpdir. Some members are m_ prefixed. others aren't. Some member vars shouldn't be member vars. Consider using much more const refs or views. I'm confused about when you use std::string and QString. It seems to be a bit random which one you pull out of the tool chest. And std::thread and QThread. Why are you using std::filesystem::__cxx11::path ? (Especially the __cxx11 part) Also there seems to be a pattern of |QString foo; |foo = someFunction(); Just having |QString foo = someFunction(); Is normally easier to work with. Also note that we are about to move everything to Qt6/KF6; This seems to be stuck on quite ancient frameworks and qt versions. /Sune
Re: KDE Review: Hash-o-Matic
On 2023-10-01, Carl Schwan wrote: > Hello, > > I started writting a small application to generate and compare files with > their > checksum two years. I piked it up again recently and I think this is now > ready > for a kde review. Even two years ago, checking stuff with md5 was not a good idea, unless just for checking for transfer errors. But maybe add a sha3 variant instead? /Sune
Re: State of server-side retrace of KDE crashes?
On 2021-12-19, Nate Graham wrote: > For what it's worth, I don't think server-wise retracing is solely a > workaround for distro-specific issues. Even for distros that ship debug > symbols, I often find in my bug triaging that it can be a challenge to > get users to actually use them. Server side retracing is king of orthogonal to this. Server side retracing is taking the coredump (maybe minidump), shipping it to a server and combining it with debuginfo from the original binary build. But this would require the serverside retracer to be able to consume debuginfo packages correctly for all (relevant?) distros and all historic? versions. The thing drkonqi does is it tries to do client side retracing and tries to get the package manager to get the correct debuginfo packages available. From a package manager perspective[*], that's often quite hard to get right, and thus why it often does not give that good bug reports. With debuginfod integration and distributions providing debuginfod, this can become better. But for both of them, it needs debuginfo available from somewhere. If the distro don't provide those, then we, no matter what, are out of luck. /Sune [*] Imagine user installs dolphin 5.4.3-1, experiences a crash 2 weeks later, drkonqi tries to get package manager to install debug symbols, but 5.4.4 has since come out. Unless the package manager systems keeps debuginfo around much longer than the package it belongs to (which I haven't heard anyone actually do), then this will not match.
Re: Calindori in kdereview
On 2020-04-12, Dimitris Kardarakos wrote: > > Hello everyone, > > I'd like to let you know that the Calindori [1] application has been > moved to kdereview. I'm a bit curious about the name. Is it just a random butchering of Calendar or does it actually have a meaning? /Sune
Re: krecipes to unmaintained
On 2019-05-09, Jonathan Riddell wrote: > I'd like to propose moving krecipes to unmaintained. It still uses > kdelibs4 and has had no feature commits since 2016. I'd like to gentle promote KookBook here ... it has a krecipes converter should anyone feel stuck with their data. /Sune
Re: Installing qml caches
On 2018-06-04, Alexander Volkov wrote: > This can be made optional, as it is done in Qt. > So distros will have a choice whether to install qmlc files or not. > Debian installs them. I think Debian only installs the qmlc files for Qt packages (where the versioning already is tightly coupled to Qt stuff) /Sune
Re: Fwd: Elisa Music Player is in kdereview
On 2018-02-07, Matthieu Gallien wrote: > I have updated the readme. I still do not know if it is possible to properly > check for them at build time It doesn't make sense to do build time checks for runtime dependencies, other than as an informal notice. The build is for distributions happening in a different environment than where it is run. /Sune
Re: karchive and QSaveFile
On 2017-03-28, Boudewijn Rempt wrote:
> I'm now wondering whether to hack QSaveFile's close to just not
> abort, or add inherits("QSaveFile") checks all over KArchive --
> or whether there's a third, better option that I've missed...
Without having put too much thought into it, add an "Don't close the
device underlying device" boolean option to the relevant KArchive
classes?
/Sune
Re: Review Request 128941: ZLIB dependency is in libkonq since 7635179
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128941/#review99267 --- I don't get the review description and its relevance to the patch. konqueror/src/CMakeLists.txt <https://git.reviewboard.kde.org/r/128941/#comment66844> I think the comment is wrong. I can't find any zlib references in konqueror itself. Also note that the linkage is actually commented out. - Sune Vuorela On Sept. 18, 2016, 11:36 p.m., Andreas Sturmlechner wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128941/ > --- > > (Updated Sept. 18, 2016, 11:36 p.m.) > > > Review request for KDE Base Apps and David Faure. > > > Repository: kde-baseapps > > > Description > --- > > Add ECMMarkAsTest, used by fsview tests > > > Diffs > - > > konqueror/CMakeLists.txt 53c4829cbc2f8b380ad8608b555eb6e15b24a3bb > konqueror/src/CMakeLists.txt e8e408611335fa56faf24466307f83e40a3b70ee > lib/konq/CMakeLists.txt 7a61493ff13561340c1a6c114763489343212f41 > > Diff: https://git.reviewboard.kde.org/r/128941/diff/ > > > Testing > --- > > > Thanks, > > Andreas Sturmlechner > >
Re: Naming scheme for Qt5/KF5-based libraries outside of KF5
On 2015-09-27, Boudhayan Gupta wrote: > "Seen before" is no reason to not move forward if we can actually fix > this. As I said, Extragear library developers will *have* to provide > API/ABI guarantees. Good luck with that. > That's the ideal scenario, but isn't becoming a framework... hard? No. Once you have something useful, reviewed and wants to commit to abi/api stability it is just a bit of paperwork. /Sune
Re: Naming scheme for Qt5/KF5-based libraries outside of KF5
On 2015-09-27, Boudhayan Gupta wrote: > What I propose is that all libraries which want to manage their own > release cycles and their own namespaces, be moved to Extragear Libs > and release from there. All the libraries which can stick to the > Applications release-unit, move to Support or a new module and be > released with them. What happens if an Applications application uses an extragear lib? or an extragear application uses an application lib? Yes. this will happen. And then you have a abi/api unstable library out of sync with the application it uses. And that's highly annoying. Seen before with e.g. Digikam/Gwenview/KPhotoAlbum and libkipi/libkexiv2/... I don't see why we need a extra organizational level to house something we should try to avoid to have in the fist place. Let's get all good libraries made frameworks. /Sune
Re: Naming scheme for Qt5/KF5-based libraries outside of KF5
On 2015-09-26, Boudhayan Gupta wrote: > We could kill two birds with one stone here, creating a new KDE module > just for libraries (say, KDE Companion Libraries or something) and put > everything in the KC5 (or whatever we decide) namespace. By doing this, we kind of make it a thing to .. become. I do think that shared cross-repository libraries that aren't frameworks should be avoided as much as possible, and for the few ones where it isn't possible for specific functionality we should still try to limit it. It is libraries that might change abi and api, and that's generally a mess, especially if the users have different release schedules. And people will use an available shared library. > I'm all for just putting everything in KDE Support, using the KS5 > namespace and removing the tier0 restriction from Support. KDE Support is our 'low level' libraries, but many of them has become frameworks, which I think should also be the road ahead. /Sune
Re: Naming scheme for Qt5/KF5-based libraries outside of KF5
On 2015-09-26, Alexander Potashev wrote: > 1. Many people prefer a "KF5" prefix, e.g. libKF5Screen.so). > 2. Another way of naming is a -qt5 suffix, e.g. libmarblewidget-qt5.so. > 3. (probably some others?) > > Friedrikh said in [1] that using a KF5 prefix for all libraries will > "blur the hint by the name if something is part of KF5 or not". > > Any thoughts? I believe we can have guidelines for library names. I do think that having things named KF5 that aren't actual frameworks is bad for several reasons. 1) It blurs what's a framework 2) We promise ABI and API compatibility for frameworks, but not for other things 3) Moving something from "not a KDE Framework" to "KDE Framework" gives a last chance for fixing up abi/api. so. foo-qt5 is fine for a qt5 version of foo. /Sune
Re: Distros and QtWebEngine
On 2015-04-20, Thomas Lübking wrote: > You can apply that on really *anything* - the obvious (claimed) failure is > "Qt breaks somehow Plasma" because either > a) a client relied on undocumented behavior (client bug) or > b) a foundation broke documented API/ABI/Behavior (foundation bug) a) is happening quite a lot. Just look for usages of Qt private headers across our modules. > Also your list implies that one never can update KDE, because that breaks > GNOME, requires a kernel update and whatnot. No. One can update things, but it is not "just" update Qt. >> Unfortunately, I haven't really used my imagination here. > That implies the Linux SW stack is crap. Point taken. Or .. fast moving. /Sune
Re: Distros and QtWebEngine
On 2015-04-20, Albert Astals Cid wrote: > Just state that there's no such long maintaince time for that package o= > r just=20 > install the newer version of Qt. And yes again that probably goes again= > st your=20 > rules, but it's your rules, so you can just improve them for everyone's= >=20 > benefit :) Let's just try to follow that thru. A new QtWebEngine pulls in a new Qt. The newer Qt breaks somehow Plasma, because relying on internals. Then a newer Plasma is pulled in. THat requires a newer KDE Frameworks, and a newer Wayland and a newer Mesa. Those two components requires a newer kernel. The newer KDE frameworks also has a couple of extra requirements. Some of those extra requirements happens to break parts of the Gnome stack. So a update of that is needed too. That requires a newer systemd, that discovers issues with apache. The newest apache has a changed plugin api that requires changes to all the apache extensions. Including php, ruby and python. You can likely continue the story yourself from here. Unfortunately, I haven't really used my imagination here. /Sune
Re: Distros and QtWebEngine
On 2015-04-20, Albert Astals Cid wrote: > IMHO the duty of a distro is providing software to their users to use, = > if the=20 > rules of the distro make providing software hard/impossible they need t= > o be=20 > updated or these distros need to understand they will lose users to mor= > e=20 > flexible distros. Unless distros and KDE work together somehow, it is going to be a lose/lose situation for both KDE and and for the distros in question. And maybe even for the free software desktop. The exact problem here is that packaging chromium in Debian is something that needs at least 2 skilled dedicated people to. Packaging QtWebEngine is like packaging chromium (because it is chromium) + a little bit more. The rumors is that (K)Ubuntu is likely following Debian. To the best of my knowledge, chromium aren't shipped at all in fedora because maintenance nightmare. And Red Hat is following Fedora. That's likely half of the actual linux desktop landscape. We (as KDE) can either insist saying "if you don't ship this technology we won't deal with you" or we can try to work together with our downstreams to find a way to somehow make everyone somehow happy. We (as KDE) need to understand that if we don't have our software in distributions, it is just as likely that people will switch applications, as it is that they will switch distributions. So, all in all, if everyone takes a hard stance, everyone will lose. Let's find a way so we all can win. /Sune
Re: Moving KDE Telepathy to kdenetwork
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. > *) ktp-call-ui is not yet ported and will most probably be dropped from > the 15.04 release So that one is staying in ... playground ... so far? /Sune
Re: Co-installability
On 2014-04-29, Alexander Neundorf wrote: > On Tuesday, April 29, 2014 21:00:57 Christoph Feck wrote: >> I cannot remember we had these issues with the KDE3->KDE4 transition. > > Actually I think we had the same issues. We did have the same issues. I pushed them thru with help of Allen and David. /Sune
Re: frameworks build instructions wrong / won't work with kubuntu 14.04
On 2013-12-18, Harald Sitter wrote: > Thoughts on this? What do we do about it? Tell ubuntu users to not use their distribution provided cmake because ubuntu decided to break cmake by doing quick hacks instead of figuring out how stuff works and then solve problems? /Sune
Re: Review Request 113503: make dbus dependency optional in JobWidgets
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113503/ --- (Updated Nov. 25, 2013, 1:56 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks, kdelibs and Stephen Kelly. Repository: kdelibs Description --- Make dbus dependency optional in JobWidgets Many don't have dbus available on all platforms, especially windows, but JobWidgets is very much useful without it. Diffs - tier2/kjobwidgets/CMakeLists.txt ca53024 tier2/kjobwidgets/src/CMakeLists.txt 0a575a6 tier2/kjobwidgets/src/config-kjobwidgets.h.cmake 35b64a2 tier2/kjobwidgets/tests/kjobtrackerstest.cpp 7a61407 Diff: http://git.reviewboard.kde.org/r/113503/diff/ Testing --- build tested on windows without dbus. not yet tested on other platforms Thanks, Sune Vuorela
Re: Review Request 113503: make dbus dependency optional in JobWidgets
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113503/ --- (Updated Oct. 30, 2013, 10:08 a.m.) Review request for KDE Frameworks, kdelibs and Stephen Kelly. Changes --- workin on linux with dbus Repository: kdelibs Description --- Make dbus dependency optional in JobWidgets Many don't have dbus available on all platforms, especially windows, but JobWidgets is very much useful without it. Diffs (updated) - tier2/kjobwidgets/CMakeLists.txt ca53024 tier2/kjobwidgets/src/CMakeLists.txt 0a575a6 tier2/kjobwidgets/src/config-kjobwidgets.h.cmake 35b64a2 tier2/kjobwidgets/tests/kjobtrackerstest.cpp 7a61407 Diff: http://git.reviewboard.kde.org/r/113503/diff/ Testing --- build tested on windows without dbus. not yet tested on other platforms Thanks, Sune Vuorela
Re: Review Request 113503: make dbus dependency optional in JobWidgets
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113503/#review42696 --- for some reason the cmake magic that is supposed to ensure the files are properly added, always returns false, so doesn't build with dbus. needs fixing - Sune Vuorela On Oct. 29, 2013, 10:27 p.m., Sune Vuorela wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113503/ > --- > > (Updated Oct. 29, 2013, 10:27 p.m.) > > > Review request for KDE Frameworks, kdelibs and Stephen Kelly. > > > Repository: kdelibs > > > Description > --- > > Make dbus dependency optional in JobWidgets > > Many don't have dbus available on all platforms, especially windows, but > JobWidgets is very much useful without it. > > > Diffs > - > > tier2/kjobwidgets/CMakeLists.txt ca53024 > tier2/kjobwidgets/src/CMakeLists.txt 0a575a6 > tier2/kjobwidgets/src/config-kjobwidgets.h.cmake 35b64a2 > tier2/kjobwidgets/tests/kjobtrackerstest.cpp 7a61407 > > Diff: http://git.reviewboard.kde.org/r/113503/diff/ > > > Testing > --- > > build tested on windows without dbus. not yet tested on other platforms > > > Thanks, > > Sune Vuorela > >
Review Request 113503: make dbus dependency optional in JobWidgets
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113503/ --- Review request for KDE Frameworks, kdelibs and Stephen Kelly. Repository: kdelibs Description --- Make dbus dependency optional in JobWidgets Many don't have dbus available on all platforms, especially windows, but JobWidgets is very much useful without it. Diffs - tier2/kjobwidgets/CMakeLists.txt ca53024 tier2/kjobwidgets/src/CMakeLists.txt 0a575a6 tier2/kjobwidgets/src/config-kjobwidgets.h.cmake 35b64a2 tier2/kjobwidgets/tests/kjobtrackerstest.cpp 7a61407 Diff: http://git.reviewboard.kde.org/r/113503/diff/ Testing --- build tested on windows without dbus. not yet tested on other platforms Thanks, Sune Vuorela
Re: Review Request 113479: fix kshareddatacache on windows
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113479/ --- (Updated Oct. 28, 2013, 8:08 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, kdelibs and Michael Pyne. Repository: kdelibs Description --- fix kshareddatacache on windows to at least not be a way to have a bytearray roundtrip. Also, the windows implementation is currently only a in-memory one, so don't test on windows if there is a file written. Diffs - tier1/kcoreaddons/autotests/kshareddatacachetest.cpp a4484560735f9096ecdac26b3c539394602e0f31 tier1/kcoreaddons/src/lib/caching/kshareddatacache_win.cpp cdc6536b56888a615e74960bf1b55fb12cc3e70d Diff: http://git.reviewboard.kde.org/r/113479/diff/ Testing --- Test suite passes Thanks, Sune Vuorela
Re: Review Request 113479: fix kshareddatacache on windows
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113479/ --- (Updated Oct. 28, 2013, 10:07 a.m.) Review request for KDE Frameworks, kdelibs and Michael Pyne. Repository: kdelibs Description --- fix kshareddatacache on windows to at least not be a way to have a bytearray roundtrip. Also, the windows implementation is currently only a in-memory one, so don't test on windows if there is a file written. Diffs - tier1/kcoreaddons/autotests/kshareddatacachetest.cpp a4484560735f9096ecdac26b3c539394602e0f31 tier1/kcoreaddons/src/lib/caching/kshareddatacache_win.cpp cdc6536b56888a615e74960bf1b55fb12cc3e70d Diff: http://git.reviewboard.kde.org/r/113479/diff/ Testing --- Test suite passes Thanks, Sune Vuorela
Review Request 113479: fix kshareddatacache on windows
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113479/ --- Review request for kdelibs and Michael Pyne. Repository: kdelibs Description --- fix kshareddatacache on windows to at least not be a way to have a bytearray roundtrip. Also, the windows implementation is currently only a in-memory one, so don't test on windows if there is a file written. Diffs - tier1/kcoreaddons/autotests/kshareddatacachetest.cpp a4484560735f9096ecdac26b3c539394602e0f31 tier1/kcoreaddons/src/lib/caching/kshareddatacache_win.cpp cdc6536b56888a615e74960bf1b55fb12cc3e70d Diff: http://git.reviewboard.kde.org/r/113479/diff/ Testing --- Test suite passes Thanks, Sune Vuorela
Re: Review Request 113205: Make KJob::result public for the new signal/slot syntax.
On Oct. 11, 2013, 9:51 p.m., Mark Gaiser wrote: > > We are here making a 'hole' for people to do 'bad things' that wasn't > > possible in the past. I'm not sure we want that. > > Mark Gaiser wrote: > Interesting. > So that mean we simply can't use the new signal/slot syntax because of > it? That would seem rather strange to me.. > > If you do a stat call, or listEntry or ... > Then you are supposed to connect to the result slot. For listEntry you > are supposed to connect to the finished signal. Both of those are defined as: > signals: > private: > > AKA. Private signals. > I really don't see how you can work around this besides perhaps > QSignalMapper, but that would be very odd as well. I'm really curious to see > how that "bit of magic" is supposed to work. Do you have some links for me > there? I'm not saying we can't use the new syntax because of it. I'm saying it needs a bit more work, and before a 'stable' version is needed. There is a solution out there. It's applied to QAIM and others. - Sune --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113205/#review41570 --- On Oct. 11, 2013, 5:59 p.m., Mark Gaiser wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113205/ > --- > > (Updated Oct. 11, 2013, 5:59 p.m.) > > > Review request for KDE Frameworks and kdelibs. > > > Repository: kdelibs > > > Description > --- > > The new signal/slot connection: > connect(job, &KJob::result,... > > does't like result to be private and throws an compile error: > error: 'void KJob::result(KJob*)' is private > > Making it public resolves the issue and makes this slot usable in the new > syntax. In my case i wanted to use the new syntax and directly use a lambda > as slot. Which isn't possible on this signal if it isn't public. > > > Diffs > - > > tier1/kcoreaddons/src/lib/jobs/kjob.h d663530 > > Diff: http://git.reviewboard.kde.org/r/113205/diff/ > > > Testing > --- > > Works just fine. > > > Thanks, > > Mark Gaiser > >
Re: Review Request 113205: Make KJob::result public for the new signal/slot syntax.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113205/#review41570 --- tier1/kcoreaddons/src/lib/jobs/kjob.h <http://git.reviewboard.kde.org/r/113205/#comment30378> You are kind of now actually making it fully public so that it can be emitted by others, contrary to what the documentation seems to imply. I think QAIM had a similar thing that steve solved with a bit of magic. We are here making a 'hole' for people to do 'bad things' that wasn't possible in the past. I'm not sure we want that. - Sune Vuorela On Oct. 11, 2013, 5:59 p.m., Mark Gaiser wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113205/ > --- > > (Updated Oct. 11, 2013, 5:59 p.m.) > > > Review request for KDE Frameworks and kdelibs. > > > Repository: kdelibs > > > Description > --- > > The new signal/slot connection: > connect(job, &KJob::result,... > > does't like result to be private and throws an compile error: > error: 'void KJob::result(KJob*)' is private > > Making it public resolves the issue and makes this slot usable in the new > syntax. In my case i wanted to use the new syntax and directly use a lambda > as slot. Which isn't possible on this signal if it isn't public. > > > Diffs > - > > tier1/kcoreaddons/src/lib/jobs/kjob.h d663530 > > Diff: http://git.reviewboard.kde.org/r/113205/diff/ > > > Testing > --- > > Works just fine. > > > Thanks, > > Mark Gaiser > >
Re: QML-using app developers: use private.* imports
On 2013-09-25, Sebastian Kügler wrote: > On Wednesday, September 25, 2013 17:51:41 Mark wrote: >> Doesn't your naming proposal completely ruin the org.kde.* stuff? Up until >> now i could fairly safely assume that all QML KDE imports where hidden >> under org.kde.* but that isn't the case anymore if you introduce >> private.org.kde.* > > That's exactly the point: we don't want you to find it, much less to rely on > it. It's basically application internal "stuff" you have no business with. > >> It looks like you miss a part in the url.. I would say something like this: >> org.kde.public.* = public imports >> org.kde.private.* = private imports >> >> But that would require changing all existing components to reflect this >> idea.. > > That, and it would encourage to maybe use it as second class API, and still > cause us the same problems. QML is not my specialty, but clearly stuffing private/internal stuff away is a great thing. Given QML is a interpreted thing, you need to have all the bits installed, so clearly marking something for 'stay away' is needed. We can't do like in c++ where we choose to just not install some headers. It would btw be great if upstream could agree on private.* for 'please stay out of this'. /Sune
Re: Review Request 112816: Do not use internal headers in kcolorutilsdemo
> On Sept. 24, 2013, 2:23 p.m., Sune Vuorela wrote: > > tier1/kguiaddons/src/lib/colors/kcolorutils.cpp, line 42 > > <http://git.reviewboard.kde.org/r/112816/diff/1/?file=190519#file190519line42> > > > > My initial reaction is that it could return a bool wether or not things > > went okay, given there is a 'path that does nothing' in the code. Besides > > that, everything looks great. > > Aurélien Gâteau wrote: > I wrote it this way to be consistent with QColor::get*() methods. I think > users of such code are going to be used to QColor API, so it makes more sense > this way, what do you think? I'm convinced. - Sune --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112816/#review40692 --- On Sept. 24, 2013, 2:19 p.m., Aurélien Gâteau wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/112816/ > --- > > (Updated Sept. 24, 2013, 2:19 p.m.) > > > Review request for KDE Frameworks and kdelibs. > > > Description > --- > > This is a two-commit patch: > > 1. Add a KColorUtils::getHcy() method > > 2. In kcolorutils demo: use KColorUtils::getHcy() instead of the internal > KColorSpaces::KHCY > > This is a required first step to make kconfigwidgets build standalone > > > Diffs > - > > staging/kconfigwidgets/tests/kcolorutilsdemo.cpp 940569e > tier1/kguiaddons/src/lib/colors/kcolorutils.h c20c6f7 > tier1/kguiaddons/src/lib/colors/kcolorutils.cpp 9212bba > > Diff: http://git.reviewboard.kde.org/r/112816/diff/ > > > Testing > --- > > kcolorutilsdemo still works. > > > Thanks, > > Aurélien Gâteau > >
Re: Review Request 112816: Do not use internal headers in kcolorutilsdemo
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112816/#review40692 --- tier1/kguiaddons/src/lib/colors/kcolorutils.cpp <http://git.reviewboard.kde.org/r/112816/#comment29951> My initial reaction is that it could return a bool wether or not things went okay, given there is a 'path that does nothing' in the code. Besides that, everything looks great. - Sune Vuorela On Sept. 24, 2013, 2:19 p.m., Aurélien Gâteau wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/112816/ > --- > > (Updated Sept. 24, 2013, 2:19 p.m.) > > > Review request for KDE Frameworks and kdelibs. > > > Description > --- > > This is a two-commit patch: > > 1. Add a KColorUtils::getHcy() method > > 2. In kcolorutils demo: use KColorUtils::getHcy() instead of the internal > KColorSpaces::KHCY > > This is a required first step to make kconfigwidgets build standalone > > > Diffs > - > > staging/kconfigwidgets/tests/kcolorutilsdemo.cpp 940569e > tier1/kguiaddons/src/lib/colors/kcolorutils.h c20c6f7 > tier1/kguiaddons/src/lib/colors/kcolorutils.cpp 9212bba > > Diff: http://git.reviewboard.kde.org/r/112816/diff/ > > > Testing > --- > > kcolorutilsdemo still works. > > > Thanks, > > Aurélien Gâteau > >
Re: Review Request 112852: Proposed patch to enable compilation of nepomuk-core on Mac
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112852/#review40588 --- Ship it! Ship It! - Sune Vuorela On Sept. 21, 2013, 7:53 a.m., Nicolas Pavillon wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/112852/ > --- > > (Updated Sept. 21, 2013, 7:53 a.m.) > > > Review request for kdelibs and Nepomuk. > > > Description > --- > > Patch to solve the bug reported at > https://bugs.kde.org/show_bug.cgi?id=325058. > > > This addresses bug https://bugs.kde.org/show_bug.cgi?id=325058. > > http://bugs.kde.org/show_bug.cgi?id=https://bugs.kde.org/show_bug.cgi?id=325058 > > > Diffs > - > > tools/nepomukctl/main.cpp 9d350ea > > Diff: http://git.reviewboard.kde.org/r/112852/diff/ > > > Testing > --- > > Applied the patch on several OS X platforms to ensure that compilation does > not crash. See https://trac.macports.org/ticket/40498 for details. > > > Thanks, > > Nicolas Pavillon > >
Re: Releases in 3 months
On 2013-07-14, Inge Wallin wrote: > Here are some assumptions. Correct me if they are wrong: > - KDE developers support the last relesed and *maybe* the second to last > release with bugfixes. > - Distributions have a release cycle of 6 months or longer. > - Distributions pick their contents 2-3 months in advance, at least I think these assumptions in general are correct, with some exceptions (the rolling distros like arch and gentoo to one side, and distros like debian in the other side). > So therefore I am against the proposal. I think keeping 6 months is a good > figure to ensure both reasonable turn-around *and* actual bugfixes of > versions > being used in the real world. Thank you for a very well-written email. /Sune
Re: Releases in 3 months
On 2013-07-10, Àlex Fiestas wrote: > I can't fight with distros, and I don't want to fight with them. If distros > need .5 .6 and .200 so be it, just they will have to do them themselves (and > I > hope we can make the process smooth so they can actually do it). > > As has been said in this thread, almost no KDE developer is using the stable > branch, blindly backporting has shown to be dangerous and has created many > issues in the past so we are not the right people to make these point > releases. Other developers has said in other contexts 'do not backport patches without running them thru me'. The maintainer of the code in question is the best one to judge wether or not a given patch is suitable for backporting or not. All the rest of us don't know the code as well. So I really do think that marking patches for backporting *should* be done by the people behind the code, not by others. But thank you for making it clear that a large part of the reasoning for this proposal is that you want to drop maintenance of our product. /Sune
Re: Releases in 3 months
On 2013-07-10, Aaron J. Seigo wrote: >=3D=3D On scheduling mainenance releases > > in a longer 4 month cycle, i=E2=80=99d cut that to 8 weeks and keep jus= > t the one=20 > update. > > this would ease the burdon on our release team (and by extension packag= > ers)=20 > while also giving developers more time to get better tested fixes in. I don't think that it would lessen the burden on anyone. And as long as our quality of our stable releases is like they are, we need the first couple of point releases early. I would feel compelled to be much more on top of branch and maybe do branch updates when it fits my schedule rather than just wait for the next scheduled release, because it comes too late. and then I end up snapshotting other people's code maybe in a state where they weren't ready to do it. > > i don=E2=80=99t have a strong opinion or compelling thoughts here, othe= > r than to=20 > remind us that 3 is not the only number we can consider in this :) We could also consider 6 :) >=3D=3D On people being awesome ack. /Sune
Re: Releases in 3 months
On 2013-07-09, Sune Vuorela wrote: > So. first one. Second one Release frequency. We have a giant quality problem. Distros won't ship a .0 release to real users (as opposed to testers/power users) and wait until there has been a couple of bug fix releases. Until we ensure that our .0 releases are usable I don't see how we can cut down on that. Some distros release in a 6 month cycle. Others in a 8. and ones even in longer cycles. Going for anything shorter than 6 months will ensure that distros are going to skip releases. why work with releases that they aren't going to ship to users anyways? And given there need to be some stabilization and integration work, I'm sure skipping releases would be the default for most distros. Hopefully distros can coordinate and at least skip the same. Mostly leading to the other releases being useless because they only reach very few users. So, more work for most people, but no one gains. And as it currently is, we need the .4 and .5 releases. /Sune
Re: openSUSE packagers' take on the 3 month release cycle
On 2013-07-09, Àlex Fiestas wrote: > If we keep copyright holders and licence, we can change the structure of the > header, no? We can. /Sune
Re: Releases in 3 months
On 2013-07-08, Àlex Fiestas wrote: I'm going to provide a handful of replies, each dealing with different aspects of this - hopefully I will post them all over the next couple of days. I will try to keep them short. So. first one. > Basically the idea is to cut testing time and compensate it by keeping master > always in a "releaseable" state, now that two major components are frozen it > looks like it is a good time to get used to it. I once learned by a guy who was trying to make his moped go faster that one should always only adjust one thing at a time, to figure out if the one thing you do has the effect you want. Adjusting several things at once makes it hard to figure out what actually was the reason behind it. I kind of agree with that, and thun I think it is a bad idea to adjust several factors at the same time. one is switching to a 'always summer in trunk'-approach. Another is switching the release frequency. Doing both at once makes it hard to see if one is wrongly thought thru. So if we are going forward with this, i would suggest to just move forward with 'always summer in trunk' for a while and then later look at release frequency, if it turns out that we can work with "always summer in trunk". That's all for now. I hope my remaining mails can be kept as short. /Sune
Re: openSUSE packagers' take on the 3 month release cycle
On 2013-07-09, Vishesh Handa wrote: > On Tue, Jul 9, 2013 at 6:08 PM, Harald Sitter wrote: >> there would not be any problem. But reality diverges :( > > I'm all for fixing this in at least KDE SC. That way if/when we have > shorter releases you can have some kind of guarantee that you will not > encounter strange behaviours like the one you described. try get okular source code (Or another app that has been around since forever) then install midnight commander (mc) and set the right pane to quickview. Now you can see in the right pane all the various licensing headers while you in the left pane scrolls tthur the files. Try also libkdcraw. or kdepim. But all this is mostly old code. Looking at something new like nepomuk-core or okteta, the licensing is quite clear and conformant to be automatically figured out. /Sune
Re: K(Abstract)FileItemActionPlugin
On 2013-06-20, Frank Reininghaus wrote: > That would be great. I don't really know when will be the next time > Thanks for your help and best regards, Done. Regards, Sune
Re: K(Abstract)FileItemActionPlugin
On 2013-06-20, Frank Reininghaus wrote: > I admit that the current "solution" is an ugly hack. But it was never > meant to be an "arms race". Please note that I proposed and > implemented this at a time when Ivan still refused to acknowledge that > there is a bug in his plugin at all. There was no real solution in > sight, so a hackish workaround was the only way to protect users who > have the plugin installed on their system (i.e., everyone who uses > KDE) and who do not use it, from its bugs. And to be honest, I also > needed this for myself, to prevent that this extremely frustrating > experience completely ruins my motivation to work on KDE in my free > time. I fully understand that getting blame for such issues that one has absolutely no control over can lead to fustration and decrease motivation. I might also, had I been in your wanted to do something about it. I have also - as a user - run into that bug a couple of times and cursed quite a bit. I found it in the right click menu of konqueror (web browser) though, not in the file manager. >> so Frank, please, pretty please, can you reconsider? > > I see that Ivan rewrote the plugin and that it does at least not do > anything fishy any more before the context menu is shown. I also > understand that people who do not have to deal with the bug reports > mess and only see the possible benefits of the plugins don't like my > proposal to disable all plugins by default. I haven't - yet - seen such bug reports, but that's mostly because we are a bit behind in Debian. I'm sure that, if it wasn't fixed, I would have recieved multiple bug reports there about the issue. And I'm pretty sure that most people active in this thread has seen the downsides of plugins or at least thought about them. > So yes, I am willing to > reconsider, and I don't mind if the ugly workaround is removed before > the API freeze. But I'd appreciate it if someone else (Sune maybe?) > could make the changes in the three repositories. I have wasted so If you want, I can allocate the time tonight to remove the workaround in the ~three repositories. Best Regards Sune
Re: K(Abstract)FileItemActionPlugin
On 2013-06-19, Thomas Lübking wrote: >> If I was a plugin developer here, I would of course think my plugin >> should be enabled by default and thus in my ctor call >> setEnabledByDefault(true) > > I would suggest to leave the path of plugin enabling as solution asap - it's > not a solution at all. Yes. That would also be my suggestion, but Frank has actually committed code to kdelibs master that does this - targetting 4.11. Unless we revert it quite fast, we will have to stick with it, the setEnabledByDefault(bool), function. Having such a facitily also gives much wider implications: 1) is it allowed to ship poor plugins if they aren't enabled by default? 2) must other users FileItemActionPlugins also have to adapt to this? > Synchronous I/O in the GUI thread can, at least post-init, be reasonably > considered a bug. I agree that bugs should be fixed, not worked around. And not by starting arms races. so Frank, please, pretty please, can you reconsider? /Sune
Re: K(Abstract)FileItemActionPlugin
On 2013-06-17, Frank Reininghaus wrote: > Yes, it can block for random reasons, and this is why making D-Bus > calls in the code that is executed before the context menu is shown is > unacceptable IMHO. I agree with the problem. But the issue is to *fix* kactivities to not do something insane. The fix isn't to make it harder for the normal sane users nor actually start a arms race between you and plugin developers If I was a plugin developer here, I would of course think my plugin should be enabled by default and thus in my ctor call setEnabledByDefault(true); and then we are back to the drawing board, only with a extra added layer of complexity. /Sune
Re: startkde modifies PATH to add qt4 bin dir to the front
On 2013-06-16, Albert Astals Cid wrote: > So my path in a Plasma session is > /usr/lib/x86_64-linux-gnu/qt4/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games > > This makes the QT_SELECT thing from qtchooser not work > since if i do > QT_SELECT=qt5 moc > i still get the /usr/lib/x86_64-linux-gnu/qt4/bin moc in path first > > Any idea why are we doing that? I'm pretty sure it is so that we can reach qdbus even when no Qt is installed in system directories. > Do we still need this? Can we at least change it so the path is added to the > end? > > It is reported and assigned to noone in > https://bugs.kde.org/show_bug.cgi?id=320623 We could at least wrap it in a if ! which qdbus >/dev/null ; then modifypath ; fi But we need to do something. /Sune
Re: Crashes with libQtUiTools.a if linked multiple times into the same process (with Bsymbolic-functions flag)
On 2013-05-11, Friedrich W. H. Kossebau wrote: > So, anyone with more clue than me WRT symbols from static libs and the > Bsymbolic-functions linker flag who could tell if that indeed should fix such > problems if code from the same static lib is arriving multiple times in the > same process via different libs/modules? It most likely will help on such a case. -Bsymbolic-functions ensures that functiotns are first resolved in the library/plugin itself before resolving it from outside the library. What happens, I think, is that it is sometimes using the functions from one of the static libs, other times from some of the other. I'm not sure we want libraries linking QtTools to be built with -Bsymbolic-functions because it breaks debugging and other magic using function overriding with LD_PRELOAD tricks, because they rely on being chosen first over the 'internal' functions. /Sune
Re: Initialization of QSharedDataPointer's for empty objects (i.e. Foo::Foo(void))
On 2013-04-29, Milian Wolff wrote: > I do wonder though why QString has both, a shared_empty and a shared_null > object. A single one should suffice for most objects, no? I'm pretty sure this is because QString can be empty and not null. e.g. the difference between QString() the empty string. /Sune
Re: Review of kdev-python for move to extragear
On 2012-12-25, Sven Brauch wrote: > Also, I'm still not sure what exactly concerns you about security and > maintenance. Problems I see include increased build time, and > maintenance efforts for me personally in updating the fork, but none > really seem fatal. Can you elaborate a bit about which problems you One of the problems are that in a distribution like debian and/or ubuntu has around 60-70 patches against python2.7 to ensure it builds and works everywhere. All these patches might also be needed the extra copy - and given the extra copy is modified, then these patches might need to be adapted. Another of the problems is that if there is a security bug in libpython, then instead of just doing a security fix to python, one also needs to do one to kdev-python. The first problem is large amount of work for the distribution packagers, and the second problem is quite annoying for distribution security teams. All of this applies to every embedded library. And python is a quite big thing. /Sune
Re: kcmsambaconf removed from kdenetwork-filesharing
On 2012-12-01, Del wrote: > I just realised that System Settings no longer has the kcmsambaconf module > for > configuring Samba. The only trace I found of the decision was a Debian bug > report: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691634 It is available. it can be reached thru the file manager. /Sune
Re: Moving ktouchpadenabler to kdebase^Wkde-workspace
On 2012-10-13, Albert Astals Cid wrote: > Back when I moved ktouchpadenabler to extragear-base Christoph mentioned he'd > like to see it in kdebase[1], we don't have a kdebase anymore though. > > Anyway i'd like to move it to a more central place, I guess kde-workspace > would be the place for this kind of stuff? > > For those that don't know/remember does it is a *very simple* (200 lines) > kded > module that listens to > XF86XK_TouchpadToggle/XF86XK_TouchpadOn/XF86XK_TouchpadOff key presses and > toggles/enables/disables your touchpad accordingly. > > You can find it's code at kde:ktouchpadenabler or browse it online at > http://quickgit.kde.org/index.php?p=ktouchpadenabler.git > > Comments? I think it make a perfect fit in -workspace. I was actually hoping for it to end up there one day once it is ready. Which seems to be now :) /Sune
Re: Review Request: Start the notification service if it is dbus autostartable and we are not in a full kde session
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106780/#review20172 --- Ship it! Ship It! - Sune Vuorela On Oct. 10, 2012, 1:20 p.m., Albert Astals Cid wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/106780/ > --- > > (Updated Oct. 10, 2012, 1:20 p.m.) > > > Review request for KDE Runtime. > > > Description > --- > > This makes the notifications of kmail show up though the proper unity > notifications when running on unity instead of though the "ugly-ish" passive > popups > > > Diffs > - > > knotify/notifybypopup.cpp 213421c > > Diff: http://git.reviewboard.kde.org/r/106780/diff/ > > > Testing > --- > > Works fine both in unity and in plasma desktop (i.e. does not autostart > anything) > > > Thanks, > > Albert Astals Cid > >
Re: Use of bin versus libexec
On 2012-09-20, David Faure wrote: > We really need a FHS addition for libexec. not really. the libexec executables is in general a implementation detail of the given library. We have the rare case in KDE that we actually call other libraries' executables, which is a different thing, and one I have the impression is declining a bit. ..and by sharing libexec locations between unrelated libraries, we get the joys of possible collisions, of executing other libraries implementation details by accident with all the mess that is created by that. /Sune
Re: Use of bin versus libexec
On 2012-09-20, Kevin Krammer wrote: > Do you mean $PREFIX/libexec, where $PREFIX will often be /usr (for=20 > distribution packages)? that only works in redhat/fedora land. In other distributiotns, like debian and ubuntu, libexec is placed in directories under prefix/libdir/libraryname/ - e.g. /usr/lib/kde4/libexec or /usr/lib/utempter/ /Sune
Re: Use of bin versus libexec
On 2012-09-20, Kevin Krammer wrote: > Agreed. It is important, however, to remember that some of those (e.g.=20 > akonadiserver, akonadi_control) are not KDE programs and can therefore not = > be=20 > in a KDE specific libexec location but have to go into a standard (FHS or=20 > freedesktop.org) location for that purpose. Or in a akonadi specific location... like $prefix/$libdir/akonadistuff/ /Sune
Re: When do we need to update KSYCOCA_VERSION ?
On 2012-08-30, David Faure wrote: > I think this is a "belt and suspenders" kind of thing (extra precaution)... > in > theory it's not necessary, kded will detect new desktop files on kde startup, > or during the upgrade process if KDE is already running. > > I wonder if Waldo added that (long ago) for the case where we change fields > in > ksycoca and forget to increase the version number while doing so. It is, though, highly annoying when the number is changed as, if I understand things correctly, it requires a relogin and restart of everything immediately after upgrade (and not when it fits your workflow a bit later) in order to keep applications that loads plugins or uses kio working /Sune
Re: When do we need to update GENERIC_LIB_VERSION / KDE_NON_GENERIC_LIB_VERSION ?
On 2012-08-29, Albert Astals Cid wrote:
> Yes, this is what we did.
>
> Let me rephrase the question.
>
> Is what we did the correct thing? (I'm not saying it is or it is not, just
> that i have to tag 4.9.1 tomorrow and i want to know if I have to increase
> that or not).
having them saying {4,5}.9.1 for 4.9.1 is the good thing to do.
/Sune
Re: [RFC] Merging LightDM into KDE Workspaces (forwarded from plasma-devel)
On 2012-08-22, David Edmundson wrote: > release. This isn't a decision forced by Canonical, they just think > it's better, though obviously it helps that the backend is already > tested on Ubuntu. Other distributions have also expressed an interest, Is LightDM a canonical project? one that is covered by the license agreement htat several high profile kde developers have refused to sign? I remember the adventure with dbusmenu-qt, a canonical project, wasn't too pleasant because of that. > obviously I do feel mine is better. What I would like to do is discuss > moving LightDM into KDE workspaces _alongside_ KDM and making > compiling KDM optional, but keeping it enabled by default. >From my personal view and as a packager, I would say "we only need *one* display manager in the workspace". So, if lightdm comes, then KDM must go in my opinion. > Features KDM has that are still missing in LightDM-KDE > - ability to switch X sessions > - connect to remote XDMCP sessions > - Get hot new stuff/theme installer > - Ability to reboot into a different grub entry(not that that > actually works for me) > > What's coming in the future: > - everything important KDM has :) Which of the above bits is not important? /Sune
Re: KDE SC 4.8.4 important problems
On 2012-06-12, Sebastian Trüg wrote: > I do not have much time. But the real problem is that I am not sure > where to look. It has to do with my own implementation of unix socket > communication. Someone with experience in that area might want to review > the *Socket* classes in soprano/client... This might be a stupid question, but isn't soprano 2.6 using QLocalSocket ? I was btw trying to track down what is going on. I'm still unsure why it is crashing, but a launch of e.g. gwenview is deleting & recreating GlobalModelContainer::localSocketModel and related bits 6 times. in newer kdelibs (when init(true) is called) and I'm not sure if references to the old localSocketmodel can still be around. I agre with Jose Santamaria Lema that something in that commit looks a bit fishy. /Sune
Re: KDE SC 4.8.4 important problems
On 2012-06-12, Vishesh Handa wrote: > --bcaec554d60626569204c246cba9 > Content-Type: text/plain; charset=ISO-8859-1 > > Yeah. So Nepomuk is the cause of the problems - > > Here our our options - > > 1. I revert Sebastian's commits in kdelibs. This should fix the issue, but > we would need to reintroduce the changes for 4.9, and since we do not have > separate branches ... > > 2. Sebastian should release a new version (2.8) of Soprano any day now, > packagers will need to get everyone to update. 3. Actually track the bug down and fix it rather than try to do workarounds? This sounds like the most obvious thing to me. /Sune
Re: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+
On 2012-06-11, Sebastian Kügler wrote: > I'd consider that a bug in your packaging. There's no absolute requirement of > an app for a specific version of kdelibs. If your packages need that, you > should probably fix them. The decoupling of libs and apps, and especially the > modularization of kdelibs into Frameworks will only reveal more problems with > your packages. The actual issue from my pov is that the file paths in $othermodules is dependant on the kdelibs version. the y in libfoo.so.x.y.z is inherited from kdelibs in most other modules. /Sune
Re: Nepomuk - Moving out of kde-runtime
On 2012-05-17, Sebastian Trüg wrote: > I think we can manage BC. The only thing that would be hard are the DBus > interfaces. But since nepomuk-core contains client libs which are > supposed to be used instead of the dbus interfaces... Great. thanks. hugs and kisses /Sune > > On 05/17/2012 09:19 PM, Sune Vuorela wrote: >> On 2012-05-17, Vishesh Handa wrote: >>> @Packagers: We will not be maintaining binary compatibility in >>> nepomuk-core. At least not for KDE 4.10. We still need to break a lot of >>> things. >> >> NACK. >> >> this is a completely no go. >> >> /Sune >> >> >
Re: Nepomuk - Moving out of kde-runtime
On 2012-05-17, Vishesh Handa wrote: > @Packagers: We will not be maintaining binary compatibility in > nepomuk-core. At least not for KDE 4.10. We still need to break a lot of > things. NACK. this is a completely no go. /Sune
Re: The Nepomuk Situation
On 2012-05-07, Vishesh Handa wrote: > I'm not okay with applications having to stick with the old faulty APIs I'm not okay with a api or abi break in kdelibs. /Sune
Re: The Nepomuk Situation
On 2012-05-07, Vishesh Handa wrote: > Right. > > We could maintain BC and SC by not touching the kdelibs nepomuk, and just > making nepomuk-core a dependency of kdelibs. But that would result in both > nepomuk-core and kdelibs installing the same headers. what happens if both libraries are loaded into the same process? /Sune
Re: Extra KDE Telepathy modules moving to Extragear
On 2012-04-28, George Kiagiadakis wrote: > No, the classes that wrap GObjects do not need a d-pointer. All the > calls are forwarded to the underlying GObject and if for any reason we > ever need to save extra data on the wrapper class (which is highly > unlikely), we should use the GObject qdata for that. Wrapper classes > may be destroyed and re-allocated by QtGLib and therefore they > shouldn't hold any data. aren't you this way also locking your self to always require just to wrap the GObject classes and not actually have the possibility to do teh implementation without the GObject classes at all ? /Sune
Re: Exposing KSSL in KIO
On 2012-04-06, Thiago Macieira wrote: > > --nextPart4816581.q9J4AAnfuU > Content-Transfer-Encoding: 7Bit > Content-Type: text/plain; charset="us-ascii" > > On sexta-feira, 6 de abril de 2012 01.14.34, David Edmundson wrote: >> > I don't think so. The classes are likely not to be exported. >> >> Weirdly they are. At least there's a "KIO_EXPORT" in the class >> definition in the header of KSSLCertificate. > > Then they are exported. I didn't check the file, I just spoke in terms of > likelihood (I can't think of anyone that would want to use them aside from > KIO > handling). > > If they are exported, you might be able to do what you want. but please please pretty please don't. if headers aren't installed it is not public api and then you should stay out of it. really. /Sune
Re: [GSoC] KWin colour management
On 2012-03-22, Daniel Nicoletti wrote: > people draw API they have this in mind and we don't need a whole new Qt just > to > introduce a new feature, easy solution: QApplication::setColorCorrected(true); That's crap API thoug.h QApplication::setBehaveSane(true); QApplication::setPleaseDontCrash(true); QApplication::pleaseFixMyBrokenApplication(true); /Sune
Re: Review Request: include KolorManager in kdegraphics
On 2012-03-14, Lamarque V. Souza wrote: > I should stop working in Plasma NM then since for distributions that > ships Gnome as default desktop nm-applet is the standard. erm. you are aware that colord better can be compared to NetworkManager than to Plasma NM ? /Sune
Re: Review Request: include KolorManager in kdegraphics
On 2012-03-14, Lamarque V. Souza wrote: > You are talking as if colord is the default standard and well used in > KDE and then out of a suden comes oyranoes trying to replace it. Colord is > not > wide used in KDE and since oyranos includes a wider feature set I guess it is No. colord seems to be the default standard for linux. unless we have a good reason, I don't see why we should go for anything else. > more usefull for a wider range of users. As said in other e-mails colord is > required in Gnome3, so why not add oyranos to kdegraphics since other KDE > software already work with it? erm. kolor-manager is currently the only tool working with oyranos as I understood it. so we should add it because it is already there? /Sune
Re: Review Request: include KolorManager in kdegraphics
On 2012-03-14, Boudewijn Rempt wrote: > It's easy enough to package -- the opensuse packages I use work perfectly > fine, so I cannot imagine that there are any real and relevant problems > for other distributions. Sure it can be done. but it is just useless churn if it doesn't really provide anything that matters to the end user that colord doesn't. I could package oyranos and the weird things it requires. but in the same time I_could probably fix 20 small annoyances for all users and package the new nice nepomuk ioslaves. What is the best use of my time? /Sune
Re: Review Request: include KolorManager in kdegraphics
On 2012-03-14, Daniel Nicoletti wrote: >> Request: > >> After working on KolorManager and Oyranos in the past months for the last >> Oyranos-0.4.0 release, we feel the stack is ready to review for inclusion >> into >> KDE. >> KolorManager resides currently in Playground/Graphics: >> http://quickgit.kde.org/?p=kolor-manager.git&a=summary > > Just a quick question, currently we have two CMS stacks, colord and > oyranos, while > I have nothing against having two of them in KDE I would really prefer to at least have one common gui. preferably just one stack. But if we have to have two competing stacks until one of them dies, then I guess we will just have to live with it. But do it with a common gui. pretty please. > I wonder if this would become > a problem for colord-kde [1] to enter in kdegraphics too? In that case > would be better > to both go to kdeextragear or is there some different policy in this case? I hope that we aren't going to select a solution based on who is a month faster than the other. /Sune
Re: bugzilla situation
On 2012-02-22, David Faure wrote: > up with was the few cases where bugs turned into actual political flamewars; > his answer was obviously "give rights to everyone, and remove rights when > someone abuses them". This is also what we do for SVN/GIT, so why don't we do > this for bugzilla? Presuming people are innocent upfront, rather than guilty Everyone can manipulate with bugs in the debian bugtracking system. There is very littel abuse. From time to time, assholes drop by but usually tehy can actually be educated to at least find another place for their trolling. beside that, the debian bts blacklist, iirc called politely @gFuckheads, has over time had around 10 people on it or so. /Sune
Re: Binary compatiblity for liboxygenstyle.so
On 2012-02-24, Hugo Pereira Da Costa wrote: > I understand that. The point I was trying to make, is that you would > still get the "old" pluggin, admittingly without crashing, but which > would nonetheless be not correct. Whattabout just linking liboxygenstyle static into the oxygen style? Problem solved. No more abi to manage. Alternatively, set the SOVERSION of liboxygenstyle to the version of KDE Workspace. As you have no external dependencies outside kde-workspace this should not give any problems for anyone. /Sune
Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?
On 2011-10-03, Allen Winter wrote:
> On Monday 03 October 2011 5:04:45 AM Albert Astals Cid wrote:
>> A Dilluns, 3 d'octubre de 2011, Alexander Neundorf vàreu escriure:
>> > On Monday 03 October 2011, Allen Winter wrote:
>> > > Howdy,
>> > >
>> > > A lot of CMakeLists.txt use the ${GENERIC_LIB_VERSION} to set the so
>> > > versioning of their libraries. That variable is hard-coded in
>> > > kdelibs/cmake/modules/KDE4Defaults.cmake
>> > >
>> > > If we rely on kdelibs-4.7 for the KDE SC 4.8 release, then all the
>> > > shared
>> > > libraries using ${GENERIC_LIB_VERSION} will be still set to 4.7. for
>> > > example the kdepimlbs kcalcore library will be versioned to 4.7.0
>> > > instead
>> > > of 4.8.0 in the KDE SC 4.8 release.
>> >
>> > How about simply increasing the version number to 4.8 ?
>> > This would also give the libs in kdelibs the version number 4.8, but I
>> > don't
>> > see a problem with that.
>>
>> Third time in this thread. This is Dirk's plan all along.
>>
> Ok then.
> If there are no objections I will increase the variables in kdelibs-4.7 to
> say "4.8"
erm. I think it was the plan to do it when we are about to release 4.8.
not now.
/Sune
Re: Who relies on Soprano::Model::statement[s]Added|Removed signals?
On 2011-09-30, Albert Astals Cid wrote: > A Divendres, 30 de setembre de 2011, Sebastian Trüg vàreu escriure: >> Hi lists, >> >> with frameworks in the building and Nepomuk probably going that >> direction already for 4.8 I would like to clean up a bit. One of these >> cleanup tasks targets the Soprano::Model statement signals. So far these >> were the only way to get informed about changes in Nepomuk - with a very >> bad impact on performance and bad usability. >> With 4.7 we already introduced a preliminary version of the >> Nepomuk::ResourceWatcher[1] which is now in charge of informing clients >> about changes. >> I would like to anyone using the "old" API to change to the new >> ResourceWatcher as soon as possible because I would like to disable the >> old signals soon. They simply entail to many problems and clutter the API. > > Removing signals of what seems to be an existing public class/daemon is a > very > bad idea and you should wait until 5.0. Full ack. /Sune
Re: KNotify-considerations for frameworks
On 2011-09-22, Albert Astals Cid wrote: > This means that as a user if the developer decides to use a "Popup" I can no > longer configure the application to do nothing? Or to play a sound? No. It just means that the responsibility is handed over to the application developer if they want to offer that functionality, rather than now where the notification settings dialog more feels like something badly welded on to the application rather than being a part of the application. I've asked around my local circles (not my internet circles) which of such functionality tehy use, and the only configuration option tehy use is to globally disable all audible notifications. > Seems like > a huge loss of functionality to me. It's at least a change, and a small loss of functionality. And a huge reducement in complexity. Does the advantages outweigh the disadvantages in what I'm proposing? I think so. But I want to discuss it before actually starting to write any code in case it is just me who is weird. /Sune - developer for hire
Re: KNotify-considerations for frameworks
On 2011-09-22, Sune Vuorela wrote: ...and of course, bits of my drafts fell out when doing the last reorder of things. > Hi > > I'm considering doing some work on the knotify-stuff for the kde > frameworks. > This involves the KNotification class and the KNotify daemon and related > classes. > > I started hacking a bit on it in Randa, but have ended up scratchig my > work and starting over. http://pusling.com/blog/?p=200 > > Currently, it is a quite complex framework that is hard to debug for the users > of knotify (the application developers). It seems a bit overengineered, > at least compared to how many of the features that is normally used. > > the full knotify stack can notify users in I think at least 5 different > ways: > Popup > Sound > Run-a-command > kttsd > nothing > > But, for the developer that's not currently something to *directly* care > for. The developer creates a KNotification object and sends it. This > communicates over dbus to the knotify daemon. The knotify daemon looks > up in the configurations what to do with it, and then does that. The configuration that the user has the possibility to do is not very userfriendly, nor really integrated with the application. > What does it do? > For Popup, which is the all-dominating case, it sends out a > org.freedesktop.Notifications conformant message (galago spec) > > For nothing, which is the next case, it does nothing > > for Sound, it plays something using phonon > > for kttsd it sends a dbus message to kttsd > > and for run-a-command, it runs the specified command. > > The user can of course change what a notification does. > > > What I would like to do is the following: > > Create a handful of classes, either in a separate library or in a > fitting library, basically giving a public api to skip over the > configuration bits and knotify bits for the Popup case. There is code > available for several platforms already in the knotify code. Consider doing some classes for Phonon to do audio notifications for those who needs that or alternatively get a cross desktop audio notification dbus spec, just like the galago spec and get the workspaces to implement it. (Issue here might be that Gnome has chosen that one need to link libcanberra for audio notifications) > Make teh current knotify stack use the above code for popups and move it > either to kde4support or to the high level platform integration bits. > Depending on where it goes, I would like to also fold in the knotify > daemon into the KNotification classes, as a daemon to - mostly rewrite > dbus messages - seems a bit extreme[x]. > > > Comments, requests for more details and questions are most welcome > > /Sune > - developer for hire > > > x) Yes. There is also two other uses. 1) to keep applications from > having to link phonon for audionotifications and 2) to make sure that > audio notifications will be played to the end when quitting a app > >
KNotify-considerations for frameworks
Hi I'm considering doing some work on the knotify-stuff for the kde frameworks. This involves the KNotification class and the KNotify daemon and related classes. I started hacking a bit on it in Randa, but have ended up scratchig my work and starting over. http://pusling.com/blog/?p=200 Currently, it is a quite complex framework that is hard to debug for the users of knotify (the application developers). It seems a bit overengineered, at least compared to how many of the features that is normally used. the full knotify stack can notify users in I think at least 5 different ways: Popup Sound Run-a-command kttsd nothing But, for the developer that's not currently something to *directly* care for. The developer creates a KNotification object and sends it. This communicates over dbus to the knotify daemon. The knotify daemon looks up in the configurations what to do with it, and then does that. What does it do? For Popup, which is the all-dominating case, it sends out a org.freedesktop.Notifications conformant message (galago spec) For nothing, which is the next case, it does nothing for Sound, it plays something using phonon for kttsd it sends a dbus message to kttsd and for run-a-command, it runs the specified command. The user can of course change what a notification does. What I would like to do is the following: Create a handful of classes, either in a separate library or in a fitting library, basically giving a public api to skip over the configuration bits and knotify bits for the Popup case. There is code available for several platforms already in the knotify code. Make teh current knotify stack use the above code for popups and move it either to kde4support or to the high level platform integration bits. Depending on where it goes, I would like to also fold in the knotify daemon into the KNotification classes, as a daemon to - mostly rewrite dbus messages - seems a bit extreme[x]. Comments, requests for more details and questions are most welcome /Sune - developer for hire x) Yes. There is also two other uses. 1) to keep applications from having to link phonon for audionotifications and 2) to make sure that audio notifications will be played to the end when quitting a app
Re: RFC: replacing MacroLogFeature.cmake with FeatureSummary.cmake
On Thursday 14 July 2011 03:42:01 Michael Jansen wrote: > On Thursday 14 July 2011 10:49:50 Ian Wadham wrote: > > On 14/07/2011, at 5:16 AM, Alexander Neundorf wrote: > > > What do you think of this ? > > > More wishes ? > > > Should it do it in a different way ? > > > > Very nice. I especially like the PURPOSE concept. > > > > As we discussed before, in connection with use of OpenAL sound > > in some games, could it be possible to have grades of requirement > > in between REQUIRED and OPTIONAL? They would not bomb out > > the cmake run, but should issue some stronger message that the > > requirement was not met than just saying it was "optional". > > I would suggest RECOMMENDED. Like it works without but we think its really > less useful then. > > OPTIONAL would be stuff then that enabled additional functionality that is > not really needed for all of us. like something that add iphone support. > not everyone has one. Several packaging systems has 3 levels of relations. stuff that must be there. RPM-language: Requires. Deb-language: Depends. optional stuff that should be there by default on normal systems RPM-language: Recommends. Deb-language: Recommends Optional stuff that gives something extra RPM-language: Suggests. Deb-language: Suggests. Maybe we could be inspired by that? Note that on debian systems, apt and aptitude installs Depends and Recommends by default, and allows Recommends to be removed without removing other package. Yum don't know about Recommends nor Suggests and just installs Required packages. /Sune -- Genius, I cannot doubleclick the OpenGL fan over a file to the ISA attachment on the device of the fan, how does it work? From Word you neither must doubleclick on the 4X driver, nor should insert a SIMM to boot a coaxial icon.
Re: -Wunused-but-set-variable warnings
On 2011-07-04, Albert Astals Cid wrote:
> --Boundary-01=_YFgEOebgzUxkqvf
> Content-Type: text/plain;
> charset="us-ascii"
> Content-Transfer-Encoding: 7bit
>
> A Monday, July 04, 2011, Dawit A va escriure:
>> The following files all contain set but unused variables:
>>
>> snip
>>
>> Unlike the -Wunused-parameter fixing this warning messages requires
>> context because the variable may be set and unused due to a mistake
>> that can potentially be causing a bug. As such can kdelibs cmake file
>> be changed to error out, -Werror=unused-but-set-variable, for such
>> warnings ?
>
> You really want to make kdelibs uncompilable?
I expect him to make kdelibs clean for these warnings first.
(these=unused-but-set-variable).
it is for things like
{
int error = function_call()
}
or as I found in some code at work
{
QObject* obj = hash[key];
}
I don't think it is a bad idea to get rid of these warnings, and prevent
further of *this* kind of things.
/Sune
Re: Review Request: Add missing dependency to xmllint
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101707/#review4053 --- Ship it! Looks right to me. Thanks for fixing. - Sune On June 20, 2011, 10:58 p.m., Luigi Toscano wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101707/ > --- > > (Updated June 20, 2011, 10:58 p.m.) > > > Review request for kdelibs and Sune Vuorela. > > > Summary > --- > > This patch adds the missing checks for xmllint. xmllint is a de facto > dependency for kdelibs, a fresh rebuild fails without it (thanks to Sune > Vuorela for catching it). It seems that the check was never added to KDELibs > 4.x. > > I apologize as I should have been submitted this patch before, but I'd like > ask for an exception and have it in 4.7 (as it solve a FTBFS). > > > Diffs > - > > kdoctools/CMakeLists.txt 0d3cec3731bf8ded148cccde5cdb9e9b15748cd7 > > Diff: http://git.reviewboard.kde.org/r/101707/diff > > > Testing > --- > > > Thanks, > > Luigi > >
Re: grantlee-0.1.8 build failed on arm7
On 2011-06-21, Rolf Eike Beer wrote: > So if it is a double you are truncating it to a float (on ARM). I don't know > if > that is intentional. Given the api is taking qreal's, I think it is intentional. /Sune
Re: grantlee-0.1.8 build failed on arm7
On 2011-06-04, ?? ?? wrote: > Hello. I am using Gentoo on the Beagleboard-Xm. > When I try to compile kde-4.6.80, I stoped on the grantlee build phase. > This is a full log. > http://paste.ubuntu.com/618234 /var/tmp/portage/dev-libs/grantlee-0.1.8/work/grantlee-0.1.8/templates/lib/abstractlocalizer.cpp: In member function 'virtual QString Grantlee::AbstractLocalizer::localize(const QVariant&) const': /var/tmp/portage/dev-libs/grantlee-0.1.8/work/grantlee-0.1.8/templates/lib/abstractlocalizer.cpp:50:47: error: call of overloaded 'localizeNumber(double)' is ambiguous /var/tmp/portage/dev-libs/grantlee-0.1.8/work/grantlee-0.1.8/templates/lib/abstractlocalizer.h:94:19: note: candidates are: virtual QString Grantlee::AbstractLocalizer::localizeNumber(int) const /var/tmp/portage/dev-libs/grantlee-0.1.8/work/grantlee-0.1.8/templates/lib/abstractlocalizer.h:99:19: note: virtual QString Grantlee::AbstractLocalizer::localizeNumber(qreal) const is the interesting bits of the build log. And when reading abstractlocalizer.cpp line 50, it is quite clear what the issue is. A untested patch: diff --git a/templates/lib/abstractlocalizer.cpp b/templates/lib/abstractlocalizer.cpp index 4e5b15d..104d888 100644 --- a/templates/lib/abstractlocalizer.cpp +++ b/templates/lib/abstractlocalizer.cpp @@ -46,8 +46,8 @@ QString AbstractLocalizer::localize( const QVariant& variant ) const return localizeDateTime( variant.toDateTime() ); else if ( isSafeString( variant ) ) return localizeString( getSafeString( variant ).get() ); - else if ( variant.type() == QVariant::Double ) -return localizeNumber( variant.toDouble() ); + else if ( variant.type() == QVariant::Double || variant.type()==QMetaType::Float ) +return localizeNumber( variant.toReal() ); else if ( variant.canConvert( QVariant::LongLong ) ) return localizeNumber( variant.toInt() ); return QString(); /Sune
Re: [4.7 Beta1 blocker] plasma depending on kdelibs/experimental
On 2011-05-21, Dirk Mueller wrote: > Is the previous rule no longer valid? otherwise, how to deal with this > situation? Move plasma to experimental? remove the dependency again? That rule is still valid. And. how is one supposed to be building kdelibs if it requires kdelibs-experimental which requires kdelibs (which requires kdelibs-experimental ...recurse infinity) /Sune
Re: Klipper
On 2011-05-17, Steven Sroka wrote: > Exactly. Do I hear KDE5? :) if you do hear it, it will still require a clipboard manager in the workspace as long as we are targetting X11... /Sune
Re: Backwards compatibility for shared desktop ontologies?
On 2011-05-17, Sebastian Trüg wrote: > KDE-PIM < 4.7 is another problem as it does not build against kdelibs > 4.7. But then again: who does that? I know that is not a great argument, I'm pretty sure several distributions might want to push kdelibs + workspaces and such in newer versions to users with the old kdepim while the paint on the new kdepim (probably provided thru secondary channels) dries. /Sune
Re: Klipper
On 2011-05-16, Steven Sroka wrote: >>On 16 May 2011 04:24, Andreas Pakulat wrote: >> On 15.05.11 22:32:21, Steven Sroka wrote: >>> I'm interested if anyone knows why kdebase-workspace depends on >>> Klipper? I love how various KDE components are very modular, but for a >>> while now that weird dependency has been bugging me... >> >> Huh? klipper is part of kdebase-workspace. It does not depend on it in >> the sense of an external dependency. >> >> kdebase-workspace is meant to be a single module giving you a working >> KDE desktop, that includes a clipboard and hence klipper is part of it. > > Aha! Thanks. I should ask what else is included in kdebase-workspace? > (I don't need much detail) > ksysguard systemsettings kwin plasma-desktop plasma-netbook kinfocenter khotkeys kmenuedit freespacenotifier ksmserver cursors krunner ksplash kwrited powerdevil some solid plugins and the qt platform plugin and maybe something more. /Sune
Re: prison - a barcode library now in kdereview
On 2011-02-15, Sune Vuorela wrote: > Hi peoples > > I have added prison (git clone kde:prison) to kdereview, targetting > kdesupport. moved. /Sune
Re: prison - a barcode library now in kdereview
On 2011-02-15, Sune Vuorela wrote: >> Are there generated docs available somewhere for easier API review? > > Currently not, but I can do that later. http://alioth.debian.org/~pusling-guest/prison/apidocs/html/ /Sune
Re: prison - a barcode library now in kdereview
On 2011-02-15, Parker Coates wrote: > On Tue, Feb 15, 2011 at 03:45, Sune Vuorela wrote: >> I have added prison (git clone kde:prison) to kdereview, targetting >> kdesupport. > > Out of curiosity, what SC component is intended to use it? It is partly based on code I wrote for klipper half a year ago, and I want to replace it with a library. I also plan to make kaddressbook show vcard data in barcode format (so I can transfer it to my phone) I have also heard of someone with ideas for a barcode flake for calligra. >> Please review. >> >> I'm having a couple of doxygen warnings... > > Are there generated docs available somewhere for easier API review? Currently not, but I can do that later. /Sune
prison - a barcode library now in kdereview
Hi peoples I have added prison (git clone kde:prison) to kdereview, targetting kdesupport. Please review. I'm having a couple of doxygen warnings that I'm unsure how to deal with: prison/testapp/prison.h:17: warning: Member data_changed() (slot) of class main_window is not documented (and similar. this is just 'test code' to see that it works) prison/lib/prison/abstractbarcode.h:95: warning: return type of member prison::AbstractBarcode::d is not documented My library doesn't use i18n, so no Messages. Please comment along. /Sune
Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?
On 2011-02-15, Thiago Macieira wrote: > > --nextPart8281750.Kf80iGgygM > Content-Transfer-Encoding: 7Bit > Content-Type: text/plain; charset="us-ascii" > > On Tuesday, 15 de February de 2011 07:53:15 Rolf Eike Beer wrote: >> Since I have some of these machines: is there any detail on this available >> somewhere? Does this count for HP-UX only or also for Linux? > > You can find the info in Qt's source code: src/corelib/arch/qatomic_parisc.h > and src/corelib/arch/parisc/* > > Linux on PA-RISC is not supported. We have no clue if it even compiles. It > probably does if the assembler can compile src/corelib/arch/parisc/q_ldcw.s. It compiles. Qt4 is available in debian/unstable hppa. (Debian recently dropped hppa as a release architecture due to large problems with the lowlevel things, like threading / vfork issues. Qt is heavily hit by this, especially in QProcess, so it doesn't work that well. We have a hack that works around it, but it is not one I would like to see spread too much) /Sune
Re: Installing specific packages on demand (was: Re: proposal: remove KTextEditor interface from kdelibs repository)
On 2011-02-01, Friedrich W. H. Kossebau wrote: > We can't assume for all, but in many installations the user does. Like the > ususal private computer. > For administrated systems, there could be a substitute which instead of > allowing to install rather aids the user to file a request to the admin, for > convenience and getting things done. > >> and we shouldn't set up a complete development >> environment for him. > > I was thinking of interfacing to the normal packaging system of the system. > He, something like DrKonqi installing the debug info packages on request. So > something like that is existing already, just needs to be generalized perhaps. Basically, a piece of software than have three relations: 1) Required things 2) Optional things that should be availably by default 3) optional things that doesn't need to be available by default Packagers should assure that 1) is around. Packagers should try hard to make 2) available for all not uncommon installations. if 1) is missing, file bugs at the distribution. if 2) is missing, file bugs at the distribution or alternatively tell the user "you broke your system, you get to keep the pieces". And then there is the handling of 3). Well.. let's not make it a bigger issue than it actually is. /Sune
Re: proposal: remove KTextEditor interface from kdelibs repository
On 2011-02-01, Friedrich W. H. Kossebau wrote: >> And I'm not sure there should be >> such a thing. > > Hm. You don't agree that a user experience like > "Sorry, missing X to do Y. Would you like to get X now for that?" > is better than one à la > "Na, no way to do Y."? Yes. since we can't assume the user has the right to install to the system directory, and we shouldn't set up a complete development environment for him. /Sune
Re: proposal: remove KTextEditor interface from kdelibs repository
On 2011-02-01, Aaron J. Seigo wrote: > perhaps we should think about being more clear in our runtime definitions a= > nd=20 > stricter with requiring apps to advertise their runtime expectations, so th= > at=20 > we can go from having a huge pile of dependencies to just the requirements = > for=20 > a given application. I'm all for modularizing and being more clear, but it should not be done by tearing out parts of kdelibs to see what happens. Rather: Identify how we want apps to communicate their runtime requirements. Get apps to specify it using the communication way described above. This is for all apps built on the KDE Platform, no matter if they resides in git.kde.org, gitorious, launchpad or sourceforge. Get packagers and others to test that things work Break things apart at tarball generation. Test that things work Break up repositories Profit. /Sune
Re: proposal: remove KTextEditor interface from kdelibs repository
On 2011-02-01, Friedrich W. H. Kossebau wrote: > Uh, that is old-fashioned. Should instead ask the user whether she wants to > install the proper text editor module. Isn't there some simple standard api > for that these days? A simple standard api for what? installations of scripts and wallpapers and stuff, sure. there is the ghns things. For isntallation of compiled stuff, no. And I'm not sure there should be such a thing. /Sune
Re: proposal: remove KTextEditor interface from kdelibs repository
On 2011-02-01, Christoph Cullmann wrote: >> So far, we as packagers have been told that applications can expect all >> plugins (kio slaves, kparts, ...) located in kdelibs and kdebase-runtime >> to be available, and segfault is a acceptable way of handling missing >> things. > I agree that this will lead to additional dependency to kate package for some > modules, but is this that bad? It is bad, because the software is already out there. We cannot go out and change dependencies for things already released. And we don't know what software it is. KDE Software is in no way 'announcing' what plugins they requires. nor which they can optionally use. So we have two ways of figuring out who needs to require katepart. 1) make nothing require katepart and wait for bug reports and play whack-a-mole 2) read thru the sourcecode of all software built on KDE Platform or just be on the safe side and pretend that katepart is still part of kdelibs >> It also means that people who builds from source can do svn up / git >> pull in kdelibs and install new requirements,make, make install and >> still have all apps working. > They never can do that. Every now and then new dependencies come up. New > versions of virtuoso needed, new lib*, whatever. You NEVER was able to rely > that you can just up + recompile kdelibs and be fine. Normally it not even > compiled... Yes. you could rely that when kdelibs *compiled*, things worked. We are shipping things built against 4.1 or 4.2 that are run against 4.4, 4.5 or 4.6. /Sune
