This looks slightly nicer on very pixel-dense screens (scale factors 5 and up) than nearest neighbour fractional upscaling does.
Also fix window icon disappearing at times and the window being resized after configuration changes.
We should maybe start preserving window size also at some point, the way we do position now.
Namely when the main window is resizeable and its size isn't the same as it would be with the active scale mode with resizing disabled.
Also fix window position not being restored when the main window is resizeable.
By zero-initializing pointers in OptionsView so they don't crash when they don't get initialized, which up until very recently they always had. In the cases of the emscripten and android ports, certain components are never created.
Another rat's nest; I'm still not entirely satisfied.
This introduces "frame personalities": one for embedded frames (emscripten), one for handheld devices and everything else that doesn't really work with windows (android), and one for everything else. For now these affect which frame options are configurable by the user and what values they are forced to take if they are not configurable, and whether optimal scale is guessed based on screen size.
Also introduce a future TouchUI config node to allow switching between normal and touch-optimized UI on android. Again, because chromebooks and other android devices with mouse and keyboard support are a thing.
Also enable debugging of debug builds of android. It took me hours to attach a stupid debugger to the process; see:
- https://www.sh-zam.com/2019/05/debugging-krita-on-android.html
- https://source.android.com/docs/core/tests/debug/gdb#app-startup
I also had to adb forward the port that lldb was supposedly talking to lldb-server over because otherwise it wouldn't attach; I don't get it either.
That is, if the PROP tool is active and is configured correctly, instead of sampling a type and activating the corresponding ElementTool, sample whichever property has been configured in the PROP tool and put the result back into the PROP tool.
The problem is that Engine outlives GameController and thus also LuaScriptInterface. The solution is to not try to access LSI's lua_State if it doesn't exist; this is the case in Engine's dtor.
This is ugly as hell and the root of the problem is the cursed ownership model of LuaComponents and Windows by Engine, which I don't think I'll be fixing any time soon.
This was because brushes are not in an initialized state by default, SetRadius needs to be called on them before they can be used. This is ensured elsewhere but had not been ensured on this code path.
This is hilariously bad design and needs to be fixed sometime.
By refusing to exit unless the property being set is correct, rather than throwing an error when it's not and exiting anyway. It's still possible to cancel changing the current setting by exiting with Esc.
Notable changes:
- tpt.{input,throw_error,message_box,confirm} have been superseded by ui.begin{Input,ThrowError,MessageBox,Confirm}, each with an extra callback argument and no blocking behaviour, but otherwise the same semantics as their predecessors.
- The "script not responding" error doesn't wait for user confirmation anymore, it fires without asking. Future exercise: maybe let the user configure the timeout.
- Remove the confirmPrompt argument of tpt.getscript; this also means it unconditionally fails if the destination file exists.
Both Save and Load were recently migrated to block coordinates, see 7ef02a6c0b. The expected behaviour for Save is to extend the particle-oriented rect it gets to the smallest enclosing block-oriented rect and save all blocks inside that rect, but exclude the particles that fall outside the original rect. Using block coordinates made this exclusion impossible.
