Re: KDE service provider for handling arbitrary links (namely tel: links)
On 2019-05-08, Hans-Peter Jansen wrote: > Since some time, special links like e.g. tel:+49... appear on the web, and > I've taught my browser (Firefox) to handle those as well. Now, I would like > integrate with kmail, chromium, ... https://phabricator.kde.org/D18369 I think that patch helps enabling it for e.g. kmail. /Sune
Re: How are tier 1 framework qm translations supposed to be loaded?
On 2021-01-26, Halla Rempt wrote: > Ah... I guess that explains it. GenericDataLocation is only useful in a linux > distribution packages setup, because it's the location that's shared with > other applications, so we patch ki18n to use AppDataLocation -- I guess we'll > have to patch ECM as well. I'm not sure I would be opposed to having AppDataLocation also searched; I don't think the runtime overhead would be significant. I'm also not sure there would be significant security implications, and it might work better on some platforms where there is only sometimes the Generic location. (Iirc there are also platforms where Generic maps to App) /Sune
Re: Would Scandoc be somthing for Extragear?
On 2022-11-10, Thomas Baumgart wrote: > I don't know, if you have thought of this when writing invoices. Include > an EPC QR (https://de.wikipedia.org/wiki/EPC-QR-Code) on the invoice. I am > thinking about adding a webcam interface so that KMyMoney can use it to > read the QR code and use the data to fill out the form for online payments > that KMyMoney already has. Or even use the PDF file as input an pull out > the QR code. That would improve productivity I think. I know, a bit off > topic here. libprison and itinerary application might help you in this; they should together have the features to both read barcodes from pdf's, from webcam and generate barcodes. /Sune
Re: QML: a packagers nightmare. Assistance please.
On 2023-11-08, Nicolas Fella wrote: > Furthermore, kwin is not a framework, it's part of Plasma, and > dependencies between Plasma components are generally fine. That there is > a circular dependency between plasma-workspace and kwin is not good and > should probably be addressed somehow, but the severity is somewhat lower > given the cycle doesn't exist at built time. Though given packagers are being heavily suggested, and several has already, to write tools to help atuomatically track QML dependencies to ensure no depends: is left behind, cycles like these makes it impossible to actually do so. Either we should retract that suggestion and live with more broken QML dependencies in distributions until users randomly fix it, or we should try harder to not have such cycles, and when we see them be quick to fix them. /Sune
Re: QML: a packagers nightmare. Assistance please.
On 2023-11-08, Kai Uwe Broulik wrote: > Hi, > > that WorkspaceComponents is used for a ShadowedLabel which is literally > one QML file with a Label and a DropShadow. KWin could just not use that > (and build its own) and we’d resolve the issue. It sounds like either moving that component one level "up" in the hierachy or this suggestion or something else would resolve the issue. And in a nice way. /Sune
KF6 porting. KSelectAction::triggered signal
Hi I just - during KF6 porting of an app - fall in an api trap: Original code: | connect(d->aZoom, QOverload::of(&KSelectAction::triggered), | this, &PageView::slotZoom); The wrong porting code: | connect(d->aZoom, &KSelectAction::triggered, this, &PageView::slotZoom); The gotcha is that the QAction* overload, while with the same name, is emitted under different rules than the only remaining triggered function (from QAction) The correct porting would have been: | connect(d->aZoom, &KSelectAction::actionTriggered, this, | &PageView::slotZoom); So, just a heads up to whomever might hit this as well. (I wonder if one has enough sources checked out to be able to grep this to see what might be relevant. /Sune
Re: KF6 porting. KSelectAction::triggered signal
On 2024-01-03, Albert Astals Cid wrote: > scripty has everything checked out so if you tell me what to grep for, I can > run a query on it. I got access to the lxr machine and has been grep'ing there instead, and I only found one maybe-issue that I need to investigate /Sune
Re: KF6 porting. KSelectAction::triggered signal
On 2024-01-04, Sune Vuorela wrote: > On 2024-01-03, Albert Astals Cid wrote: >> scripty has everything checked out so if you tell me what to grep for, I can >> run a query on it. > > I got access to the lxr machine and has been grep'ing there instead, and > I only found one maybe-issue that I need to investigate Patch submitted. I was grepping for KSelectAction::triggered and then going thru the occurences and ignoring those that were in Qt5 ifdeffery. /Sune
Re: KDE Gear projects with failing CI (release/24.02) (Branching edition)
On 2024-01-12, Albert Astals Cid wrote: > okular: > * https://invent.kde.org/graphics/okular/-/pipelines/580655 > * It's trying to find packages in a wrong branch On it. Will report a MR for others with likely similar issues. /Sune
Re: KDE Gear projects with failing CI (release/24.02) (Branching edition)
On 2024-01-12, Sune Vuorela wrote: > On 2024-01-12, Albert Astals Cid wrote: >> okular: >> * https://invent.kde.org/graphics/okular/-/pipelines/580655 >> * It's trying to find packages in a wrong branch > > On it. Will report a MR for others with likely similar issues. https://invent.kde.org/graphics/okular/-/merge_requests/908 fixed it in master and release branch /Sune
Re: KDE Gear projects with failing CI (master) (20 February 2024)
On 2024-02-21, Ben Cooksley wrote: >> ark - 3rd week >> * https://invent.kde.org/utilities/ark/-/pipelines/611869 >> * tests fail on FreeBSD >> > > Wonder if the tests properly handle umask being set? I agree that the issue is likely here /Sune
Re: KDE Gear projects with failing CI (master) (20 February 2024)
On 2024-02-21, Sune Vuorela wrote: > On 2024-02-21, Ben Cooksley wrote: >>> ark - 3rd week >>> * https://invent.kde.org/utilities/ark/-/pipelines/611869 >>> * tests fail on FreeBSD >>> >> >> Wonder if the tests properly handle umask being set? > > I agree that the issue is likely here Force umask: https://invent.kde.org/utilities/ark/-/merge_requests/234 /Sune
Re: Post-MegaRelease projects
On 2024-02-22, Nate Graham wrote: > I've started pondering post-megarelease projects. We've spent so long on > porting and bugfixing that I think it might be useful to shift gears to > feature work, and I'd like to brainstorm potential large-scale projects > and gauge the level of interest in putting resources into them soon. A bit more from the devops end that I'd love to see people tackle: - Ensure frameworks and app unit tests interacting with windows can run on Windows. More details: The following fails on our windows CI https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp I find it weird that we are spending resources on putting things in the windows store and making apps available on windows, but we can't actually have passing tests in our CI. - Find a way to run unit tests on android CI. - Make autotests guarding on all our CI's. - Clazy and clang-tidy and cppcheck on all our repositories in CI /Sune
Re: KDE Gear projects with failing CI (master) (28 February 2024)
On 2024-02-28, Albert Astals Cid wrote: > > ark - 1st week > * https://invent.kde.org/utilities/ark/-/pipelines/616910 > * flatpak fails complaining about KF6BreezeIcons I think this is due to an old flatpak environment https://invent.kde.org/frameworks/breeze-icons/-/commit/a4970ce40ec43c0a1db418aa05ee2853497a0c14 So will probably be fixed together with the rest. /Sune
Re: KDE Gear projects with failing CI (release/24.02) (28 February 2024)
On 2024-02-28, Albert Astals Cid wrote: > konversation - 1st week > * https://invent.kde.org/network/konversation/-/pipelines/616933 > * cmake fails to find dbus on Linux CI This seems like intentional sillyness from the konversation developers. Let's fail at build time for runtime components that are used in fringe usecases. My suggestion is to revert the offending commits. /Sune
Re: resvg
On 2024-03-14, Igor Mironchik wrote: > Hello, > > What do you think about https://github.com/RazrFalcon/resvg in case of > processing and rendering SVGs? > > Do you have any plans to have this in Craft? With the current revitalization of QtSvg, I kind of think we should work harder with that rather than try to replace it. It is after all hooked in quite deep in our stuff already, so most of our svg's needs to be compatible with QtSvg anyways. /Sune
Re: Should we stop distributing source tarballs?
On 2024-04-03, Albert Vaca Cintora wrote: > What's the advantage of providing tarballs? I do think there is an advantage in being able to verify that the soure tarball is the same across distributions. Using a checksum on the tarball is an easy way of doing it. Different git invocations for git archive, different tar options and so on can create different checksums for the same content. I do also think it is nice if we get someone else to verify that the tarball we ship actually matches the tag. I think some people in distributions have already started looking into verifying that. Also, git tags can be moved. /Sune
Re: Should we stop distributing source tarballs?
On 2024-04-04, Ben Cooksley wrote: >> I do also think it is nice if we get someone else to verify that the >> tarball we ship actually matches the tag. I think some people in >> distributions have already started looking into verifying that. >> > > Hopefully they'll be gentle with tooling that does this? I have only seen 'starting to look into it', not actually yet figuring out what to do with it. But as an approximation, I would expect 'does the tarball content match the tag?' 'can we easily and automatically explain the difference?' 'does it use autotools?' 'can autogenerated docs and stuff be moved to build time instead?' and other such things that might flag it differently and probably for manual inspections. I think we have stopped injecting translations at tarball creation time and our tarballs should actually match the git tags? /Sune
Re: Review Request 114933: KF5 Port of kdeui/kmessagewidgetdemo
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114933/#review47428 --- kdeui/kmessagewidgetdemo/CMakeLists.txt <https://git.reviewboard.kde.org/r/114933/#comment33732> Would it be hard to get rid of XmlGui here? I don't see what it really buy us for this example? Replacing it with kwidgetaddons - and maybe switch from kmainwindow to qmainwindow will make the example simpler. - Sune Vuorela On Jan. 10, 2014, 8:49 p.m., Laurent Navet wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/114933/ > --- > > (Updated Jan. 10, 2014, 8:49 p.m.) > > > Review request for KDE Examples and Sune Vuorela. > > > Repository: kdeexamples > > > Description > --- > > This is part of Google Code-IN Contest. > As I'm no more student, I've waited for the end of the contest to work on it. > > Comments appreciated, > > > Diffs > - > > kdeui/kmessagewidgetdemo/CMakeLists.txt 12ef4ac > kdeui/kmessagewidgetdemo/main.cpp d3a5bf0 > kdeui/kmessagewidgetdemo/window.h d3a67c8 > kdeui/kmessagewidgetdemo/window.cpp 9786da6 > > Diff: https://git.reviewboard.kde.org/r/114933/diff/ > > > Testing > --- > > Regression on KTextedit::setClickMessage(), as it don't exist in QTextEdit > I've commented the line. > > > Thanks, > > Laurent Navet > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 114933: KF5 Port of kdeui/kmessagewidgetdemo
> On Jan. 15, 2014, 9:17 a.m., Sune Vuorela wrote: > > kdeui/kmessagewidgetdemo/CMakeLists.txt, line 23 > > <https://git.reviewboard.kde.org/r/114933/diff/2/?file=233694#file233694line23> > > > > Would it be hard to get rid of XmlGui here? I don't see what it really > > buy us for this example? > > > > Replacing it with kwidgetaddons - and maybe switch from kmainwindow to > > qmainwindow will make the example simpler. > > Laurent Navet wrote: > XmlGui replaced with KWidgetAddons and KConfigWidgets. > switched from KMainWindow to QMainWindow. I don't see the updated diff ? - Sune --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114933/#review47428 --- On Jan. 10, 2014, 8:49 p.m., Laurent Navet wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/114933/ > --- > > (Updated Jan. 10, 2014, 8:49 p.m.) > > > Review request for KDE Examples and Sune Vuorela. > > > Repository: kdeexamples > > > Description > --- > > This is part of Google Code-IN Contest. > As I'm no more student, I've waited for the end of the contest to work on it. > > Comments appreciated, > > > Diffs > - > > kdeui/kmessagewidgetdemo/CMakeLists.txt 12ef4ac > kdeui/kmessagewidgetdemo/main.cpp d3a5bf0 > kdeui/kmessagewidgetdemo/window.h d3a67c8 > kdeui/kmessagewidgetdemo/window.cpp 9786da6 > > Diff: https://git.reviewboard.kde.org/r/114933/diff/ > > > Testing > --- > > Regression on KTextedit::setClickMessage(), as it don't exist in QTextEdit > I've commented the line. > > > Thanks, > > Laurent Navet > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Should KDED4 run all the time?
On 2014-06-28, Ian Wadham wrote: > Hi guys, > > When fixing some bugs in the KCrash-DrKonqi sequence on Apple OS X, > I have come to a point where Dr Konqi attempts to call kded4, using DBus, > and issues a message "Failed to communicate with kded. Make sure it is > running." In the kdelibs4.x-age, yes. kded should be running all the time no matter what. Unfortunately, it isn't refcounting its users so it is running like forever. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Should KDED4 run all the time?
On 2014-07-01, Ian Wadham wrote: >> In the kdelibs4.x-age, yes. kded should be running all the time no matter >> what. > > In Linux and a KDE desktop manager, that is fine: kded4 is part of the > structure > of a KDE desktop manager. But in Apple OS X (or other desktop managers), that > should not be a requirement, if KDE is to be truly portable. kded4 is a helper tool for libkdecore, not part of the structure of a KDE Desktop manager. But at least on linux, it is started on demand (when a KDE application is started no matter under what desktop system) Lots of this is fixed by KF5 by separating teh bits, but in the kdelibs 4.x age, kded4 is needed. Among other things to ensure that sycoca is updated. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: code convention
On 2014-08-12, Rodrigo Bonifacio wrote: > Dear kevin, I am conducting a survey about the use of exception > handling constructs in C++. I would really appreciate if you could > contribute to this research by answering a few questions on the > subject. > > The survey is available on-line: > > https://pt.surveymonkey.com/s/exceptionHandling The survey misses options. The main reason why I don't use exceptions and recommend people to stay away from exceptions is that exceptions in c++ is hard. You very easily leak resources. There is no possibility to have compiler-checks that specific exceptions are handled (think java's checked exceptions). You can only emulate a try-finally thing with raii-structs, but that's more bulky. And c++-exceptions don't have stacktrace information. I develop stuff at work sometimes in java, sometimes in c++ (often with Qt) and enjoy using exceptions in java just as much as I avoid using them in c++. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Fwd: Re: kscreengenie
On 2015-04-20, Boudhayan Gupta wrote: > Well, Sune Vuorela and Luigi Toscano got on my back and I ended up > re-doing the ungrab workaround the proper way, without the dependency > on private headers, so yay! Try building master now. Yay. Thanks. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Qt -fPIC building suggestion
On 2015-05-22, Jeremy Whiting wrote: > /home/jeremy/devel/kde/build/kdesupport/phonon/phonon/CMakeTmp/check_qt_visibility.cpp:1: > /usr/include/qt/QtCore/qglobal.h:1050:4: error: #error "You must build > your code with position independent code if Qt was built with > -reduce-relocations. " "Compile your code with -fPIC (-fPIE is not > enough)." > # error "You must build your code with position independent code if > Qt was built with -reduce-relocations. "\ > Do we need to "fix" the arch qt packages to build with -fPIC or something? Yes. There is a patch merged into Qt. please ask your packagers to include it. 083c9269ed73e8771e1dbe10812696b45b7389f3 in qtbase. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Metadata for shared libraries: .json or .desktop?
On 2015-07-04, Filipe Saraiva wrote: > Hi, I am developing the port of Cantor plugins and libraries to "JSON > files way" - translanting the .desktop files to .json and putting it in > the binaries. Are you talking about plugins (those that gets loaded by [KQ]PluginLoader / QLibrary / dlopen) or libraries (those you target_link_libraries at build time) ? Libraries usually doesn't have this kind of metadata, as they are loaded by the system loader (ld.so). (Yes. pedantics. on ELF systems you can also dl-open libraries, but it is not in general something that should be done) > In plugins I am using kcoreaddons_add_plugin. With shared libraries, > what must I to use? just add_library. no metadata. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: kcoreaddons_add_plugin without INSTALL_NAMESPACE
On 2015-09-04, Filipe Saraiva wrote: > But for libcantorpart.so I can not to use kcoreaddons_add_plugin because > I need to install that part in the "plugins root" directory. If I use Why do you need to do that? It seems wrong to me. Maybe you should look at your plugin loading code at the same time? I think it makes sense that plugins are separated into directories based on what can use them. It also makes finding plugins much more efficient, because just having to read all plugins in a specific directory is much faster than reading all plugins and then filter them afterwards. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Implementing "translation in context"
On 2015-09-18, Thomas Lübking wrote: > On Freitag, 18. September 2015 09:17:16 CEST, Dashamir Hoxha wrote: > >> The most difficult part in my opinion is how to mark (or decorate) >> the translated string, so that it can respond to a Ctrl+Click event. > > You need a plugin for the (every, could be a11y stuff?) Qt client > that provides an IPC (dbus) interface/object/method to respond > "stringAt x y" and which searches the QWidget/QtQuick item stack > top down for the first thing that has some text. I wouldn't be too surprised if there was something in the a11y stack that could help with that. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 126105: Fix yet another crash in Dolphin when Baloo isn't running
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126105/#review88556 --- without actualy knowing the code in question, a brief look over gives me the impression that the error handling could be improved and that would make this patch not needed. src/engine/database.cpp (line 104) <https://git.reviewboard.kde.org/r/126105/#comment60724> SHouldn't there be a if(rc == 0) return false here ? src/engine/database.cpp (line 137) <https://git.reviewboard.kde.org/r/126105/#comment60725> if(rc == 0) return false src/engine/database.cpp (line 167) <https://git.reviewboard.kde.org/r/126105/#comment60726> if(rc == 0) return false - Sune Vuorela On Nov. 18, 2015, 7:40 p.m., Boudhayan Gupta wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126105/ > --- > > (Updated Nov. 18, 2015, 7:40 p.m.) > > > Review request for Baloo, KDE Frameworks, Pinak Ahuja, and Vishesh Handa. > > > Repository: baloo > > > Description > --- > > Add a check in Baloo::Database::open() to return false if we're opening the > database in ReadOnly mode and the database doesn't exist. This fixes a crash > in Dolphin when Baloo isn't running. > > This isn't the entire fix - one will also have to remove > ~/.local/share/baloo/index to not crash anymore; this patch prevents the file > from being recreated everytime Baloo::Database::open() is run, and re-causing > the crash. > > > Diffs > - > > src/engine/database.cpp 4f0579f > > Diff: https://git.reviewboard.kde.org/r/126105/diff/ > > > Testing > --- > > Builds, runs, doesn't crash anymore, the works. > > > Thanks, > > Boudhayan Gupta > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: I developed a workaround for Qt5.4 DND bug that KDE apps might need
On 2016-01-16, PCMan wrote: > Since DND is crucial for a modern desktop environment and it's an upstream > bug, I believe that KDE is also affected. > Luckily I found some quick workarounds, so I'm gonna share it with you. > > https://github.com/lxde/pcmanfm-qt/pull/295/files > > I made it an independent C++ class which is licensed under LGPL, so it can > easily be reused by other Qt projects. > Just add two lines in your main() and it will work automagically. Please do *not* pick this up in any places. Usages of Qt private headers is really throwing spanners in the wheels of our downstreams. It should be fixed in the right place. in Qt. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: The situation of KWallet, and what to do about it?
On 2016-07-07, Kevin Ottens wrote: > There's two sides to that problem in fact, use from applications and the=20 > service provided by our workspace. One issue that I'm a bit puzzled about is the following scenario: A user uses KMail for emails. But switches between various desktop environments. Would he need to configure KMail in all of them? /Sune
Re: CMake code to find KrossPython
On 2011-02-27, Daniel E. Moctezuma wrote:
> I'm trying to make a CMake Module to find whether or not KrossPython is
> installed, as fas as I know once you install the Python plugin for Kross,
> you will have a 'krosspython.so' file installed (in my case this file is in
> /usr/lib64/kde4).
It sounds like you want to do a build time check on a runtime
requirement (else, I don't understand why want to do this)
Please don't do build time checks for runtime things that actually
changes the result.
Most users of KDE Software is using software built in a different
environment than where you use it.
so if you need krosspython at runtime, do a check in your code
if(!krosspython) {
KMessageBox::critical("krosspython not found, installation broken");
exit(1);
}
/Sune
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: CMake code to find KrossPython
On 2011-02-28, Daniel E. Moctezuma wrote:
> Yes, this CMake code is to check whether or not the krosspython library is
> installed on the system when you execute the configure file before build.
> We think it is necessary to check it because it allows the user to know
> which functionalities you will have. As krosspython is used to be able to
> run Python plugins via Kross, the user can decide whether or not to have
> those features.
You know that just because you install krosspython in the build
environment doesn't mean that it will be there at runtime.
People getting your app from a linux distribution will have a completely
different environment than the build environment
>
> Btw, what do you mean by "runtime things that actually changes the result"?
I mean please don't do in your cmake code
(pseudocode)
if(!runtime_component_available) {
add_definition("-DDISABLE_STUFF")
}
but rather
if(!runtime_component_available) {
warn("please note that runtime component FOO isn't currently
available. we can use it at run time. If you want to disable support
for this, please build with -DDISABLE_STUFF")
}
/Sune
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: KIO::Slave for secrets collections browsing
On 2011-08-14, Valentin Rusu wrote: > Hello, > > Just wanted to inform you that I introduced a new component into the > KSecretsService infrastructure, a KIO::Slave. This will let you browse > for the secrets directly inside Konqueror or Dolphin. See this screen > capture: > http://wstaw.org/m/2011/08/14/plasma-desktopLo2386.jpg > > The code lives into the kio subdirectory, next to client and daemon and > it's in a very early stage, but I'll quick get it advanced, as it'll be > very useful for testing the new service. Just curious; will it also work for browsing gnome-keyring items? /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Moving installed kdelibs
On 2011-08-30, Michael Jansen wrote: > But perhaps you find some problems and have to fix them. I am not absolutely > sure of our DESTDIR support. Perhaps it is completly screwed up. Which would > be another cmake regression compared to automake. DESTDIR works nicely. It is also very important for packagers, who basically does what is described. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bug triage process needs help
On 2011-09-28, Bart Kelsey wrote: > Hi folks, > > I'd like to draw attention to the fact that KDE's bug triage process is > lacking. Hi Bart You are absolutely right that we get more bug reports to any component than we can currently handle, as you have noticed yourself. I haven't looked at the bug report in question, so this is a generic comment on bug reports. Many bug reports are 'low quality', as in 'hard to figure out what the submitter means'. There are really many bug reports in general. This leads to a fact that finding the 'high quality' bug reports is the classic of finding a needle in a haystack. I'm sure that if you want to help triage the bugs reports and finding the actual high quality ones, I'm sure it would be most welcomed. If you could just spare a couple of hours pr week, it would actually make a difference. I think the plasma product gets several hundred bugs a week, and there is only a handful of people actually working on plasma, and not only on bugfixing but also doing new or missing features, so there is clearly room for helping here, as well as in any other product. Thanks for your interest in KDE /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bug triage process needs help
On 2011-10-02, Kevin Krammer wrote: > Interesting. So do other projects ship bug fixes without patch level releas= > e or=20 > do the not ship bug fixes at all? At least in debian, for stable updates it is only for very serious issues there are shipped updates in stable releases, among other things because 'non-changing' is also part of 'stability'. In many pieces of 'deployed software' you as a user or integrator or sysadm have deployed workarounds for known bugs, and fixing them might actually introduce new issues because of the workarounds. But this might also be primarily for 'server components' this is important. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Relicensing Questions
On 2011-11-26, Andras Mantia wrote: >> a) current license of a file > > Maybe krazy can do it? Maybe modestas vainius' (of debian kde) copyrighthelper script can help. http://anonscm.debian.org/gitweb/?p=users/modax/copyright-helper.git;a=summary >> Regarding b) I wonder: >> Is anyone who ever contributed a patch to a given file automatically >> copyright holder? > > Probably depends on the country and the amount of contribution (changing a > comment probably doesn't give anybody copyright assignment). I think the GNU people is having a rule of thumb about less than 10 lines isn't copyrightable. (due to triviality) /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Hacking KDE applications
On 2012-01-07, Bjoern Schiessle wrote: > How does other KDE developers handle this situation? Is it possible to > compile and run a program in my home directory without messing up my > system installation? make sure the Plasma session has KDEDIRS variable set to your install prefix. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Get involved on KDE Development
On 2012-02-02, Aaron J. Seigo wrote: > that said, there are a lot of projects in need of helping hands and don't > require year-long commitments :) kde-edu and kde-games are two great > communities to get started with and both have great need for participation, > for instance. Another example could be akregator. it's a great but slightly unmaintained application, and a codebase that several Google Code-in students have been able to find their ways around in. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Konqueror- GSOC idea
On 2012-02-13, Andrew Mason wrote: >> By the way, if you want to sort downloads by file types, using Nepomuk >> is the obvious solution. > > I like this idea but please consider there are some people, for which Nepomuk > is disabled. This can be because Nepomuk impacts the performance of their > desktop in some way, or simply because the benefits of Nepomuk aren't > perceived to be significant enough to jusitfy running it. I don't think these people should be our main target audience. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: GSoC idea: improving scanning and OCR in KDE (skanlite/kooka)
On 2012-03-06, todd rme wrote: > Scanner kio slave. An easy scanner interface using file managers > (like the current CD ripper kio slave). There would be a folder for > each scanner. When the folder is opened it will pull in a preview > from that scanner. There would then be folders for supported > resolutions, with individual files for common paper sizes, the whole > scanner area, auto-detected pictures (i.e. if you can multiple > pictures at the same time) and, if available, text files for OCR. > Dragging one of these to the filesystem will trigger a full scan with > those settings. I'm not sure a KIOslave makes that much sense for managing a scanner. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: GSoC idea: improving scanning and OCR in KDE (skanlite/kooka)
On 2012-03-07, Kåre Särs wrote: > How do we go forward from here? Put it on the wikipage, wait for KDE to be a gsoc approved organization, wait for official project submissions, get the student to submit the project. hope that KDE as a organization selects your project. > Who is willing to mentor for an ORC library + plugins + ...? My best guess for a great mentor for such a project would be someone with a iki.fi address with a firstname and a lastname of 4 letters, both containing some 'nordic' letters. :) > What does a mentor do and how much time does it take? a mentor answers questions from the student. A mentor ensures the student is on right track. A mentor fails or passes the project. A mentor does a lot of code review A mentor also ensures that the project plan is good and sane. Mentoring, depending on student and the task, is probably 1-2 hours a day or something like that. Fram my experience with santa, he is probably going to be one of the students who is going to be pretty light to mentor. /Sune > > /Kåre > > On Wednesday 07 March 2012 16:16:59 todd rme wrote: >> 2012/3/7 Kåre Särs : >> > On Wednesday 07 March 2012 10:59:50 todd rme wrote: >> >> On Wed, Mar 7, 2012 at 10:46 AM, Andreas Pakulat wrote: >> >> > On 07.03.12 10:23:32, todd rme wrote: >> >> >> On Tue, Mar 6, 2012 at 8:03 PM, Klaas Freitag wrote: >> >> >> > On 06.03.2012 18:02, todd rme wrote: >> >> > [...] >> >> > >> >> >> > These kind of things. Not sure if a kio is cool for any of these. >> >> >> >> >> >> A gui able to do all the things you listed would necessarily be >> >> >> extremely complicated and likely difficult to use, unless most of the >> >> >> tasks were automated push-button affairs. In the latter case, there >> >> >> is little advantage over a kio slave. I would think that a kio slave >> >> >> would be more natural, since users would not need to know terminology >> >> >> or the menu structure. >> >> > >> >> > Maybe I didn't use enough of the more fancy kio-slaves, but I have a >> >> > hard time imagining how I'd be able to use this with say konqueror. I'd >> >> > go to >> >> > >> >> > kscan:/// >> >> > >> >> > And then see whats been scanned, but how do I initiate a scan? Do I >> >> > need >> >> > to go to some special url? If so, how do I trigger the OCR creation >> >> > after scanning? >> >> >> >> To activate a scan of an image, you either drag the image file in the >> >> kio slave to another folder, or you open it in a program (either by >> >> clicking or using the right-click menu). In the case of dragging it >> >> to a folder, it will be automatically scanned and saved in the >> >> destination folder without the user needing to do anything else. In >> >> the case where you open it in a program, it will probably be scanned >> >> to a temporary folder or stored in memory and then opened in the >> >> program, once again without the user doing anything else. >> >> >> >> In the case of OCR, it would be the same, except a temporary image >> >> file woulds be scanned, OCRed, and deleted (or again stored in >> >> memory). >> >> >> >> This, at least, is how the CD kio slave does it. >> > >> > If somebody is interested in making such a kio slave, for simple usecases, >> > I would say go ahead and scratch your itch :) I do have a some doubts >> > about the usability tho. >> > >> > 1) You would have to "refresh" the view to get a new preview of new photos >> > placed on the scanner and the automatic photo finder is bound to fail >> > sometimes and you would be unable to select the correct part of the >> > images. >> >> Yes, refreshing would be needed, both for this and for a standalone app. >> >> The issue with incorrectly detected borders would also affect a >> standalone app. Of course this is intended for simple jobs, anything >> complicated would need a more advanced app. But for most cases simple >> is enough. >> >> > 2) You have options (folders?) >> > - scan mode: grayscale, color >> > - resolution 50 100 150 300 600 1200 2400 4800 ... >> > - source: flatbed, automatic document feeder, transparency unit, ... >> > - how would you adjust gamma if available >> > - contrast/light... >> >> The only folders would probably be resolution, and one extra folder >> for the ADF if available. The ADF would primarily be useful for PDFs, >> TIFFs, and OCR, so in that folder could be individual files for OCR, >> PDFs at various resolutions, and TIFFs at various resolutions. >> >> Color vs. grayscale could have two images for the whole scan, so only >> one more file per resolution. OCR would handle that automatically, >> and scanned photos are unlikely to be in grayscale. >> >> Transparency units usually replace the main scan bed, so the could be >> detected as individual pictures and scanned that way. >> >> Gamma, contrast, lightness, etc would require a standalone app. >> >> > 3) Multipage scanning from ADF can not have a preview... >> >> No, but this is true in a standalone app as well.
Re: Should the library version follow the KDE release version?
On 2012-05-02, Stefan Majewsky wrote: > On Wed, May 2, 2012 at 8:30 PM, Weng Xuetian wrote: >> For example, libkdecore is now 5.8.0, but still the api is 4.7. > > When the VERSION was 5.1.0 previously, can I go back to 4.9.0 to reach > consistency with the KDE release, while I still bump the SOVERSION > from 5 to 6? both the VERSION and SOVERSION in the cmake line relates to the same thing. and is completely unrelated to api versioning. technically, cmake might be able to do that, but oh boy, it would be weird. for example, I have on my file system: /usr/lib/libkio.so /usr/lib/libkio.so.5 /usr/lib/libkio.so.5.7.0 one being symlink to two being symlink to three being the real file. the loader basicalyl looks at applications for the NEEDED entries: objdump -x /usr/bin/kioclient | grep NEEDED | grep kio NEEDED libkio.so.5 then it looks in RPATH, $LD_LIBRARY_PATH, ld.so.conf paths and the build in paths in ld for a file named like that and loads that. so, if libkio.so.5 pointed to libkio.so.4.9, I guess things would actualy still work, but you would confuse the hell out of everyone. and going backwards - then you risk actually colliding with earlier libkdegames editions on the sytem /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: What builds libnepomukdatamanagement?
On 2012-05-06, Vishesh Handa wrote: > --===4448671127468223506== > Content-Type: multipart/alternative; boundary=bcaec554de825124e104bf5e7f70 > > --bcaec554de825124e104bf5e7f70 > Content-Type: text/plain; charset=ISO-8859-1 > > On Sun, May 6, 2012 at 4:38 PM, Lindsay Mathieson < > lindsay.mathie...@gmail.com> wrote: > >> I'm building trunk from src and kde-baseapps is falling due to this lib >> missing >> > > kde-runtime > Can't you just fix kde-runtime to not install any headers as it used to be. kde-runtime is for runtime-stuff, not shared libraries, and should thus not install any headers. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: using unixodbc-dev instead of libiodbc2-dev
On 2012-05-25, Aaron J. Seigo wrote: > (assuming virtodbc_r is indeed the correct library from unixodbc to use; i > don't know, just going from what's in the patch you posted) This one isn't about switching to unixodbc, but bypassing the drivermanager bits called 'odbc' completely. The reason for this is that we don't actually want to ask for a generic odbc driver, but we want virtuoso odbc driver, and nothing else. (kind of like KTrading for a text editor component if you know you need katepart and can't live with anything else) The reason why this actually succeeds (and will succeed) is a combination of a couple of things: 1) on glibc-systems, you can actually link to a plugin 2) the abi of the odbc drivers is given by external entities 3) when linking something in 'weird directories' we get a RPATH automatically 4) lotsofmagic As such, the solution is pretty elegant and iirc originates from Steve Langasek of Debian (and Ubuntu) fame. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: When does kbuildsycoca4 run?
On 2012-09-18, mk-li...@email.de wrote: >> Technically it needs to be run if new .desktop files are installed. > > Is the assumption correct that the run would have to be carried out by the > user and not by root? Yes. (and kded takes care of running it (with a small delay of a minute or so (to only do one run in case of many updates ) ) ) /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: KPluginLoader ==> cannot load any more object with static TLS
On 2012-10-30, Stephane MANKOWSKI wrote: > On kubuntu 12.04 (with KDE 4.9.1), all plugins were successfully loaded. > On kubuntu 12.10 (with KDE 4.9.2), some plugins are not loaded due to a=20 > NULL pointer returned by /*loader.factory()*/ > I didn't change the code of Skrooge in between. > > If I print the error message returned by /*loader.errorString()*/, I get=20 > this: > /*dlopen: cannot load any more object with static TLS*/ > > I don't understand this error. > What does it mean? > What should I do to be able to load all plugins like on previous version? the error is coming from libdl (the thing that is a few layers underneath kpluginloader). And it is apparantly because there isn't room in the DTV to initalize the static TLS. TLS is short for Threaded Local Storage (not related to ssl-TLS) the code is in http://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-open.c;h=9c39a34a4b0baafd93f37b1364c10724b0fa6d9b;hb=HEAD line 546 /Sune - who don't fully understand the email he is writing >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: <3 for some people
On 2013-02-17, Lydia Pintscher wrote: > Who's on your list? On top of my list is Lydia for doing stuff like this, for managing stuff like GSoC and for ensuring new and old people feel welcome in KDE. Albert also have a sweet spot in my heart for stepping up on getting stuff released. and a 3rd person is actually a mix of Carl, Sebas and Jos for doing marketing & communication stuff better than I can only dream of doing. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Incubation Request: Kiview
On 2024-04-28, Méven wrote: > The immediate goal with this application is to fill this request feature > for dolphin : > https://bugs.kde.org/show_bug.cgi?id=272539 > And we can imagine reusing it in many other places potentially. I just opened 'DocumentViewer' class and spent 5 minutes and got a bit scared. "instant" preview? Launching a background libreoffice? Doing weird command line parsing of libreoffice? and bash pipe grep ? Then throwing a generated pdf at qtwebengine and hoping the best? There is a lot of std::tsring to qstring and back again conversions There are plenty of std::string deepcopies. Who deletes ConversionThread ? If this class is in any way representative of the code quality of the app, I really think we should reconsider. If this class is not representative, then it definitely should be architecturally re-done. /Sune
Re: KDE Gear projects with failing CI (master) (25 June 2024)
On 2024-06-26, Ben Cooksley wrote: > Possible fallout of the Windows image being rebuilt, except libssh hasn't > changed since 2023 in Craft, so this must be due to Qt changes. > Pretty sure we've seen this type of error before though? (curiously, > qplatformdefines.h should include sys/types.h and therefore solve this > issue) I think libssh is quite new added to the image ? anyways. I did a MR and also fixed a .. weirdness on the way. Reviews welcome. /Sune
Re: Coding style: const QString foo = foo();
On 2024-10-28, Albert Astals Cid wrote: > My vote goes for rename the variable, there's 2 reasons i can think why you > do > > const QString foo = foo(); > > (there's probably many more, i spent 5 seconds thinking) > > Reason 1: You're caching it because foo is expensive, rename the variable to > cachedFoo > > Reason 2: You're remembering it because you're going to change it and then > later want to compare against it, rename it to oldFoo Reason 1a: You cache it because you use it multiple times in the function and it gets annoying to type the parenthesis and/or you don't want anything you do to by accident change the foo() you are evaluating. Thanks for your feedback. I'm hoping for a bit more voices before heading somewhere with some MR's. /Sune
Coding style: const QString foo = foo();
Hi peoples Quite some repositories have enabled cppcheck with a ruleset that I more or less have composed so far. I do think it provides valuable feedback, especially if we can get the rules groomed sufficiently and fix the remaining points. It at least have helped me with quite some bugs over time. There is though one pattern that cppcheck complains about that I'm a bit unsure if we should ask cppcheck to not complain about or if we should fix the instances. | Minor - Local variable 'foregroundColor' shadows outer function Basically, various versions of people doing | const QString foo = foo(); inside their functions. Is this a issue we should suppress at cppcheck level, or one where we should rename the variable ? There are a bit of pros and cons. The biggest argument for adapting cppcheck settings is that it is unlikely that anyone will actually be confused by this kind of shadowing, and most IDE's will help you anyways. Another big argument for doing it as a cppcheck setting is that it is normally 'the good name' for the thing in question, so the variable will be less good. Either people start adding tails_ to the variable or weird abbrvs. The biggest argument for adapting the code is that it makes things more readable for people without a IDE and for simpler search/grep in source code. (by IDE I also includue various language-server additions to editors) Does anyone have opinions here? /Sune
Re: New Application Status
On 2024-12-03, Ingo Klöcker wrote: > Is "passing KDE Review" really connected in any way to "packaged by some > distro"? I guess that's a question only distro packagers can answer. It is not. But "having stable releases" is connected, though if the thing is sufficiently interesting, prereleases and snapshots can be packaged. I do agree that some sort of marking for 'early-in-development'-apps on apps.kde.org does make sense, and maybe that marker should only be removed once we at least have releases, but maybe also have passed kde review. /Sune
Re: Help with a KMail crash
On 2024-12-04, Ingo Klöcker wrote: > Given that iterators are involved I suspect that shadowIdentities is modified > while it is being iterated over which invalidates the iterator it. There are > some signals emitted in this loop so that there's is a lot of potential for > additional calls to KIdentityManager by connected slots including reentrancy > of KIdentityManager::commit(). If Ingo is right, bruteforcing it by putting a non-recursive mutex around all calls to the hash should lead to a deadlock rather than a crash :) /Sune
Re: KDE Gear projects with failing CI (master) (14 January 2025)
On 2025-01-14, Albert Astals Cid wrote: >> kamera - NEW >> * https://invent.kde.org/graphics/kamera/-/pipelines/865501 >> * FreeBSD build fails >>* It's a gphoto2 bug but we should probably workaround it >> * https://github.com/gphoto/libgphoto2/issues/1077 > > How does https://invent.kde.org/graphics/kamera/-/merge_requests/20 feel? It feels not great, but also not horrible. I see Ingo has approved it already. No objections. /Sune
Re: Test Failures Fatal by Default in KDE CI
On 2025-03-18, Ingo Klöcker wrote: > For libkleo we do have Windows CI. But those tests seems green? or are they flaky? /Sune
Re: Test Failures Fatal by Default in KDE CI
On 2025-03-18, Ingo Klöcker wrote: > Options: > require-passing-tests-on: ['Linux', 'FreeBSD'] > ``` > and there are builds for Linux, FreeBSD, and Windows. > > I suppose I can safely add > ``` > allow-failing-tests-on: [ 'Windows' ] > ``` > now _additionally_ to the require-passing-tests-on. Correct? That would at least be the same. Though I guess waiting with that part until we actually have windows CI for it would be better. /Sune
Re: Proposal to Update Minimum CMake Version to 3.22
On 2025-03-30, Ömer Fadıl USTA wrote: > I hope this message finds you well. I would like to propose an update to > the minimum required version of CMake for KDE Frameworks and KDE Plasma > projects, raising it from 3.16 to 3.22. I'm missing the good argument for this other than larger is better. But just some data points Debian oldstable has 3.18.4-2 Debian stable has 3.25.1-1 I do not consider it reasonable to support debian oldstable for new developments. I do know that Debian stable is not uncommon as a base. /Sune
Re: Performance improvement
On 2025-05-22, Igor Mironchik wrote: > Hi. > > I'd like to ask you, guys, maybe I'm a dumb a little, and you know how > to optimize a following function. I don't understand the requirements. Can you provide 10 sets of input/output ? /Sune
installing kcfg xml files
Hi Due to I was looking at why we install kcfg files. They seem to have two different usages in the sources: They can be KConfigLoader'ed at runtime or they can be kconfig_compiler'ed to c++ code at build time. Or sometimes both. I don't know if I have missed something, but do we have utilities that work with other projects kcfg files where it would be an advantage to have the kcfg files around for the code generated c++ files ? Do we gain anything from installing a settings.kcfg file for a component that is using it for code generating at build time, or are we just confusing our future selves by having them also installed? /Sune
