Note, I finally managed to harmonize all toolbar buttons and icons sizes, yay! :-D
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Sep 24 2021
Mar 1 2021
Feb 28 2021
Link to the merge request for the first prototype:
Feb 17 2021
From IRC:
We seemed to have removed Karbon's gradients: https://invent.kde.org/graphics/krita/-/commit/91c359e1977a8c5ff5c6f5be1c5bd618baafc5f2
Feb 11 2021
Ok, so with the stop gradients icc-color merged, and with the HDR gradients patch merged, Krita can now do StopGradients in all the colorspaces it supports, including unbounded color gradients (So rec2020 12.0, 0.5, 0.5 is now possible).
Feb 10 2021
I finally gave up trying to set the size of all the buttons in KToolBar, there must be a way to do it but it's definitely beyond my very limited c++ skills...
I'll let someone more knowledgeable do it.
I'm personally OK with using standard sizes in other places ;)
Well, as I said on IRC I'm fine with making toolbar "an exception" and making all the widgets fixed size. But for other places in Krita, we would better use standard sizes.
To complete my previous comment, I would add that there are also several other component on the toolbar that have a defined size that looks best if all the buttons are 32x32:
-The Gradient button and the Patterns button (which are 32x32)
-The Foreground/Background colors widget (this one is 28x28, but looks good when components around are 32x32)
-The blending mode combobox, and the sliders (they have a fixed height of 32)
Thanks for the feedback :)
Though actually I would prefer to do the other way around, that is change KToolBar to use the same values as we have in the paintopbox, and in the paintopbox do both setFixedSize(32,32) and setIconSize(22,22). This looks much better I feel, as then the buttons are the same height as the combobox and as the sliders (else, with just setting the icon size, the buttons are a bit smaller than the sliders with fusion). But for this I need to dig more into KToolBar to see how to properly set the size of buttons, and the height of the toolbar itself (actually the height of the toolbar is adapted automatically, I was confused thinking it would not by setting its size by mistake in my tests...)
Okay, I have spent some time on investigating into the code. It looks like for the toolbar we need to use values from KToolBar. It has a complicated system for determining the icon size. I still don't know how to fetch this value. (I haven't checked actually).
While I agree that "technically" it would be nice to can use those QStyle values, in practice it doesn't seem very good...
I believe that in all the places where we use custom sizes (except of the few really custom widgets, like layers docker and onion skins widget), we should try to use values like style()->pixelMetric(QStyle::PM_ToolBarIconSize) instead. I didn't do any good research for it though. We used custom values because we were too lazy or didn't know about existence of QStyle-defined values. So I believe we can just replace them in most of the cases.
Feb 9 2021
I first made this proposal after noticing that we already define our own sizes for buttons in several places, and so thought that it could make sense to do it everywhere the same way to be more consistent.
We should probably not reuse Qt-provided constants
Feb 6 2021
Documented KPL (which was on my todo forever as well...)
Feb 5 2021
Feb 4 2021
Then I think we should do that.
Feb 3 2021
In T14093#249262, @rempt wrote:Could we just ignore the parts of the standards with weird colorspaces and refuse to load gradients that use those?
Could we just ignore the parts of the standards with weird colorspaces and refuse to load gradients that use those?
Feb 2 2021
Inkscape's way of handling lab and xyz is rather strange :/
Aug 31 2020
Possible solutions:
Jun 6 2020
May 26 2020
Thanks Tusooa for your hard and useful work. I think Snapshot docker is a good addition for complex images.
For your week 6 if you think this could be doable:
I used that in PS long time ago and i remember there was a feature that allowed you to paint from history. (history mean ,snapshot) It is only a note if you are going to work more in this feature with more options. Right now in my tests works pretty well. Again Thanks
May 22 2020
I did some tests just now regarding rotation in the brush texture:
May 21 2020
Allow KoPatterns to carry a QTransform, this is necessary here because svg patterns will have their own transforms, so we should load those in and use them as default values for pattern transforms.
Nov 9 2019
Oct 20 2019
Okay, having slept on it, and looking at the code again, Cairo is not doing a per pixel transformation, but rather is just passing on the matrix to... wherever, and I for the live of me cannot find the place where the transform is applied to the pixel. I do suspect the that per-pixel transform might be a strategy to pursue. (so, pixel to paint x, invert transform on x, what do we find in the original tiled pattern at that location, paint that at x), but I am not smart enough to understand how we'd apply transform filters here.
Oct 18 2019
https://gitlab.com/inkscape/inkscape/blob/32e9ba119663b9d5800392ba34700053eaaa7f90/src%2Fsp-pattern.cpp#L526 < inkscape's pattern implementation
Oct 10 2019
Aug 9 2019
In T10901#193043, @tusooaw wrote:https://invent.kde.org/tusooaw/krita/commit/24355db3272a02230a14217da6023a953ec8f119
The crash does not come from KisCanvas2 but KisNode actually, as I said that it happens only when the undo command is not created (so KisNode is deleted by KisNodeReplaceBasedStrokeStrategy::Private's destructor, which is executed in the image thread (by the destructor of KisStroke)).
Jul 26 2019
The crash does not come from KisCanvas2 but KisNode actually, as I said that it happens only when the undo command is not created (so KisNode is deleted by KisNodeReplaceBasedStrokeStrategy::Private's destructor, which is executed in the image thread (by the destructor of KisStroke)).
Jul 25 2019
In T10901#192951, @tusooaw wrote:On the crash upon deletion of stroke strategy without creating an undo command:
It happens only when (1) we are not using debugger (so it is probably some timing issue); (2) the mouse is released immediately after pressing; and (3) no undo command is created.
https://invent.kde.org/snippets/335 indicates that the problem probably lies in KisCanvas2, whose m_d->canvasUpdateCompressor is of type KisSignalCompressor instead of the thread-safe one.
But I did also get another error message complaining from QObject::~QObject().
On the crash upon deletion of stroke strategy without creating an undo command:
Jul 8 2019
A note on KisNode::copyFromNode():
Currently the methods return a KUndo2Command that will do the changes. However, it should be possible to make them only do the changes, by taking a clone of the active layer before making undoable changes to it.
Jun 28 2019
Refactor out q-pointers and derived d-pointers in Flake
Jun 21 2019
Jun 20 2019
In T10901#189466, @tusooaw wrote:Discussion on derived d-pointers.
About q-pointers.
Discussion on derived d-pointers.
Discussion on q-pointers.
Jun 18 2019
There is said to be delay when switching between snapshots if one uses OpenGL canvas.
May 29 2019
The branch for this task is at https://invent.kde.org/tusooaw/krita/commits/tusooaw/T10991-snapshot-docker (deleted after merging)
May 27 2019
Related branch:
May 17 2019
May 8 2019
Apr 29 2019
Apr 19 2019
Apr 6 2019
Apr 1 2019
Mar 28 2019
Mar 19 2019
Feb 20 2019
Feb 19 2019
ok, for the frames stuff, based on this reddit post:
https://www.reddit.com/r/krita/comments/arr8rw/memory_limit_reached_i_cant_save_my_frames/
Feb 18 2019
I like the colored bar, but I do think that having an icon with danger sign would also helpful.
Feb 17 2019
Regarding the bar, I was thinking something like this(though perhaps should go into red faster). The smaller lighter box at the start is the imagesize compared to the full colored box, which would be the total ram consumption(stats.totalMemorySize) vs total memory limit. Problem: Sometimes the imagesize(stats.imageSize) is larger than the total ram consumption(stats.totalMemorySize), and I don't know why, @dkazakov?
Feb 10 2019
I'm thinking we should have an icon that shows up at 50%, as the current one shows up at 87.5%. Furthermore, I remember an old presentation of this shooter game where they set the healthbar to start warning the player at 50%, because humans aren't very good at judging their resources, and they found players would manage their resource(health) much better when they were warned at 50%.
Jan 17 2019
Very good. Thank you for opening this topic. From a user perspective; I'll answer something basic and minimal: a yellow icon (maybe with a orange outline) appears on the bottom (near the memory usage) around 80% of max resources used. The icon might look like a button one can press: a pop-up display a small text explaining basic things about ram and proposing solution: reduce layer stack by merging, split large animation into scenes, etc...
Dec 2 2018
Oct 17 2018
@dkazakov I see that you've changed the code to use devicePixelRatioF. I can see that the canvas now attempts to render at 100% device pixel size.
Oct 10 2018
One more issue: The fix seems to have used the integer version of devicePixelRatio somewhere instead of the floating point devicePixelRatioF. This is from my observation forcing a 1.5x scaling on Windows. I haven't checked the code. Even though Qt now rounds the scale factor to nearest integer on Windows, we should assume that real fractional scaling support will be added in the future. In fact the then-in-progress task https://bugreports.qt.io/browse/QTBUG-53022 is exactly for this. (It might even be already supported on KDE, but I can't confirm.) So please fix it to use the floating point devicePixelRatio.
@dkazakov Thanks for the partial fix. I've done some testing on Windows with krita-nightly-x64-v4.1.3.1-239-ge64348e693, so here's my observations/findings:
Oct 7 2018
Oct 5 2018
In T2299#162926, @davidedmundson wrote:I'm not sure that it really happens this way.
Feel free to check.
This fixes one of the two issues that will make it less blurry https://phabricator.kde.org/P263
Oct 4 2018
Okay, it looks like Qt actually creates the double-sized frame buffer, but we still see it as a single-sized (and reset the viewport). We should just set the viewport to this doubled size.
In T2299#162926, @davidedmundson wrote:Feel free to check.
I'm not sure that it really happens this way.
In T2299#162907, @dkazakov wrote:Hi, @davidedmundson!
I have just tried to reproduce the problem again, and I do still reproduce it with Qt 5.9.1. I will try to search for exact lines in Qt's code, but I'm not sure I will manage to finish it today. Steps to reproduce:
- Set GUI scaling in windows to 150-200%
- Start Krita
- Go to Settings->General->Enable HiDPI support (it basically activates GUI scaling). Without this option, openGL canvas behaves exactly like you explain, that is, renders inRestart hardware pixels. But after activating this option, scaling starts.
- Restart Krita
- Create 500x200 image
- Activate "Use same aspect as pixels" box at the bottom-right corner of the window
- Press '1' to set 100% zoom
- BUG: See that the image has actually size of 1000x400 physical pixels. And Krita does not pass any extra scaling to openGL. It paints just in logical pixels.
In T2299#162908, @davidedmundson wrote:
Right, I think we just have some miscommunication rather than a code difference.
I have just tried to reproduce the problem again, and I do still reproduce it with Qt 5.9.1. I will try to search for exact lines in Qt's code, but I'm not sure I will manage to finish it today. Steps to reproduce:
Okya, I'll check it once again. But as far as I remember the scaling is activated when we enable "Scale GUI" option in Krita settings...
Dmitry, you did figure out once where this happened -- can you locate that again and add a link to the exact bit of source code to this task?
Oct 3 2018
Bumping this, because I just saw this comment about QOpenGLWidget by Boud on Reddit today.