The broadway backend would move the focus from one window to another based on
where the mouse was (i.e. 'focus-follows-mouse' approach). Handling the focus
this wait didn't play well with widgets which rely on focus-in-event and
focus-out-event, like the GtkEntry when using a completion popup window, see
e.g:
https://bugzilla.gnome.org/show_bug.cgi?id=708984
So instead, setup broadway to require a click in a window to move the focus
(i.e. 'click-to-focus' approach):
* The implicit GDK_FOCUS_CHANGE events that were generated upon reception of
BROADWAY_EVENT_ENTER or BROADWAY_EVENT_LEAVE are removed.
* The broadway daemon will now keep track of which is the focused window
* Whenever the daemon detects an incoming BROADWAY_EVENT_BUTTON_PRESS, it will
trigger the focused window switch, which sends a new BROADWAY_EVENT_FOCUS to
the client, specifying which windows holds the focus.
* Upon reception of a BROADWAY_EVENT_FOCUS, the client will generate a new
GDK_FOCUS_CHANGE.
* gdk_broadway_window_focus() was also implemented, which now requests the
focus to the broadway server using a new BROADWAY_REQUEST_FOCUS_WINDOW.
This is based on an initial patch from Aleksander Morgado <aleksander@lanedo.com>.
If a motion event handler (or other handler running from the flush-events
phase of the frame clock) recursed the main loop then flushing wouldn't
complete until after the recursed main loop returned, and various aspects
of the state would get out of sync.
To fix this, change flushing of the event queue to simply mark events as
ready to flush, and let normal event delivery handle the rest.
https://bugzilla.gnome.org/show_bug.cgi?id=705176
Don't recurse the mainloop in _gtk_tree_view_column_start_drag().
It doesn't serve any discernible purpose, and recursing the
mainloop from the flush-events phas of the frame clock breaks
frame synchronization with mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=705176
If a queue_redraw() (invalidating a region, or the whole widget) was
called from the draw() call, it could get ignored if surface_dirty
existed, as it would then be updated, but destroyed right at the end of
the _gtk_pixel_cache_repaint(), leading the next call to
_gtk_pixel_cache_draw() have its call to repaint() be a no-op
(since there's no surface_dirty) and then simply draw from (non
updated) surface.
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
https://bugzilla.gnome.org/show_bug.cgi?id=711545
Arrange for the scales to control the speed of the activity
mode progress bar in gtk3-widget-factory. This will be useful
in demonstrating smoother progress bar animation in the future.
Add an application shortcut for the Music folder in testfilechooser.
The file chooser used to filter duplicates out, but this broke
in the sidebar merge.
currently it's using the same sizes for natural and minimum, but it
happens that, when it's allowed to use the arrow, the minimum size
can be smaller than natural.
https://bugzilla.gnome.org/show_bug.cgi?id=693227
Although I can't find explicit documentation for clipboard pointer, it
seems to be possible to modify clibpoard memory without side-effects.
According to MSDN,
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366596%28v=vs.85%29.aspx
"The global and local functions are supported for porting from 16-bit
code, or for maintaining source code compatibility with 16-bit
Windows. Starting with 32-bit Windows, the global and local functions
are implemented as wrapper functions that call the corresponding heap
functions using a handle to the process's default heap."
"Memory objects allocated by GlobalAlloc and LocalAlloc are in private,
committed pages with read/write access that cannot be accessed by other
processes. Memory allocated by using GlobalAlloc with GMEM_DDESHARE is
not actually shared globally as it is in 16-bit Windows. This value has
no effect and is available only for compatibility. "
https://bugzilla.gnome.org/show_bug.cgi?id=711553
Setting event compression to false will allow inter-frame
mouse motion events to be delivered, which are necessary
for painting applications to produce smooth strokes.
https://bugzilla.gnome.org/show_bug.cgi?id=702392
This is based on the rolling hashes code from
http://cgit.freedesktop.org/~krh/weston/log/?h=remote
It works by incrementally calculating hashes for every 32x32 block
in each frame sent, and then refering back to such blocks when
encoding the next frame. This means we detect when a block matches
an existing block in the previous frame in a different position.
This is great for detecting scrolling, which we need now that
the gdk level scrolling is neutered.
