KritaProject
ActivePublic

Details

Description

This is the primary project for upcoming Krita projects and versions.
New features leading to the next major release and wishlist items go here.

Flow of a feature:

  1. First goes into Krita: Abyss
    1. Here artists with ideas can leave their idea(but do notify us first).
  2. Then someone who is interested, will take this task(assign it to themselves). (You absolutely need to be commited to making the feature work)
  3. It will be moved to Krita: Next Features
    1. Figure out usecases(idea gathering)
    2. Consolidation of ideas.
    3. First architecture is designed.
    4. Make gui.
    5. Make the feature... feature complete..
    6. get approved for merge.
  4. If feature is implemented, merged, and there has been a mail to the mailing list(!Important!)
  5. Assign Krita: Manual and krita testing. (So that it can be documented, and get a test-by-fire)
  6. When those are done. Move to Krita next releases, where it'll be put into a 'make noise' column.
  7. Final resting place in column of release that it was in.

Discussion and GUI design of the upcoming features

Please use this dashboard for quick access to all discussion and testing tasks:
https://phabricator.kde.org/dashboard/view/25/

(You can also access the same tasks from the big Krita: Next Features board itself)

Release process:

The process of making a release (building packages and making announcements) is managed in Krita Current (3.1.2) board.

To get more information, see a special dashboard:
https://phabricator.kde.org/dashboard/view/24/
(all the "Tasks" panels are linked to the corresponding columns of the board)

Other boards:

Source: T3541

Recent Activity

Tue, Mar 12

vanyossi added a comment to T17188: Proposal for changing the way how we link internal Krita libraries together.
  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.
Tue, Mar 12, 7:55 AM · Krita

Wed, Mar 6

dkazakov added a comment to T17188: Proposal for changing the way how we link internal Krita libraries together.

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.

Wed, Mar 6, 3:07 PM · Krita
rempt added a comment to T17188: Proposal for changing the way how we link internal Krita libraries together.
  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
Wed, Mar 6, 10:56 AM · Krita
dkazakov created T17188: Proposal for changing the way how we link internal Krita libraries together.
Wed, Mar 6, 10:02 AM · Krita

Tue, Mar 5

havocado added a watcher for Krita: havocado.
Tue, Mar 5, 9:40 PM

Nov 29 2023

dkazakov added a comment to T16346: Krita dependencies management issues.

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

Nov 29 2023, 2:34 PM · Krita

Nov 26 2023

dkazakov added a comment to T16469: Windows CI roadmap.

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:

Nov 26 2023, 5:49 PM · Krita

Nov 20 2023

dkazakov updated the task description for T17019: Benchmark variety of GPUs for the support of host-memory access.
Nov 20 2023, 3:43 PM · Krita
dkazakov created T17019: Benchmark variety of GPUs for the support of host-memory access.
Nov 20 2023, 3:39 PM · Krita

Nov 6 2023

paulb updated the task description for T16983: Optimise Krita's PeerTube account.
Nov 6 2023, 8:01 AM · Krita, KDE Promo

Nov 2 2023

paulb updated the task description for T16983: Optimise Krita's PeerTube account.
Nov 2 2023, 9:47 PM · Krita, KDE Promo
rempt added a comment to T16983: Optimise Krita's PeerTube account.

Following done!

Nov 2 2023, 9:46 PM · Krita, KDE Promo
paulb created T16983: Optimise Krita's PeerTube account.
Nov 2 2023, 9:29 PM · Krita, KDE Promo

Oct 2 2023

dkazakov added a comment to T16430: Ideas about the cmake-based deps build system.

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

Oct 2 2023, 3:53 PM · Krita

Sep 25 2023

woltherav added a comment to T16862: Requirements for dependent shapes framework.

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.
Sep 25 2023, 8:46 AM · Krita
dkazakov added a comment to T16862: Requirements for dependent shapes framework.

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

Sep 25 2023, 7:58 AM · Krita

Sep 20 2023

woltherav added a comment to T16862: Requirements for dependent shapes framework.

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?
Sep 20 2023, 2:34 PM · Krita

Sep 18 2023

dkazakov created T16906: Draft for modernize proposal policies.
Sep 18 2023, 9:28 AM · Krita

Aug 31 2023

dkazakov added a comment to T16862: Requirements for dependent shapes framework.

Btw, a new set of weird technical questions:

Aug 31 2023, 9:59 AM · Krita
dkazakov added a comment to T16862: Requirements for dependent shapes framework.

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

Aug 31 2023, 9:46 AM · Krita

Aug 30 2023

alvinhochun added a comment to T16862: Requirements for dependent shapes framework.

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

Aug 30 2023, 7:21 PM · Krita
alvinhochun updated the task description for T16862: Requirements for dependent shapes framework.
Aug 30 2023, 7:06 PM · Krita
woltherav added a comment to T16862: Requirements for dependent shapes framework.

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.

Aug 30 2023, 3:42 PM · Krita

Aug 29 2023

dkazakov added a comment to T16862: Requirements for dependent shapes framework.

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)

Aug 29 2023, 7:55 AM · Krita
dkazakov updated the task description for T16862: Requirements for dependent shapes framework.
Aug 29 2023, 7:53 AM · Krita

Aug 28 2023

kamathraghavendra added a comment to T16862: Requirements for dependent shapes framework.

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

Aug 28 2023, 2:31 PM · Krita
dkazakov created T16862: Requirements for dependent shapes framework.
Aug 28 2023, 12:43 PM · Krita

Aug 14 2023

dkazakov updated the task description for T16814: Notes on AppImage build tools to linuxdeploy.
Aug 14 2023, 3:05 PM · Krita
dkazakov created T16814: Notes on AppImage build tools to linuxdeploy.
Aug 14 2023, 3:04 PM · Krita

Aug 7 2023

dkazakov added a comment to T16430: Ideas about the cmake-based deps build system.

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.

Aug 7 2023, 3:55 PM · Krita

Jul 13 2023

rfool removed a watcher for Krita: rfool.
Jul 13 2023, 1:07 AM
rfool added a watcher for Krita: rfool.
Jul 13 2023, 1:07 AM

Jun 22 2023

dkazakov added a comment to T16430: Ideas about the cmake-based deps build system.

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...

Jun 22 2023, 11:23 AM · Krita
rempt added a comment to T16430: Ideas about the cmake-based deps build system.

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

Jun 22 2023, 7:56 AM · Krita

Jun 21 2023

dkazakov added a comment to T16430: Ideas about the cmake-based deps build system.

Just a note:

Jun 21 2023, 8:01 AM · Krita

Jun 15 2023

bcooksley added a comment to T16469: Windows CI roadmap.

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.

Jun 15 2023, 7:28 PM · Krita

Jun 14 2023

dkazakov added a comment to T16469: Windows CI roadmap.

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

Jun 14 2023, 12:12 PM · Krita
bcooksley added a comment to T16469: Windows CI roadmap.

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.
Jun 14 2023, 11:30 AM · Krita
dkazakov added a comment to T16469: Windows CI roadmap.

Thank you for your replies!

Jun 14 2023, 10:11 AM · Krita
bcooksley added a comment to T16469: Windows CI roadmap.

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/
Jun 14 2023, 9:36 AM · Krita

Jun 13 2023

dkazakov created T16469: Windows CI roadmap.
Jun 13 2023, 12:19 PM · Krita

Jun 5 2023

dkazakov added a comment to T16449: Krita Color Management strategies after compositors getting color management compatibilities.

Weston's ICC -> GPU implementation:

Jun 5 2023, 1:29 PM · Krita

Jun 1 2023

woltherav added a comment to T16449: Krita Color Management strategies after compositors getting color management compatibilities.

Windows questions:

Jun 1 2023, 3:29 PM · Krita
dkazakov created T16449: Krita Color Management strategies after compositors getting color management compatibilities.
Jun 1 2023, 3:02 PM · Krita

May 31 2023

dkazakov added a comment to T16430: Ideas about the cmake-based deps build system.

Oh, another manual needed:

May 31 2023, 7:07 AM · Krita

May 30 2023

rempt added a comment to T16430: Ideas about the cmake-based deps build system.

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.

May 30 2023, 6:11 PM · Krita
dkazakov added a comment to T16430: Ideas about the cmake-based deps build system.

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.

May 30 2023, 11:48 AM · Krita
rempt added a comment to T16430: Ideas about the cmake-based deps build system.

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?

May 30 2023, 10:55 AM · Krita
dkazakov added a comment to T16430: Ideas about the cmake-based deps build system.

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.

May 30 2023, 9:01 AM · Krita
rempt added a comment to T16430: Ideas about the cmake-based deps build system.

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 30 2023, 7:46 AM · Krita