In T10034#206961, @fbg13 wrote:

In T10034#206954, @thiagosueto wrote:

Subtitle editors are also lacking on linux, Aegisub is the only full-featured one I'd say, but it's deprecated.

There's SubtitleComposer
https://github.com/maxrd2/SubtitleComposer/issues/74

https://github.com/maxrd2/SubtitleComposer/issues/74 Interesting ;)

I see that the Subtitle Composer dev was very willing to become part of KDE! That's great! That would be @maxrd2 I believe, congrats :D

I e-mailed the kid3 maintainer but no reply yet
https://sourceforge.net/projects/kid3/

It looks like we should start a table in the task description to track where each project is at and maybe also who the contacts (on the project's side and on our side) are.

Another tag editor using qt github.com/Martchus/tageditor

Please add your own projects and progress to the table

Is there an equivalent to kdesvn, but for git? This would be very helpful after migrating to Gitlab.
Even more useful if it includes Dolphin integration, like kdesvn does.
kdesvn helps translators a lot for updating the translation repository and sending commits.

qgit, https://github.com/tibirna/qgit, (Tibirna is an old-time KDE contributor).

In T10034#209403, @adridg wrote:

qgit, https://github.com/tibirna/qgit, (Tibirna is an old-time KDE contributor).

Last time I asked Tibirna about moving qgit under kde.org (two years ago, uh, time flies), he said that we wanted to add some desktop integration first. You may want to try again.

GoldenCheetah, https://github.com/GoldenCheetah/GoldenCheetah ("Performance Software for Cyclists, Runners and Triathletes").
Stellarium, https://github.com/Stellarium/stellarium However, competes with KStars probably.

@Zren could maybe profit from having some of his projects hosted on KDE as well?
Event Calendar for instance has Google Calendar integration and if I recall correctly it is also integrated with KDE PIM.
We already have some widgets hosted like Eike's Simplemenu and Psifidotos' Latte Dock, for instance.

Please put your suggestions in the list in the task description.

At some point we should maybe start working through the list, maybe ordering the items. One criteria could be "easiness" (taking into account whether we already have contacts within the project, whether the technology they use is similar to that used by KDE, etc.). Another could be, from Promo's point of view, visibility: for KDE, it would be much more of a coup to incorporate, say, Scribus, than another much more obscure and less developed application. Yet another could be "usefulness for KDE", as in, it fills a niche we don't yet cover with one of our on projects, say some helpful framework or application that would make developers' or translator's work easier.

Like that we can systematically go through them and decide which project to cover first.

Shall we do that?

To summarize the current situation, the following are mentioned in the comments but not included in the table (checked this briefly, will repair it later if it's wrong and can't update the table rn):
BasKet Clementine CrossLine KtikZ KiCad medinria Qtemu tuxclocker Calamares Filmulator-GUI HDRMerge LuminanceHDR LMMS Rosegarden Pulse Effects KeepassXC Spectral OBS Studio QtPass QGIS OpenToonZ Mixxx ScreenTranslator asteroidOS SpeedCrunch kdbg Kup ScanTailor Sigil ZombieTrackerGPS ContainerManager kid3 tageditor qgit GoldenCheetah Stellarium Event Calendar
(Edited to make comment smaller)

I'd like to also suggest the Qt VoIP project Mumble (https://github.com/mumble-voip/mumble, https://www.mumble.info/). It would be interesting to have it in the portfolio. It uses a BSD license, though.

Added some placeholders so it should be easier to add new projects to the table.

Let's put a temporary brake on adding new projects for now and try and move this on to the phase in which we talk strategies we are going to use to convince the projects to join us.

Doubt: Some projects accept donations, how would becoming part of KDE affect this?

@afarid Some KDE projects (Krita, GCompris, ...) are also asking for donation, so I don't think this is a problem.

In T10034#188965, @crozbo wrote:

I start using matrix, and i use Riot client. In may 5min research Riot is currently most completed, but it is electron app. Do KDE have any matrix client app? There some some numbers of Qt based clients, so if kde dont have matrix client app, maybe is time to incubate some.

Excluding Riot, Nheko is probably the most complete Matrix client. I think it would be good to add it to the list.

https://github.com/Nheko-Reborn/nheko

What about ONVIFViewer? :)

ONVIF camera viewer for Android, Plasma Mobile and Linux desktop

The goal of this project is to replace the proprietary app that was needed to configure and view my IP camera. The ONVIF protocol can be used to view and configure many types of camera's and is a open standard that can be implemented using standard SOAP libraries. Using Qt5 for the back-end and Kirigami UI framework makes this application a cross-platform solution. The primary focus is Plasma mobile and the Linux desktop, but an Android build is also available.

@caspermeijn

Two duplicates were removed.

In T10034#178564, @kamathraghavendra wrote:

+1 for Scribus. Scribus and Krita are a fantastic combination for artists and professionals working in print.

Yes! For example, the historical move of Janayugom newspaper migrating into a completely libre software based workflow.

Hello, I'm an admin and dev for FreeCAD, a cross-platform 3D CAD software that uses Qt as an application framework. I'm interested in closer ties to the KDE project in the long term since the adoption of KDE Frameworks into FreeCAD could help prevent reinventing the wheel and boost code quality. However one of the main difficulties with FreeCAD is that it already has a pretty huge amount of dependencies that are quite difficult to maintain across multiple Linux distros, Windows, and Mac, so adding anything to the dependency list would be a difficult proposition and something probably best done in small steps.

P.S. As an aside, after positive experiences using kdesrc-build to get my feet wet with KDE development, it seems like it could be a very useful tool for managing FreeCAD's development dependencies too. Something I'll have to add to the list...

Hi @kkremitzki, it's good to see FreeCad interested! What do you have in mind?

Have you considered incubating or something along the lines?
https://community.kde.org/Incubator

In T10034#229076, @kkremitzki wrote:

Hello, I'm an admin and dev for FreeCAD, a cross-platform 3D CAD software that uses Qt as an application framework.

I'm sure the everybody is familiar with FreeCAD already. Excellent piece of software, @kkremitzki. I am very impressed with the stability and features of the latest versions.

Considering we already have a 3D printing project, FreeCAD will fit in very well. I hope that you find that KDE provides a fertile environment for the future development of FreeCAD.

I should first mention this interest is basically unilateral--since we already have so many dependencies, starting a discussion about adding them tends to be less productive than making something and demonstrating the value.

As far as Incubator, it's probably too early for that yet, as we are currently considering joining the Software Freedom Conservancy and other people would probably want to continue maintaining our own infrastructure.

I can explain what I had in mind a bit more. One of FreeCAD's main limitations is poor UX and a dated, early-2000's UI. Part of the reason for this is that FreeCAD is going on 18 years old now, so there's a large "accretion" aspect to it, compounded by the fact that we use a modular workbench-based approach that depends on the workbench author for consistency, but since workbenches can be C++, Python, or a mix of both, that's difficult.

In the early 2010's there was an effort to begin overhauling this aspect of FreeCAD by migrating from Qt Widgets to QML. The proof-of-concept was beautiful and well-received, but the author didn't continue it and that branch has basically bitrotted due to almost 20,000 commits since then.

To cut to the chase, it seems like a technological leapfrogging would be possible by making a proof-of-concept Kirigami-based FreeCAD UI, and once it's been shown to be possible, the rest should follow. I think the "sell" to our community of leaning on KDE for UI/UX expertise and letting CAD programmers work on CAD instead should be pretty easy and outweigh possible packaging pain.

Unfortunately though we are short on empty-handed developers, and the FreeCAD viewport involves some messiness involving a custom Qt Widget called Quarter which hooks into our scenegraph library Coin3D, and VTK... so it could be a fairly involved effort. Thus, it might be some time before this can move from a nebulous idea to something more.

In T10034#229083, @kkremitzki wrote:

To cut to the chase, it seems like a technological leapfrogging would be possible by making a proof-of-concept Kirigami-based FreeCAD UI, and once it's been shown to be possible, the rest should follow. I think the "sell" to our community of leaning on KDE for UI/UX expertise and letting CAD programmers work on CAD instead should be pretty easy and outweigh possible packaging pain.

Hello, Kirigami maintainer here.
I'm a big fan of FreeCAD! I started wetting my toes into CAD about a year ago after getting a 3d printer and a tiny desktop-CNC and while i'm still at a somewhat noob level, I found FreeCAD a very impressive, functional and powerful piece of software :)
I feel honored that you are considering Kirigami for rewriting parts of the application UI, tough I know how hugely complex that is, and how much QtQuick is still subpar for many desktop-specific things unfortunately.
I would probably suggest a more gradual approach, so rather that starting to directly to porting everything to a single QQuickView (for which i guess porting that Quarter widget to it would be fairly a mayor undertake?) would be starting from smaller things, like that "tasks" views (which i found so far the least pleasant UI within FreeCad)
The use of QQuickWidget has its drawbacks and big headaches too, but it may be useful to start gradually to port single pieces of the "chrome" UI gradually expanding without having a big rewrite that can take potentially years to go reach feature parity with the prior qwidgets version

In T10034#229198, @mart wrote:

I feel honored that you are considering Kirigami for rewriting parts of the application UI, tough I know how hugely complex that is, and how much QtQuick is still subpar for many desktop-specific things unfortunately.

May I add a question here, a bit offtopic? It appeared to me that there is a general trend towards QtQuick because a) it looks great and b) tends to be touch and mobile friendly. While I disagree with a, I wonder whether an inherently complex UI like that of FreeCad would benefit from b. KXmlGui is great for customizing the toolbars and QDockWidgets are nice to rearrange the UI components on the screen. While I have nothing to say about the technical implemenation, would/could these features (which FreeCAD already has) be kept with QtQuick?

In T10034#229260, @davidhurka wrote:

May I add a question here, a bit offtopic? It appeared to me that there is a general trend towards QtQuick because a) it looks great and b) tends to be touch and mobile friendly. While I disagree with a, I wonder whether an inherently complex UI like that of FreeCad would benefit from b. KXmlGui is great for customizing the toolbars and QDockWidgets are nice to rearrange the UI components on the screen. While I have nothing to say about the technical implemenation, would/could these features (which FreeCAD already has) be kept with QtQuick?

yeah, freecad is one of those very complex cases where going all qml yet wouldn't probably be great, as i said, tough it seems indeed a technical conversation to be had elsewhere :)

Hello! I'm new to suggestions and contribution, sorry for any mistakes or misunderstandings.

• I fixed the formatting of the table and links to match ReMarkup style. At first I wanted to convert the main table to HTML but it would become too big with empty cells, better just use a single line. Aslo added Incubator link, since I only found it after reading comments. Might be useful for others.
• I contacted StuntRally developer, they replied with a positive answer but I already made a mistake by attracting a project that hasn't been updated in a while. Should've asked about it being maintained first. So, marked as "Canceled" (by me, as a requester). Going to settle this myself (but also thanks to Promo team for proofreading). Learning through mistakes!
• I know two projects (Zrythm and Radium) which are focusing on music creation, both are well-made DAWs, both are being actively maintained. One is fresh and still an alpha, another one is old but extremely functional, bugs are still being fixed and new features are being added (I even made a simple theme for it). But they both use a "paid binaries" strategy. Is it possible to do something with those projects or should we avoid them?

Manuskipt seems to be a nifty tool for writers written in Python3 and PyQt5.

Website: http://www.theologeek.ch/manuskript/

Twitter contact: @olkesh

Bonus: already has a k in the name.

Calamares is officially sponsored by BlueSystems. Both Theo and the current dev gets paid by our official sponsor and they are working together tightly with the KDEPartitionmanager: That one even splits its project into half, in order for Calamares to use and contribute to the backend more efficient. At which point counts a project as 'incorporated'?

I've updated the table with myself as contact for Calamares on both sides. @teo is also still around. I've filled in "no" for now. I think I've written this before, but there's these issues:

• (political) Calamares is a distro- and desktop-independent installer. *Not* being a KDE project has value there, although as KDE grows more umbrella-ish the political side is reduced: also with Calamares established now as an independent installer there's less "oh, that's KDE, can't use it for my xfce distro". So .. not much of an issue anymore.
• (administrative) It has its own domain (calamares.io) which is owned by Blue Systems; if I understand the manifesto correctly this would have to be transferred to sysadmin: that is only partly my (the maintainer) decision to make. Besides which I gather sysadmin isn't really jumping at the opportunity to host lots of domains. On the other hand, it's a simple GitHub pages (i.e. Jekyll) site, so it's easy enough to host. So .. a bit of an issue, for administrative reasons.
• (technical) GitHub was, for a while, much nicer than the git hosting provided by KDE. Now with GitLab, I'd say that KDE hosting is nicer. But with the ongoing uncertainty about GL issues versus Bugzilla, that's a reason to stick with GH and one stream of issues. So .. needs clarification, might be blocker.
• (technical) Who's going to do the work of creating importers-and-migrators? (Er .. come to think of it, GL has GH importers that work just fine) So .. resolved.
• (i18n) Existing translation workflow is via Transifex, I would either need to keep that translation source or you'd need to convince me that KDE's translation workflow is effective (and supports Esperanto and Interlingue and ..) and can give the kind of turnaround for Calamares's two-week release schedule. So .. needs explanation.

So, all in all: I'm not against it, but there seem to be very limited benefits and some potential disruption in existing workflows. Or, @shalokshalom , do you see specific upsides? (Or maybe you mean "this is already effectively incorporated, it just lives somewhere else")

This all makes sense @adridg and it is good to have such a detailed list of caveats beforehand. The list is a brainstorm after all. Not all will work out.

Yes, I mean this is already effectively incorporated, it just lives somewhere else :D

I found this DAW written with QT 5 and C++ called MusE (no, it's not the same thing as MuseScore): https://muse-sequencer.github.io/

It's published under the GNU General Public License.

Edit: I couldn't find an email to contact them. The only way I saw is publicly through their forum.

I added Haruna Video Player to the list. They already use KDE Frameworks and they're building on top of MPV, which is a solid base. Maui's Clip does the same.

Because it's made with QML it might be suitable for Plasma Mobile in the future as well.

I am the developer of Haruna. I considered making Haruna a KDE project, but decided against.
The biggest reason was that I like to have complete control over the project.
But I changed my mind.

So, if Haruna is something you want in KDE I'm on board.

In T10034#254694, @fbg13 wrote:

I am the developer of Haruna. I considered making Haruna a KDE project, but decided against.
The biggest reason was that I like to have complete control over the project.
But I changed my mind.

So, if Haruna is something you want in KDE I'm on board.

Cool. Give me a ping on Matrix if you want to start off the incubation process https://webchat.kde.org/#/room/#kde-devel:kde.org