- I'm not sure how to do that.
- that sounds like a good idea
- I am simply not sure.
- 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.
- 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.
- if that's possible, it's a very good idea
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Wed, Mar 6
Nov 2 2023
Following done!
Jul 14 2023
Current state (still qwidget-based)
Jul 13 2023
Jul 5 2023
Jun 22 2023
In T16430#292419, @dkazakov wrote:(not that is "blocks" the split, we should just model and document how to do such MRs)
May 30 2023
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)
May 26 2023
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)
May 24 2023
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.
Feb 5 2023
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.
Jan 25 2023
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.
Jan 10 2023
Jan 5 2023
The updated flyer is here: https://files.kde.org/krita/marketing/Krita_brochure_2022.pdf
Dec 22 2022
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:
Dec 12 2022
I'll try to update our flier.
Sep 26 2022
Sep 24 2022
Oh, this looks good! I think the translation issue is something we just will have to accept.
Sep 14 2022
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.
Aug 3 2022
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
Aug 2 2022
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.
Jul 5 2022
@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.
Jun 24 2022
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.)
Jun 22 2022
Ah, I was too late reading my mail. Seems a solution is already there?
Feb 16 2022
My take:
Feb 14 2022
Shall we make sure that Krita really does not use OpenGL for the rest of the UI when "Canvas Graphics Acceleration" is disabled?
Feb 13 2022
Feb 8 2022
I've read it...
Dec 7 2021
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.
Dec 2 2021
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...
Dec 1 2021
Nov 5 2021
Nov 2 2021
Oct 18 2021
- With the new funding site, we need to integrate it better with krita.org so it is not just a banner on the top
Oct 14 2021
Oh, I probably would drop item 2 in stage 1.
Yes, this sounds like a good plan.
Sep 10 2021
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.
Aug 29 2021
I would prefer not to go the sqlite route, for the following reasons:
Aug 22 2021
The QSettings files are used in main.cc before the i18n system is initialized. Using kconfig for that would break that.
Aug 20 2021
Actually, that's just a bug I introduced accidentally when doing the previous refactoring. Since this is gui code, it should be false...
Aug 19 2021
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.
Aug 7 2021
The apk's are broken:
Aug 6 2021
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.
Jul 20 2021
Sounds good to me
Jul 13 2021
I would propose
Jun 17 2021
It probably should go directly to the 4.4.3 setup.exe download.
May 31 2021
- 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.
May 24 2021
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...
May 18 2021
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?
May 6 2021
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:
May 4 2021
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.
Apr 23 2021
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.
Apr 22 2021
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.
Apr 15 2021
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.
Apr 14 2021
Get the build-patch tool
Apr 12 2021
That would be quite useful even for GUI and in some non-essential other places. If I'm not mistaken, Dmitry said however that it would require high maintaince.
I'm not sure if it solves our issue, but I hope it could, then the maintaince would be probably worth it.
In T14357#253576, @tymond wrote:
2: Krita wil load the existing shine.ggr, not the new one, but the new one will be in the database (and marked as inactive). The solution would be to prefer finding dependent resources in the storage of the owner resource.
Apr 9 2021
This looks pretty good and is very thorough :-)
Apr 8 2021
Thanks, added!
Apr 7 2021
https://fund.krita.org/grants/ -- I've filled this in, but I need some more spice, so if you worked in a given year on something cool, leave a note here.
- I'd like to have Corporate Memberships and One Time Donations also in the toplevel bar.
Mar 31 2021
Thanks! I've started working on the CMS pages.
Mar 27 2021
Ah, no, chromium also says, after logging in:
Weird, with firefox, it says "The page isn’t redirecting properly" now -- chromium seems to get redirected.
Mar 26 2021
Yes, I managed to login!
This can be edited in https://fund.krita.org/cms/
I'm currently getting an error: