From time to time the app::BackupObserver::backgroundThread() will use
ui::execute_from_ui_thread() to show/hide the backup notification icon
in the StatusBar (see SwitchBackupIcon class). This
ui::execute_from_ui_thread() function enqueues a ui::FunctionMessage
calling the Manager::enqueueMessage(). The issue here is that
enqueueMessage() uses ui::is_ui_thread() to check if the thread that
wants to enqueue the message is the UI thread or other thread, and
depending on this decission the message will be directly added to
msg_queue or enqueued into concurrent_msg_queue.
The issue was that ui::is_ui_thread() was not working correctly on
Windows because GetCurrentThread() is not useful to check the current
thread with a previous call of GetCurrentThread() from other
thread (the function always return the same value, a special generic
value that identifies the current thread whatever it is).
This change also avoids three scroll events when we zoom in/out, so
there are no two extra scroll events with invalid mouse position <->
editor position conversions.
This simplifies the code about timers: we can use a std::vector
instead of a obs::safe_list, and use ui::execute_from_ui_thread() to
avoid using mutexes, etc.
When a menu item is clicked a kExecuteMenuItemMessage is enqueued, so
the msg_queue will not be empty until we exit the menu item
callback (MenuItem::onClick()). This will prevent us to use a
os::Event::getEvent() where we can wait the OS for the event (see that
Manager::generateMessagesFromOSEvents() checks that msg_queue must be
empty to block the thread for OS events).
In some cases we have to enable the DIRTY flag in the hierarchy.
Reproducible case: right-click a tab with an image, open in a folder,
then right-click the tab again.
Fixed regression introduced in d20436f957.
Now overlays are kept on the screen and the overlapped area is restored
just in time when we have to re-paint some widget on that area.
There were two problems:
1) Overlays weren't using the screen color space, so restoring the
pixels were modifying the original saved area
2) A custom cursor (when "Use native cursors" option were enabled) was
using overlays, when we could use a native custom cursor
anyway (without overlays)
With this change we will reduce the CPU and energy consumption levels
as now we can go to sleep when there is no OS messages left and no
timers running.
When we're moving or resizing a window, sending several
kWinMoveMessage doesn't make sense. So we discard all kWinMoveMessage
and re-enqueue a new one with the latest window bounds.
With this change we've moved the propagateToChildren/propagateToParent
flags from ui::KeyMessage to ui::Message so anykind of
message (e.g. user defined messages like kSavePreferencesMessage) can
use these flags (processed by ui::Widget::onProcessMessage()).
This is related to #1100, as the Linux port is not well tested and may
fail, it's good to have an option to disable the native clipboard code
just in case.
This is a weird combination of things:
1. StatusBar::onPixelFormatChanged() is being called in a non-UI thread
because ChangePixelFormatCommand changes the color mode from a
Job (background thread).
2. The UI layer is not prepared to work on multithreading, so all UI
stuff should be used in the main UI thread (anyway, generally, the UI
layer doesn't crash if it's used by multiple threads).
3. The harfbuzz library (used for TTF fonts) crashes if it is used by
multiple threads, so that was the trigger of this crash.
If a text field (ui::Entry) contains text with length=1 (e.g. the number
"8"), and we focus and press that same char ("8"), the caret will be in
the position 0 with text "8" (the caret should be in position 1). this
patch fix this behavior.
If we pressed the mouse button in the toolbar and start moving the mouse
like crazy just to create/destroy the toolbar popup multiple times, it
reached a situation where the Manager's mouse_widget was equal to a
deleted widget (and mouse_widgets_list contained that widget too),
producing a crash when we tried to access it.
* This implements the Cmd+H and Cmd+M keys too:
https://community.aseprite.org/t/279
* Also Cmd+, has more priority on macOS than Cmd+K to open the
preferences (so macOS menu shows Cmd+,)
