Yes, this works. We handle patches in invent.kde.org these days, that makes it easier to merge things. Do you have commit access yourself?

Oh, that would be great!

@rempt Ping?

The other blender repo is responsible for the entire blender unified styling. I don't use it anymore and I generated the pure HTML templates in /templates and use the CSS from krita.org directly.

I see that fund-krita-org also pulls in one other blender repo, websrc/blender-web-assets -- I guess we should clone or integrate that on fund-krita-org, right?

Dmitry stepped in and made following commits:
f62910b0
a5d92c04
f88c8b35
dcae8c78
regarding the transform tool crashes and asserts.

For the last one, which I'm in favour now because it seems to be working well and it does make sense (although I still believe something should cancel the stroke nicely...), I made some notes in the snippet. I thought it would be good to repeat them here. (https://invent.kde.org/snippets/659)

Transform Tool, possible partial solutions (partial as in: will prevent crashing, but they're ugly and may have other issues):

@mwein Wow! Thanks! I totally forgot about this bug; I know I knew about it but... and it makes sense with reopening too, since then Krita will just check the global selection mask and see there is nothing there.
Although one person said that when it happens, all other old files are affected. It doesn't fit this description.
I guess I can try to cherry-pick relevant commits (one for the fix and one for the fix to the fix :P ) you mentioned and see what happens next.

Hm the "cannot draw" bug 415086 sounds a lot like this bug:
https://bugs.kde.org/show_bug.cgi?id=412808

Bug 414572 - I cannot reproduce it. (zoom works butterly smooth on my Yoga on Linux).
Bug 414672 - I believe it's already fixed.
Bug 415932 - can be reproduced using h)_Chalk_Soft brush.
Bug 415891 - I cannot reproduce it.
Bug 415086 - no known steps to reproduce.
Bug 415773 - I cannot reproduce it; I believe it is related to bug 414572 which I cannot reproduce either.
Bug 415213 - probably fixed already; I'm gonna wait one day and ask them to try Krita Plus version.

Regarding unnamed autosaves and saving in Temp directory: https://bugs.kde.org/show_bug.cgi?id=415810 (fixed)

This looks like the broken onion skin changes:

Yes, that's exactly what I saw, too.

One of the reasons I believe it's not an user error is that they tell me Select -> Deselect is greyed out, and when I tell them to do Select -> Select All, and then Select -> Deselect, it fixes the issue. It shouldn't work because either there is a selection and you can easily deselect it, or there is no selection and deselection won't change anything. And it happened enough times that I can see a pattern. The only problem is that I cannot reproduce it, and I can't even be sure if all cases when I thought it was this what happened it was the same issue all the time or not...

For that bug, I've seen it happen, too. I could fix it for that user by showing the global selection mask and deleting that. There was something really screwed up in that file.

Ahh I made a mistake with the bug number... what I meant was this: https://bugs.kde.org/show_bug.cgi?id=415086 it has my comments and I wanted it on this list for a reason, and the reason is that it must be related to input/focus issues, not user errors and I have reasons to think that, and I believe I stated those reasons in the comments.

I removed

415891 gets into a infinite wait trying to process al events that never cease to occur. its different than the loop the other bug is. I don't know why it happens but I can at least get out of the waiting and get the file to load.

You could probably make them a duplicate only if you knew one patch will solve both and then add a comment to the main bug report that there are other issues as well (Fill layers, File layers, Group layers).

that is probably the case. im debugging 415891 now. Ill let you know what I find

Yeah, a random empty file also has an annotations folder. The problem in bug 414818 is that Krita gets in a loop on the Colorize Mask because of Dmitry's changes to assigning color space to layers. Annotations directory contains color profiles (and possibly some other metadata; here there is icc and proofing/icc, in the empty file I've got only icc), so I guess it might be that removing it will help loading the file since some other path is used, I guess just assigning a default color space instead of reading, maybe somehow it skips the infinite loop. The file in bug 41891 however doesn't have any Colorize Masks, only Group layers, File layers and Fill layers. It might be related of course; maybe there is the same reason. But they're not duplicates since the second one doesn't have Colorize Mask that would cause the trouble.

415891 is a duplicate of 414818, the file attached has an annotations folder

Thank you for the patch, it works on Galaxy Tab S4 as well.

Compiled an x86_64 build and tested on ChromeOS 76 (ARC) on a Surface Go w/ pen,

I have briefly tested Krita on Galaxy Tab S6 (current git build with dependencies from the binary factory; I have disabled finger painting in the settings). Observations so far:

• The S-Pen draws fine even without the stabilizer. Pressure sensitivity works, tilt does not (I'm not sure about the hardware/software support of tilt for the device, though in Autodesk Sketchbook some brushes react to angle of the pen).
• Sometimes the pen stops drawing (it seems to be resolved with merge request 196, but I need more testing to confirm that).
• Sometimes the UI does not respond to the pen, only to touch (or maybe it is just too slow with the pen).
• I haven't find a way to access context menus (e.g. in layers or brush presets dockers).
• Upon creating new document nothing happens. After changing the device orientation, the UI redraws and the document shows up.
• The native title and navigation bars take too much space on the screen. Maybe we would be able to plug the main menu into a button in the toolbar and run Krita always on fullscreen and save space.
• For the popup palette (and possibly other actions), we might consider three-finger touch gestures/swipes.

Yes, please. Sorry for the delay, I'm on vacation, actually. Also, we use gitlab for patches these days: invent.kde.org/krita

I would really like Krita to have also a way to reach the Krita crash log as well and maybe even a little function "install debug package". Crash logs are extremely useful and considering we're dealing with people that are not exactly technically knowledgeable, it would be useful do make sure that everything that now requires them to go through their file system and doesn't need to, is put in GUI as well.

Just a reminder since it's easy to forget it exists: Holding ctrl+alt+shift when Krita is starting up will ask the user if they wish to clear Krita's settings file. This feature was originally implemented to help reset a config file that causes Krita to crash. The function responsible for this is KisApplication::askClearConfig() and KisApplication::clearConfig(). The caveat is that the functions have to be called before the config has been loaded.

shall i rebase ?

Looks good to me, :)

I wonder where this should be? I feel like this is common enough that we should make it really easy to find off the main menu...and not in the "configure krita" dialog.

The preview functionality mentioned seems similar to the -experimental- functionality I coded for the Clone Brush (DuplicateOp), which can be seen in this video.

Okay :-)

In T11969#208754, @dkazakov wrote:

I guess it would be a good idea to check how QModelIndex and QPersistentModelIndex are implemented. Perhaps we could just copy their idea? I have a feeling as if QModelIndex just stores a pointer to the item, and QPersistentModelIndex uses some safer design :)

In T11969#208755, @dkazakov wrote:

The main idea of "reactive programming" and "functional programming" is that we don't use any pointers at all :) We can use them internally, like @tusooaw replied above, but all the "user-level" code works with "immutable" (?) copies of the objects. I'm not sure how applicable it is to Krita, but the general idea is: "don't use pointers at all" :)

Firstly, thanks for the video, I'll check it :)

You are quite right. Most of the tools don't need any pointer/id for the shapes. They can live with quite high-level finctions, like "get shape under cursor" or "get a vector of selected shapes".

In T11969#208565, @eoinoneill wrote:

As for the forest idea, wouldn't it also be possible to use something like a unique pointer so that nodes can be checked out of the forest as a weak pointer? I think that the biggest problem is that data-ownership is currently a bit unclear which is why cloning and duplication can lead to memory problems (having said that, I'm not as experienced with the Krita code base yet.) I at least think that would be a better fallback than using KisNodeSP.

@dkazakov These are interesting points and I'm interested in hearing more of your thoughts on implementing these ideas in future updates.

How to locate shapes/items in the Forest seems to be a problem since we currently do not have a way to identify them without pointers.

In T11969#207387, @tusooaw wrote:

This is very interesting.

Blender fund use a simple CMS system to manage the content. The fixtures to generate the initial content is located at:
https://invent.kde.org/carlschwan/krita-dev-fund/blob/master/blender_fund_main/fixtures/wagtail.json

The work concerning KDE Identity is tracked in T8449. I already contacted the blender devs some time ago for license clarification and possible upstream of some features (2fa, multiple emails address support), but I didn't have the time until recently to work more on it (moving all the KDE website to php7 and some problems in the mediaWiki instances).

@ognarb - thanks for starting to look into this. This could work out pretty well. It sounds like the KDE identity work is still in flux a bit, so maybe this blender ID mechanism is something that could replace the old system.

I'm doing some using blender id as a replacement for KDE identity. This would allow to get a krita fund based on blender fund 'very easily'.

Solved AppImage issue in Steam's runtime environment running through a small launcher script that unsets the LD_LIBRARY_PATH envinronment variable.

Two things:

Thanks!

Points 1 and 2 are now in the contributor's manual. Point 3 will reincarnate in later documentation efforts.

Hey @rbreu, sorry for the delay.

Need to solve an issue where AppImages are not working properly when run through Steam for some users. In contact with Steam support.

Note: OpenEXR 2.4.0 is out with some security updates, so I think we really want to update to that release. See https://github.com/openexr/openexr/releases

I'll merge this in a bit :)

I think the ui layout is fine by the way. Im just daydreaming about stuff i do elsywre. Tho a command box "at the bottom" might interest the kat folks or KDE linux folks.

When I paint over the edge, some folks expect me too. Making me do that in reality in a paint app, kicks ps ass if you can do it live.
Just paint on/ver the screen "mode". It's like 3d painting. It is not a mesh it is a curve.

Some of the folks don't understand parametrics and scaling yet... that is ok.

@rempt I mean the opening 'canvas' is the perfect size to paint on within this window.(us as we) ... errrm I mean learn with.
I hope you understand...