ognarb

Use the Reuse specification and tooling instead: https://reuse.software/

There is no need to reinvent a solved problem by rewritting it in rust with a different format, particularly considering that reuse was developed by the FSFE in collaboration with some lawyers.

That's really cool. I am always impressed about that people are able to do with Krita, this makes me happy as a KDE developer even though I am not really involved with Krita.

Already discussed less than a day ago: https://news.ycombinator.com/item?id=42803559

There are quite a few stock images on that website...

Since planet.kde.org is mentioned, it's super easy to create something similar with a bit of python and a static site generator like Hugo :)

https://invent.kde.org/websites/planet-kde-org/-/blob/master...

I managed to pass the catcha on my on my second attempt \o/

From their FAQ:

> I’m blind/I have problems with my visions and I can’t navigate your captcha.

> Please contact us.

https://events.ccc.de/congress/2023/infos/tickets.html#faq

Blast of the past

I much prefer Symfony, but that's mainly because it's the framework I started with.

I love hugo, it's a bit complex to get started with but extremely powerful. And the backward compatibility is very good, I started using that 4 years ago and aside of a handful of small issues which could be resolved in 5 min, my websites could be upgraded without any issue. This wasn't my experience with Jekyll.

I did use gdb recently on Windows, but this was for a cross compiled program using mingw. Not sure it works for programs made with MSVC.

Proton does a lot of open source washing. Their public communication often mention that they are open source, while in reality only some of their clients are open source and the uploaded source code[1] often lags behind by months (currently 3 months).

[1]: https://github.com/ProtonMail/WebClients

This is not open source, just take a look at the license.

https://github.com/Dokploy/dokploy/blob/main/LICENSE.MD

For text to speech.

Disclaimer: I work on GPG and I am one of the KMail core developer.

The standard way to use GPG is via the gpgme librairie which then communicate with the Assuan protocol to the gpg deamon. Gpgme has official bindings to C++, Qt and python. In KMail we use the Qt bindings and it works fine.

I long argued that we should use markdown (without the inline HTML) or a similar simple text markup instead of HTML for rich text in emails. This would makes it easy for emails clients to decide about either showing the text as rich text or just plain text, while supporting most of the formatting that a normal user might need: bold, italic, quotes, inline images, code blocks, headers, ...

Sure it wouldn't be good for marketing emails with the super advanced HTML but I don't think anyone should care about this use-case.

What are you using qmetaobject-rs or cxx-qt?

QML is not just a markup language, it supports js, data bindings and various other structures.

It's like saying why people had to invent JSX in their react app when they could use JSON.

Yes and if you want more screenshots I put some on my blog about this change https://carlschwan.eu/2023/08/29/frameless-view-with-qtwidge...

And there is also some before and after comparison on the announcement https://kde.org/announcements/megarelease/6/

There is effort to multiple concurrent efforts to update the breeze style:

Mine is here which is still quite WIP https://carlschwan.eu/2023/12/19/announcing-brise-theme/

And there is another one for icons https://anditosan.wordpress.com/2023/12/30/breeze-icons-upda...

The prefered input methods for Plasma is Fcitx5 but the situation is not perfect yet. But with Wayland, this opens a few new possibilities: http://blog.davidedmundson.co.uk/blog/new-ideas-using-waylan...

Qt6 now support the wayland fractional scaling protocol which should improve the situation quite a bit for applications ported to Qt6.

KDE developer here. Probably for a few more years but there is no timeline yet, but then we do we will definitively announce it some times before (e.g. a year) and are likely to make the release before that an LTS version.

The author or Slint worked on Qt and is one of the designer of the QMetaObject system and QML.

Just did an implementation of this in C++ with Qt Scene Graph as a learning experience in case someone is interested https://invent.kde.org/carlschwan/warpong/-/blob/master/src/...

Also a KDE dev here and I also love when people port KDE Software to more platforms.

Related someone is porting KDE applications to Haiku https://discuss.kde.org/t/haiku-porting-efforts/9032 and someone else is working on gitlab CI/CD directly to the Microsoft Store https://blogs.kde.org/2023/12/20/gitlab-microsoft-store

And the repo you pointed out is from a former colleague ;) the world is small

This is wrong. Accessibility software uses the at-spi protocol and this work with kde, gnome and in both x11 and wayland.

There are some minor issues with Wayland but most of it works.

I don't know what talon is doing as it seems proprietary, but the issue might be there.

I'm curious, why are you using this instead of the official Python bindings?

Not OP, but QML is not a great language to put more logic than simple bindings and functions like

    Button {
        text: "Save"
        enabled: textField.text.length > 0 // this is reactive to the value of a TextField
        onClicked: Backend.save()
    }

as soon as you try to for example implement the save method in JS/QML this starts to become very painful as it often ends up with a lot of spaghetti code. The very cool thing with QML is that the save function can be simply implemented in C++ like this.

    Backend::save()
    {
        // call QFile/QNetworkRequest/...
    }

It force the programmer to split their logic from the UI layer which I don't consider a bad thing.