FreeSoftware to the fullest!

Tag: KDevelop

KDE SDK Next, how will we develop in a year?

Since the beginning of my involvement in KDE and, more specifically, my involvement with KDevelop, many people have come to me and said that what we “actually need” is an SDK. So far, I never gave this much thought. Especially given that for me, the SDK was the system I’m running on and, by extension, the packaging system of my GNU/Linux distribution.

After all this time and given one of KDE Frameworks goals is to broaden our portability, I started wondering about the subject again. Some of the pieces are starting to come together already, but I still think we need to actually glue them together in a clear and pragmatic approach.

Premise: we want to build an SDK on top of the tools we generally use:
CMake, Qt, KDE Frameworks 5, Plasma, QML and C++.

For starters, we have two different major scopes: Integration with Plasma and Cross-platform facilities.

KDE Applications should be as distributable and portable as possible. On the other hand, we should be providing the tools to specifically integrate to the Plasma Workspaces.

Applications have different use-cases than the Plasma Workspaces. While applications need to be as easily distributable as possible, Plasma will want to have as much control on the system as needed to work accurately. Therefore, we want applications interacting with Qt5+KF5 and integrating through Qt abstractions, while Plasma will want to interact random components in the system regardless without fear.

What I propose:

  • Figure out which frameworks are portable and which are Plasma Platform integration frameworks. (e.g. KDED modules, KNotifications, Solid: are they portable? do we want to support the different platforms?)
  • Figure out what do we mean by supported platform (both in the case of Plasma and Applications).

Once we get there, we will be able to think about developers and:

  • Offer a sensible set of tools to support the development and ease testing.
  • Figure out a packaging plan for the libraries and tools for developers, so they can start using them for their development.
  • Figure out a deployment plan for the frameworks on the different platforms, so that deployed applications know how to rely on the needed dependencies.

So this are mostly thoughts, I would like to know if you’d be interested in the project. I think it makes a lot of sense to figure this out and then gather this year’s Randa meeting to make sure we’re coming up with a coherent next development platform.

KDevelop4’s Documentation Integration

I’m back to you today to show something that we have been baking lately for KDevelop. It is its new documentation integration.

With KDevelop 4 we have been focusing on putting together the information that the user will be willing to read every moment. Until now, while browsing the code, we were only showing the information gathered by the C++ support. Since the last week this is no longer true, we can now show the documentation provided by the different documentation plugins. We only have a QtHelp plugin for now, but I hope the architecture will be flexible enough for the new plugins we will have on the future, such as, maybe, a Doxygen’s, cmake’s or anything the reader can imagine.

Here you can see a couple of screenshots that might give you an idea of how does it work so that you can see KDevelop 4, love it and try it.

– The information shown when hovering the DUChain:
Documentation support integration on tooltip

– The tool view on the right showing the requested information:
Documentation tool view inside KDevelop

🙂

© 2024 TheBlindCow

Theme by Anders NorenUp ↑