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).
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).
Fixed regression introduced in d20436f9570302e20484b51435276dc9bad94009.
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.
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.
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 is an old bug that makes the UI looks as "partially painted." We
have to process all logic messages first, and then generate paint
messages so we paint the latest UI state (instead of a intermediate
UI state).
There were some crash reports in these days on the focus movement
code. It looks like we could arrive into an invalid/strange UI state
double-clicking palette buttons and showing menus two consecutive
times. After that, pressing Tab key would crash the focus-movement
logic.
Added a new flag in messages to know if they came from a filter or from
the original chain of recipients. To do this, we've added a new way to
process message filters: instead of pre-adding filters to the list of
message recipients, we process filters in the Manager::pumpQueue()
member function itself. (So the list of "recipients" is not modified.)
This change adds support to write text with dead keys, and assign
keyboard shortcuts to special key combinations with Unicode characters
on macOS and Windows.
Fix#1083, close#796
