I've done the first just now, also added the bugzilla version. I just got mail: the updated macos version is in review, so that's fine, too.

@vanyossi did you resubmit to the macos store?

epic is done

appimage zsync is done

APK have been signed, packages have been uploaded, the windows store submission has been done.

I've updated build.gradle and am waiting for the android builds to be finished.

1. Done
2. Cannot be done; we need to use the billing library 6.0.1 and the api level 34; we are using 5.0.0 and 33.
3. done
4. done
5. done
6. done
7. done
8. done

It will probably be faster to prepare a new release today and roll it out to the stores tomorrow; for the windows and epic store, a rollback isn't possible. It should be possible onthe play store, not sure about the macos or steam store.

3. is done: I also found out how to add a publish date for the window store, so I set that to wednesday

I removed the dmg again because it's unsigned. @vanyossi can you do the signing?

1. done
2. done
3. not possible right now, the status of the package is read-only
4. done
5. done
6. done
7. done
8. done

Just got the message that the windows submissions has been approved...

Epic store done now

Emmet, could you check the status of the steam package?

I haven'[t heard from the windows store, so they probably are still re-reviewing the submission.

apart from epic, still to do, this checklist should also include the apple store.

Thanks for making the list.

1. I'm not sure how to do that.
2. that sounds like a good idea
3. I am simply not sure.
4. I'm pretty sure that kritaui _is_ a super library that links to everything , and that's an issue. I'm fine with the subfolder/header.h approach, but that needs a lot of, hopefully automatable, changes. I don't think it's useful to split those folders out in separate libraries, since I'm not sure those files actually don't refer to files in other subfolders of the same library, or files in the toplevel library. I'm also not sure it would actually reduce the number of -I switches.
5. The angular brackets thing for includes outside has actually been our coding standard since the kimageshop days, but lots of people are pretty sloppy -- and then also, files get moved from library to library.
6. if that's possible, it's a very good idea

Following done!

https://invent.kde.org/graphics/krita/-/merge_requests/1853

Current state (still qwidget-based)

Possible interim design:

In T16430#292419, @dkazakov wrote:

(not that is "blocks" the split, we should just model and document how to do such MRs)

In T16430#291701, @dkazakov wrote:

So, what you're saying is that having deps commits mixed in with Krita commits helps somehow to figure out which dep change was related to which change in Krita <...> I don't think that's important at all.

Well, in some cases this info is rather useful for me.

So, what you're saying is that having deps commits mixed in with Krita commits helps somehow to figure out which dep change was related to which change in Krita. Though, of course, oftentimes, deps change without a corresponding change in Krita's code?

If we split deps, we will have to update Krita's repo somehow with what deps it needs (it is required for complex changes that rely on changes in deps)

I'd actually say that's an advantage... Krita's unstable branch would always checkout the master branch of the deps repo, unstable the unstable branch (so no manual changes needed), and every release would be linked to the correct dependency release. So it's the release manual that gets a bit longer (but I removed the copy_po) step today, so that's fine :P)

Maybe related, maybe not, but I thought today that maybe we should spin our deps build system into a separate repo with stable and unstable branches, and actual releases.

I'm not a fan of std::bind, but we need to be pretty careful with lambdas, they're often a source of bugs, too.

Undo/Redo has already been implemented, it's just not visible in the merge request I made for it because to work properly it needs to remove the KisPaletteEditor class.

The updated flyer is here: https://files.kde.org/krita/marketing/Krita_brochure_2022.pdf

Not much luck. I wanted to update the splash image to the current one, but I'm having scribus problems. The existing flyer is here:

I'll try to update our flier.

Oh, this looks good! I think the translation issue is something we just will have to accept.

I can always export the donation data from the mollie website -- and I've never really felt like doing an analysis :-)

Oh -- the IDEAL (that's specifically Dutch) payments through mollie _do_ make a difference. There have been about fifty of them since we started using mollie, and they tend to be large -- in the order of 100 euros a time.

I guess I was a bit confused. The reason I was worried and thought we might have to replace the mollie form on the current website with a braintree form was their unreasonable demand to have the UBO form signed by an accountant. That turned out not be the problem.

In https://donorbox.zendesk.com/hc/en-us/categories/360002194912-Payment-Options it looks like donorbox also supports IDEAL, which I think stripe by itself doesn't -- which is why I was interested.

donorbox.org looks like a good option, too

Mollie still provides the largest selection of payment options. I would prefer braintree to stripe, because braintree pretty much is credit-card only, as far as I can see from here.

@rempt - We need to eventually think about what to do with the Mollie stuff...or an alternative. I haven't hooked up any one time payment things in the new site. If we want to go a different direction like Stripe, I could start looking into that.

I don't think fund.krita.org has that ability -- blender also still has a separate single time donation page. The donate link in the top menu goes to fund.blender.org, which has a link to https://www.blender.org/about/donations/. In any case, we will keep needing the single-time donation option for after the downloads. (We might have to change that to using braintree or stripe after the summer, since Mollie is messing around with UBO declarations.)

Ah, I was too late reading my mail. Seems a solution is already there?

My take:

Shall we make sure that Krita really does not use OpenGL for the rest of the UI when "Canvas Graphics Acceleration" is disabled?

I've read it...

The two ideas (flexibility in adding tool instances vs tool presets) are not the same, though there are places where they touch. I still haven't got a better solution for saving tool config settings than the one in my merge request for tool presets.

No, that really is the problem for people like Andreas Resch.

That won't satisfy the people who want to see an eraser tool in the toolbox...

1. With the new funding site, we need to integrate it better with krita.org so it is not just a banner on the top

Oh, I probably would drop item 2 in stage 1.

Yes, this sounds like a good plan.

Make sure that when going from core 3 to core 4, the Qt opengl qpainter engine doesn't stop working. Afair, that was the big problem.

I would prefer not to go the sqlite route, for the following reasons:

The QSettings files are used in main.cc before the i18n system is initialized. Using kconfig for that would break that.

Actually, that's just a bug I introduced accidentally when doing the previous refactoring. Since this is gui code, it should be false...

I made a patch yesterday that changes all openConfig() calls to openConfig("krita5rc") -- but then ran into trouble because we both have a krita(5)rc in the Qt resources system and installed to disk, and sometime the embedded one is used, sometimes the installed one, until there is a local one in the user's config folder.

The apk's are broken:

Okay. I'll try to do that as soon as my system is back up again... I'm still wrestling with a bunch of issues, though.

Sounds good to me

I would propose

It probably should go directly to the 4.4.3 setup.exe download.

1. Do I understand it right that now we should make sure that all our resources embed their dependencies inside? Including filters and generators?

Okay, we're clearly not going to come to an agreement here based on the premises of this discussion. I don't want an already over-complicated system to get even more complicated in sight of the finish line, and Dmitry isn't going to allow me to implement the original design.

The reason this discussion has dragged on so long is basically that I am not trusted to design and write code once Dmitry has touched any part of that. And, yes, this makes me very unhappy and very tired. I am not intererested in a compromise: I want to have the trust to be allowed to work on the application I am the maintainer of.

Please WAIT a bit until I've read everything that has been posted before coming to conclusions...

I'm not sure I get it? I'm making the windows store uploads from our binary releases from the binary factory -- and those are around on download.kde.org, too, of course. Do I need to do something more?

In T14357#254998, @dkazakov wrote:

I am not trying to "break" anything, I'm trying to keep a relatively simple and sensible design working, instead of overcomplicating things. The version system simply is not suitable for what you're trying to do.

This "simple" system just doesn't solve the user's problem.

The dev fund is now officially live. I think on the krita.org side, we should:

Oh, and we're live...

We now have two images:

I am not trying to "break" anything, I'm trying to keep a relatively simple and sensible design working, instead of overcomplicating things. The version system simply is not suitable for what you're trying to do.

In T14357#254964, @dkazakov wrote:

That is one of the problems of your approach, which leads to undefined behavior in numerous cases.

Okay, let's start with this, and I'll repeat it a couple of times:

I have a feeling people think we deduplicate resources by filename. We don't: we use the md5sum for that.

As I have said a couple of times: resource versioning has NOTHING to do with resource de-duplication. Any discussion that confuses the two topics is useless.

In T14357#254342, @dkazakov wrote:

In T14357#253880, @rempt wrote:

Can you try to forget about the implementation detail for a minute and think about the problem itself for a bit of time?

I don't think this discussion is making much sense. You're fixated on one issue -- bundles that replace existing bundles with a new version of a resource, which isn't the whole problem at all. And nothing I say seems to get through, so let's close this task.

I'm not fixated on just "bundles replacing bundles". I point out a real problem. You expect all resource filenames in the world be unique, but that just cannot work in real life.

You also break the main expectation that the user has from "file format": the file (in our case resource) must look exactly the same on all the systems that open it. With your "fixation" on filenames the look of the resources when they are loaded on the user's system is just "undefined behavior". They may start look differently from how the author expected them to look because of the numerous reasons the user doesn't control and has no idea about. For example, some other bundle may have a different resource with the same filename (like watercolor.png) or the order with which different versions of the same bundles are added will define how the resource will look. The user has no idea about such implementation details (and shouldn't have).

UPD:
And the main reason why I try to raise this problem now, before we release Krita 5.0, because you want to bake this incorrect behavior into the file format and into the database scheme. After we release Krita 5 and start getting all these bugs like "I published brush bundle and it works wrongly on the user's machine and I have no idea why", it will be extremely difficult to fix that.

Can you try to forget about the implementation detail for a minute and think about the problem itself for a bit of time?

You are abusing the idea of the database now.