Thanks, @tymond. If it's ok with you, I will summarize all the ideas for static analysis, both yours and mine, into a more concrete proposal that we then can refine together and implement.
Mon, Jan 20
Thu, Jan 9
Hi, @rbreu, thanks for joining in!
Tue, Jan 7
I'm adding an idea from @tymond: in preparation for the beta survey, developers would list of things that they changed and possible reasons it could break. This would give the beta testers ideas of where to focus while testing.
Another thing to look into: the 'Saving issues', https://phabricator.kde.org/T11194 (there are several issues mentioned, I think some of them are solved and other in progress)
Mon, Jan 6
Merged into documentation (https://invent.kde.org/websites/docs-krita-org/merge_requests/85).
Sun, Jan 5
Fri, Jan 3
Wed, Jan 1
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).
- The UI does not respond to the pen, only to touch.
- 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.
Nov 8 2019
Oct 26 2019
Oct 22 2019
May I close this as resolved? From what I have seen, the beta testing is quite successful so far and I'm not aware of something missing implementation-wise.
Oct 21 2019
Points 1 and 2 are now in the contributor's manual. Point 3 will reincarnate in later documentation efforts.
Oct 20 2019
Oct 15 2019
Oct 7 2019
Sep 26 2019
Sep 23 2019
Sep 22 2019
I’m trying out a prototype in which I have decoupled the development build alert and new version notifications:
- When appimage updater is in use, there are also updates for dev builds. The area next to Start header is too crowded then.
- It makes more sense to me if the updater notification is under the “Check for updates” checkbox, not on the other side of the window.
Sep 21 2019
Sep 18 2019
Sep 17 2019
Sep 15 2019
Sep 14 2019
What does the link do after it is done updating. The "To complete the update, run the new version". Does that restart Krita?
Sep 13 2019
Current progress (still on localhost; the size of the appimage is not final, it's just my debug build). The core of the check and update process is done. I am not sure what to do with the UI part and reporting errors to users. I have added the update button and placeholder messages to the original area in the Start section, but it feels crowded and overall weird to me. Errors are logged to the usage log but not propagated to the user interface right now (apart from 'Error occurred' message). @scottpetrovic, may I ask you for a bit of your time to look at it with me?
Sep 11 2019
Sep 7 2019
Aug 29 2019
Aug 23 2019
It looks great :)
Aug 21 2019
I think we should start with a short description of the survey, what is expected of the participants and point to our reporting bugs docs page, should the participant encounter a bug while testing.
Aug 16 2019
Aug 15 2019
I have drafted a more detailed analysis, based on the ideas discussed in this task. The high level outline is there, but a lot of important detail is missing.
Aug 3 2019
I have converted points 1 and 2 into manual pages, draft here: https://invent.kde.org/websites/docs-krita-org/merge_requests/59
Okay, that mail didn't work. I thought we might just put the survery link in the krita welcome page; that way people have to at least start the right version to do the survey.
Monthly development news is a good idea. I'm not sure that it will work for getting people to test, or that it will cover all the features. I thought that making it one feature/change at a time (we should hand pick the right one though) would make it seem more easy and quick and thus attract more testers.
Concerning the surveys themselves, can we use https://survey.kde.org/?
Jul 29 2019
Jul 15 2019
Jul 13 2019
Jul 12 2019
Jul 11 2019
I do not understand how it is possible to not get any warning anymore when saving fails in the ordinary way, because we now explicitly check whether there is a readable file in the destination location.
Jul 8 2019
Related bug report - a race condition in the saving process leading to missing files: https://bugs.kde.org/show_bug.cgi?id=409395, work in progress fix: https://invent.kde.org/kde/krita/merge_requests/59
Jun 14 2019
Jun 10 2019
Jun 5 2019
Jun 4 2019
May 20 2019
May 15 2019
Apr 28 2019
@scottpetrovic I think both your approach and mine are compatible. I suggest having two separate sections, for now let’s call them “Help most needed” and “Special interest groups”.
Apr 26 2019
While working on plans for QA and looking into the contributor’s manual I arrived at an idea which relates to this effort, maybe from a bit different angle.
Apr 21 2019
Apr 7 2019
Apr 6 2019
Apr 4 2019
Mar 23 2019
Mar 22 2019
Mar 18 2019
- KisMirrorManager: store decoration() pointer in local variable
The patch looks fine, please push it!
I understand that my inline comment might be considered as a "matter of taste", so it is not obligatory :)
Mar 15 2019
Mar 12 2019
Instead of a separate docker, I propose to add the brush texture controls to the existing Patterns docker (and maybe also to Patterns popup in the toolbar).