lzip vs. xz

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

> 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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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á ?

[Tobias Leupold]

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á ?

[Tobias Leupold]

> 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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

> 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

[Tobias Leupold]

> 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

[Tobias Leupold]

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"

[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

Re: Trigger loading a list of files from Dolphin using "open with"

[Tobias Leupold]

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"

[Tobias Leupold]

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

[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

Re: Help with tarme.rb

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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?

[Tobias Leupold]

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?

[Tobias Leupold]

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?

[Tobias Leupold]

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?

[Tobias Leupold]

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?

[Tobias Leupold]

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

[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

Re: Question about KWrite's new tab behavior

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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?

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[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

Re: CI seems to be broken for KGeoTag

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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?

[Tobias Leupold]

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?

[Tobias Leupold]

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?

[Tobias Leupold]

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?

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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

[Tobias Leupold]

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?

[Tobias Leupold]

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?

[Tobias Leupold]

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