Maui RoadMap
This year KDE’s Akademy event is officially over and there is now a clear road map for the near future of the Maui Project.
At this year’s Akademy event I talked about VVAVE, the music player that forms part of the Maui Project, and also had the chance to have a discussion around the MauiKit and the other Maui apps about design and development with distribution packagers, designers, developers and other supportive people.
With this post, my idea is to give you all who are interested in the project a quick overview of what happened at the Akademy event and what’s going to happen next in the near weeks and month.
So let’s start by the most basic issue that was raised: there was not an easy way to test the applications, the only way was to compile everything from source and even then there were submodules not picking up correctly.
So that’s the first issue to target on the near roadmap, to release testing packages within the KDE infrastructure, which should allow the Maui apps to be available on the unstable or testing repositories of KDE Neon to easily test the project on Plasma Mobile, Plasma Desktop and also get DEB and APK packages to distribute to elsewhere.
To make that happen in first place the MauiKit project has to become a full framework instead of working just as a simple submodule. A few steps towards this direction has been made by making Mauikit support cmake instead of just qmake, this move has also been made for all the other Maui apps.
After this step is done the MauiKit should be distributed and installed system-wide and then used locally by all the other Maui apps instead of statically linking to the kit.
Once that work is done and the project is out in the wild the idea is to get as much feedback and bug reports as possible form the community and improve the apps based on the reports.
So to recap, the near road map plans aim to make releases of the Maui apps under the KDE infrastructure.
Parallel to that endeavor there will be still an ongoing work on improving the current set of applications back-ends and the integration with the supported/targeted system and devices in order to make beta releases before the stable ones, and also work on the front -end to improve on the Maui HIG and its controls on the side of the MauiKit project.
For example Index, the file manager will start making use of KDE framework APIs, such as Baloo, KIO and others.
All the benefits made on the MauKit should be immediately available on all the other applications.
So far the plans are:
- Make MauiKit a framework
- Move the apps to make use of cmake instead of qmake
- Set up everything to work with the KDE infrastructure
- Work on the Maui apps back-ends and improve the front-end on the MauiKit side
- Release of testing packages
And finally, there will be a lot of work dedicated to make all the Maui apps to be on sync between devices, versions and distributions.
The idea is to sync all the information that makes sense to be synced. The first iterations of such system would be part of the MauiKit project and probably
will make use of other open source services such as NextCloud; this idea applies to Index, VVAVE, Buho and even Pix.
Then once these goals are meet I’ll start working on finishing up the basic set of convergent applications adding a simple text editor, video player, and a launcher.
There will be still iterations on the design of the MauiKit controls but that is something is I’ll cover on another post, and let you know what happened on the Maui BOF session at this year’s Akademy event.
