lzip vs. xz
Hi devs! We provide all source tarballs xz-compressed. Now, apparently, xz is quite a badly designed format (cf. http://lzip.nongnu.org/xz_inadequate.html ), and lzip provides the same compression, but an apparently distinctly more reasonable format. I must admit that I personally neither heard about lzip, nor about xz being no good choice until today, but the current tar even supports it through the -- lzip switch. It seems to me that xz has more attention and popularity than it deserves, and lzip has less. Did you ever think about promoting lzip by using it for tarballs? Just in case the criticism about xz is justified. Cheers, Tobias
libkgeomap
Hi list, back then, I advocated to release libkgeomap as a single library via KDE (not as a part of Digikam), so that distributors would include it and it became available to users without Digikam being installed. This was beacause we used that library (along with libkface, also from the Digikam project) in KPhotoAlbum. Quite some time ago, we dropped libkface support, and -- speaking of Gentoo -- the library also disappeared from Portage. With the next release of KPhotoAlbum (I'll expectedly tag it this week-end), we will also drop libkgeomap in favor of using Marble's API directly. As far as I know, we from KPhotoAlbum were the only project (apart from Digikam itself of course) to use those libraries. So, if nobody has an objection against it, maybe there's no longer a need to keep those libraries as single-release parts of KDE. Cheers, Tobias
Introducing KGeoTag, a KDE photo geotagging program
Hi devel mailing list :-) I'm Tobias Leupold. I have been a KDE developer since 2014. I mostly participated in KPhotoAlbum. Currently, I'm one of the three active developers of the project (somewhat a jobbing developer, because I'm the only one not earning my money with writing code. I'm just a hobby programmer, but I try to do my best ;-) I'd like to introduce a new project I recently started. It's KGeoTag, a photo geotagging program for KDE. The code can be found on https://invent.kde.org/tleupold/kgeotag . At the latest since Digikam's geolocation KIPI plugin isn't available anymore, I think the Linux desktop lacks a decent geotagging program. There are a few programs able to write coordinates in Exif headers, but some aren't maintained anymore, some only do it besides and some are only graphical frontends to console programs without a real added value. At least -- speaking of me -- I didn't find a straightforward, nice geotagging program. I used GpsPrune recently, but it's written in Java, not nicely integrated with my desktop and it's inconvenient for geotagging. Mostly, it's lacking a simple drag-and-drop interface. As a KPA tenet is to not alter the images we cataloguize, I decided to write a small, overseeable new standalone program with the only purpose to geotag photos. And that's KGeoTag. Marble is used to display a OpenStreetMap map. One can load geodata from one or more GPX files which is drawn on the map. Images can be added and then assigned with coordinates in three ways: One can search for exact matches between the images' dates and available points from the GPX data, with a defined maximum deviation. If no exact data is available, interpolated matches can be calculated, with both a maximum timespan and distance between the points used for the interpolation. Finally, all coordinates can be set or corrected manually by dragging and dropping the images directly on the map. This is also possible without loaded geodata. Missing or incrorrect altitude values can be obtained from opentopodata.org's API. Either manually or automatically when dropping images on the map. This is disabled by default (for privacy reasons, as coordinates have to be transferred to opentopodata.org's servers when asking for a specific elevation). If there's a time drift in the images' metadata due to the camera's clock not being exactly in sync with the GPS data, it can be corrected and considered when searching for matches. Also, it can be fixed in the images' headers. Finally, the coordinates (and possibly fixed dates and times) can be written to the images. KGeoTag uses the libkexiv2 library with it's nicely geared-up geodata functions. Libkexiv2 being mature, well-tested and documented, I suppose we can be quite sure that KGeoTag doesn't eat the images it works on. Nevertheless, by default, a backup of the original files is created before saving the changes. I consider this project to be a complementary tool for KPhotoAlbum, and possibly other geodata-aware programs. It's purpose of application has tight limits, and consequently, the codebase is overseeable and should be easy to maintain. The code is quite new (still lacking even a 0.1 tag); anyhow, it's already fully functional. I successfully geotagged some real-life datasets of family vacation photos where I carried a GPS logger most of the time, and it worked nicely. Maybe, some of you also think that this would enrich the KDE ecosystem. I'd be happy to get some feedback. And perhaps, if I'm not the only one who thinks we need this, it could be moved to graphics/, like KPA? Surely, it's by far not important enough to be distributed by KDE like Marble or such, but maybe, it could be a KDE extragear application like KPA one day. Thanks to anybody having read the whole thing until here, and thanks in advance for all feedback :-) Cheers, Tobias
Re: Introducing KGeoTag, a KDE photo geotagging program
Hi Albert! Thanks a lot for your reply and your input! Can you control Marble's widget right mouse button menu, it's a bit confusing to have all those options that don't really seem related to KGeoTag. It was quite not trivial to outwit MarbleWidget (Marble's API is a bit odd sometimes), but now, we have a context menu with only a few meaningful checkable floaters to toggle, along with an option to show or hide the map center crosshairs. That's what it was about: A possibility to hide the default floaters if one doesn't need them. The rest (like routing etc.) is actually not used by KGeotag and should consequently not be showed. Loading 1 image (without coords) and choosing "Assign images interpolated" crashes here. Thanks for finding this ;-) Fixed with commit 78932011. This didn't depend on the number of loaded photos, but happened if one tried to do an interpolated association without geodata being loaded (due to an inconsiderate use of QVector::first()). Finally, all coordinates can be set or corrected manually by dragging and dropping the images directly on the map. This is also possible without loaded geodata. Could you think another way to set the coordinates that doesn't involve dragging and dropping images into the map? Knowing what the app was about i had to come back to this email and read it in more detail to figure out how to set the coordinates of a photo, so maybe it's not the most usable way. What i tried was double clicking in an image in the "Unassigned images" list and also right clicking on it. I think i was expecting that double clicking/right clicking would offer a "set coordinates to the center of the marble map" option, after all it has that X marker, but feel free to ignore me, i'm not an expert in user design :) Me neither ;-) KGeoTag now offers the option to assign an image with the coordinates of the current map center via the context menu. The map is now only centered to the selected image if the image is clicked or selected by the arrow or page up/down keys. When dragging the image or invoking the context menu, the map stays at it's last position. I think it's a great tool, i have lots of pictures without geotagging, and i'm never going to get around to fix it because i'm lazy, but if i would this is really the tool i'd like to use :) Thanks for the commendation ;-) Cheers, Tobias
KGeotag development
Dear devs, some time ago, I introduced the KGeoTag project. Meanwhile, the git repository has been moved from my personal projects to graphics/, we have a Bugzilla product (already used for a translation-related issue), and an IRC channel. The hardworking i10n enthusiasts team actually already translated the whole thing in several languages (despite the project still being beta and lacking a first stable release!). At least two KDE devs have had a closer look at the code, Nicolas Fella concerning the build system and Johannes Zarl-Zierl helping me with the item model and the drag and drop support. So, apparently, I'm not the only one thinking this could be a convenient program for KDE :-) Ben Cooksley said that necessarily, a new project at first is declared as "playground", until some review process is passed and it then can become an "extragear" app. I think, at least for a first release, the program now is feature-complete, and currently, I'm also not aware of any bugs. So what are the next steps for KGeoTag to become extragear and making it possible to do a first "official" release? Thanks again for all the support and interest :-) Cheers, Tobias
Accessing a (sub)menu defined in an XmlGui ui.rc file
Hi list :-) I have a problem with a KXmlGuiWindow and I honestly can't find respective docs or howtos/tutorials. I hope someone here can help me ... It's a allegedly basic task: How can I access a submenu (or better: a submenu's QAction) for a menu defined in a ...ui.rc file? If I define the submenu like so: Some text I can access the "someAction" action like the other ones like so: auto *someAction = actionCollection()->addAction(QStringLiteral("someAction")); someAction->setText(i18n("Some action")); someAction->setIcon(QIcon::fromTheme(QStringLiteral("some-icon"))); connect(someAction, &QAction::triggered, this, &SomeClass::someFunction); and so on. But how can I get the "bar" QMenu (or it's respective QAction)? So that I can e. g. disable or hide the menu, or assign an icon? For manually defined menus, this would be as easy as "auto *action = menu->menuAction();" ... Sorry if I overlooked something obvious, but I have no idea how to do this. Thanks in advance for all help! Cheers, Tobias
Re: Accessing a (sub)menu defined in an XmlGui ui.rc file
Hi Thomas! Thanks for this info, but this is about context menus ... I want to access a submenu inside a menu of the main menu bar ... such as the "File" --> "Recently used" menu of KWrite or such Am Mittwoch, 13. Januar 2021, 11:25:18 CET schrieb Thomas Baumgart: > Here's how it is done in KMyMoney (may not be the best way, but it's > working): > > > https://invent.kde.org/office/kmymoney/-/blob/master/kmymoney/kmymoney.cpp# > L1270 > > creates all the menus during initialization. The QStringLiterals contain the > names used in the xmlgui.rc file. KMyMoneyApp is derived from KXmlGuiWindow > and thus provides the factory() method. The actions need to exist before > the menu is initialized from what I see. All this is called before > setupGUI() is executed. > > > The context menu can then be executed by e.g. > > lutMenus[Menu::Institution]->exec(QCursor::pos()); > > Hope that helps and gives you some ideas.
Re: Accessing a (sub)menu defined in an XmlGui ui.rc file
I still don't get it :-D All I get is nullptrs ... Maybe I'm missing the forest for the trees?! I now attached a minimal example showing my dilemma. After having put demoui.rc to ~/.local/share/kxmlgui5/demo/, the GUI is setup nicely and all, but how do I get a pointer to the "subMenu" menu? To e. g. assign an icon to it's action or to disable the whole menu?! Am Mittwoch, 13. Januar 2021, 14:58:25 CET schrieb Ismael Asensio: > Once you have the main QAction, it has a menu() method, which in turn has > an actions() method. > > So for instance: > bar = foo->menu()->actions().at(0). > > Of course with much more logic to check that every item exists and not > hardcoding the position, but I hope you get the point. cmake_minimum_required(VERSION 3.8.0) project(demo CXX) find_package(ECM 1.1.0 REQUIRED NO_MODULE) set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH} ${CMAKE_SOURCE_DIR}/cmake) find_package(Qt5 5.11 COMPONENTS Widgets REQUIRED) find_package(KF5 COMPONENTS XmlGui REQUIRED) set(CMAKE_AUTOMOC ON) add_executable(demo ${CMAKE_SOURCE_DIR}/main.cpp) target_link_libraries(demo Qt5::Widgets KF5::XmlGui) demoui.rc Description: application/vnd.kde.kxmlguirc #include #include #include class MainWindow : public KXmlGuiWindow { Q_OBJECT public: explicit MainWindow() { auto *topMenuAction = actionCollection()->addAction("topMenuAction"); topMenuAction->setText("Some top menu action"); topMenuAction->setIcon(QIcon::fromTheme("document-new")); auto *subMenuAction = actionCollection()->addAction("subMenuAction"); subMenuAction->setText("Some sub menu action"); subMenuAction->setIcon(QIcon::fromTheme("document-open")); // How do I get a pointer to the "subMenu" menu? // To e. g. assign an icon to it's action or to disable the whole menu?! KStandardAction::quit(this, &QWidget::close, actionCollection()); setupGUI(Keys | Save | Create, "demoui.rc"); } }; int main(int argc, char *argv[]) { QApplication app(argc, argv); auto *mainWindow = new MainWindow; mainWindow->show(); return app.exec(); } #include "main.moc"
Re: Accessing a (sub)menu defined in an XmlGui ui.rc file
Hi Alexander :-) This actually works! It has to be done after having called setupGUI(), just to notice this, otherwise, one still gets a nullptr. What I did in the example I wrote before: #include #include ... setupGUI(Keys | Save | Create, "demoui.rc"); auto *guiFactory = this->guiFactory(); auto *subMenu = dynamic_cast( guiFactory->container("subMenu", this)); subMenu->menuAction()->setIcon(QIcon::fromTheme("document-save-all")); ... I really tried hard to read the docs. And I really searched! But honestly, there's no way to grasp this (for somebody not having worked with this for ages or so). This should be either mentioned somewhere in a tutorial/howto or some more intuitive way to get a menu pointer should be available imo ... At least, the mailing list archive now knows this, so that possibly, one will be able to find this when googling it later. Thanks a lot :-) Tobias Am Mittwoch, 13. Januar 2021, 21:18:57 CET schrieben Sie: > Hi Tobias, > > > I have a problem with a KXmlGuiWindow and I honestly can't find respective > > docs or howtos/tutorials. I hope someone here can help me ... > > [...] > > But how can I get the "bar" QMenu (or it's respective QAction)? So that I > > can > > e. g. disable or hide the menu, or assign an icon? For manually defined > > menus, > > In your main window class deriving from KXMLGuiWindow you do the following: > > auto* factory = this->guiFactory(); > auto* menu = dynamic_cast(factory->container("bar", this)); > if (menu) { > //add your logic here with the menu pointer > } > > Is this what you're looking for? > > -- > Alexander
Re: Accessing a (sub)menu defined in an XmlGui ui.rc file
Hi David! Thanks for the input! In my case, it was only about how to get a pointer to a menu defined via XML. What Alexander wrote does this very job: auto *someMenu = qobject_cast( guiFactory()->container("menuId", this)); (for the XML you wrote, calling this with "foo", would return a pointer to the menu defined via ''. Am Mittwoch, 13. Januar 2021 23:53:20 CET schrieb David Hurka: On Wednesday, January 13, 2021 10:39:48 AM CET Tobias Leupold wrote: Hi list :-) I have a problem with a KXmlGuiWindow and I honestly can't find respective docs or howtos/tutorials. I hope someone here can help me ... I faced the same problem... :( It's a allegedly basic task: How can I access a submenu (or better: a submenu's QAction) for a menu defined in a ...ui.rc file? If I define the submenu like so: ... I probably don’t understand properly what you need. But if you want to modify the action which contains the menu "bar", you could use KActionMenu. Change the ui.rc to: then create a KActionMenu called "bar" in your KActionCollection, set its icon etc., and populate its menu. Of course this moves UI definition from ui.rc to C++ code, but it looks like you want to modify the menu at runtime.
Gitlab CI help
Hi list :-) Please be merciful, I'm completely new to CI and never used GItLab CI before ;-) I tried to setup CI for KGeoTag. I added a .kde-ci.yml and a .gitlab-ci.yml file, but the resulting build fails: https://invent.kde.org/graphics/kgeotag/-/jobs/134843 I don't really know what's wrong or where to start fixing this ... would anybody be so kind to give me a hint about what's wrong? Thanks a lot! Cheers, Tobias
Re: Gitlab CI help
> You have a dependency on a non-Frameworks project, which the system is > currently not setup to handle. > > 'graphics/libkexiv2': '@stable' > 'education/marble': '@stable' > > One of the pending items on the list of 'todos' is to make the system > handle missing dependencies better in terms of the error message it > provides. > > I'm afraid you'll need to wait until we're ready to rollout seed builds of > non-Frameworks projects. > > Cheers, > Ben Oh, okay. I was pretty sure I did something wrong ;-) I'll comment out the gitlab-ci for now. Thanks a lot for the help! Cheers, Tobias
Re: Announcing General Availability of Gitlab CI for Linux, FreeBSD and Android
Hi list :-) Sorry in advance for bothering you again about KGeoTag, but I still can't get it to work (which is most probably my fault, I'm still a CI n00b). I tried again with what I did some time ago, and it failed due to missing dependencies (cf. https://invent.kde.org/graphics/kgeotag/-/jobs/163441 ). I first thought this is still caused by Marble being not available, but only Frameworks libs, but then I saw that such a dependency should be referenced by e.g. 'kde/education/marble', not only 'education/marble'. I then tried again, but now, libkexiv2 isn't found, cf. https://invent.kde.org/graphics/kgeotag/-/jobs/164537 What am I missing? Also: Would/will it be possible to build on another system than Suse Tumbleweed, e.g. on Debian stable? Thanks for all help and sorry again for the noise ... Cheers, Tobias
Re: Announcing General Availability of Gitlab CI for Linux, FreeBSD and Android
Am Montag, 29. November 2021, 12:24:40 CET schrieb Albert Astals Cid: > So add >'graphics/libkexiv2': '@same' > to your .kde-ci.yml > > Cheers, > Albert I tried, but then, I get Exception: Unable to locate requested dependency in the registry: libkexiv2 (branch: @stable) Would you mind having a quick look at my .kde-ci.yml and .gitlab-ci.yml? All I do is trial and error, without any success :-( Thanks again for all help!
Re: Announcing General Availability of Gitlab CI for Linux, FreeBSD and Android
Am Montag, 29. November 2021, 13:58:46 CET schrieben Sie: > KDE Gear stuff doesn't have "@stable" in CI yet, note that i wrote "@same" > instead, that will make you use keviv2 master for your master branch, that > maybe is not what you want, but it will work, and given that kexiv2 doesn't > change that much it's probably fine anyway. Ah okay! Thanks a lot, it works now :-)
Re: Announcing General Availability of Gitlab CI for Linux, FreeBSD and Android
Am Montag, 29. November 2021, 17:25:14 CET schrieb Ben Cooksley: > > @same should only be used when the other project is part of the same > release unit. > While this works for the moment because all of the involved projects have a > 'master' branch, when you go and tag/branch a stable release it will fail - > as your branch/tag names will be different. > > The correct fix in this case is to update > https://invent.kde.org/sysadmin/repo-metadata/-/blob/master/branch-rules.yml > with the appropriate details for '@latest' and '@stable' for both marble > and libkexiv2. > > Cheers, > Ben Which versions are "latest" and/or "stable" is something the libkexiv2 and Marble guys would have to decide or set, yes? Like "stable" could be the version released with Debian stable or so, and "latest" the latest released version? Or master?
Re: Announcing General Availability of Gitlab CI for Linux, FreeBSD and Android
Am Dienstag, 30. November 2021, 06:31:05 CET schrieb Ben Cooksley: > On Tue, Nov 30, 2021 at 8:21 AM Tobias Leupold wrote: > > Am Montag, 29. November 2021, 17:25:14 CET schrieb Ben Cooksley: > > > @same should only be used when the other project is part of the same > > > release unit. > > > While this works for the moment because all of the involved projects > > > > have a > > > > > 'master' branch, when you go and tag/branch a stable release it will > > > > fail - > > > > > as your branch/tag names will be different. > > > > > > The correct fix in this case is to update > > > > https://invent.kde.org/sysadmin/repo-metadata/-/blob/master/branch-rules.y > > ml> > > > with the appropriate details for '@latest' and '@stable' for both marble > > > and libkexiv2. > > > > > > Cheers, > > > Ben > > > > Which versions are "latest" and/or "stable" is something the libkexiv2 and > > Marble guys would have to decide or set, yes? Like "stable" could be the > > version released with Debian stable or so, and "latest" the latest > > released > > version? Or master? > > Generally I would expect @latest to correspond to the current development > branch for Qt 5 yes. > Likewise, @stable should correspond to the most current stable branch for > Qt 5. > > Due to the way the system works it is flexible and allows us to introduce > additional @ tags as needed - such as @latest-qt6 or @lts if they are > needed in the future. > > Cheers, > Ben Okay! But I can't push some change to this file only because I want to use a library as a dependency, right? This is up to the maintainers?
Re: Anyone interested in taking over Trojitá ?
Hey Andreas! Big thumbs up! Please bring Trojitá back to life. Apart from KMail, it's the only really nice and usable mail client out there. It was really a shame that it was e.g. dropped by Gentoo due to unfixed security issues and the dependency to qtwebkit. Thanks in advance for all work on Trojitá :-) Cheers, Tobias Am Sonntag, 26. Dezember 2021, 11:51:32 CET schrieb Andreas Artz: > Hey Albert, > > I would like to maintain Trojitá! > > v/r > > Andi > > On 12/26/21 11:49 AM, Albert Astals Cid wrote: > > Hello, > > > > Albert with Security Team hat here. > > > > Trojitá hasn't been released for over 5 years and doesn't seem to have any > > active developers left. > > > > It has a [reasonably important] security issue and we need someone to take > > care of it> > >https://bugs.kde.org/show_bug.cgi?id=432353 > > > > If no one steps up in 1 month we will ask sysadmin to move Trojitá to > > unmaintained > > > > Cheers, > > > >Albert
Re: Anyone interested in taking over Trojitá ?
> Unfortunatly, it was dropped in Gentoo. But let us not do the same > failure for us here ;) Well, I think that it will be immediately re-added if the issues are solved. Gentoo is quite fast with those things. Thanks again, happy holidays and keep rocking :-)
libksane seems to break QProcess::start calls
Hi all :-) I have a very odd problem, and I have no idea what could cause this or even how to debug this. maybe, someone of you can give me a hint. I revently wrote a small helper program for one special purpose: Scanning documents at a defined size, post processing them a bit and saving the processed, compressed images as a PDF file to e.g. send them via mail. The sources can be found at https://invent.kde.org/tleupold/scandoc/ . It uses libksane, ImageMagick's convert and pdfjam as helper programs. This may be too special or too hacky to become e.g. an official KDE extragear program, but that's another thing. However the problem is: As said, the program uses convert to post process the scanned images. I use QProcess to run the respective command, in a procedural, synchronous way, as the command is typically finished within fractions of a second. The call strips down to: QProcess process; process.start(command, arguments); waitForFinished(); Using one scanner I have (it's a Brother MFC device), this works without a problem. Everything is fine. But using another one, a CanoScan LiDE 25, a really strange problem happens: After having scanned the first page, everything works as expected. But after having scanned the second one, the QProcess call doesn't exit anymore. It runs normally, and the output file is created. But it doesn't return, until it's killed by the waitForFinished() call. ps lists the process as "defunct". As expected, the GUI freezes for 30 seconds (the default timeout). But after the process is killed, the GUI is still frozen for another 30 seconds (why?!), then it becomes responsive again and the post processed image is added like if the call would have exited normally. It's also not about the "convert" call. Each and every QProcess I start after the seconds scan does not exit anymore. Even something like "dmesg" or such. After the first scan, everything is fine, after the second scan, QProcess::start does not exit anymore. As long as I don't do a second scan, I can start as many QProcess processes as I want, and all exit normally. But not anymore after the second page. I also tried to create the QProcess on the heap, and to implement the command run asynchronously. The result is the same: After the first scan, the process returns normally, after the second scan, it doesn't exit anymore ("can't start, already running"). To make it even more peculiar: At first, I implemented the convert process to read from stdin and write to stdout, piped the image data to it, and read the output to get the processed image directly. This caused no problem, no matter how much scans I did. But later on, I needed to call programs not reading from stdin. So ... how can that even happen? Where do the 30 seconds unresponsiveness come from, after the QProcess has already been killed?! Is this something that libksane causes? How can it influence a completely unrealted QProcess call? Or did I simply write crappy code?! If anybody has any idea about this, I would really appreciate some enlightenment ;-) Thanks for all help in advance! Cheers, Tobias
Re: libksane seems to break QProcess::start calls
Hi Klaas! > Interesting, I wrote a very similar little utility called PDFQuirk: > https://dragotin.github.io/quirksite/ Well, apparently, this is a quite common task to do ;-) > PDFQuirk has a very similar idea, yet it does not use libksane, but the > command line tool scanimage directly, started via QProcess. The idea > behind that is that the users should not need to tweak around with > scanner settings after the 'admin' set them, as in the average office, > the scanner does not change so often... I also thought about using scanimage (actually, scandoc is the GUI version of a shell script I used until now). But being able to set the scanner settings via the GUI (esp. the page size) seemed nicer to me. Once set, the settings are saved and restored per scanner, so that one only has to set them once, too. > As this only happens with one scanner and works fine with the other > (right?), Correct > I would point to the scanner driver that is loaded by sane. > Have you tried the scanimage command line utility from SANE if it works > with the scanner in question? Using scanimage on the console works without a problem. The thing I really don't get is how scanning two images can ever affect a QProcess started somewhere else ... I mean the convert process does work, but QProcess thinks that it doesn't finish ... but only after two scans ...
Re: libksane seems to break QProcess::start calls
Am Donnerstag, 3. März 2022, 19:06:21 CET schrieb Stefan Brüns: > Are you using either Qt5 < 5.15 or a kernel version which does not support > CLONE_FD? - then you are relying on SIGCHLD for process exit notification. > > CLONE_FD: https://lwn.net/Articles/636646/ > Qt5: https://codereview.qt-project.org/c/qt/qtbase/+/108456/ > > sane-backends/backend/plustek-usbhw.c messes with the signal handlers and > fails to restore it: `sigaction(..., ..., NULL)` I use Qt 5.15.2 and Gentoo's kernel 5.15.16. Is there something I can check to figure out if this could cause the problem? Apparently, there's no kernel option I can set? Apart from that, the scanner in question actually does use the plustek backend! I fear there's no way to fix this in my code?!
Re: libksane seems to break QProcess::start calls
Hi Thiago and all, thanks a lot for the input so far! I'm really a bit lost here ... Am 04.03.22 um 01:06 schrieb Thiago Macieira: > Fix the problem where the problem is. I would really love to, esp. if this could be some upstream issue. And if not, I'd also love to fix it ;-) You can strace the process. Add the options -f -bexecve to see the current process and its forks & threads, but stop when it executes a child process. You should see SIGCHLD line, like this: I did it like this. I created one strace for the scanner not causing problems and scanned two pages. This resulted in 27,096 lines of output. Then I created one for the scanner causing the issue, also scanning two pages. This yielded a solid 270,807 lines :-O To be honest, I don't have a clue for what I search in those files ... would you be so kind to have a look? Or can I lessen the output, so this becomes more readable? I uploaded the traces here: https://l3u.de/tmp/strace_brscan.txt.xz https://l3u.de/tmp/strace_plustek.txt.xz Thanks again for all help! Cheers, Tobias
Re: libksane seems to break QProcess::start calls
Hey Thiago, Am Freitag, 4. März 2022, 18:35:23 CET schrieb Thiago Macieira: > And this is the reason why you got the symptom of QProcess breaking. We'd > have expected that the eight mention be the same as the fifth, to keep the > pattern going, but it isn't. It's the same as the second and sixth > mentions. The SIGCHLD handler that ran is that stupidly short one, which we > now know to be definitely buggy. Thanks a lot for the comprehensive analysis! I don't grasp this compleley -- or, to be honest, not at all ... most likely, one has to be a real programmer to do so ;-) But it's definitely quite impressive how you can read this from the trace! But this: Am Freitag, 4. März 2022, 18:02:37 CET schrieb Thiago Macieira: > So the question is why this brscan didn't even attempt to use pidfd. There's > some code in Qt5's QProcess to attempt to detect whether you've subclassed > QProcess and skip using the pidfd feature: > > if (typeid(*q) != typeid(QProcess)) > ffdflags |= FFD_USE_FORK; > > https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qprocess_unix.cpp? > h=5.15#n462 made me try one thing: I used a small helper class subclassing QProcess to execute the external commands. It did not much, just took a command line like you would type it in a shell, along with the in and out file, extracted the program parameter from it and assembled the arguments QStringList. And then ran QProcess::start and checked if the start succeeded, and catched STDERR if the program would not exit with 0. I simply made this a QObject subclass and rather then using start() etc. directly, I created a QProcess object and did the same stuff with this one. No freezes anymore. No matter what scanner I use. I never thought subclassing the QProcess would change the behavior in such a radical way :-O Is there some passage in the docs that says "Never ever subclass a QProcess unless you exactly know what you are doing, otherwise, you will experience the weirdest problems"? :-D I would never have figured this out. Thank you very very much for having a look at this and pointing me in the right direction. Cheers, Tobias
Re: libksane seems to break QProcess::start calls
> It's a side-effect. The problem is the QProcess::setupChildProcess virtual > in Qt 5, that had been there since QProcess was introduced the the > Paleolithic Era. When we use CLONE_PIDFD, we have to call clone() directly, > which means the hooks installed by pthread_atfork() do not get run. In > particular, this may mean the mutexes locked by other threads are all still > locked, including one inside malloc(). That would mean the user's code in > setupChildProcess() could deadlock depending on the kernel version. Thanks again for clarifying this! > ... So it was simplified to "if you derive, assume setupChildProcess > was overridden." I don't know if this would be still possible for the Qt 5 docs, but a small hint like "If you subclass this, be aware that ..." woudn't hurt ... As said, I would never have thought that this would have such side-effects! Sure, Qt 6 has been out for some months now, but I think Qt 5 may be still used for quite some time. Here at Gentoo, we e.g. don't even have Qt 6 in the main package repository yet, and normally, Gentoo is not much hesitant to add new versions ... but that's another issue. > Anyway, please note that simply your problem still exists even without > subclassing on kernels older than 5.4. For those, we have to use the SIGCHLD > handler anyway. This must be fixed in the SANE backend. If you're really bored some time, maybe you want to file an issue for the SANE Pixma backend and tell the devs what exactly is wrong there and/or how to fix this? > Or you can work around it by doing what it is doing: fork(). Well, I think, if I'm safe with Qt >=5.15 and Kernel >=5.4, for now, I'd stick with the simple implementation that works now. Forking some part of a Qt program is something I even know less about than what can happen if I call external programs via QProcess ... I'm quite happy to have it in a working state now! Surely, the fact that some SANE backends may cause issues with process calls with older kernels should be mentioned in the still-to-write docs. But at the moment, I think I should first see if anybody besides me ever considers the project to be meaningful and if it would be worth it to make it safe for older environments. Although it may be worth it to mess with this stuff to learn more about process handling, threads and forks and so on. I think, first, I'll get the whole thing in shape with a program icon, installation target, message extraction script and so on. So that it _could_ be used. And then, I'll see if anybody actually wants to use it ;-)
Re: libksane seems to break QProcess::start calls
> It shouldn't have any side-effects. In fact, the code exists to *avoid* > side-effects in the first place. > > Of course, it assumes that there isn't buggy code elsewhere. If there is, > then all bets are lost. I'm not going to document how to bugfix other code, > especially complex code like this. And we've already established that the > SANE backend is buggy. Sorry, I got that wrong. I thought that always if one subclasses a QProcess, one would have to care about implementing some virtual functions to get it working correctly. If it's only the SANE backend that breaks this, you're of course right. > > If you're really bored some time, maybe you want to file an issue for the > > SANE Pixma backend and tell the devs what exactly is wrong there and/or > > how to fix this? > > I'm not. I'll explain if you file or if you want to actually fix, but I > don't have that much free time available. Within what I could grasp, I filed an issue: https://gitlab.com/sane-project/backends/-/issues/582 I fear fixing this is far beyond my programming skills. I hardly understand what's going on here at all ... > Well, if you use QProcess to call the full SANE backend, that will also > avoid the problem. Yeah, maybe if I would acquire the images not by using libksane, but by calling scanimage via QProcess, I would not have any problem. But apart from losing the functionality I wanted to implement (setting the scanner options in a nice GUI way) that would only work around the real problem, which is a buggy implementation of the plustek backend, wouldn't it? > "If you write buggy code, the application may misbehave" is not > documentation. Let's hope the SANE devs fix it ;-)
Re: The KIPI fate
Hi all, I'm just the small junior dev here, with surely no authority to decide anything. But don't do that. That will make a lot of people stop using our software. I'm pretty sure about that. Either, we create a surveillance state or, in the best case, it's just plain annoying (would you like to collect and submit telemetry data? -- No). Do we really want to shift in this direction?! Please someone say no. At least for the projects I created or work on, I want my user feedback via IRC, mailing lists, bug reports, feature requests or whatever. But not via data collected by my applications and sent to some central server. Cheers, Tobias Am Samstag, 16. April 2022, 17:09:39 CEST schrieb o lu: > On 4/15/22 07:42, Harald Sitter wrote: > > Going off on a tangent: > > I think you are hitting on a very important point. No matter what > > happens with kipi here, we should add userfeedback support for > > features that we'd like to remove and get a sense of the users the > > removal impacts. Right now we have no metrics, so all we are left with > > is removing stuff and see how many people complain and possibly > > backpedaling after the fact. That is not ideal. > > > > HS > > I used to be *completely* against telemetry of any sort until I saw an > article a couple of weeks ago that explained a use case in Firefox: they > were able to make a "heat map" of where users click in the toolbar to > see which buttons were being pressed and with what frequency. So I > think that all KDE applications should have a (configurable and > inspectable) telemetry option to let developers know exactly which > features are being used and how much. This would solve (at least in > part) the problem described above.
Trigger loading a list of files from Dolphin using "open with"
Hi list! I'm working on Bug #455074, and I noticed some behavior of Dolphin I wonder if it can be changed or worked around. What happens when I select multiple files in Dolphin and do "open with" is that not a list of the selected files is passed to the called program, but one instance of the program is opened for each file. This does not only happen for what I try to implement in KGeoTag, but also e.g. for the Gimp (instead of opening a tab for each file, one Gimp instance is opened for each file). So: Can this behavior be changed? Is it possible to send a list of files to a program called via "open with"? And can I tell Dolphin to do so via the .desktop file or such? In case of KGeoTag, what I implemented to open files and/or directories using command line parameters works fine if it's called via the command line (also with wildcards), but not via Dolphin ... Thanks for all help! Cheers, Tobias
Re: Trigger loading a list of files from Dolphin using "open with"
Maybe it depends on if the respective file type is associated with the program or set by default to be opened with it? When I select three jpg files and choose "open with Gwenview", I get one Gwenview instance showing all three files. If I do the same with "open with Gimp", I get three Gimp instances. Same for KGeoTag: Three files selected --> three instances. I'm on Gentoo btw. Am Freitag, 15. Juli 2022, 23:44:27 CEST schrieb David Hurka: > On Friday, July 15, 2022 11:35:11 PM CEST Tobias Leupold wrote: > > What happens when I select multiple files in Dolphin and do "open with" is > > that not a list of the selected files is passed to the called program, but > > one instance of the program is opened for each file. > > > > This does not only happen for what I try to implement in KGeoTag, but also > > e.g. for the Gimp (instead of opening a tab for each file, one Gimp > > instance is opened for each file). > > I did not notice this behavior yet. > I frequently select a couple of source files in Dolphin, and do Enter to > open all of them in Kate. > It always opens only one Kate instance. > > But if I select only one, do Enter, then select another one, do Enter, > before any Kate instance has launched, I get multiple Kates. > So I think either your Dolphin works different than mine, or you have > another mistake. > > BTW here it works the same whether I do Enter or right-click -> Open with...
Re: Trigger loading a list of files from Dolphin using "open with"
That's it. Thanks a lot :-) Am Freitag, 15. Juli 2022, 23:50:40 CEST schrieb J Blackquill: > Hi, this is controlled by the KIO::ApplicationLauncherJob. > It asks KService whether it can launch one instance or if it needs to > do n instances, and this is the code that KService uses for that: > > bool KService::allowMultipleFiles() const > { >Q_D(const KService); >// Can we pass multiple files on the command line or do we have to > start the application for every single file ? >return (d->m_strExec.contains(QLatin1String("%F")) // > >|| d->m_strExec.contains(QLatin1String("%U")) // >|| d->m_strExec.contains(QLatin1String("%N")) // >|| d->m_strExec.contains(QLatin1String("%D"))); > > } > > In short, you should be using the standard XDG thing that says you can > take multiple URLs on launch in your .desktop file (%U in the Exec > key). > > Cheers, Janet > > Am Fr., 15. Juli 2022 um 17:35 Uhr schrieb Tobias Leupold : > > Hi list! > > > > I'm working on Bug #455074, and I noticed some behavior of Dolphin I > > wonder if it can be changed or worked around. > > > > What happens when I select multiple files in Dolphin and do "open with" is > > that not a list of the selected files is passed to the called program, but > > one instance of the program is opened for each file. > > > > This does not only happen for what I try to implement in KGeoTag, but also > > e.g. for the Gimp (instead of opening a tab for each file, one Gimp > > instance is opened for each file). > > > > So: Can this behavior be changed? Is it possible to send a list of files > > to a program called via "open with"? And can I tell Dolphin to do so via > > the .desktop file or such? > > > > In case of KGeoTag, what I implemented to open files and/or directories > > using command line parameters works fine if it's called via the command > > line (also with wildcards), but not via Dolphin ... > > > > Thanks for all help! > > > > Cheers, Tobias
Help with tarme.rb
Hi all, I have a small problem with creating release tarballs. I must have missed something?! Yesterday, I created a release tarball for both KPhotoAlbum and KGeoTag. I first tried to do this as I always did it: ./tarme.rb --origin trunk --version 5.9.0 kphotoalbum that gave me Traceback (most recent call last): 8: from ./tarme.rb:74:in `' 7: from ./tarme.rb:74:in `collect' 6: from ./tarme.rb:81:in `block in ' 5: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/ release.rb:66:in `get' 4: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/ release.rb:154:in `check_ci!' 3: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/ jenkins.rb:60:in `from_name_and_branch' 2: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/ jenkins.rb:23:in `get' 1: from /usr/lib64/ruby/2.7.0/net/http/response.rb:133:in `value' /usr/lib64/ruby/2.7.0/net/http/response.rb:124:in `error!': 302 "Found" (Net::HTTPRetriableError) Then, I had a look at the wiki and found "--origin stable". I used this, and the tarball was created. Too late, I noticed (thanks Heiko Becker for mailing me!!!) that no translations are included in neither tarball. As said, I must have missed something -- what's wrong?! Thanks for all help for a (after all those years still) junior dev not doing releases too often ... ;-) Cheers, Tobias
Re: Help with tarme.rb
Am Montag, 5. September 2022, 00:19:24 CEST schrieb Tobias Leupold: > Hi all, > > I have a small problem with creating release tarballs. I must have missed > something?! > > Yesterday, I created a release tarball for both KPhotoAlbum and KGeoTag. I > first tried to do this as I always did it: > > ./tarme.rb --origin trunk --version 5.9.0 kphotoalbum > > that gave me > > Traceback (most recent call last): > 8: from ./tarme.rb:74:in `' > 7: from ./tarme.rb:74:in `collect' > 6: from ./tarme.rb:81:in `block in ' > 5: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/ > release.rb:66:in `get' > 4: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/ > release.rb:154:in `check_ci!' > 3: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/ > jenkins.rb:60:in `from_name_and_branch' > 2: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/ > jenkins.rb:23:in `get' > 1: from /usr/lib64/ruby/2.7.0/net/http/response.rb:133:in > `value' /usr/lib64/ruby/2.7.0/net/http/response.rb:124:in `error!': 302 > "Found" (Net::HTTPRetriableError) > > Then, I had a look at the wiki and found "--origin stable". I used this, and > the tarball was created. > > Too late, I noticed (thanks Heiko Becker for mailing me!!!) that no > translations are included in neither tarball. > > As said, I must have missed something -- what's wrong?! > > Thanks for all help for a (after all those years still) junior dev not doing > releases too often ... ;-) > > Cheers, Tobias I have not much clue about Ruby, but I just noticed that the problem seems to originate from "jenkins.rb", where a connection to build.kde.org is established. This URL is since recently redirected to metrics.kde.org/login (due to the retirement of Jenkins I think). Also, invent.kde.org/sysadmin/repo-metadata lists "trunk", "stable", "stable_kf5" and "trunk_kf5" in i18n.json, whereas tarme.rb acceps (according to "./tarme.rb --help") "trunk", "stable", "lts", "trunk_kde4" and "stable_kde4". So ... is this a tarme.rb issue?!
libksane, KSaneCore and QT_NO_KEYWORDS
Hi all! I recently had to port Scandoc from libksane to KSaneCore, and now, I have questions ;-) Question 1: On Gentoo, we have libksane 22.04.3 (stable) and 22.08.1 (testing). On an Artix machine I run, there's only 22.08.1 (those guys are even more bleeding edge than Gentoo ...). I could not link against libksane 22.08.1 anymore there. I knew that there was effort going on to create a separate library only containing the SANE communication backend, without the QWidgets dependencies. This is of course a reasonable thing to do -- but if I get this correctly, libksane itself now depends on KSaneCore, and one can't link against it as before. So what's the rationale behind still releasing libksane, when it can't be used anymore, and one has to port one's code to KSaneCore anyway? Apart from that: The KSaneCore API docs say that one should use "target_link_libraries(yourapp KF5::SaneCore)" in CMakeLists.txt to link against it. That actually didn't work, I had to use "target_link_libraries(scandoc ... KSane::Core)" to make it work. Am I missing something, or should either the documentation be changed and/or the "KF5::SaneCore" target be added/defined? Question 2: KSaneCore depends on at least KF 5.90.0. After bumping this dependency in my CMakeLists.txt, I was deluged with compiler errors. It was a bit hard to figure out what was going on, but long story short, "-DQT_NO_KEYWORDS" is now set by default, which makes it necessary to use "Q_SIGNALS", "Q_SLOTS" and "Q_EMIT" instead of "signals", "slots" and "emit". I know that defining these keywords is argued about, as it "pollutes" the global namespace. But afaik, the only scenario where one has to define "- DQT_NO_KEYWORDS" is when a third-party signal/slot mechanism is used. Doing so seems to be reasonable when coding the frameworks (as Qt add-ons) to leave this up to the user. But what's the rationale or benefit of doing so by default for applications? Thanks for all clarification and/or explanation! Cheers, Tobias
Re: libksane, KSaneCore and QT_NO_KEYWORDS
Am Donnerstag, 29. September 2022, 12:09:10 CEST schrieb Christophe Giboudeaux: > libksane is still needed by a couple applications: > https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=KF5%3A%3ASane Yeah, sure, Scandoc was one of those -- but the problem is that on can't build the code anymore against newer versions of libksane. The code before the port (last commit was ea5fe5b890147d0f70235ae9dcdeb022fe7df8a3) compiles without a problem against libksane 22.04.3, but with version 22.08.1, I get: In file included from /home/tobias/tmp/git/scandoc/build/scandoc_autogen/ UVLADIE3JM/moc_ScannerSettingsWidget.cpp:10, from /home/tobias/tmp/git/scandoc/build/scandoc_autogen/ mocs_compilation.cpp:9: /home/tobias/tmp/git/scandoc/build/scandoc_autogen/UVLADIE3JM/../../../ src/ScannerSettingsWidget.h:9:10: fatal error: KSaneCore: No such file or directory 9 | #include | ^~~ because libksane doesn't include or at least install the respective header(s) anymore ... On my Gentoo machine with 22.04.3, the following headers are installed: /usr/include/KF5/KSane/ksane_export.h /usr/include/KF5/KSane/KSaneWidget /usr/include/KF5/KSane/KSaneCore /usr/include/KF5/KSane/KSaneOption /usr/include/KF5/KSane/ksanewidget.h /usr/include/KF5/KSane/ksanecore.h /usr/include/KF5/KSane/ksaneoption.h /usr/include/KF5/ksane_version.h On the Artix machine with 22.08.1 (and also if I upgrade the lib on Gentoo), only /usr/include/KF5/KSane/KSaneWidget /usr/include/KF5/KSane/ksane_export.h /usr/include/KF5/KSane/ksanewidget.h /usr/include/KF5/ksane_version.h remain. So ... nothing besides KSaneWidget ... and if some code uses libksane's KSaneCore and KSaneOption headers, it can't be built against 22.08.1 anymore ... also, one can't use the new KSaneCore lib as a drop-in replacement, as the namespaces as well as some signal signatures have been changed. Don't get me wrong, It's of course the right thing to do to retire libksane in favor of KSaneCore. But I would have expected to see some emphasized "Don't use me anymore, port your stuff to KSaneCore, libksane will be discontinued soon" warning for at least some time, before an upgrade leaves non-ported code uncompilable ... > > The KSaneCore API docs say that one should use > > "target_link_libraries(yourapp KF5::SaneCore)" in CMakeLists.txt to link > > against it. That actually didn't work, I had to use > > "target_link_libraries(scandoc ... KSane::Core)" to make it work. Am I > > missing something, or should either the documentation be changed and/or > > the > > "KF5::SaneCore" target be added/defined? > > The change is intentional: https://invent.kde.org/libraries/ksanecore/-/ > commit/40c3d3687aee > > The metainfo.yaml also needs an update Thanks for the clarification!
Re: libksane, KSaneCore and QT_NO_KEYWORDS
Am 29.09.22 um 16:10 schrieb Ahmad Samir: On 29/9/22 10:22, Tobias Leupold wrote: Hi all! I recently had to port Scandoc from libksane to KSaneCore, and now, I have questions ;-) Question 1: On Gentoo, we have libksane 22.04.3 (stable) and 22.08.1 (testing). On an Artix machine I run, there's only 22.08.1 (those guys are even more bleeding edge than Gentoo ...). I could not link against libksane 22.08.1 anymore there. I knew that there was effort going on to create a separate library only containing the SANE communication backend, without the QWidgets dependencies. This is of course a reasonable thing to do -- but if I get this correctly, libksane itself now depends on KSaneCore, and one can't link against it as before. So what's the rationale behind still releasing libksane, when it can't be used anymore, and one has to port one's code to KSaneCore anyway? Apart from that: The KSaneCore API docs say that one should use "target_link_libraries(yourapp KF5::SaneCore)" in CMakeLists.txt to link against it. That actually didn't work, I had to use "target_link_libraries(scandoc ... KSane::Core)" to make it work. Am I missing something, or should either the documentation be changed and/or the "KF5::SaneCore" target be added/defined? Question 2: KSaneCore depends on at least KF 5.90.0. After bumping this dependency in my CMakeLists.txt, I was deluged with compiler errors. It was a bit hard to figure out what was going on, but long story short, "-DQT_NO_KEYWORDS" is now set by default, which makes it necessary to use "Q_SIGNALS", "Q_SLOTS" and "Q_EMIT" instead of "signals", "slots" and "emit". I know that defining these keywords is argued about, as it "pollutes" the global namespace. But afaik, the only scenario where one has to define "- DQT_NO_KEYWORDS" is when a third-party signal/slot mechanism is used. Doing so seems to be reasonable when coding the frameworks (as Qt add-ons) to leave this up to the user. But what's the rationale or benefit of doing so by default for applications? Switching to Q_EMIT was done in KF because "emit" is going to be used by the STL in C++20 and later: https://lists.qt-project.org/pipermail/development/2020-February/038812.html https://en.cppreference.com/w/cpp/io/basic_osyncstream/emit Thanks for all clarification and/or explanation! Cheers, Tobias Regards, Ahmad Samir This is indeed an understandable reason to use the Q_... macros by default. Thanks for the explanation!
Re: libksane, KSaneCore and QT_NO_KEYWORDS
Hey Alexander, > Sorry for causing the extra work! Everything is fine, wasn't too hard ;-) And, as said, KSaneCore is of course the way to go. So, sooner or later, I would have ported my stuff anyway. > Since the KSaneCore interface inside libksane was never publicly announced, > Kåre and I decided that it is okay to remove it from the libksane repo. > I wasn't really aware that any other application besides Skanpage and > KSaneWidget actually used it directly. And I wasn't aware that this wasn't intended to be used directly ... and it seems that I was the only one to do so, because otherwise, someone else would also have complained about this I think. It was just I didn't like the KSaneWidget too much, as it was too ready-made for my taste, and I wanted to do it in a slightly different way. Thus, I implemented my own stuff. Also, Scandoc is currently a personal project, so I think that not too many people are using it by now. However, I use it in production in my dentist's office since I started to write it, and my wife also likes it :-) I didn't ask for opinions about the project yet (if this was possibly something that somebody may consider to be suitable for Extragear or so). Just for anybody being curious: I'm talking about https://invent.kde.org/tleupold/scandoc . Okay, but after all, all my questions are fully answered now. I now know what's up with libksane, KSaneCore (thanks for that again!) and the Qt keywords. Thanks for all the kind and detailed replies :-) Cheers, Tobias
l10n data move from svn to git
Hi all :-) So a few hours ago, a new "po" folder appeared in KGeoTag, KPhotoAlbum and most probably everywhere. Apparently, the translations data is now not hosted on some svn repo anymore, but right indside the respective project? Which seems to be reasonable to me. I only have one question, after screwing up the last release of KGeoTag and KPhotoAlbum (which lacked all translations, due to tarme.rb not having been updated yet, and me having been the probably only misadventurer to make a release in the exact timeframe where the problem existed): Is there something I have to take care of in another way I had to do before when I do the next release using tarme.rb? Sorry for this possibly redundant question, but once burnt, twice shy ;-) Cheers, Tobias
Re: l10n data move from svn to git
Am Montag, 3. Oktober 2022, 18:37:34 CEST schrieb Albert Astals Cid: > El diumenge, 2 d’octubre de 2022, a les 14:06:58 (CEST), Thomas Baumgart va > > escriure: > > Hi all, > > > > On Sonntag, 2. Oktober 2022 13:42:16 CEST Tobias Leupold wrote: > > > Hi all :-) > > > > > > So a few hours ago, a new "po" folder appeared in KGeoTag, KPhotoAlbum > > > and > > > most probably everywhere. Apparently, the translations data is now not > > > hosted on some svn repo anymore, but right indside the respective > > > project? Which seems to be reasonable to me. > > > > > > I only have one question, after screwing up the last release of KGeoTag > > > and > > > KPhotoAlbum (which lacked all translations, due to tarme.rb not having > > > been > > > updated yet, and me having been the probably only misadventurer to make > > > a > > > release in the exact timeframe where the problem existed): > > > > > > Is there something I have to take care of in another way I had to do > > > before > > > when I do the next release using tarme.rb? > > > > A short description of the process would be wonderful. The last time I did > > a KMyMoney release, I ran into the problem, that tarme.rb requires a newer > > Ruby version than my distro (stock opensuse leap 15.4) currently supports. > > I simply reverted back to the last one working and kept going. Of course, > > that will not be working when there are changes coming up regarding the > > po subdir. > > > > > Sorry for this possibly redundant question, but once burnt, twice shy > > > ;-) > > > > I feel with you. Thus any hint/link is very welcome also from my side. I > > have to admit that I did not closely follow the latest changes due to time > > constraints. > > Unrelated to your actual question, but you should add ki18n_install(po) to > your base CMakeLists.txt, releaseme was doing that for you, but you should > really have it in your repo, for example for people that build from source. Kindly, Christophe Giboudeaux already did that, also for KPhotoAlbum and possibly other projects. Thanks :-) > I'll let Harald answer if any modification needs to be done to the releaseme > process or not. That would be nice, and surely also relevant for others! > Cheers, > Albert > > > Cheers Thomas
Re: Copying po/docbook files to repositories nightly
Am Montag, 3. Oktober 2022, 15:47:15 CEST schrieb Albert Astals Cid: > El dilluns, 3 d’octubre de 2022, a les 15:38:29 (CEST), Albert Astals Cid va > escriure: > > El diumenge, 2 d’octubre de 2022, a les 17:57:10 (CEST), Johannes > > Zarl-Zierl> > > va escriure: > > > Hi Albert, > > > > > > Thanks for the change ! > > > > > > Am Sonntag, 2. Oktober 2022, 07:51:04 CEST schrieb Albert Astals Cid: > > > > Nothing broke but at least it seems the po files did not get commited > > > > to > > > > these projects (maybe there are some more problematic repots, please > > > > check > > > > yours if it's not part of KDE Gear, KDE Framworks or Plasma, those are > > > > the > > > > ones i did check more thoroughly and fix if found something) > > > > > > > > digikam > > > > gcompris > > > > kaffeine > > > > kbibtex > > > > kphotoalbum > > > > kst-plot > > > > rkward > > > > skrooge > > > > trojita > > > > ubiquity-slideshow-neon > > > > > > > > Because it is ignoring the po folder at the .gitignore file level, > > > > please > > > > don't do that anymore. > > > > > > I'm not sure why kphotoalbum is listed here - the "Sync po/docbooks with > > > svn" commit did land in our repo and po is not listed in our .gitignore. > > > > It seems I failed reporting kphotoalbum, apologies. > > Actually no I was right, the .gitignore has > kphotoalbum > in it > > which is making git ignore the >po/language/docs/kphotoalbum > folders. Hey Albert, Thanks for pointing this out! I think this is a remnant from old times where we didn't build inside of a "build/" directory. Which is possibly also the case for most of the other entries in .gitignore, but that's another thing. I hope I fixed this with commit ab87cf51, is it okay now? Tobias > Cheers, > Albert > > > > > > > This is a heads up, as a developer there's nothing you need to do, > > > > > > at > > > > > > most > > > > > > remove the po/ folder from .gitignore if for some reason it is > > > > > > there. > > > > > > Should I add "ki18n_install(po)" to my CMakeLists.txt? > > > > Yes, well no because Christophe already added it. > > > > Cheers, > > > > Albert > > > > > Cheers, > > > > > > Johannes
FreeBSD build for KGeoTag fails
Hi all, I just pushed a commit (with no code change, only updated metadata) to KGeoTag's repo, which triggered a CI build, and the one for FreeBSD failed: https://invent.kde.org/graphics/kgeotag/-/jobs/570090 I have no idea about FreeBSD -- is this something I can fix (apparently some dependecy problem?!)? Or could anybody knowing what's going on have a look at this? Thanks in advance! Cheers, Tobias
Re: FreeBSD build for KGeoTag fails
Am Donnerstag, 3. November 2022, 23:57:22 CET schrieb Albert Astals Cid: > El dijous, 3 de novembre de 2022, a les 19:46:41 (CET), Tobias Leupold va > > escriure: > > Hi all, > > > > I just pushed a commit (with no code change, only updated metadata) to > > KGeoTag's repo, which triggered a CI build, and the one for FreeBSD > > failed: > > > > https://invent.kde.org/graphics/kgeotag/-/jobs/570090 > > > > I have no idea about FreeBSD -- is this something I can fix (apparently > > some dependecy problem?!)? Or could anybody knowing what's going on have > > a look at this? > > I'm guessing https://invent.kde.org/education/marble/-/merge_requests/85 may > have something to do it given it's coming from a FreeBSD person. Seems like this is the exact issue! Thanks for the clarification. So, it doesn't seem like I can do anything about this, can I? Hopefully, this will be addressed soonish. > Cheers, > Albert > > > Thanks in advance! > > > > Cheers, Tobias
Would Scandoc be somthing for Extragear?
Hi all! Nowadays, sending PDFs of scanned documents via email or uploading them somewhere has become a recurring task. For years, I was using shell scripts to kind-of automate scanning, doing some post-processing and conversion -- after a fashion. But I thought that there should be some more straightforward tool for this. The known general-purpose scanning applications we have didn't do what I wanted to. So, at the beginning of the year, I started to write a quite specialized scanning program whose only purpose is to make scanning documents and turning them into a PDF file as easy as possible. The result is Scandoc. It currently lives at https://invent.kde.org/tleupold/scandoc The Readme contains a description of what it is. It uses KSaneCore to access a scanner and runs (by default well-known) helper programs to post-process the scanned pages and save them as a PDF file. By default, ImageMagick's convert tool is invoked for the colour/sharpness/gamma post-processing and TeX Live's pdfjam is used for the PDF conversion. However one can use any CLI helper program or script for those tasks. E.g. the repository contains an example script to output searchable PDFs by using the Tesseract OCR engine. Scandoc has been used for half a year in production now in my (dentist's) office, and -- from what I heard from the (of course by now only few) users -- it makes this very task of creating PDF files from documents a lot easier and can be used quite conveniently. I thus wondered if this would be something we could need in Extragear. At least, I wanted to share this with you, maybe, someone may find this useful :-) Cheers, Tobias
Re: Would Scandoc be somthing for Extragear?
Am Mittwoch, 9. November 2022, 20:22:08 CET schrieb Nate Graham: > Hello TObias, > > Have you checked out Skanpage? It does PDF scanning, including creating > multi-page PDF documents out of the scanned files. It also integrates > with the Purpose framework to offer a simple "Share" menu that lets you > email scanned documents very quickly. Hi Nate! Yes, I also checked Skanpage. However (like stated in the Readme), I can't batch post-process in Skanpage to sharpen/adjust the scanned pages and I can't fine-tune the size of the resulting images (and thus the resulting PDF). I simply needed/wanted a general-purpose scripting interface. Stuff like that Tesseract OCR thing can't be done from inside Skanpage (as far as I could grasp it). Also, Scandoc includes handy options on top of KSaneCore for duplex scanning: You can define and choose a source for single-page (flat bed) scanning and one for duplex scanning, which can be easily switched per scan. Also, you can work around an issue some duplex scanners have by rotating all even pages by 180° automatically. It's simply way more use-case specific, and (imo) does it's job better -- for that very use-case. > Nate > > On 11/9/22 06:32, Tobias Leupold wrote: > > Hi all! > > > > Nowadays, sending PDFs of scanned documents via email or uploading them > > somewhere has become a recurring task. For years, I was using shell > > scripts to kind-of automate scanning, doing some post-processing and > > conversion -- after a fashion. But I thought that there should be some > > more straightforward tool for this. > > > > The known general-purpose scanning applications we have didn't do what I > > wanted to. So, at the beginning of the year, I started to write a quite > > specialized scanning program whose only purpose is to make scanning > > documents and turning them into a PDF file as easy as possible. > > > > The result is Scandoc. It currently lives at > > https://invent.kde.org/tleupold/scandoc > > > > The Readme contains a description of what it is. It uses KSaneCore to > > access a scanner and runs (by default well-known) helper programs to > > post-process the scanned pages and save them as a PDF file. By default, > > ImageMagick's convert tool is invoked for the colour/sharpness/gamma > > post-processing and TeX Live's pdfjam is used for the PDF conversion. > > However one can use any CLI helper program or script for those tasks. > > E.g. the repository contains an example script to output searchable PDFs > > by using the Tesseract OCR engine. > > > > Scandoc has been used for half a year in production now in my (dentist's) > > office, and -- from what I heard from the (of course by now only few) > > users -- it makes this very task of creating PDF files from documents a > > lot easier and can be used quite conveniently. > > > > I thus wondered if this would be something we could need in Extragear. > > At least, I wanted to share this with you, maybe, someone may find this > > useful> > > :-) > > > > Cheers, Tobias
Re: Would Scandoc be somthing for Extragear?
Am Mittwoch, 9. November 2022, 20:59:15 CET schrieb Klaas Freitag: > Am 09.11.22 um 20:22 schrieb Nate Graham: > Hello, > > very interesting, seems we had a similar idea. > > I wanted it even simpler for the every day office with one (and exactly > one) scanner - with less options for (pot. confused) users. > I wrote a tool called PDF Quirk: https://dragotin.github.io/quirksite/ > > It is also in production for quite some time with good success. That is essentially what my old document scanning script did -- using the same tools. But without a GUI of course. Nice idea! Seems like I'm not the only one who worked on getting this very task done as easy as possible ;-) > regards, > Klaas > > > Have you checked out Skanpage? It does PDF scanning, including creating > > multi-page PDF documents out of the scanned files. It also integrates > > with the Purpose framework to offer a simple "Share" menu that lets you > > email scanned documents very quickly. > > > > Nate > > > > On 11/9/22 06:32, Tobias Leupold wrote: > >> Hi all! > >> > >> Nowadays, sending PDFs of scanned documents via email or uploading them > >> somewhere has become a recurring task. For years, I was using shell > >> scripts to > >> kind-of automate scanning, doing some post-processing and conversion > >> -- after > >> a fashion. But I thought that there should be some more > >> straightforward tool > >> for this. > >> > >> The known general-purpose scanning applications we have didn't do what I > >> wanted to. So, at the beginning of the year, I started to write a quite > >> specialized scanning program whose only purpose is to make scanning > >> documents > >> and turning them into a PDF file as easy as possible. > >> > >> The result is Scandoc. It currently lives at > >> https://invent.kde.org/tleupold/scandoc > >> > >> The Readme contains a description of what it is. It uses KSaneCore to > >> access a > >> scanner and runs (by default well-known) helper programs to > >> post-process the > >> scanned pages and save them as a PDF file. By default, ImageMagick's > >> convert > >> tool is invoked for the colour/sharpness/gamma post-processing and TeX > >> Live's > >> pdfjam is used for the PDF conversion. However one can use any CLI helper > >> program or script for those tasks. E.g. the repository contains an > >> example > >> script to output searchable PDFs by using the Tesseract OCR engine. > >> > >> Scandoc has been used for half a year in production now in my (dentist's) > >> office, and -- from what I heard from the (of course by now only few) > >> users -- > >> it makes this very task of creating PDF files from documents a lot > >> easier and > >> can be used quite conveniently. > >> > >> I thus wondered if this would be something we could need in Extragear. > >> At least, I wanted to share this with you, maybe, someone may find > >> this useful > >> > >> :-) > >> > >> Cheers, Tobias
Re: Would Scandoc be somthing for Extragear?
Am 10.11.22 um 10:09 schrieb Thomas Baumgart: On Donnerstag, 10. November 2022 09:28:17 CET Klaas Freitag wrote: Am 09.11.22 um 21:18 schrieb Tobias Leupold: Am Mittwoch, 9. November 2022, 20:59:15 CET schrieb Klaas Freitag: Am 09.11.22 um 20:22 schrieb Nate Graham: That is essentially what my old document scanning script did -- using the same tools. But without a GUI of course. Nice idea! Seems like I'm not the only one who worked on getting this very task done as easy as possible ;-) Yes, well, that is what people in the office need. "Classical" office suites are just the beginning. Things that we Linux guys considered black magic for long time (such as printing, scanning, ocr, doc analysis etc) are now super easy and available on mobile platforms. And that is what we compete with on the office desktop. 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. Would be a cool feature for sure -- but I don't think I could add this to Scandoc in a meaningful way, can I? I know people who run Kraft on Chromebooks to enable the users to use the "nice" productivity apps available with android. Tough times ;-)
Re: Would Scandoc be somthing for Extragear?
Am Donnerstag, 10. November 2022, 12:25:26 CET schrieb Klaas Freitag: > Am 10.11.22 um 10:09 schrieb Thomas Baumgart: > > Hi Thomas, > > > 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. > > The next version of Kraft that I am about to release has EPC QR Code > capabilities already [1]. That was a feature wish from users. I should > have docu and a blog post about that... > > > 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. > > Well, if it was only Kraft, we would probably be better off using in the > PDF embedded Metadata to detect that. Having that as an OCR based > feature would add that more generic of course. > > > I know, a bit off topic here. > > Is it? Where else would we discuss that? This mailing list is the right place for sure, but I think Thomas meant it's a bit off-topic for this thread (about whether or not Scandoc would be something enriching and/or suitable for Extragear). > regards, > Klaas > > [1] > https://github.com/dragotin/kraft/commit/4adecbf263844dd27141b6b1cf5c15a89af > 15102
Question about KWrite's new tab behavior
Hi all, the recent "Kate ate KWrite" change hit Gentoo's stable branch. Now, when opening more than one file, I get a tabbed view of all in one window instead of multiple instances. Obviously, I'm too dumb to find the respective setting (if it exists) ... when I set the maximum tab count to 1 and open two files, I see the second one and one tab in one window. After closing the tab, I see the first file, still in same window, without a tab bar (is this intended to function in this way btw?). How can I get the old behavior with multiple instances instead of tabs back?! We fear change :-D Thanks in advance for the explanation! Cheers, Tobias
Re: Question about KWrite's new tab behavior
Am Samstag, 3. Dezember 2022, 16:55:41 CET schrieb Reindl Harald: > Am 03.12.22 um 11:29 schrieb Tobias Leupold: > > How can I get the old behavior with multiple instances instead of tabs > > back?! We fear change :-D > > > > Thanks in advance for the explanation! > > [harry@srv-rhsoft:~/.local/share/applications]$ cat Kate\ \(New\ > Window\).desktop > [Desktop Entry] > Comment= > Exec=kate --new -b %U > Icon=kate > Name=Kate (New Window) > NoDisplay=false > Path[$e]= > StartupNotify=true > Terminal=0 > TerminalOptions= > Type=Application > X-KDE-SubstituteUID=false > X-KDE-Username= Having such a .desktop "cheat" file won't help when opening multiple files from within KWrite, will it?
Re: Question about KWrite's new tab behavior
Am Samstag, 3. Dezember 2022, 11:29:56 CET schrieb Tobias Leupold: > Hi all, > > the recent "Kate ate KWrite" change hit Gentoo's stable branch. Now, when > opening more than one file, I get a tabbed view of all in one window instead > of multiple instances. > > Obviously, I'm too dumb to find the respective setting (if it exists) ... > when I set the maximum tab count to 1 and open two files, I see the second > one and one tab in one window. After closing the tab, I see the first file, > still in same window, without a tab bar (is this intended to function in > this way btw?). > > How can I get the old behavior with multiple instances instead of tabs > back?! We fear change :-D > > Thanks in advance for the explanation! > > Cheers, Tobias Oh, there's already a bug report about this: https://bugs.kde.org/show_bug.cgi?id=458621 Sorry for the noise ...
Re: Retirement of Capacity
Am Sonntag, 15. Januar 2023, 07:36:03 CET schrieb Ben Cooksley: > Hi all, > > Since time immemorial, KDE has had a custom PHP framework known as Capacity > which we've used to build a good number of our websites. > > With the rise of Static Site Generators such as Jekyll and Hugo though, > we've been phasing this out and given that Hugo especially is now well > established as the go-to-tooling for building KDE websites, it is time we > retire Capacity. > > In addition, in the next few weeks the current server for our > static/capacity sites, Nicoda, will be replaced by a new system (Tyran) > that is currently awaiting configuration and i'd very much prefer to not > have to deploy legacy Capacity support there. > > I have checked our server configuration this evening and it looks like the > following sites still rely on Capacity in some form or another: > > konversation.kde.org > pe.kde.org > marble.kde.org > kmplayer.kde.org > www.kde.org > games.kde.org > docs.kde.org > czechia.kde.org > freebsd.kde.org > kmymoney.org > edu.kde.org > multimedia.kde.org > ro.kde.org > konqueror.org > kpdf.kde.org > jp.kde.org > utils.kde.org > events.kde.org > kst-plot.kde.org > conference2004.kde.org > conference2005.kde.org > akademy2006.kde.org > akademy2007.kde.org > akademy2008.kde.org > akademy2009.kde.org > www-staging.kde.org > il.kde.org > umbrello.kde.org > krusader.org > ev.kde.org > okular.kde.org > kdemail.net > extragear.kde.org > lakademy.kde.org > kphotoalbum.org > > Having a quick look through the repositories/sites, I see: > - Some that have already made the jump to Hugo/Jekyll (so likely just need > their Capacity support switched off) > - Some that are just redirects to apps.kde.org or elsewhere, and therefore > just need Capacity support switched off (and probably the repository > archived on invent.kde.org too) > - Others where the site content is still in Subversion and the site talks > about Maemo (eek!) > - Others where the site content is many years out of date and it is > probably best we just redirect it to www.kde.org / apps.kde.org. > > It would be appreciated if people could please take a look through these > sites. > > For the akademy2xxx.kde.org sites, it would be nice if we could get their > content migrated and incorporated into the new Hugo based akademy.kde.org > site, but in the absence of that I will be turning them into static sites > > Many thanks, > Ben Hi Ben, kphotoalbum.org has been moved to Jekyll and git quite some time ago and doesn't rely on Capacity (tbh I never even heard it before ;-) Cheers, Tobias
Re: Registration
Am Dienstag, 17. Januar 2023, 10:01:28 CET schrieb Ben Cooksley: > I have checked the backend provider we use to determine if someone is a > spammer. > The email address of the person trying to register here was listed by that > provider back in November 2022. > > The action of KDE Identity in this instance was therefore correct and given > their conduct I'm not going to be manually overriding it in this instance. > I've also set the moderation flag on them for this mailing list. > > For the record, due to the amount of abuse that they're utilised for, it is > very common for VPN providers and services like Tor to be blocked from > registering. > > With regards to the conduct of this person, it is not the first time i've > seen conduct like this (have seen far worse actually) directed at Sysadmin > or the services we operate (for those wondering) > > Thanks, > Ben Cooksley > KDE Sysadmin Just so that anybody says it: Thanks for keeping this calm and professional. You're -- as always -- doing a great job as our Sysadmin :-) > On Tue, Jan 17, 2023 at 9:36 PM Konstantin Kharlamov > > wrote: > > Indeed, given web sites are usually maintained by system administrators > > and that there's also a "sysadmin" KDE mailing list, I have no idea what > > are you doing here. > > > > With that said, I'm not sure you will get any help at all after the amount > > of insults you've done. I see someone elsewhere in the discussion even > > started to troll you, I don't think that is a good reaction either. > > > > Anyway, in terms of future advice: please apply Hanlon's Razor, it is most > > often correct, i.e. no one attempted to attribute malice to you. People > > make mistakes (like the one with the site), which Hanlon's razor describes > > as well. > > > > Also, vast majority of KDE contributors aren't funded (and I'm sure no one > > by you specifically), so nobody has obligations to you. > > > > Try to understand that and try to be calmer the next time you attempt to > > collaborate with any project, be it KDE or something else. If anything, > > insulting maintainers of a project you're interested in just impacts moral > > resources of its maintainers, hence impacts you specifically as a user of > > that project, as it may make maintainer procrastinate due to stress the > > project just brought thanks to you. > > > > For example, there's one big project I'm not gonna name for translating > > API calls to analogous ones on other systems. It's hard to contribute to > > for an outsider, which I experienced twice, I currently have a patch > > addressing serious usability problem that no amount of pinging makes to > > either merge or at least to review. It's just ignored. That annoys me, but > > do I insult them? Of course no, it is an active project (mostly due to > > paid > > developers) which I'm using, so what good would insulting them do? > > Nothing. > > > > On Mon, 2023-01-16 at 22:36 +0100, be...@tuta.io wrote: > > > > Who could I refer to in the developers' mailing list? Hmm, let me ponder > > this question, it's so complicated... > > > > -- > > I'm using Tutanota - the end-to-end encrypted email service > > > > > > > > 16 янв. 2023 г., 16:24 От nmariu...@gmail.com: > > > > Hello, > > > > When you say "Did you design this thing in such way that a VPN user is > > considered a spammer?" > > who do you think this "you" person or group of persons is? > > > > Thanks. > > > > On Mon, Jan 16, 2023 at 11:13 AM wrote: > > > > I've filled the captcha properly and I'm using a VPN. Did you design this > > thing in such way that a VPN user is considered a spammer? Really? > > > > -- > > I'm using Tutanota - the end-to-end encrypted email service > > > > > > > > 16 янв. 2023 г., 12:03 От bcooks...@kde.org: > > > > On Mon, Jan 16, 2023 at 9:58 PM wrote: > > > > Hello there! > > I've just tried to register on your KDE Identity thing. I did everything > > properly and saw "Client rejected by automatic spammer detection system". > > What is that shit supposed to mean? I'm not a spammer. > > > > > > Hi there, > > > > This usually means that you haven't completed the Google reCAPTCHA on the > > registration page, or there was something wrong with your details. > > > > Can you confirm that you have completed the CAPTCHA? > > > > Cheers, > > Ben
Easy mouse settings changing from right- to left-handed
Hi all! My little son starts to use a computer for school, so I currently share my notebook with him. He's left-handed (and I'm right-handed), so I searched for a convenient way to switch the mouse settings from right-handed to left-handed and vice versa, like with a small systray icon and just one click to do. The only thing I found was "mouseswap-kf5" ( https://www.pling.com/p/998954/ ) which seems to do this exact thing. But it seems to be outdated and unmaintained -- I could not build it. I then looked into the sources and thought it could not be that hard to re- write or update the thing, but after messing a bit with it, I have to admit that I have no idea how to do it properly ;-) I could not even connect to some DBUS signal telling me that any systemsettings setting has been changed (I never worked with this before) ... So: Is there anything comparable we have in "official" KDE? And if not, can anybody point me to docs about how to do it, so that I can try to implement this myself? This would imo be a nice addition to the default mouse system settings, like "show a systray icon to switch between left- and right-handed" or such. I think this would be a nice extra for a lot of people sharing their computer with others. Thanks for all help and all hints :-) Cheers, Tobias
Re: Easy mouse settings changing from right- to left-handed
Am Samstag, 18. Februar 2023, 14:22:07 CET schrieb Konstantin Kharlamov: > Did you consider adding a separate user account, and just logging out/in as > the new user for him to use? So one user would be left-handed, the other > one is right-handed. > > P.S.: I tried running `dbus-monitor` and changing left-handness in > systemsettings5, but don't see any event being sent, so not sure how to > automate such change. Perhaps someone else knows. Hi Konstantin, thanks for the input! Of course one could create a separate account. But as of now, it's not more than opening a web browser and using some educational websites (anton.app and antolin.westermann.de). So when he wakes up my notebook from suspend to disk, he sees my (right- handed) desktop, would have to log out using the right-handed mouse, and would need to login as another user. It's not about a real user account, it's about quickly using the machine for a few minutes. I simply liked the (apparently) simple approach of that "mouseswap" plasmoid, as it seems you would just have to do one click to do the job. Also, I think it would be an alluring challenge to get it to work this way ;-) I think the mouseswap Plasmoid didn't look for a change to that specific option, but for any configuration change via systemsettings, and looked up the specific setting via the kconfig framework afterwards. So I would (possibly) already be happy to figure out how I can detect any config change ...
Re: Easy mouse settings changing from right- to left-handed
Am Samstag, 18. Februar 2023, 14:37:33 CET schrieb Juraj Oravec: > Hello Tobias, > > Have you considered using libinput and undex Xorg xinput tool and some > scripts around (create script and bind to keyboard shortcut, create some > icon...)? > > Example from my machine (mouse can have multiple entries here): > $ xinput list > ⎡ Virtual core pointerid=2[master pointer (3)] > ⎜ ↳ Razer Razer Basilisk V3 id=17 [slave pointer (2)] > > > $ xinput --list-props 17 > Device 'Razer Razer Basilisk V3': > . > libinput Left Handed Enabled (294): 0 > libinput Left Handed Enabled Default (295): 0 > ... > > > Probably: > $ xinput --set-prop 17 "libinput Left Handed Enabled" 1 > > Good luck, > Juraj Hi Juraj, thanks for the input! Using xinput would be another option for sure. Actually, on my desktop, I use the following script to configure my Logitech Trackman for left-handed use, that is on the left side of my keyboard, along with the normal mouse on the right side: lsusb | grep 'Logitech, Inc. Marble Mouse' &>/dev/null || exit 0 xinput set-button-map "Logitech USB Trackball" 3 2 1 4 5 6 7 8 9 xinput set-prop "Logitech USB Trackball" "libinput Accel Speed" 1 xinput set-prop "Logitech USB Trackball" "libinput Scroll Method Enabled" 0 0 1 xinput set-prop "Logitech USB Trackball" "libinput Button Scrolling Button" 9 xinput set-prop "Logitech USB Trackball" "libinput Scrolling Pixel Distance" 50 xinput set-prop "Logitech USB Trackball" "libinput Horizontal Scroll Enabled" 0 which is started automatically on KDE login. I'm just wondering if I could do it like the mouseswap Plasmoid did, see my previous mail ;-)
Re: Easy mouse settings changing from right- to left-handed
Am Samstag, 18. Februar 2023, 14:22:07 CET schrieb Konstantin Kharlamov: > P.S.: I tried running `dbus-monitor` and changing left-handness in > systemsettings5, but don't see any event being sent, so not sure how to > automate such change. Perhaps someone else knows. Hey, wasn't too hard after all ;-) Actually, I solved this not by listening to some DBUS signal, but by simply watching the respective RC file for changes. Here we are. Just FYI I uploaded what I wrote to https://invent.kde.org/tleupold/mousetoggler Does the job, shows if "Left-handed" is activated or not, and toggles this setting with one click. But still, maybe, someone could give me (QML n00b) a hand? When I test the plasmoid with "plasmoidviever -a package" (inside the sources, after compiling the plugin and installing it), it's shown as it should be, everything works ... but when I try to add it to my desktop or the task bar, nothing happens. No plasmoid is added ... no error message, simply nothing. What's wrong? How can I even debug this? Sorry for asking dumb questions, I never worked with QML before ... Thanks again for all help!
Re: Bringing Cantata under the KDE umbrella?
Am Montag, 20. Februar 2023, 23:15:41 CET schrieb Reindl Harald: > Am 20.02.23 um 22:45 schrieb Justin Zobel: > > "Music player" daemon > > Cantata is the client and don't play anything itself > > but what do i expect from someone converting text mails to HTML, post a > one-liner on top of inline-quotes and use reply-all on a > maling-list... Hey, we're quite a mellow crowd here I think. Stay nice, friendly and professional everybody ;-)
Re: Easy mouse settings changing from right- to left-handed
Am Freitag, 24. Februar 2023, 01:33:17 CET schrieb David Hurka: > On Saturday, February 18, 2023 1:09:22 PM CET Tobias Leupold wrote: > > Hi all! > > > > My little son starts to use a computer for school, so I currently share my > > notebook with him. He's left-handed (and I'm right-handed), so I searched > > for a convenient way to switch the mouse settings from right-handed to > > left-handed and vice versa, like with a small systray icon and just one > > click to do. > > Hi, just want to add: > > There is a systray icon for the keyboard that appears automatically when you > configure more than one keyboard layout. > > Now you need the same for the “mouse layout”, right? > That seems perfectly reasonable to me, and I support this wish! :) Hi David and all! I actually managed to get it to work, you can check it out at https://invent.kde.org/tleupold/mousetoggler It's a very simple plasmoid, consisting only of an icon. Either a "left-click" icon if the mouse is configured for right-handed use, or a "right-click" icon if it's left-handed use. When you click on it, either with the left or the right mouse button, the layout is toggled. Also, it watches if the layout is changed via the systemsettings. What actually doesn't work at the moment is that if the systemsettings' mouse settings widget is notified when it's opened and the toggling is done via the plasmoid. I'm not sure if this is possible at all ... maybe one could connect to some DBUS signal that to check if the systemsettings are opened and disable the plasmoid for this time or so. However, the plasmoid can be placed in the window bar and gets the job done. The problems I wrote about (when trying to add it to the desktop or the window bar, nothing happens and I have no idea how to debug it) were -- at least I think so -- caused by some caching that QML/Plasma stuff does: I played around with the "Hello world" plasmoid from the wiki. Worked. I changed the text to "foo bar" -- still got "Hello world" (with an installed instance). After having uninstalled it, having logged out, having deleted ~/.cache/plasma*, loggin in again and installing it again, I got the changed text. I still have no idea how to debug this though, as e.g. plasmaconsole --replace started in a console window didn't show any errors, ~/.xsession-errors was empty, and the syslog as well as X's log also didn't contain anything about this :-( However: Most probably, some non-functional state was cached somewhere, and I could change what I wanted without getting another result. Problem was that, with a C++ library, that one has to be installed (system-wide?! At least, I couldn't get it to work after setting my install prefix to ~/.local) even to test the plasmoid with plasmoidviever. I ended up doing a partial install (only the library) and messing with the plasmoid via plasmoidviever before also installing it. Maybe, someone with a deeper insight of Plasma/QML's internals can clarify this and maybe add some hint to the basic plasmoid howto to prevent such headache?! And if someone knows how to talk to the systemsettings mouse widget if it's opened, let me know ;-) Cheers, Tobias
IRC and Matrix
Hi all! I don't know if there's official documentation or something on this, but at least, I didn't overhear anything specific ... so: Since ever (at least since I'm a KDE dev), we used IRC to communicate. First Freenode, and since those guys went nuts Libera Chat. Then, Matrix came, and there were bridges or such so that somebody using only Matrix would see the IRC stuff and vice versa. Now, since quite some time, I'm quite lonely in "my" IRC channels. No bridging, (almost) no users. But commit messages and Bugs still hit IRC. So: What's the state of IRC in KDE (dev) communication? Is IRC meanwhile officially deprecated? Can I stop messing with Quassel Core and whatnot so that I don't miss a message? Thanks for all info :-) Cheers, Tobias
CI seems to be broken for KGeoTag
Hi all, I just pushed an update to KGeoTag. It was just a change in a PNG file. However, the CI build failed, so I think something is broken? Seems like I missed something that should have been updated or changed? Here's the job: https://invent.kde.org/graphics/kgeotag/-/pipelines/568977 I'm not really fit with this ... would somebody be so kind to tell me what's going on here, or to give me a hint how to fix this? Big thanks in advance! Cheers, Tobias
Re: CI seems to be broken for KGeoTag
Am Freitag, 29. Dezember 2023, 15:37:45 CET schrieb Tobias Leupold: > Hi all, > > I just pushed an update to KGeoTag. It was just a change in a PNG file. > However, the CI build failed, so I think something is broken? Seems like I > missed something that should have been updated or changed? > > Here's the job: https://invent.kde.org/graphics/kgeotag/-/pipelines/568977 > > I'm not really fit with this ... would somebody be so kind to tell me what's > going on here, or to give me a hint how to fix this? > > Big thanks in advance! > > Cheers, Tobias Nevermind, I stole the necessary changes from KPhotoAlbum's repo ;-) Sorry for the noise ...
Flathub and Snap Store entries for KGeoTag
Hi all! As far as I can grasp it, https://apps.kde.org/de/kgeotag/ is automatically generated from KGeoTag's appdata.xml file. However, the site lists both Flathub and the Snapcraft as a possible installation source for KGeoTag, with "KDE" referenced as the publisher on both sites. I never used neither, so I don't know much about this besides those two are approaches to provide distribution independent packages, without relying on the respective package manager. But what this is about: On Flathub, one can read "No changelog provided" and "Proprietary: This app is not developed in the open, so only its developers know how it works. It may be insecure in ways that are hard to detect, and it may change without oversight." Obviously, neither is true ... On Snapcraft, there's a similar "License: unset". How can this be fixed? Is there something I can do about this? By adding something to the invent repo? Or somewhere else? Thanks for all help! Cheers, Tobias
Re: Flathub and Snap Store entries for KGeoTag
Am Mittwoch, 3. Januar 2024, 00:12:06 CET schrieb Carl Schwan: > On Tuesday, January 2, 2024 10:50:07 PM CET Tobias Leupold wrote: > > Hi all! > > > > As far as I can grasp it, https://apps.kde.org/de/kgeotag/ is > > automatically > > generated from KGeoTag's appdata.xml file. However, the site lists both > > Flathub and the Snapcraft as a possible installation source for KGeoTag, > > with "KDE" referenced as the publisher on both sites. I never used > > neither, > > so I don't know much about this besides those two are approaches to > > provide > > distribution independent packages, without relying on the respective > > package manager. > > > > But what this is about: > > > > On Flathub, one can read "No changelog provided" and "Proprietary: This > > app > > is not developed in the open, so only its developers know how it works. It > > may be insecure in ways that are hard to detect, and it may change without > > oversight." > > > > Obviously, neither is true ... > > No changelog provided is true. You don't have any changelog in your > appdata.xml, you can look at how we do this in NeoChat > https://invent.kde.org/network/neochat/-/blob/master/ > org.kde.neochat.appdata.xml?ref_type=heads#L407 > > Generally I recommend to follow the quality guidelines of Flathub > https://docs.flathub.org/docs/for-app-authors/appdata-guidelines/quality-gui > delines/ > > For the proprietary part, I asked in the flatpak matrix channel and this is > probably an issue with appstream-glib used by gnome software and flathub and > that doesn't recognize LicenseRef-KDE-Accepted-GPL in your appdata.xml. > Discover actually has the same issue... > > I'm not sure we need to add the LicenseRef in the appstream file is actually > needed. For the user it's interesting that the project is licensed under > gpl 3 not that it could also potentially be licensed under gpl 4 in the > future. This is an information only needed in your source code, I would say > but INAL ;) > > On Snapcraft, there's a similar "License: unset". > > This is afaik not taken from the appstream file and doesn't affect only > KGeoTag, the way I got this resolved in the past is to ask Jonathan to fix > it ;) > > How can this be fixed? Is there something I can do about this? By adding > > something to the invent repo? Or somewhere else? > > > > Thanks for all help! > > I hope this helps :) > Cheers, > > Carl > > > Cheers, Tobias Thanks for all the information so far :-) I'll see what I can fix ...
Re: Flathub and Snap Store entries for KGeoTag
Am Donnerstag, 4. Januar 2024, 11:08:34 CET schrieb Scarlett Moore: > So looking at https://github.com/snapcore/snapd/blob/master/spdx/licenses.go > > LicenseRef-KDE-Accepted-GPL is not recognized as a valid SPDX licence > in the snap world. > Either change it to GPL3 or I can manually put a license: field in the > snapcraft.yaml > Cheers, > Scarlett Thank you for the follow-up! I meanwhile put "GPL-3.0-only" as the project license into the appdata.xml. I think this is the most appropriate SPD-X license, as -- as far as I can grasp it -- "LicenseRef-KDE-Accepted-GPL" is only KDE's backdoor to later approve (or refuse) a GPLv4 if there should be one in the future. So, effectively, this means that our stuff is licensed as GPL 3 only, isn't it? At least, this is what Johannes did for KPhotoAlbum, and I think he has more insight of all that than me ;-) It would be kind if you would put this into snapcraft.yaml at the correct place. I then also can adapt it for KPA. Thanks in advance! Apart from that, IMO those Snap and Flat guys should include LicenseRef-KDE- Accepted-GPL. It's not that this is some strange vendor-specific commercial license. I mean, we're one of the Big Boys here, aren't we?! ;-) Cheers, Tobias > On Thu, Jan 4, 2024 at 2:47 AM Tobias Leupold wrote: > > Am Mittwoch, 3. Januar 2024, 00:12:06 CET schrieb Carl Schwan: > > > On Tuesday, January 2, 2024 10:50:07 PM CET Tobias Leupold wrote: > > > > Hi all! > > > > > > > > As far as I can grasp it, https://apps.kde.org/de/kgeotag/ is > > > > automatically > > > > generated from KGeoTag's appdata.xml file. However, the site lists > > > > both > > > > Flathub and the Snapcraft as a possible installation source for > > > > KGeoTag, > > > > with "KDE" referenced as the publisher on both sites. I never used > > > > neither, > > > > so I don't know much about this besides those two are approaches to > > > > provide > > > > distribution independent packages, without relying on the respective > > > > package manager. > > > > > > > > But what this is about: > > > > > > > > On Flathub, one can read "No changelog provided" and "Proprietary: > > > > This > > > > app > > > > is not developed in the open, so only its developers know how it > > > > works. It > > > > may be insecure in ways that are hard to detect, and it may change > > > > without > > > > oversight." > > > > > > > > Obviously, neither is true ... > > > > > > No changelog provided is true. You don't have any changelog in your > > > appdata.xml, you can look at how we do this in NeoChat > > > https://invent.kde.org/network/neochat/-/blob/master/ > > > org.kde.neochat.appdata.xml?ref_type=heads#L407 > > > > > > Generally I recommend to follow the quality guidelines of Flathub > > > https://docs.flathub.org/docs/for-app-authors/appdata-guidelines/quality > > > -gui delines/ > > > > > > For the proprietary part, I asked in the flatpak matrix channel and this > > > is > > > probably an issue with appstream-glib used by gnome software and flathub > > > and that doesn't recognize LicenseRef-KDE-Accepted-GPL in your > > > appdata.xml. Discover actually has the same issue... > > > > > > I'm not sure we need to add the LicenseRef in the appstream file is > > > actually needed. For the user it's interesting that the project is > > > licensed under gpl 3 not that it could also potentially be licensed > > > under gpl 4 in the future. This is an information only needed in your > > > source code, I would say but INAL ;) > > > > > > > On Snapcraft, there's a similar "License: unset". > > > > > > This is afaik not taken from the appstream file and doesn't affect only > > > KGeoTag, the way I got this resolved in the past is to ask Jonathan to > > > fix > > > it ;) > > > > > > > How can this be fixed? Is there something I can do about this? By > > > > adding > > > > something to the invent repo? Or somewhere else? > > > > > > > > Thanks for all help! > > > > > > I hope this helps :) > > > Cheers, > > > > > > Carl > > > > > > > Cheers, Tobias > > > > Thanks for all the information so far :-) I'll see what I can fix ...
Re: Should we stop distributing source tarballs?
E-Mail von Albert Vaca Cintora vom Mittwoch, 3. April 2024, 18:34:04 CEST: > Hi KDE folks, > > The recent xz backdoor scandal made me realize how bad and obsolete > distributing tarballs is. The source of truth for our code are the > repositories, and releases can simply be tags on those repos. > > As a big free software community, I think we should lead by example > and get rid of tarballs altogether (as I hope to see in other projects > as well) after the recent events. > > Packagers can git pull. > > If we ever replace git with something else, that something else will > have tags as well. > > What's the advantage of providing tarballs? > > Albert Hi, I'm for sure nobody of importance here, but when you demand stopping releasing tarballs because some compression tool has been compromised you could as well demand to shut down all SSL servers because of the heartbleed bug or whatever. Just speaking of me, I not only release tarballs for KDE software, but also for other projects. There, I do the following more than for KDE: A release tarball is not necessarily one exact tag. Some (re)source files may be altered whilst preparing the release, some other stuff may be compiled from different repos or sources. E.g. for the documentation of one of my other projects, I use a @DATE@ placeholder that is finally replaced by the actual release date by a release script, and translated from RST to HTML for the final release tarball. I often e.g. also use a version.h.in header file and let cmake generate the real version.h when compiling. When releasing, I remove it and replace it by a version.h file containing the very version of this release -- which does not exist in git at all. Just what comes into my mind at once. A release is not always only a git tag. Also, git tags can be moved, deleted, created again and so on. When you do a release tarball, one can create checksums, sign it and so on. And even if the git repo is deleted, the sources are moved to another CVS or whatever at some point in the future: The tarball still exists. Also, one should think a bit more comprehensive here: Why should thousands of users create the same sources package over and over again if you can create it once, compress it and simply deliver it? This would be a waste of resources and energy, cause unneeded server load and so on. So, from my point of view the answer here is: No, we definitely should not stop to distribute source tarballs. Cheers, Tobias
Re: Should we stop distributing source tarballs?
Am 04.04.24 um 13:25 schrieb Harald Sitter: On Thu, Apr 4, 2024 at 12:57 PM Tobias Leupold wrote: Just what comes into my mind at once. A release is not always only a git tag. Doesn't that make your source tarball a derived work from the source in your git tag? Yes, of course! this was the point of what I wrote ...
Re: Should we stop distributing source tarballs?
Am 05.04.24 um 06:25 schrieb Juraj Oravec: On streda 3. apríla 2024 18:34:04 CEST Albert Vaca Cintora wrote: Hi KDE folks, The recent xz backdoor scandal made me realize how bad and obsolete distributing tarballs is. The source of truth for our code are the repositories, and releases can simply be tags on those repos. As a big free software community, I think we should lead by example and get rid of tarballs altogether (as I hope to see in other projects as well) after the recent events. Packagers can git pull. If we ever replace git with something else, that something else will have tags as well. What's the advantage of providing tarballs? Albert Hello Albert, The release tarballs can be signed with GPG (or is it PGP?) which provide another layer of protection to make sure the release is authenthic. If KDE wants to lead by example and use only git tags for releases, at least the tags should be signed with GPG for verification. It would be best to have all commits in the repository signed (in Gitlab "Verified"). While we are unable to make sure that the historical commits are also signed, since most of them are not, at least new commits and tags should be signed. Maybe the commits can be signed retrospectively (while breaking the repository history), but this is probablôy just my dream. If all commits in the xz repo would have been signed, the backdoor would have been sneaked in as well -- only that the commit would have been signed. Also if the tags would have been signed, the releases with the backdoor would have been published exactly as is -- only difference: The respective tags would have been signed. Just sayin ... With modern approach for "reproducible" builds in the Linux distributions, it is required to provide a way to make sure that the release is authentic, the tarballs allows that, but with current use of git tags we do not even provide a way to make sure the tag was made by trusted developer or a release team, iinstead the tag could be faked by anyone providing another way of entry. Have a nice day. Juraj
Re: Should we stop distributing source tarballs?
Am Samstag, 6. April 2024, 18:22:22 CEST schrieb Sven Brauch: > Hi, > > On 06.04.24 13:07, Marc Deop i Argemí wrote: > > > If you automate things, everything can be reviewed/validated by more than > > one > > entity and thus increasing security. > > > > The CI can be reviewed and audited but your personal laptop and your > > workflow > > cannot. > > > This is basically a discussion about whether it is less risky to trust > the individual developers, or the people with access to the CI signing > key. You are trading likeliness of there being one bad actor vs. impact > one bad actor can have. It's a matter of personal opinion; there is no > right or wrong choice here. > > Whenever one option goes wrong, it will be easy to argue for changing to > the other, until that one goes wrong, at which point you can change back. > ;) > IMO the only actual improvement here would be reproducible tarballing: > if each run of the packaging script produces the same result on all > systems, the maintainers can locally build the tarball, sign the hash, > upload the signature, then have the CI system build the same tarball and > sign it again. Then KDE publishes both signatures and downstreams check > them both. > > I don't know how hard that would be to achieve technically, several > obstacles come to mind immediately. But it would actually increase trust > instead of just moving it around. > > Greetings, > Sven Hi Sven and all, you're totally right about the fact that you can trust an individual dev packaging a release on a local machine as much or as less as somebody running the infrastructure on the other side. I personally am all with Carl: I also would like to continue creating release tarballs on my local machine. None of all those technical dodges, may they be crafty as can be, would have prevented the backdoor which was the initial ignition of this whole discussion. Don't get me wrong. I'm all for signing release tarballs. If you want, we can also create signed tags if you think we need them. I also see that it's meaningful that such a release tarball contains the exact code of a tag. But we currently create checksums and PGP signatures for release tarballs, all created by a script. Which already makes the whole process completely reproducible. The tarball is the very code you get if you check out the tag. A distributor could check out the tag and compare the tarball with the resulting code. I only want to say we should ponder which real benefit any change will actually bring. Please don't make contributing to KDE harder than it has to be. Cheers, Tobias
CI fails for KGeoTag
Hi all :-) Currently, CI fails for KGeoTag on the systems that are added automatically (not on the ones added manually), cf. https://invent.kde.org/graphics/kgeotag/-/jobs/1842186 https://invent.kde.org/graphics/kgeotag/-/jobs/1842188 It's something about a missing dependency: raise Exception(f"Package {identifier} was not found in branch {branch}") ... raise Exception("Unable to locate requested dependency in the registry: {} (branch: {})".format( identifier, branch )) ... Exception: Package marble was not found in branch release/23.08 I didn't change anything in the CI config. Apparently, I missed some change, didn't update a config file or such? Could somebody give me a hand about this? Thanks a lot in advance! Cheers, Tobias
KGeoTag's main window position is not restored
Hi all! I'm a bit lost with this one. Maybe someone with more insight in KXmlGuiWindow could give me a hand about this? Most probably, this is PEBCAK ;-) Currently, KgeoTag's main window position is not restored when closing it and opening it again. The dock arrangement is restored, and also the window size -- but the window always appears always in the middle of the screen. Initially, I used a QMainWindow and stored the windowState() manually, to restore it in the main window's ctor. Later on, I ported the main window to KXmlGui, keeping the manual restore. I now noticed that KMainWindow also stores the window state on closing, although I never called setAutoSaveSettings(), along with some position parameters that are stored differently from what QWidget::saveGeometry() would yield. I now created the "xmlgui" branch, where the duplicate saving of the window state is removed, and setAutoSaveSettings() is called. However, neither with the master branch (without setAutoSaveSettings()), nor with the xmlgui branch (with setAutoSaveSettings(), most probably more the way this is intended to be used), the window's position is restored -- the window always appears in the middle of the screen. At this point, I'm completely out of ideas why this doesn't work and how I can fix it. has anybody an idea?! Thanks a lot for all hints! Cheers, Tobias
Re: KGeoTag's main window position is not restored
E-Mail vom Sonntag, 26. Mai 2024, 18:14:12 CEST: > It is not possible anymore in Wayland because window coordinates cannot be > set. I know (from the KMainWindow sources), but I don't use Wayland. Also, e.g. for KPhotoAlbum (which apparently does exactly same), the position is restored as exptected ...
I'm blocked from editing the KDE Community Wiki
Hi all, and possibly Sysadmin! I just tried to to edit KGeoTag's Community Wiki page at https://community.kde.org/KGeoTag I wanted to add some more info about dependencies you need to build it, i.e. I wanted to change cmake build-essential extra-cmake-modules qtbase5-dev libkf5coreaddons-dev libkf5i18n-dev libkf5xmlgui-dev libkf5crash-dev libkf5doctools-dev libkf5kexiv2-dev libmarble-dev to {{Input|1= git cmake build-essential gettext extra-cmake-modules qtbase5-dev libkf5coreaddons-dev libkf5i18n-dev libkf5xmlgui-dev libkf5crash-dev libkf5doctools-dev libkf5kexiv2-dev libmarble-dev }} I logged in using my Identity user name and the 2FA password. But the Wiki won't let me save the change: Sorry, you have been blocked You are unable to access kde.org The site tells me I should contact the site owner (maybe Sysadmin in this case?!) and tell the "Cloudflare Ray ID", which was 88a47f9ed8b0b398. What's wrong here?! I tried with Firefox and Chrome, using my normal wired internet connection (not TOR or whatever), with the same result. Thanks a lot for fixing this -- I think the project maintainer should be allowed to edit the project's wiki ;-) Cheers, Tobias
Re: I'm blocked from editing the KDE Community Wiki
Hi Ben, E-Mail von Ben Cooksley vom Montag, 27. Mai 2024, 11:19:59 CEST: > On Mon, May 27, 2024 at 8:26 PM Tobias Leupold wrote: > > Hi all, and possibly Sysadmin! > > Hey Tobias, > > > I just tried to to edit KGeoTag's Community Wiki page at > > https://community.kde.org/KGeoTag > > > > I wanted to add some more info about dependencies you need to build it, > > i.e. I > > wanted to change > > > > cmake build-essential extra-cmake-modules qtbase5-dev libkf5coreaddons-dev > > libkf5i18n-dev libkf5xmlgui-dev libkf5crash-dev libkf5doctools-dev > > libkf5kexiv2-dev libmarble-dev > > > > to > > > > {{Input|1= > > git cmake build-essential gettext extra-cmake-modules qtbase5-dev > > libkf5coreaddons-dev libkf5i18n-dev libkf5xmlgui-dev libkf5crash-dev > > libkf5doctools-dev libkf5kexiv2-dev libmarble-dev > > }} > > > > I logged in using my Identity user name and the 2FA password. But the Wiki > > > > won't let me save the change: > > Sorry, you have been blocked > > You are unable to access kde.org > > > > The site tells me I should contact the site owner (maybe Sysadmin in this > > case?!) and tell the "Cloudflare Ray ID", which was 88a47f9ed8b0b398. > > > > What's wrong here?! I tried with Firefox and Chrome, using my normal wired > > internet connection (not TOR or whatever), with the same result. > > > > Thanks a lot for fixing this -- I think the project maintainer should be > > allowed to edit the project's wiki ;-) > > This is most certainly something that only Sysadmin can fix. Thankfully it > is relatively easy as you've provided the Cloudflare Ray ID. > > This appears to have been a false positive, with you managing to trip the > Command Injection - Common Attack Commands rule that Cloudflare provides as > part of their WAF. > Not the first time, alas - unfortunately the rules do tend to not handle > developer oriented content terribly well. > > I've now disabled that particular rule, so you should be able to submit > your changes. Thanks a lot for the immediate fix! It now worked :-) Cheers, Tobias > > Cheers, Tobias > > Cheers, > Ben
Re: KGeoTag's main window position is not restored
Hi all again, just fyi: I found it. It was indeed PEBCAK ;-) I use an override closeEvent() function. At the end of this function, I called QApplication::quit(). This bypassed the needed functionality. Passing the close event through to KXmlGuiWindow::closeEvent() fixed the position not being restored. What still is a bit odd is that the window state was saved and restored correctly nevertheless. But whatever. It works now. Sorry for the noise, Tobias
Re: Guidelins for one codebase that builds with Qt5 and Qt6?
E-Mail von Halla Rempt vom Montag, 5. August 2024, 16:15:19 MESZ: > Hi, > > We're finally working on porting Krita to Qt6, but that's going to be a long > road. I seem to remember that there were KDE apps that could be built with > both Qt6/Kf6 and Qt5/Kf5. Did I remember that right? And if so, is there > some howto or documentation for that? > > Thanks, > > Halla Hi, for https://invent.kde.org/tleupold/scandoc , I just set a "QT6" cmake switch (on/off) to decide if a Qt 5 or a Qt 6 build should be done. Just look at the CMakeFiles.txt, it's quite easy this way (I also do this exactly like that for https://muckturnier.org/ ; that's Qt-only, no KF, but after all, it's the same approach). I think this depends on how much effort it would be to support both versions. For Scandoc, it wasn't much, so I decided to support Qt/KF 5 and 6 for now. That's also what I think I'll do for KGeoTag, once Marble will be ported to Qt 6. If it's a lot of work and/or manpower is limited (it's always, isn't it?!) it may be better to do a Qt-6-only port. That's what we're just doing for KPhotoAlbum. I don't think there's some official guideline about this, no? Cheers, Tobias
What's the plan for Marble's Qt 6 port?
Hi all and esp. hi Marble devs :-) I just wanted to ask: What's the plan for Marble's Qt 6 port? There's a "marble-qt6" branch, but the last commit there dates back to 11/2023 ... I don't want to nag or bug you! I'm only asking because we at KPhotoAlbum and at KGeoTag (which are somehow sister projects, all about photo management) use Marble's MarbleWidget. KPhotoAlbum is just being ported to Qt 6, with Marble support left out by now, but I can't port KGeoTag before Marble's Qt 6 port is ready. That's because the MarbleWidget provides the program's core functionality, and it would be quite useless without. Artix Linux (the one distribution I use) made Plasma 6 the default quite some weeks ago already, and Gentoo (the other one I use) made it the default as of today. More and more distributions will follow, so the Qt 5 air is getting thinner ... Thanks for all infos and of course big thanks for working on this fine piece of software that makes stuff like KGeoTag possible at all in the first place :-) Cheers, Tobias