Attract existing FLOSS software projects to KDE and incorporate their members into our community
Open, NormalPublic

Description

We would want to increase the number of projects working within KDE. This task aims to lay out which existing projects we should approach to try and convince them to join our community. This would help us increase our portfolio and app catalogue, making our platform more attractive to users (= a larger catalogue of apps to install and use) and contributors (= a larger variety of projects to chose to work on). The community would grow with members of already active projects, thus increasing our reach with every project added. One would expect it would make KDE more attractive to a wider variety of sponsors.

The projects that joined us would be able to increase number of contributors (developers, artists, translators) working on their product, increasing the bus factor. They would be able to take advantage of KDE's infrastructure and services (like Promo), while at the same time increasing the probability of obtaining sponsorship and funding. Finally they would be working with like-minded colleagues.

We will approach the main developers of the project, preferably through a common acquaintance, and pitch our offer. To ensure we can accommodate the project, we will work with the onboarding project (T7116) members so we are ready to accept mature projects into the fold.

Wishlist:

@paulb 's personal wishlist:

Avoid

Projects that overlap in functionality and/or aim of working projects already within the KDE community.

TODO

Add you ideas, comments or suggestions for projects to contact (and preferably a way to contact them) in the comments below.

There are a very large number of changes, so older changes are hidden. Show Older Changes
In T10034#168055, @apol wrote:

This process is called incubation, you can see how it works here: https://community.kde.org/Incubator

But how do you approach a project? Is it someone from the board, form promo, any one? Is there a procedure for this?

afarid added a comment.EditedNov 22 2018, 7:14 PM

Another project which is interesting is FreeCad. It is still Qt4 but if the community can help porting it to Qt5 that can be a bonus to make it join KDE.

Lutris? I don't think this will ever gonna happen. It is a gtk+ application and their next major release (0.5.0) is going to use GtkHeaderBar 🙄

Oh, that is a shame. It would've been SO COOL to have Lutris.

My wishlist:

Clementine is my player of choice but there are too many audio players already imho.

In T10034#168055, @apol wrote:

This process is called incubation, you can see how it works here: https://community.kde.org/Incubator

But how do you approach a project? Is it someone from the board, form promo, any one? Is there a procedure for this?

Anyone can start the process. No special procedure: get in contact, show them the benefits and the process itself, as described on those pages.

Another project which is interesting is FreeCad. It is still Qt4 but if the community can help porting it to Qt5 that can be a bonus to make it join KDE.

FreeCad is already moving to Qt5; Debian for example enabled the Qt5 build.

paulb added a comment.Nov 22 2018, 7:56 PM

Clementine is my player of choice

I like it too.

but there are too many audio players already imho.

Yes, it would conflict at least with VVAVE and Elisa. That puts it in the "not a priority" box.

FreeCad is already moving to Qt5; Debian for example enabled the Qt5 build.

Now that is interesting.

paulb added a comment.Nov 25 2018, 6:29 PM

I'm going to tentatively add Natron to the list. According to this article, the two remaining developers have a lot of trouble in advancing the project. The program uses C++ and Qt, albeit older version of both, but they want to push conversion to more modern versions, which would mean converting to Qt5. To me it looks like a prime candidate for being "rescued".

paulb updated the task description. (Show Details)Nov 25 2018, 6:29 PM
richardbowen added a subscriber: richardbowen.EditedNov 25 2018, 8:56 PM

I think that's a good idea, pulling in projects that would benefit from the help of the KDE community. I came across one as well: https://github.com/rochus-keller/CrossLine. No idea if the developer want's assistance but the project is based on Qt4. Maybe he would be interested in porting to Qt5.

I think that's a good idea, pulling in projects that would benefit from the help of the KDE community. I came across one as well: https://github.com/rochus-keller/CrossLine. No idea if the developer want's assistance but the project is based on Qt4. Maybe he would be interested in porting to Qt5.

+1

That is an interesting looking project indeed.

An other small project, that I would love to add to the list: KtikZ. This project already use some KF5 libraries and is still often updated.

From a user point of view, KiCad could benefit from a KDE user interface. It’s a well known and probably great EDA tool, but every time I try to get started, the bad UI stops me. (But that’s common for almost all EDA tools I know.) (Yes, it’s UI could also be great with wxWidgets, which it uses currently.)

From other points of view, KiCad developers luckily continue improving KiCad, but they don’t seem to have problems with the UI.

Thanks for the suggestions, @davidhurka and @ognarb. These are both look very interesting and we will include them into the list of projects to approach.

rooty added a subscriber: rooty.Jan 17 2019, 10:28 PM

Hey if in any way possible: **medInria**
It's an up and coming medical imaging platform.

ixoos added a subscriber: ixoos.Jan 18 2019, 7:44 PM

What about https://gitlab.com/carlavilla/Qtemu/? Gnome has it's "own" Gnome Boxes, Qtemu was ported to qt5 not too long ago, and now the dev, polishes it.

paulb updated the task description. (Show Details)Jan 21 2019, 10:04 AM

I wouldn't worry too much about avoiding projects which overlap with existing KDE projects for aims, there's plenty of those within KDE already. Unrelated technologies are a bigger issue (I'm thinking of Thunderbird as being unsuitable when in the past it was looking for a new home, but it uses very different technologies.)

My reasoning is I wouldn't want to hurt projects that may be long-standing within KDE by bringing in a similar project that may absorb resources they need. In an ideal world, people would try and merge two similar projects with similar aims and underlying technologies, like... I don't know... Kontact and Kube. But that doesn't seem to happen and often all it leads to is a rift. If there are already overlaps which cause discomfort within the KDE community, don't you think drafting projects from outside can create more problems? If we were considering approaching a project and contributors to an existing KDE project had reasonable reservations because the new project may cause a rift with the KDE one, shouldn't the opinion of the KDE contributors prevail?

I honestly don't know the answer to these questions, so any insight will be helpful to me.

lydia added a subscriber: lydia.Jan 22 2019, 6:10 PM

My reasoning is I wouldn't want to hurt projects that may be long-standing within KDE by bringing in a similar project that may absorb resources they need. In an ideal world, people would try and merge two similar projects with similar aims and underlying technologies, like... I don't know... Kontact and Kube. But that doesn't seem to happen and often all it leads to is a rift. If there are already overlaps which cause discomfort within the KDE community, don't you think drafting projects from outside can create more problems? If we were considering approaching a project and contributors to an existing KDE project had reasonable reservations because the new project may cause a rift with the KDE one, shouldn't the opinion of the KDE contributors prevail?

I honestly don't know the answer to these questions, so any insight will be helpful to me.

You are correct. If we spend resources on recruiting new projects let's spend them on areas that we don't already cover of possible.

GB_2 added a comment.Jan 22 2019, 6:12 PM

The Calamares installer also seems like something we could adopt: https://calamares.io

afarid added a comment.EditedJan 22 2019, 11:39 PM

Here is my wishlist as well:

Continuing along the kreative suite line here are 3 more:

In T10034#174271, @GB_2 wrote:

The Calamares installer also seems like something we could adopt: https://calamares.io

There seems to be already KDE people involved so it seems interesting [[ https://calamares.io/team/ | [1] ]][[ https://calamares.io/about/ | [2] ]]. Although it makes me wonder why they haven't pushed for such a thing? Maybe a reason can be to stay "neutral"?

adridg added a subscriber: adridg.Jan 24 2019, 10:50 AM

With my Calamares maintainer hat on: the decision to live outside of the KDE umbrella was taken before my time, but is basically this: make sure that the installer is seen as a desktop- and sitro-neutral approach, even when it uses KDE technologies. It's an installer for a whole bunch of distro flavors, although it's also enthusiastically used by a bunch of KDE-showcase distro's. I don't want it tied to only the KDE-showcases though.

So it's not going to move, for the foreseeable future.

That said, here's a little checklist of what I would consider, before moving a project under the KDE umbrella:

  • Website. https://calamares.io/ is served from GitHub pages. Existing workflow is through Markdown pages which I can locally test with Jekyll. Forwarding requests to a KDE-thing serving websites should preserve the domain name. (A transition period, to eventually en up with calamares.kde.org or kde.org/applications/calamares, would be acceptable).
  • Wiki. Needs an application-specific wiki. I suppose community.kde.org/applications/ would house a sub-tree, and while I much prefer the Markdown-based GH approach, I can understand that c.k.o uses MediaWiki.
  • Translations. Existing translation work in Calamares is done through Transifex. So there would need to be capacity in the KDE translation teams to handle the extra workload (507 strings and growing, in 59 languages). There needs to be import from .ts to the form KDE translations use. In the hope of attracting some of the external translators, a web-based translation workflow is probably necessary.
  • CI. Currently uses Travis. This is straightforward to move over to b.k.o, although workflow does depend on email notifications of build failure and IRC-notifications of build results. Calamares is Linux-only, needs to have a way to limit CI builds to that.
  • Bugs. Needs a simple way to report bugs that supports templates and visible screenshots in the text. Most bugs are reported by distro-packagers, so the BR capabilities are pretty good, but it's an important time-saver for me to see screenies in-context. The actual bug workflow isn't all that important to me: there's "open" and there's "closed" and I don't use GH labels all that much -- this is probably because it's a relatively small project.
  • Issues: Calamares doesn't have a forum or mailing list, so communication happens on IRC (for transient synchronous bits) or GH issues (for non-transient, async). This includes brainstorming about new features and discussions about bugs. Needs notifications with content.
  • Pull Requests. Features do come in from downstream. And having some kind of formal review in place is necessary. Wouldn't have to be in a forked repo, necessarily. With the KDE git setup and manifesto saying that everyone can commit everywhere, this would be a social problem to be solved more than anything else.

So from a developer point of view it doesn't really matter to me: I have git, qgit, a shell, and KDevelop and that's it. Moving an existing loosely-knit community (downstream, plus translators) is a different thing.

From a user point of view, KiCad could benefit from a KDE user interface. […]

I just found this roadmap for the next major release: http://docs.kicad-pcb.org/doxygen/v6_road_map.html

Somewhere it really smells like Qt, so using KDE Frameworks could help much:

Give KiCad a more modern user interface with dockable tool bars and windows. Create perspectives to allow users to arrange dockable windows as they prefer.
[…]

  • Take advantage of the advanced UI features in wxAui such as detaching and hiding.

Maybe the VDG can help here:

  • Study ergonomics of various commercial/proprietary PCB applications (when in doubt about any particular UI solution, check how it has been done in a certain proprietary app that is very popular among OSHW folks and do exactly opposite).
  • Clean up menu structure. Menus must allow access to all features of the program in a clear and logical way. Currently some functions of Pcbnew are accessible only through tool bars
  • Redesign dialogs, make sure they are following same style rules.
  • Check quality of translations. Either fix or remove bad quality translations.

Most Qt-y:

  • Develop a global shortcut manager that allows the user assign arbitrary shortcuts for any tool or action.

IMHO they still need configuration dialogs which really configure anything useful. (And sorry for failing at markup.)

Adding a new project for this "Kreative suite"

And annotating Rosegarden (https://rosegardenmusic.com/) so @jriddell and @tcanabrava said in TG promo group that they attempt to attract it to KDE before (and @dfaure is a good contributor for the project.

In other sector, I think that Free software world need a great engineering tools "user friendly" so I give "+1" to attract Freecad project like said @afarid.

filipf added a subscriber: filipf.Feb 18 2019, 8:15 PM

I'd propose PulseEffects (https://github.com/wwmm/pulseeffects)

Why?

  • already a fantastic program
  • one of a kind, the program has no (serious) competitors
  • written in C++
  • only one developer more or less, could use KDE's help with things like design, translation etc. and with being more widely shipped
  • developer is super-friendly

The issue is that the interface is GTK right now, but I still think it's worth exploring this collaboration.

ndavis added a subscriber: ndavis.Feb 21 2019, 8:07 AM

Maybe KeepassXC? It's a Qt based client for Keepass password databases. They seem interested in using Breeze as their default icon theme as well. They currently use Oxygen.

GB_2 added a comment.Mar 3 2019, 2:25 PM

What about Spectral (https://gitlab.com/b0/spectral/tree/develop)?
Now that we have a Matrix instance it would be great if we could have a good Qt/KDE Matrix client too.
It already uses QML.

lavender added a subscriber: lavender.EditedMar 3 2019, 5:13 PM

OBS Studio comes to mind. It's used by many creatives, streamers, podcasters, etc. It has a strong community (hundreds of thousands of daily users) and it uses Qt!

GB_2 added a comment.Mar 4 2019, 1:28 PM

OBS Studio comes to mind. It's used by many creatives, streamers, podcasters, etc. It has a strong community (hundreds of thousands of daily users) and it uses Qt!

That would be amazing!

paulb added a comment.Mar 4 2019, 1:55 PM
In T10034#177768, @GB_2 wrote:

OBS Studio comes to mind. It's used by many creatives, streamers, podcasters, etc. It has a strong community (hundreds of thousands of daily users) and it uses Qt!

That would be amazing!

They would all be amazing. I am so happy this task has gained so much traction.

The next step is evaluating which ones are the most realistic, though, and approach them first. I am guessing that projects that use Qt libraries and that are developed by people we know would be the most obvious bet.

paulb added a comment.EditedMar 4 2019, 1:56 PM

It would also be useful to make a list of "selling points" we can trot out to try and convince projects to join us.

Maybe talk to the people behind Falkon and see what made them decide to join KDE.

Joining KDE would make it easy to offer up-to-date packages to KDE Neon users, right?

Joining KDE would make it easy to offer up-to-date packages to KDE Neon users, right?

Yes it means KDE neon would package it and it would get git and release builds available continuously with QA as needed

GB_2 added a comment.Mar 4 2019, 3:01 PM

My top 4:
1: OBS Studio
2: Spectral
3: TuxClocker
4: Natron

This comment was removed by Ghost6.
This comment was removed by Ghost6.
ognarb added a comment.Mar 4 2019, 5:42 PM
In T10034#177799, @Pixel_Lime wrote:

My wishlist is

We have Amarok and Elisa, why we need one more music player?

Cantata is a MPD client. Amarok and Elisa are normal music player. But it's true, Cantata shouldn't be a priority.

paulb added a comment.Mar 4 2019, 5:47 PM
In T10034#177799, @Pixel_Lime wrote:

My wishlist is

We have Amarok and Elisa, why we need one more music player?

Cantata is a MPD client. Amarok and Elisa are normal music player. But it's true, Cantata shouldn't be a priority.

Where would VVAVE fit in there? By the way, another already confirmed KDE project that may be in conflict with Cantata.

ognarb added a comment.Mar 4 2019, 5:50 PM
In T10034#177799, @Pixel_Lime wrote:

My wishlist is

We have Amarok and Elisa, why we need one more music player?

Cantata is a MPD client. Amarok and Elisa are normal music player. But it's true, Cantata shouldn't be a priority.

Where would VVAVE fit in there? By the way, another already confirmed KDE project that may be in conflict with Cantata.

Let's not forget Juk ;)

paulb added a comment.Mar 4 2019, 5:51 PM
In T10034#177799, @Pixel_Lime wrote:

My wishlist is

We have Amarok and Elisa, why we need one more music player?

Cantata is a MPD client. Amarok and Elisa are normal music player. But it's true, Cantata shouldn't be a priority.

Where would VVAVE fit in there? By the way, another already confirmed KDE project that may be in conflict with Cantata.

Let's not forget Juk ;)

Confirmed: Cantata not a priority

cfeck added a subscriber: cfeck.Mar 5 2019, 1:57 AM

Manjaro wiki has a list of pure Qt applications: https://wiki.manjaro.org/index.php?title=List_of_Qt_Applications

Developers of those applications are usually aware of KDE, but decided to stay pure Qt. With some luck, dead projects can be incubated if we find new maintainers.

Maybe talk to the people behind Falkon and see what made them decide to join KDE.

The Falkon maintainer already was a KDE developer.

paulb added a comment.Mar 5 2019, 8:22 AM

Manjaro wiki has a list of pure Qt applications: https://wiki.manjaro.org/index.php?title=List_of_Qt_Applications

That is really interesting. An excellent source. Thanks!

OpenToonz: Full-featured 2D animation creation software.

Mixxx: DJ software that gives you everything you need to perform live DJ mixes.

ScreenTranslator: screen capture, OCR and translation tool.

dfaure added a comment.Mar 6 2019, 9:02 AM

OK, so we're making lists of apps. Now what? For instance, I indeed have good contacts with the Rosegarden developers, but is there a document (e.g. wiki page / whitepaper) that lists the advantages of moving an existing project to KDE? In their case I can think of a number of them (CI, more translators, etc.) but also I can imagine some of their reserves (having to learn git -- they use SVN -- which also means we'd need volunteers on our side for a svn->git migration). The overall effort of moving has to bring sufficient amounts of benefits for the effort to be worth it.
So if we could present a full list or a nice document about all the benefits of moving, that would be helpful.

OK, so we're making lists of apps. Now what? For instance, I indeed have good contacts with the Rosegarden developers, but is there a document (e.g. wiki page / whitepaper) that lists the advantages of moving an existing project to KDE? In their case I can think of a number of them (CI, more translators, etc.) but also I can imagine some of their reserves (having to learn git -- they use SVN -- which also means we'd need volunteers on our side for a svn->git migration). The overall effort of moving has to bring sufficient amounts of benefits for the effort to be worth it.
So if we could present a full list or a nice document about all the benefits of moving, that would be helpful.

Having that on the website or in a blog post would be good.

OpenToonz: Full-featured 2D animation creation software.

Mixxx: DJ software that gives you everything you need to perform live DJ mixes.

ScreenTranslator: screen capture, OCR and translation tool.

OpenToonz has a BSD license, need to change license from BSD to GPL.

OpenToonz has a BSD license, need to change license from BSD to GPL.

This is not necessary

This comment was removed by Ghost6.

What's the point of doing something if anyone can take the source code, rename it in iToonz, and make proprietary and start sell?

That is entirely up to the authors to decide as they are the ones doing it.

(Also it's something of a myth that you can arbitrarily make BSD licenced code proprietary, the licence says you can share and copy it and that can't be taken away although you can compile it so source isn't available and add other stuff which is restricted)

paulb added a comment.Mar 6 2019, 10:24 PM

OK, so we're making lists of apps. Now what? For instance, I indeed have good contacts with the Rosegarden developers, but is there a document (e.g. wiki page / whitepaper) that lists the advantages of moving an existing project to KDE? In their case I can think of a number of them (CI, more translators, etc.) but also I can imagine some of their reserves (having to learn git -- they use SVN -- which also means we'd need volunteers on our side for a svn->git migration). The overall effort of moving has to bring sufficient amounts of benefits for the effort to be worth it.
So if we could present a full list or a nice document about all the benefits of moving, that would be helpful.

Yes, you are right. My suggestion is that we move onto general advantages we can offer a project, the advantages which can be appreciated by nearly every project (T10577).

Later we can move onto the specific needs of the projects we decide to approach and decide how (or if) we can provide them.

paulb added a comment.Mar 6 2019, 10:32 PM

Another topic is who we should approach first. We had a poll and we will be discussing that tomorrow in the Promo meeting, if time permits.

My gut feeling is that, to start with, we should go for the lowest hanging fruit, projects that

  1. are easy to integrate because they share similar technologies to ours
  2. don't have an enormous team (say 5 people or less), because getting a big team to agree is complicated
  3. not very old and, therefore, not tied up to platforms incompatible with our own
  4. can clearly benefit of becoming part of KDE

This will give us the experience we need to then approach larger and more complex recruitments.

James added a subscriber: James.Mar 10 2019, 2:45 PM

Hi all! Sorry I'm a little late to the (excellent and exciting) discussion here. I'd like to add one potential project as well, that would really fit a need within KDE Applications: Kraft. As it stands today we have the excellent Scrooge and KMyMoney for finances - and even can be used for small biz accounting. To also have an easy to use invoicing program would be extremely helpful - and also unique in the FOSS world AFAIK. Basic business software is sorely lacking in the FOSS world, it would appear.

It would also be a small victory, since there were attempts in the past to make this a "official" KDE Application, but the effort was cut short due to an unfortunate, and brief, discussion. See That Was Fast: As Of Today Kraft Is Out Of KDE for some context.

Would be nice to reach out to the Dev and maybe try again to see if there would be a way forward here. Otherwise, a great list indeed and looking forward to helping move this forward.

Hi all! Sorry I'm a little late to the (excellent and exciting) discussion here. I'd like to add one potential project as well, that would really fit a need within KDE Applications: Kraft. As it stands today we have the excellent Scrooge and KMyMoney for finances - and even can be used for small biz accounting. To also have an easy to use invoicing program would be extremely helpful - and also unique in the FOSS world AFAIK. Basic business software is sorely lacking in the FOSS world, it would appear.

It would also be a small victory, since there were attempts in the past to make this a "official" KDE Application, but the effort was cut short due to an unfortunate, and brief, discussion. See That Was Fast: As Of Today Kraft Is Out Of KDE for some context.

The story is a bit different. Kraft was part of the KDE community (this discussion is about the KDE Community, not the specific product known as KDE Applications) but willingly decided to leave it.

ognarb added a comment.EditedMar 10 2019, 4:57 PM

There is also asteroidOS that is interesting. It's an open source system for smartwatch build with qt quick. Maybe some collaboration with plasma mobile and/or kde connect could be interesting.

There is also asteroidOS that is interesting. It's an open source system for smartwatch build with qt quick. Maybe some collaboration with plasma mobile and/or kde connect could be interesting.

I don’t really like smartwatches, but the part with KDE Connect sounds interesting to me too.

How about a calculator like SpeedCrunch? It would be great to access the calculator functionality directly from KRunner, or inside any text boxes (similar example available in FreeCAD’s spin boxes), or from Kate. Currently, KRunner can’t e. g. convert to hexadecimal...

+1 for Scribus. Scribus and Krita are a fantastic combination for artists and professionals working in print. Bringing in Scribus will mean greater interoperability between two software. This would be great if happened.

James added a comment.Apr 14 2019, 3:32 AM

I'd like to add keepassxc to the list as a Qt-based application that would strengthen our position in our privacy initiative, along with Vaults and others. Also, this article would seem timely here.

Also, +1 for Lutris and Scribus. Lutris has been in the press a lot lately, as has gaming on Linux in general, and that would be quite something to showcase.

I'd like to propose another suggestion: http://www.kdbg.org/. This one already use KDE Frameworks.

GB_2 added a comment.May 27 2019, 6:13 PM

Kup, an awesome backup tool that fits perfectly into Plasma: https://github.com/spersson/Kup
@ngraham already asked if it can be a KDE Project: https://github.com/spersson/Kup/issues/76

+1 on Kup. I've started using it myself and it's very close to what I think a backup system should be.

Lutris seems unlikely. It's written in Python, uses GTK3, and has a headerbar-based UI that its developers see no problem with: https://github.com/lutris/lutris/issues/1719

lutris also depends on gnome-desktop (the library)

Em ter, 28 de mai de 2019 às 06:41, Nathaniel Graham <
noreply@phabricator.kde.org> escreveu:

ngraham added a comment.

+1 on Kup. I've started using it myself and it's very close to what I
think a backup system should be.

Lutris seems unlikely. It's written in Python, uses GTK3, and has a
headerbar-based UI that its developers see no problem with:
https://github.com/lutris/lutris/issues/1719

*TASK DETAIL*
https://phabricator.kde.org/T10034

*To: *paulb, ngraham

*Cc: *kamathraghavendra, James, cfeck, Ghost6, kpiwowarski, lavender,
ndavis, filipf, rgomezantoli, dfaure, tcanabrava, adridg, lydia, GB_2,
jriddell, ixoos, rooty, davidhurka, matheusm, apol, ltoscano, ognarb,
neofytosk, afarid, Takuya, skadinna, ngraham, KDE Promo, paulb, alexde,
domson, davidc, Anachronox, nauticalnexus, nalmeida, s8321414, totte,
valorie, sebas, repinc

I have just tried ScanTailor. It is useful to convert photographed documents to good looking PDFs. (Don’t know why they talk about scans, scans don’t need this.) It already uses Qt and feels like other KDE applications.

Probably it could benefit from KDE Connect, to integrate the phones camera.

I have just tried ScanTailor. It is useful to convert photographed documents to good looking PDFs.

Some bug reporters asked to add editing functionality to Okular, like rotating & reordering pages, metadata, etc. But that is not necessarily in the scope of Okular.

I think these functions would perfectly fit into ScanTailor, it already has most of these functions. Just add PDF import and export.

Then it could be renamed Objektive, to be the complementary application to Okular. ;)

ScanTailor: Creating and correcting (PDF) documents

  • Import scans and photographs
  • Change the page layout (including splitting, cropping, deskewing)
  • Remove artifacts
  • Edit metadata (to be added together with PDF handling)

Okular: Reading and discussing (PDF) documents

  • Reading, Presentation mode
  • Printing
  • Annotations
  • Data extraction (Find function, text & table selection, image & diagram extraction (to be added))

Missing: OCR

What do you think?

Personally I'd really like for all of those functions to be integrated into a single app (Okular) but having a separate KDE app to do them wouldn't be the worst thing in the world.

crozbo added a subscriber: crozbo.Jun 15 2019, 11:51 AM

I'd like to propose Sigil. It an ebook(epub) editor.

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.

Another projects worth integrating are ZombieTrackerGPS and ContainerManager. Both are using Qt.