- User Since
- Apr 15 2015, 8:03 AM (191 w, 21 h)
Thu, Dec 6
Wed, Dec 5
Wed, Nov 21
1.) It's still working for me! Could you double-check your dedicated Color Picker Tool Options?
Yes, this problem was something local in the configs. I've reset the configs and the ctrl+click started to work as before.
1-5. I think this is a normal behavior. If you save a dirty preset, you save edited option as new preset so, you can not see the dirty flag when you re-select it.
Nov 12 2018
I have tested your patch very briefly. It looks fine :) Here are the notes:
It still doesn't update the preset (and doesn't save the color) if the color selector is changed.
Nov 6 2018
There is some weird problem with the way how this feature interacts with "Save temporary tweaks to brush presets" feature. Please see the attached video:
Nov 5 2018
The patch works almost fine, but there are a few little things that should be fixed before pushing it:
Nov 1 2018
Sorry for the delay, I still plan to test this patch, but I'm a bit busy with family problems right now. I'll try to finally check the patch by the end of the week.
Oct 31 2018
Work in progress patches on adding Float16 surface support to Qt's angle. The patch does not work atm. I'm saving it here just show the basic idea:
Oct 26 2018
Oct 25 2018
The initial idea of implementing KisDisplayColorConverter was to avoid other classes depending on big fat KisCanvas class. Why exactly this dependency was needed?
The icons are connected now :)
I have a feeling that all the global color selectors should be somehow linked to the "fixed color" of the brush. E.g. when one changes the brush to the one with fixed color, the color in all the global selectors should become synced. And when the user changes this color, then the "fixed color" should be adjusted in the preset.
Oct 15 2018
I think the sender() problem is the only thing that blocks the patch. Please refactor it to use KisSignalsBlocker and push :)
That's a good catch, thank you for the patch! I'll push it now! :)
Oct 13 2018
Looks correct. There is still one small regression: the frame selection is reset after stopping the playback if one changed speed or FPS durng the playback at least once. But this problem can be fixed later on.
Oct 12 2018
The patch basically works. The sender() thing (see inline) is actually the only serious blocker I see.
There is still the same bug in the patch. I found at least one reason for that: you changed the meaning of 'normalizedPlaybackTime'. Previously it was normalized by the "expected frame update period" and now your implementation normalizes it by the total animation time. And the problem is that your new implementation doesn't take "playback speed" into account (previously, the speed was already taken int account in the update period). Therefore every change of the playback speed drives the code crazy.
Oct 11 2018
Oct 10 2018
The patch looks fine! Please write me you email to dimula73 "at" gmail.com, so I could push your patch under your full name!
The patch looks fine! I don't know how it worked before... perhaps Qt did it somehow internally :)
Anyway, the patch doesn't break anything on Linux, so let's just push it.
The patch looks perfectly fine! Please push! :)
There is still one small regression: when changing the playback speed or fps right during playback using mouse wheel there is a weird hiccup in the playback. Basically, it stops playing for a couple of seconds. Without the patch it works smoothly, just changes the speed of the clip smoothly :(
Oct 9 2018
The patch looks fine, please push! :)
Oct 8 2018
The patch resurrects the original this condition fixes: pressing Ctrl+E on a Group Layer with Inherit Alpha option now makes it fully transparent :(
A nice presentation on HDR on Linux:
Here is a newer presentation from NVidia:
Oct 7 2018
My display size is 1366x768px. And it basically fits, but it adds a very tiny scroll bar at the brush settings area:
List of unaffected widgets:
Thank you for the patch! It looks perfectly correct, please push! :)
I've found two small issues:
Looks correct! Please push! :)
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.
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...
Thank you for the patch! Please push! :)
Oct 3 2018
It looks like this patch fixes the problem, could you check?