In my previous blog post I mentioned Akademy wasn’t completely over for me, I still had to hold an online training about the KDE Stack even though I left Thessaloniki already.

I had a few participants. Surprisingly some of them (but not all) were more experienced KDE developers than I expected. Since the training is more meant for people who want to get a feel on how to get around our stack I was a bit anxious they wouldn’t get bored… From the feedback I got immediately after the training it looks like it was well received even by the more experienced people. Apparently everybody learned quite a bit and had fun in the process. I’ll thus call it a success.

I made the slides of the KDE Stack training 2023 edition available online on my website and the page of the training in the Akademy program. Feel free to grab and go through them although I guess you’ll get most value with someone actually going through them with you.

And now? Well, we got the KDE e.V. general assembly coming in a few weeks. And hopefully we can setup another KDE PIM sprint in Toulouse around spring time if the community is interested.

As for the life of this KDE Stack training… I have this fantasy that next time I will be able to do it in-person and will make a major update of it since KF6 and Plasma 6 will be out by then. It’s not that I expect a lot of the content being invalidated by those releases. In fact quite the contrary since the 2023 edition already accounts for some of the expected changes. It’s more that an in-person format and the interest driven by major releases would be good reasons to re-think the way it is taught, probably bringing more labs and group activities.

We’ll see if I find time to actually fulfill this fantasy. 😊

As mentioned previously on this blog, I took a break from my vacations for the past couple of days. I attended Akademy 2023 over the week-end and I’m now typing this during my trip back home.

Of course it was nice to see the people. After all it’s the main reason to have such events. Still we had talks and it’s mainly what I will focus on here.

Saturday

Keynote: Libre Space Foundation - Empowering Open-Source Space Technologies

We started the day with a nice keynote about the Libre Space Foundation. It was very interesting and inspiring to see how open source can go into space. The project started in 2011 and despite all the regulation required they managed to get their first satellite in orbit in 2017. This is not a small feat. Of course, everything they produce is free and reusable by others. It was nice to touch upon some of their more specific constraints which impact quite a bit the cycles for producing software and hardware.

KDE Goals - a review and plans going forward

This was followed by a session about the KDE Goals. All three current community goals were covered.

First, the “Automation & Systematization” goal where a good chunk of tasks have been implemented around automated tests (in particular Selenium GUI testing) and the CI to ease some of our processes. It also meant updating quite some documentation.

Second, the Accessibility or “KDE For All” goal was covered. There’s been quite some effort put into adding automated tests using Selenium to check our software compatibility with screen readers and how the keyboard navigation fares. This obviously led to improvements all across the board: in Plasma, in application, in our frameworks, in Qt and in Orca.

Third, the “Sustainable Software” goal progress has been presented. It’s been quite a bit about documenting and presenting results of the efforts in various venues. But there has also been projects to setup labs to measure our software and automated tests using Selenium to implement user scenarios to measure. This can even be triggered on the CI to be executed in a permanent lab in Berlin.

Did you notice the recurring theme between the three goals? I’ll get back to it.

After this session about the KDE Goals, we split in two tracks and so obviously I couldn’t attend everything. I will write only about what I watched.

Measuring energy consumption of software

This session was a more in depth look at how the measurements of the KDE Eco effort are actually done. This is in fact an active research topic and it’s not necessarily easy to source hardware suitable for measuring properly the energy consumption of software.

The guidelines and best practices are still missing in this field.

Interestingly, we have several options available for measuring. I’d summarize it in three categories: cheap hardware, expensive specialized hardware and built-in sensors (accessible via perf if supported). Each category comes with its own set of trade-offs which need to be kept in mind.

In any case, it’s clear that the first thing to do is general profiling and optimizing. Then it’s time to focus on long-running processes, frequent workloads and idle behavior. At this stage, this is where the energy specific measurements become essential… but still difficult to do, the tools available are very basic.

KDE e.V. Board report

Lots was done on the side of the KDE e.V., the board report highlighted some of this work.

First we’re seeing the return of sprints, conferences and tradeshows. The presence and meetings of the community seem back to pre-COVID19 levels.

Also, the fundraising efforts are clearly bearing fruits. In particular a new platform has been put into place (Donorbox) which seems to work great for us. This lead to very successful fundraisers for the end of year and for Kdenlive (first fundraiser of its kind). Now, in the Kdenlive case it means we have to start spending this money to boost its progresses.

The KDE e.V. is professionalizing faster as well. All the “Make a Living” positions got filled. This is no longer a purely volunteers based organization, we have around 10 employees and contractors.

There is already great interest in our software among hardware and software vendors. Hopefully with all those efforts it will keep increasing.

Flatpak and KDE

I then attended a session about Flatpak. It was a quick recap of what it is. Hopefully a widespread adoption could reduce the amount of our users which run old outdated versions.

Interestingly, we seem to have more installations via Flatpak than I first thought. Our most successful software on FlatHub seems to be Kdenlive with around 575K installs. It’s followed by Okular with around 200K installs.

We also provide a KDE Runtime suitable for building our applications flatpaks on. There is one branch of it per Qt version.

Last but not least, we have our own Flatpak remote. This is meant for nightlies and not for stable use. Still if you want to help test the latest and greatest, it’s a nice option.

KF6 - Are we there yet?

This is the big question currently. How much time will we need to reach a port of KDE Frameworks, Plasma and our applications to Qt 6?

The work is on going with quite some progress made. Still there are a couple of challenges in particular in term of coexistence between 5 and 6 components. We’re not too bad in term of co-installability, but there are other dimensions which need catering to in this time of transition.

The talk also covered how to approach the port of our applications. So if you’re in this situation, I advise to get back to the recording and slides for details.

KDE Embedded - Where are we?

This was the last session of the day for me. It went back on what can be considered an embedded device. In this talk the definition was quite a bit reduced: we assumed a Linux kernel available but also a GPU and connectivity we’re kind of used to. A bit of a luxury embedded if you wish. 😉

In any case this is a nice challenge to invest in, it can also lead the way to more use of the KDE stack in the industry.

For such system integrations, we’re using the Yocto ecosystem as it is the industry standard. We provide several Yocto layers already: meta-kf5, meta-kf6, meta-kde and meta-kde-demo. This covers KDE Frameworks and Plasma but none of the apps.

The range of supported hardware is already interesting. It covers among others the Raspberry Pi 4, the Vision Five 2, the Beagle Play and the Beagle V. The RISC-V architecture is definitely becoming very interesting and getting quite some traction at the moment.

Plenty of dev boards have been produced during the last few years. The pain point on such devices is generally the GPU, even more so on RISC-V unfortunately.

Our stack has plenty to provide in this context. meta-kf5 or meta-kf6 could be used in industrial products of course, but Plasma and applications could be a good benchmark tool for new boards. We might want to provide extra frameworks and features for embedded use as well.

The biggest challenge for this effort is to make things approachable. The first Yocto build is not necessarily a walk in the park.

Sunday

Keynote: Kdenlive - what can we learn after 20 years of development?

This keynote gave a good overview of the Kdenlive project. This is in fact a much older project than I thought. It was started in 2003 but kind of got stuck until the actual maintainer revived it. Also it’s a good example of a project which had its own life before joining KDE officially. Indeed it became an official KDE application in 2015 only.

They explained how they keep the conversation open with the user base and how it feeds the vision for the project. It’s no surprise this is such a nice tool. The user base seems diverse, although the personal use is dominant. Still, its used in schools and by some professionals already, maybe we can expect those user groups to grow in the coming years.

They have a couple of challenges regarding testing and managing their dependencies. Clearly its on their radar and we can expect this to get better.

The fundraising effort paid off. It already allowed the maintainer to reduce the work time at his current job, he can devote one day a week to Kdenlive work.

Finally we got a tour of exciting new features they released. Most notably the nested timelines but also the support of speech to text to help creating subtitles. They won’t stop here though and they hope to bring more AI supported tools but also improve the GPU support and provide online collaborative spaces.

Make it talk: Adding speech to your application

The first lightning talk I’ve seen on Sunday was advocating for more text to speech uses in our applications. Indeed it can have some uses beyond accessibility.

It also made the case that it’s actually easy to do through Qt which provides the QtSpeech module for this with a simple API. The good news being that it is supported on almost all platforms.

The Community Working Group - Keeping a Healthy Community

Another lightning talk, this time about the Community Working Group. It didn’t a good job debunking some myths regarding that working group. It is indeed not a “community police” but it’s mainly here to help the community and provide assistance in case of issues.

They have a complex job aiming at maintaining healthy community channels. It involves making sure there is no misunderstanding between people. This is necessary to avoid loosing contributors due to a bad experience.

An OSS Tool for Comprehending Huge Codebases

Interesting talk about a tool allowing to explore codebases. Having a knack for this and having done it quite a few times in the past obviously I was eager to attend this one.

The tool is made by Codethink and funded by Bloomberg. It uses LLVM to parse C++ code and feed a model of the code stored in a relational database. In particular it takes care of finding all the C++ entities and their dependencies. There’s also traceability on which source and header files the entities and dependencies come from.

On top of this model they built visualizations allowing to track dependencies between packages. It also allows to inspect where dependencies are coming from and it makes the distinction between dependencies coming from tests or not. It also provides a plugin mechanism which allows to impact the behavior of steps in the pipeline. And last but not least, command line tools are provided to manipulate the database. This comes in handy for writing checks to enforce on the CI for instance.

They took the time to try the tool on KDE products. This is after all a big corpus of C++ code readily available to validate such a tool. This way they showed examples of cyclic dependencies in some places (like a Kate plugin). They’re not necessarily hard to fix but can go unnoticed. Another interesting thing they attempted was to use hooks to tag modules with their tiers. Which would then allow to differentiate tiers in the dependency graphs allowing to see if we have any violation of the KDE Framework model.

They have plans for providing more features out of the box like tracking unused includes, spotting entities used without being included directly, etc. This could be interesting, clearly it aroused interest in attendees.

Matrix and ActivityPub for everything

This short talk went over the Matrix and ActivityPub protocols. Both are federated but the speakers highlighted the main differences. In particular Matrix is end to end encrypted for personal communication uses, while ActivityPub is not encrypted and tailored for social media uses.

They also emphasized how both protocols are important for the KDE community and how they can be used. Some of the ideas are upcoming features which are already implemented.

In particular we’ve seen a couple of scenarios for location sharing over Matrix so that you can get it to and from Itinerary or share vie NeoChat. There’s also the future possibilities of synchronizing Itinerary data over Matrix or importing Mobilizon event in your calendar.

Selenium GUI Testing

Remember when I mentioned a recurring theme during the session about the KDE Goals? I hope that by now you realized this was about Selenium. So of course, it was to be expected that we would have a session about it. After all this effort to use Selenium for GUI testing helps push forward all of our current community goals.

What has been created so far allows to easily write GUI tests reproducible locally. This way we could catch up with industry standards, we were clearly falling behind in term of GUI testing.

Selenium is known for being web oriented, but it can be used in other contexts. What you need is mainly a WebDriver implementation and this is exactly what has been created. So we now have such an implementation bridging between Selenium and AT-SPI the protocol used for accessibility support.

One nice trait of all this which I noted is that the tests are run in a nested Wayland session. This avoids leakage with the host session. Also the session is screen recorded so we can see what happened in it after the fact if needed.

Now help is needed for more such tests to be written using this bridge. Doing so will help with all of our current goals.

Kyber: a new cross-platform high-quality remote control software

After lunch we had a whole series of lightning talk. The first one demoing Kyber. This is a new solution coming from VideoLAN to control machines remotely.

The results are so far impressive. You can play a game from Linux remotely controlling a Windows machine for instance. The delay over a 4G connection is spiking at 40ms maximum, but most of the time is close to 20ms. This means in most cases around a 1.5 frames delay if playing at 60 frame per seconds.

On the network level it uses QUIC and uses a few tricks to have crisp rendering of the image, including text, despite the compression. Of course it is portable and both the client and server are available for various platforms. It can also leverage hardware for better performances.

Impressive and exciting. Looks like we might have a very viable FOSS alternative to TeamViewer soon.

Fun with Charts: Green Energy in System Monitor

Next lightning talk was about a personal project bringing information from a solar panel installation all the way to a Plasma desktop. Indeed, those installations tend to be coupled to proprietary cloud applications, it’d be nice to not go through those to control your installation.

We were shown funny uses. Like a KInfoCenter module summarizing all the available data, or a KDED notifier which indicates the first ray of sun in the day, the storage battery status etc. And of course some command line tools to script the system allowing for instance to turn on and off services based on the amount of energy available.

What has qmllint ever done for us?

Another lightning talk, this time about qmllint. It went through the history of this tool which went from being only able to tell if a file was a QML one or not, to providing lots of warnings about missuses of the language.

Now it’s even possible to integrate it in the CI via a JSON file and it’s the base of the warnings we get in the QML LSP support. And last for not least, I learned it even has a plugin system nowadays allowing to extend it to provide more project specific checks.

It became quite powerful indeed.

Wait, are first-run wizards cool again?

The last lightning talk of the track was about our new first-run wizard. It has been introduced for good reasons, this time we’re not making it for users to configure some settings like look and feel.

This is about on-boarding the users on first use. For instances it helps them access the internet if needed, it introduces them to the important Plasma concepts, it gives them an opportunity to get involved, and it also remind them that donations are possible.

This is definitely done in a different spirit than the old wizard we had back in the days.

The End?

This was only over two days for me… But this is not over yet! The BoFs are going on strong for the rest of the week (even though I unfortunately won’t attend them this year).

Also there will be a training day. If you’re interested in how the KDE Stack is organized, make sure to not miss the training I will hold online on Thursday morning.

Make sure you commit anything you want to end up in the KDE Gear 23.08 releases to them

During this week Akademy 2023 is going on in Thessaloniki, Greece. It’s always awesome, to see many old friends and getting together with that amazing hacker community which is KDE.

There, me and Niccolò gave a talk about what;s happening in Plasma 6 and what will change, Noccolò on more visual things, about some changes we are cooking on the UI and on the visual themes. Here you can find a recording of the talk (alongside all the others of the day)

I talked more about the work I’ve bein doing in the Plasma shell during the last couple of months: code rafactors and how the API for writing plasmoids will change.

There were many things we were not quite happy about and now with the major release is the occasion for streamlining many things.

Now, It’s very important those changes are are well communicated, and easy to do for developes, because there are *a lot* of 3rd party plasmoids on the KDE store, which people are using and enjoying.

Let’s go trough the most important changes:

Dataengines

Dataengines were an API designed in early KDE 4 times, especially one of for our first offereings of Plasmoid API which was the pure JavaScript API, which existed long before the QML existed.

But now in a QML world, their API doesn’t really fit, instead is a much better fit having a QML extension which offers classes with all the needed properties, data models and signals that provide access to the needed data, such as tasks, notifications etc.

Dataengines are now deprecated and moved into a separed library, called “plasma5support” which will be still available for the time being, but consider porting away from it as we plan to eventually drop it.

Base Plasmoid API

The way plasmoids are declared in QML changed a bit: we used to have a magical “plasmoid” context property available from anywhere. This was an instance of a QQuickItem which was both the item where all the plasmoid contents were *and* a wrapper for some of the api for the central plasmoid object: the C++ class Plasma::Applet.

Now the access to plasmoid is an attahced property, the (uppercase) “Plasmoid”, which is directly the access to the instance of the central Plasma::Applet, without an in-between wrapper anymore.

The central QQuickItem is now called “PlasmoidItem”, and must be the root item of the plasmoid, just alike ApplicationWindow is for applications.

PlasmoidItem will have the purely graphical properties, such as the “compactRepresentation” or “fullRepresentation”

Here is a very minimal example of a plasmoid main file under plasma6:

import org.kde.plasma.plasmoid 2.0
PlasmoidItem {
    Plasmoid.title: i18n("hello")
    fullRepresentation: Item {....}
}

Actions

Plasmoids can export actions to their right mouse button menu, such as “mute” for the mixer plasmoid and so on.

In Plasma 5 we had an imperative API to add those actions, which was again coming from that old pure JS API, which really looked a bit out of tune in QML. In Plasma 6 the API has been replaced with a completely declarative API, in this form:

PlasmoidItem {
    Plasmoid.contextualActions: [
        PlasmaCore.Action {
            text: i18n("Foo")
            icon.name: "back"
            onTriggered: {...}
        },
        PlasmaCore.Action {
             ...
        }
    ]
}

PlasmaCore.Action is actually a binding to QAction (not the internal QML action type), so that it can be shared between C++ and QML easily

SVG theming

Plasma Themes don’t really have changed for now (and you can expect any old theme from the store to keep working), but the C++ and QML API for them has been moved to a standalone framework called KSvg. Plasma Svgs have quite some interesting features over the pure QtSvg API, such as disk caching of the rendered images, stylesheet recoloring to system colors and the 9 patch rectangular stretched images of FrameSvg.

Some applications were interested in using that, but couldn’t due to the long dependency chain of plasma-framework, so now they can be used as a much more manageable compact framework, offering both the usual C++, QPainter based api and QML bindings.

import org.kde.ksvg 1.0 as KSvg
FrameSvg {
    imagePath: "widgets/background"
}

Kirigami all the way down

Designing Kirigami in the beginning we lifted two concept from the Plasma API (which again we couldn’t use directly due to the dependency chain) Theme and Units

Theme gives access to the named system colors, and Units to standard spacing and animation durations.

Over the years the Kirigami version got way more advanced then the Plasma version, and having this code duplication didn’t make much more sense, to in Plasma6 whenever referring to a named color or an unit, the Kirigami version should be used, as the Plasma version is going away.

import org.kde.kirigami 2.20 as Kirigami
RowLayout {
    spacing: Kirigami.Units.smallSpacing
    Rectangle {
        color: Kirigami.Theme.backgroundColor
        bordere.color: Kirigami.Theme.textColor
    }
}

Today we are announcing the availability of the minor patch release 2.10.1. This release contains minor improvements and bug fixes only. The fixes are distributed over many different areas of the application and we recommend everybody update to this patch release which is available from our download page.

The full list of fixes included in this patch release are as follows:

• Support markdown library discount version 3
• Improve Vector BLF dependency (git download must be enabled if needed)
• Correctly use system header of system QXlsx (BUG 468651)
• Fix group separator problem in formulas (BUG 468098)
• Improve log scales (auto scaling and tick number)
• Improve auto scale (Issue #536)
• Fix limits when changing scales (Issue #446)
• Use system liborigin headers if linking against system liborigin (BUG 469367)
• Properly import UTF8 encoded data (BUG 470338)
• Do not clear the undo history when saving the project (BUG 470727)
• Properly react on orientation changes in the worksheet properties explorer
• In the collections of example projects, color maps and data sets also allow searching for sub-strings and make the search case-insensitive
• Properly set the size of the worksheet in the presenter mode if “use view size” is used
• Properly save and load the property “visible” for box and bar plots in the project file
• Fix copy&paste and duplication of box and bar plots
• Fix issues with loading object templates (BUG 470003)
• Fix crash when loading projects with reference ranges
• .xlsx import corrections:
  • fix crash importing empty cells
  • support datetime import (Issue #531)
• Properly set the initial properties of the reference line, like line width, etc. (Issue #580)
• Properly show the initial value of the property “visible” for the reference range (Issue #582)
• React to Delete and Backspace keys to delete selected cells in spreadsheet columns (Issue #596)
• Update the plot legend on column name changes used in box and bar plots (Issue #597)
• Fix the positioning of values labels for horizontal bar plots (Issue #599)
• Initialize the parameters for the baseline subtraction with reasonable values on first startup and improve the appearance of the preview plot

We are also working on the new features and improvements that will arrive in the next 2.11 release. This release will become available in the coming months. More on this in the next blog posts. Stay tuned!

We're happy to announce the new release 5.11.0 of KPhotoAlbum, the KDE photo management program!

Most notably, this release can be built against Exiv2 0.28, which introduced some breaking changes. Older versions are still supported as before.

Other things that have been changed and fixed (as listed in the ChangeLog) are:

Changed

• Recalculate Checksums in the Maintenance menu and Refresh Selected Thumbnails in the thumbnail context menu have been unified to do exactly the same.
• Simplified logging categories: kphotoalbum.XMLDB was merged into kphotoalbum.DB

Fixed

• Fix issue where non-empty time units in the date bar were incorrectly greyed out (#467903)
• Fix bug with the date bar showing and selecting incorrect date ranges (#468045)
• Fix crash when the annotation dialog is opened from the viewer window and the viewer is closed before the annotation dialog (#470889)
• Fix inconsistent UI where menu actions would not immediately be updated to reflect a change (#472109, #472113)

The list of contributors is quite short this time, it was only Johannes and me ;-) Anyway, thanks to everybody working on KPA in any way, to everybody having contributed in the past and for all future work!

Have a lot of fun with KPhotoAlbum 5.11.0 :-)

— Tobias

Dear digiKam fans and users,

After five months of active maintenance and long bugs triage, the digiKam team is proud to present version 8.1.0 of its open source digital photo manager.

See below the list of most important features coming with this release.

• Print Creator: Add 4 new templates for 6.8 inches photo paper.
• General : Improve usability of Image Properties sidebar tab.
• Libraw : Update to snapshot 2023-05-14
• Bundles : Update Exiv2 to last 0.28 release
• Bundles : Update KF5 framework to last 5.106
• Bundles : Includes Breeze widgets style in MacOS package to render properly GUI contents.
• Tags : Add possibility to remove all face tags from selected items.
• Tags : Add possibility to remove all tags from selected items except face tags.
• Similarity : Add usability improvements about reference images while searching for duplicates images.

This version arrives with a long review of bugzilla entries. Long time bugs present in older version have been fixed and we spare a lots of time to contact users to validate changes in pre-release to confirm fixes before to deploy the program in production.

And it can be done easily, ackshually.

But what is that all about?

The problem

It has been a longstanding complaint that the ~/.config/ directory on Linux systems can get riddled with configuration files. This is the case with KDE software as well.

My idea is that we should be putting those into subdirectories inside ~/.config/.

The Freedesktop XDG Base Directory specification generally only states that standard configuration files should go under XDG_CONFIG_DIRS. Dump them there and you’re gold. So it’s not wrong to just fill the ~/.config/ directory with them.

Caution: Technical Jargon Zone!

If you had been following my earlier blog posts, you would know that I rarely include any code in them. My focus has primarily been on explaining how things work rather than delving into the specifics of how I implemented them. But this time I will be taking a deeper dive into the code, so in case you want to skip code today, you better not start reading this. ;)

This blog post has been a bit of a learning exercise for me as I pushed myself to learn UML diagrams and study a few design patterns in Qt. Learning Qt itself has been a challenge, though I doubt I can barely say that I have learnt it - I think it’s safe to say that I have just got more comfortable not understanding most things in Qt and trying to understand the parts that concern me. Now that I’m a teeny tiny bit wiser, I feel learning Object-Oriented Programming with C++, and a few design patterns prior to learning Qt would have been a better idea. Things (read classes) make a lot more sense once you understand the core design patterns.

Bundle Creator Wizard

The plan was to split the bundle creator into four main components, each having a single responsibility (Single Responsibility Principle!). DlgCreateBundle is the main class for the Bundle Creator. Notice how it has all functions related to putting the resources, tags and metadata in the bundle.

Similarly, all the code regarding resource choosing is present in PageResourceChooser(well not all, some of it in WdgResourcePreview), PageTagChooser(and WdgTagPreview) deals with the bundle’s tags, and all the metadata logic is present in PageMetaDataInfo. These wizard pages are completely independent of each other. There is, however, a message passing between PageBundleSaver and the other wizard pages which I will discuss later.

Resource Item Viewer

The Bundle Creator’s Resource Item Viewer now shares the same user interface as the one used by the Resource Manager in Krita. However, in order to not upset existing users of Krita, a new View Mode Button has been added so that users can switch between grid view and list view as per their preference.

The WdgResourcePreview class only deals with the left half of the Bundle Creator and the Resource Manager. That said, it loads the resources from the Resource Database onto the viewer, and displays resources as filtered by text or tag. However, all the code related to what happens when a resource item is clicked is dealt within the PageResourceChooser class for the Bundle Creator and the DlgResourceManager for the Resource Manager.

To manipulate the working of the right half of the Resource Chooser Page, one would need to make modifications to PageResourceChooser. And even though the left and right halves of the Resource Chooser page look fairly identical, it is important to note that the left half is built upon a QListView (KisResourceItemListView) and the right one on a QListWidget (KisResourceItemListWidget). This is because the left half loads the data directly from the Resource Database, using KisResourceModel. And the right half provides a view of the resource items selected by the user. It does use KisResourceModel for fetching the icon and name of the relevant item, but it doesn’t use the model directly.

This is really how each class mentioned above looks like.

Qt’s Model View Architecture in Bundle Creator

Similarly to MVC, Qt’s Model/view design pattern is essentially separated into three components: Model, View and Delegate.

Instead of utilizing controller classes, Qt’s view handles data updating through delegates. It serves two primary objectives: firstly, aiding the view in rendering each value, and secondly, facilitating user-initiated changes. As a result, the controller’s responsibilities have merged with the view, as the view now assumes some of the tasks traditionally assigned to the controller through Qt’s delegate mechanism.

The KisResourceModel, KisTagModel, KisStorageModel act as the models for the QComboBox-es in the Bundle Creator(and Resource Manager). The KisTagFilterResourceProxyModel is built on top of the KisResourceModel and KisTagModel, and serves as a model for the KisResourceItemView which displays the list of available resources. And the KisResourceItemDelegate renders the items of data. When an item is edited, the delegate communicates with the model directly using model indexes.

Signal Slot Mechanism in Bundle Creator

Very classic, but just a rough sketch showing how the wizard pages communicate with one another. This connection helps to update the summary in PageBundleSaver whenever the selected list of resources or tags changes.

A bit about the Tag Chooser

This is something I have been working on last week. The Tag Chooser page is updated to look similar to the Resource Manager’s tag section. The available tags are displayed using KisTagLabel and the selected ones are displayed(and selected) using KisTagSelectionWidget. In both the cases, the KisTagModel serves as the underlying model.

Merge Request

My merge request can be viewed here.

Important Commits

• Improve Bundle Creator in Krita
• Implement Resource Chooser page
• Add common UI to Resource Manager
• Implement metadata and saver pages
• Add toolbutton to switch views
• Add ToolButton for Selected Table
• Apply background to icons
• Make icons smaller
• Add Summary
• Add tags to summary
• Highlight side widget
• Add enum for clarity
• Add enum in resource item viewer
• Improve Tag Chooser

Plans post Mid-Term Evaluation

Post midterm, I would be working on adding the feature of editing bundles in Krita, which will allow artists to add and delete components from existing bundles, so that they won’t have to go through the process of creating a bundle from scratch whenever they want to make some changes. I’ve created a post on Krita Artists Forum to better understand the preferences of artists regarding bundle editing. Feel free to drop a comment if you want to talk about it! :D

This time a drawing on paper art since I have exhausted my collection of art I made using Krita - serves as a reminder that I should do this more often. :)