1. We could patch it to add the to default PRIVATE, it may break all other framework builds though. So I would better suggest to turn OFF CMAKE_INCLUDE_CURRENT_DIR and CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE to avoid the possible mess with the other packages depending on ecm.
2. Sounds like a good idea to do so.
3. Im not very in favor of monolithic libs, however since we are not developing library only package, it might be a point in favor of reducing the number of libraries.
4. Im not sure either, and I suspect the case of a lot of export from a subfolder is not very generalized. In any case Im not sure either if the includes would reduce by doing this.
5. We were never very vocal about it, neither in HACKING or Framework_Coding_Style. However I do think its a good approach.
6. True, let's keep things in their scope.

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.

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

Okay, here is the proposal based on the KDE CI scripts:

Okay, the Windows CI is now fully deployed. There is only one todo item that should be fixed before we move release builds to Gitlab:

Following done!

A note from bcooksley: I would suggest we use something like teams/krita/ [namespace] for hosting those [forked dependencies]

In T16862#298948, @dkazakov wrote:

A text shape can flow into multiple shapes, within SVG these are just linked, so both grouped and ungrouped is possible within SVG.

Then the design of the shapes being owned by the text shape may become a bit weird in some corner cases. E.g. we might end up with a configuration like that:

• shapeA
• groupShapeB
  • shapeC
  • shapeD
• textShapeE -> flows inside shapeA and shapeD
  
  As far as I can tell this configuration is not possible to implement within the current design.

A text shape can flow into multiple shapes, within SVG these are just linked, so both grouped and ungrouped is possible within SVG.

In T16862#298100, @dkazakov wrote:

Btw, a new set of weird technical questions:

1. Can a text shape belong to multiple (ungrouped) vector shapes? Or they should always be grouped first?

Btw, a new set of weird technical questions:

Right now, for text path we are required to only apply 'local transforms' on the textpath

Also need to consider flowing text in multiple shapes, and shape-subtract.

I think technically speaking the clip-paths are also a situation where there might be shape-dependency, though that can be resolved quite easily. Beyond that it's stuff like patterns and markers, but there it is also a lot more self-evident that we should just resolve, as they're resources and therefore suitably contained.

Can this include changing the text orientation from inside the path to outside the path (for example text outside the circle and text inside the circle path)

The user should be able to edit custom handles provided by the text shape itself:

Just a note: we need some better way to manage git repositories for the deps. The thing that happened today was that @lsegovia removed a branch in their personal repo (I guess it was renamed, though I'm not sure), and it broke our deps builds.

first update the deps, verify Krita still builds with it, and then have an MR for Krita. I'm not sure why, but I think it would give me a bit of a safe feeling...

In T16430#292419, @dkazakov wrote:

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

Just a note:

The maliciously built binary is why we wouldn't sign them - in that case all we have done is provide hosting for the binary, but no actual legitimacy.

There are two different sets of expiry times we're referring to here i'm afraid

There are two different sets of expiry times we're referring to here i'm afraid:

1. Being the job timeout (which is what you've referred to) - being the maximum amount of time the job is allowed to run for
2. Being the artifact expiry time (which is what I was referring to) - being the maximum amount of time Gitlab will keep the artifacts of a given CI job around before it schedules them for deletion.

Thank you for your replies!

For the cache and artifact folders, you can use:

• KDECI_CC_CACHE=C:/Gitlab/Caches/krita-windows/
• KDECI_CACHE_PATH=C:/Gitlab/Artifacts/krita-windows/

Weston's ICC -> GPU implementation:

Windows questions:

Oh, another manual needed:

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 <...> I don't think that's important at all.

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?

Well, no. It won't be materially different because right now the deps build and the krita build are completely separate already. They might be in the same repo, but the build systems do not connect.

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)

Problems of the split repos:

Krita's unstable branch would always checkout the master branch of the deps repo

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.

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.

Notes on the KDE's CI system

After yesterday's discussion on IRC I have added one more requirement to the system:

Hi, @alvinhochun and @vanyossi!

Just my two cents, as working on macos means using the entire 3rdparty project and we have being dealing with some of the issues. The approach might be a bit naive since I have most experience on macos

I haven't built the deps in quite a while but I'll try to respond a bit from what I remember that hopefully isn't too outdated:

The ASWF dependency management system for the VFX platform images relies on compositing Docker images

I see you've done quite extensive digging on the subject: 👏 That being, said, there are a few nitpicks and elephants-in-the-room after a cursory reading.

I have seen this warning when writing the lager code. I even tried to switch to the lambda syntax, but the resulting code looks a bit too verbose. Specifically, you need to explicitly declare all the typenames for every function argument (which might not known in the template context).

You should call QSqlQuery::finish to release the result cursor and stuff. The prepared statement itself shouldn't take much memory.

IIRC, it was KisResourceCacheDb::metaDataForId where lot of time was spent in prepare().

If you, say for example, want to insert multiple records in a loop, you would prepare the statement once, then reuse it by binding different values and then executing it in the loop. But I'm guessing the cases that show up in your profiling is more complex than simple loops and would require persisting the QSqlQuery in global scope to fix.

sure, I'll look into it then :)

I don't recall QSqlQuery::prepare ever being discussed, so it's likely no one ever noticed. If you have an idea of how to cache it, give it a try?

A thing I found out when I was profiling the code for https://invent.kde.org/graphics/krita/-/merge_requests/1731, is the QSqlQuery::prepare being a bottleneck. I looked into a docs a bit and found out that prepared queries are "compiled" by sqlite into whatever its internal bytecode can understand, so this is something which doesn't need to happen over and over again, but something we can cache and only bind values whenever needed (I think Qt's QSqlQuery::exec takes care of resetting the bindings and re-executing the same prepared query).

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.

So, std::bind is to me largely an incantation that happens within the PSD parsing code. What would we replace it with?

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.

Further notes backing up the version upgrade:

Change was deployed in https://invent.kde.org/graphics/krita/-/commit/ca645e71a09e1ee81dc0f7ef153b00304af058de and reverted in https://invent.kde.org/graphics/krita/-/commit/fa671d407fd6d89c87c15c67d486e5dd1c7b0301.

One other thing, I'm not sure how I feel about the current palette auto-saving when Krita is closed, especially given the lack of undo/redo support.

The palette selection button is at the bottom, which makes for an awkward popup, especially if the palette docker is bottom-most. I would like to move this to the top of the docker and make the click are larger and the name of the palette more prominent.

In T14731#284267, @alvinhochun wrote:

Yes PO files might get big but I don't see any problem with that (so far, for various Hugo websites of ours). The risks of mistranslations, I can also say, are minimal as this website is for promo, not documentation or anything technical which I consider to be more probable to have same strings used in different contexts. In case some occur, there might be some technical difficulties in implementing context support in hugo-i18n, but I think we can work around that if it's necessary.

Understood. I will try to work with that.

One thing though, regarding strings extracted from the YAML file (krita-org.po), I think they really ought to have context. Those extracted from config.yaml (the menu items) can use the link URL, while those from i18n/en.yaml can use the translation id.

(krita-org.po is also missing line numbers to the YAML file, would be nice if they can be added.)

I think we should not add context to a large number of messages, since a context change makes the message fuzzy, we don't want translators to have more unnecessary works. We should not add context by default either, because that's just excessive: the case of having same messages used in different contexts is not regular, so we should just deal with it when it occurs. And actually, regarding implementing context support in hugo-i18n, what might be difficult is to do that for messages extracted from content files. For YAML files, that's not a big issue: we can make hugo-i18n support a "context" field in the params array of a menu item or in the declaration of an i18n string (we already support an arbitrary comment for an i18n string in the same way). So don't worry too much about that. When you find such a case, you tell me, I'll do it.

In T14731#284109, @phunh wrote:

In T14731#284093, @alvinhochun wrote:

Then I have some questions regarding i18n:

• The extracted krita-org.po seems to contain various strings from config.yaml and i18n/en.yaml, but I see that these strings can also be translated in config.yaml directly or with i18n/<language>.yaml. Which method should be preferred?

You don't translate any YAML file, only translate PO files.

In T14731#284105, @tysontan wrote:

Since zh_CN is the standard code for Simplified Chinese, I think it makes sense to do that. The same thing goes to en_US for en too.

In T14731#284074, @scottpetrovic wrote:

@phunh - If you think these tools or modules can be helpful, we can add it back in and see how it goes. I mostly would ask that you would update the readme with the new dependency so people will know how to get the build working. I like to say what it is, and where to get it.

In T14731#284093, @alvinhochun wrote:

Then I have some questions regarding i18n:

• The extracted krita-org.po seems to contain various strings from config.yaml and i18n/en.yaml, but I see that these strings can also be translated in config.yaml directly or with i18n/<language>.yaml. Which method should be preferred?

You don't translate any YAML file, only translate PO files.

• I see all text of most pages are lumped into several .po files. I don't know the typical translation workflow of other websites, but this seems a bit scary to me. (I guess I expected one .po file per page or post?) When we make long posts wouldn't that bloat the .po files? What are the risks of mistranslations from the same strings used in different context?

Yes PO files might get big but I don't see any problem with that (so far, for various Hugo websites of ours). The risks of mistranslations, I can also say, are minimal as this website is for promo, not documentation or anything technical which I consider to be more probable to have same strings used in different contexts. In case some occur, there might be some technical difficulties in implementing context support in hugo-i18n, but I think we can work around that if it's necessary.

• If I need custom text or layout for certain pages or posts in my language, I can put the custom translated markdown file in, say, content/zh-tw to bypass the .po i18n system, right?

If your markdown file is not i12ized (internationalized) (i.e. not included in the i18n section of the config file), then yes. Otherwise, currently, no, it will be overwritten by what hugo-i18n can get from KDE l10n system.