Make the sunny example useful by giving it a header bar
with app menu fallback. To test this under gnome-shell,
set APP_MENU_FALLBACK=1 in the environment.
Allow showing the fallback app menu with a menu button
in the header bar. Applications have to explicitly enable
this by calling gtk_header_bar_set_show_fallback_app_menu.
GtkAboutDialog highlights emails written as <...> and
urls written as http://... . gnome-terminal manages to
put <http://...> into its license text, which sadly
confuses the parser into running evolution on http://...
Fix things up far enough that <http://...> is now
recognized as url, and only the part inside the <> is
underlined (for email addresses, we include the <> in
the underline).
Commit 719dd636a9 replaces
margin-left/right with margin-start/end. CSS does not have
margin-start/margin-end properties, the sed script was a bit overeager.
Fwiw, CSS implements RTL margin styling via :dir(rtl) selectors.
Add margin-{start,end} and gtk_widget_{get,set}_margin_{start,end}
and drop margin-{left,right} and gtk_widget_{get,set}_margin_{left,right}.
margin-{start,end} handle right also in RTL.
https://bugzilla.gnome.org/show_bug.cgi?id=710238
Add a GtkSetting for whether the desktop shell is showing the desktop
folder icons.
This is on by default because most desktop shells do show the icons on
the desktop. We already have a patch in gnome-settings-daemon to bind
this to the org.gnome.desktop.background show-desktop-icons GSettings
key which is off by default on GNOME.
https://bugzilla.gnome.org/show_bug.cgi?id=712302
Printing a file with to PDF/etc. with the virtual printer option doesn't add
the file to the list of recently used files. It should be there, so I can
easily access it.
https://bugzilla.gnome.org/show_bug.cgi?id=668598
We add a custom im module for broadway that calls some broadway
specific APIs to show/hide the keyboard on focus in/out. We then forward this
to the browser, and on the ipad we focus an input field to activate
the keyboard.
gtk_menu_tracker_add_items() fetched the action-namespace from the menu
item, but didn't pass it into gtk_menu_tracker_section_new() when its
internal namespace was still NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=712164
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.
