With style BOTH_HORIZ the label would not be selected (if not marked
"important") and when there's no icon, it would result in an empty button.
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
https://bugzilla.gnome.org/show_bug.cgi?id=710134
When doing fallback for symbolic icons, we first shorten
the name at dashes while preserving the -symbolic suffix.
But after exhausting that, we should also try stripping
the suffix.
https://bugzilla.gnome.org/show_bug.cgi?id=708163
When showing a tooltip on the edge of a monitor, the tooltip could be wrongly
placed and be shown going from one monitor to the next.
This happened because the current_window wasn't set visible, and when it wasn't
the returned allocated size would be 1, hence wrong calculations.
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
https://bugzilla.gnome.org/show_bug.cgi?id=698730
Rework how accels are handled on GtkApplicationWindow.
Instead of having GtkApplication fill the GtkAccelMap which is then used
by GtkApplicationWindow to create a GtkAccelGroup filled with closures
that is then associated with the window, do it directly.
GtkApplication now keeps a list of accels and their actions.
Accelerators on a GtkApplicationWindow ask GtkApplication to execute the
appropriate action.
This saves a fair bit of complexity and memory use (due to not having to
create all those closures and accelmap entries). The new approach also
supports multiple accels per action (although there is not yet a public
API for it).
This patch (and the ones before) Reviewed and ACK'd by Matthias Clasen.
Add support for pulling the primary accel out of the GtkActionMuxer.
With this change, it is no longer necessary to have the accel=''
attribute hardcoded onto each menu item (and, in fact, it should be left
off if you intend to have support for dynamic accelerator changing).
Specifying accel='' is a good way to force an accelerator not to be
displayed on a menu item.
Store "action and target" format inside each GtkMenuTrackerItem. This
makes action invocation more efficient (no hash table lookups or
allocations) and slightly simplifies handling of action namespace.
More importantly, this will be used when we start to get accels from
GtkActionMuxer.
Reuse the existing infrastructure in GtkActionMuxer for propagation of
accelerator information: in particular, what accel label ought to appear
on menu items for a particular action and target.
This is a good idea because we want accels to travel along with the
actions that they're tied to and reusing GtkActionMuxer will allow us to
do that without creating another hierarchy of a different class for the
sole purpose of filling in accel labels on menu items.
Doing it this ways also allows those who copy/paste GtkActionMuxer to
insert the accels for themselves.
Add a new method on the GtkActionObserver interface to report changes.
This patch introduces a new concept: "action and target" notation for
actions. This format looks like so:
"'target'|app.action"
or for non-targeted actions:
"|app.action"
and it is used over a number of possible alternative formats for some
good reasons:
- it's very easy to get a nul-terminated action name out of this format
when we need it, by using strrchr('|') + 1
- we can also get the target out of it using g_variant_parse() because
this function takes a pointer to a 'limit' character that is not
parsed past: we use the '|' for this
- it's extremely easy to hash on this format (just use a normal string
hash) vs. attempting to hash on a string plus a GVariant
A close contender was to use detailed action strings here, but these are
not used for two reasons:
- it's not possible to easily get the action name or target out of the
strings without more work than the "action and target" format
requires
- we still intend to use detailed action strings on API (since they are
a lot nicer to look at) but detailed action strings can be given in
non-canonical forms (eg: 'foo::bar' and 'foo("bar")' are equivalent)
so we'd have to go through a normalisation step anyway. Since we're
doing that already, we may as well convert to a more convenient
internal format.
This new "action and target" format is going to start appearing in a lot
more places as action descriptions are introduced.
I suspect that nobody is using '|' in their action names, but in case I
am proven wrong, we can always switch to using something more exotic as
a separator character (such as '\x01' or '\xff' or the like).
Previously, GtkWindow would add the "app" action group to its own
toplevel muxer.
Change the setup so that GtkApplication creates the toplevel muxer and
adds itself to it as "app". Use this muxer as the parent muxer of any
GtkWindow associated with the application.
This saves a small amount of memory and will allow for accels to be
propagated from the application through to all of the windows.
With the stock system being deprecated now, we should provide
meaningful accessible names for buttons that are constructed
from icon names or GIcons. This commit reuses the existing
translations.
It is possible that some common icon names are not covered
here because they were not present as stock items. These can
be added to the table later.
Spinners are essentially animated symbolic icons. We don't really
want them being rendered to arbitrary sizes. Also the current
technique for rendering the activity is not suitable for larger
sizes. Until we have a better technique we should limit the size
to the MENU icon size or exactly twice that size.
The 'direction' parameter to gtk_widget_keynav_failed() is based on
gtk_list_box_move_cursor()'s 'count' parameter. However if the passed
in movement is GTK_MOVEMENT_DISPLAY_LINES, 'count' is modified by
the keynav handling and will always be 0. To avoid messing up the
'direction' parameter, use a local variable for keynav handling and
leave 'count' untouched.
https://bugzilla.gnome.org/show_bug.cgi?id=709687
Previous commit wrongly identified "active" as containing the new
value. Instead, applications must determine the new value to
update the model with manually based on the value currently in the
model.
Clarify that applications are expected to handle updating the model
from the 'active' property, like GtkCellRendererText does for the
'edited' property.
If a range goes all the way to the edge of the screen then we don't
have any way to activate autoscrolling. By adding a small region
at the ends of the range we can handle this case. This is the same
approach used in treeviews.
The newly-added gtk_flow_box_child_is_selected() needed to return a
gboolean, so use g_return_val_if_fail() to return FALSE when an invalid
GtkFlowBoxChild* is passed in.
Make flowbox selection more orthodox. Control and Shift now
modify the selection behaviour pretty much in the same way
they do in a tree view, and clicking without modifiers will
clear the selection.
When dealing with touch devices, we treat modifier-less events
as modifying the selection.
This commit also adds a few other selection necessities, such
as catching Escape key presses to cancel rubberband selection,
and handling grab notify.
GtkFlowBox is a container that its children in a reflowing
grid, which can be oriented horizontally or vertically.
It is similar to GtkListBox in that the children can
be sorted and filtered, and by requiring a dedicated child
widget type, GtkFlowBoxChild. It is similar to GtkTreeView
in that is supports a full set of selection modes, including
rubberband selection.
This is the culmination of work that has happened in the
egg-list-box module, and earlier in libegg. The origins of
this code are the EggSpreadTable in libegg, which was written
by Tristan van Berkom. It was moved to egg-list-box and
renamed EggFlowBox by Jon McCann, and I gave it some finishing
touched in the flowbox-improvements branch of that module.
Previously, the "Places" sidebar was populated by the update_places()
call from within gtk_places_sidebar_style_set(). After
742a2f11a9, update_places() is never called
and the sidebar is never populated unless gtk_places_sidebar_add_shortcut()
happens to be called. This commit fixes this by calling update_places()
at the end of gtk_places_sidebar_init().
https://bugzilla.gnome.org/show_bug.cgi?id=709522
GtkWidget had a hack where if opacity is 0.999 we set up an opacity group when
rendering the widget. This is no longer needed in 3.10, and GtkStack doesn't
use it anymore.
GdStack is using it, so applications should be ported from GdStack to GtkStack
in 3.12.
https://bugzilla.gnome.org/show_bug.cgi?id=703603
Resize modes don't work anymore, both because nobody ever uses them and
because the frame clock changed the way things work quite a bit. So we
don't want to advertise them as a good idea.
https://bugzilla.gnome.org/show_bug.cgi?id=708787
Add a has-tab-gap style property to GtkNotebook so that we can
disable drawing the gap between tabs and the page in the Adwaita
theme without breaking existing themes.
https://bugzilla.gnome.org/show_bug.cgi?id=707920
GtkSourceView draws before chaining upo to GtkTextView and assumes
that this will be visible, but the pixelcache will just overdraw
that with background.
So, we stop drawing the background to the pixel cache and instead
make it an CAIRO_CONTENT_COLOR_ALPHA surface to make the previously
drawn content see through.
This is slower, but more backwards compatible.
https://bugzilla.gnome.org/show_bug.cgi?id=708423
Previously, we were showing and hiding the custom titlebar
widget in response to state changes such as maximization.
Instead, use gtk_widget_set_child_visible() and leave
show/hide to applications. This makes it possible to set
a custom titlebar and hide it, for a titlebar-less appearance.
https://bugzilla.gnome.org/show_bug.cgi?id=707132
When loading a symbolic icon, g_file_get_contents() is currently used
with the icon pathname, to load its SVG data. This won't work when the
icon is not a local file, for instance when a symbolic icon is loaded
from a GFileIcon with a GResource path.
Fortunately GtkIconInfo already holds a GFile, so we can just use
g_file_load_contents() to load the data instead.
https://bugzilla.gnome.org/show_bug.cgi?id=709056
Updated documentation to specify that '0' should be specified if
one does not need to automatically assign a bound child to a public
or private instance member (now that negative values are private
structure offsets).
If we start with a padding of -1 then it can leak out of the size
allocation request for the column when the treeview is empty. The
GtkTreeView will then collect these -1 values and add them together,
returning -n where 'n' is the number of columns.
This is usually not a problem because treeviews tend to be used with a
scrollbar and the width of the scrollbar will be added to this number
bringing it into positive territory again. On Ubuntu, with overlay
scrollbars, this is not the case, however.
https://bugzilla.gnome.org/show_bug.cgi?id=703062
The size of the shadow and invisible borders can (and usually
will) change between backdrop and focused windows, while the
overall window size remains unchanged. This causes the visible
window to visually 'jump'. We can avoid this by always reserving
the maximum of the focused and unfocused border sizes. The code
for positioning the input-only windows making up the invisible
border is adjusted to deal with this. We now always place the
invisible border right outside the visible content, even if the
shadow extends out much farther.
https://bugzilla.gnome.org/show_bug.cgi?id=707524
And use the "header" style class to do that.
This allows themes to set e.g. the background of the tab header
differently.
Themes will need slight adjustment to make things appear
as before.
https://bugzilla.gnome.org/show_bug.cgi?id=643914
This allows subclasses of GtkTextView that require a corresponding
subclass of GtkTextBuffer to automatically do the right thing when
constructed with a NULL buffer. An example of this is GtkSourceView
which requires a GtkSourceBuffer.
https://bugzilla.gnome.org/show_bug.cgi?id=708584
The GtkStack and GtkStackSwitcher code did not really
follow GTK+ conventions for includes. Fix that, and also
fix up a case of gpointer vs gpointer* confusion
in gtkstack.c.
This adds new 'over' and 'under' transitions which work by moving
the new page over the previous one, or moving the previous page off
to reveal the new one. We also add an over/under combination that
is going to be used in GtkAboutDialog.
https://bugzilla.gnome.org/show_bug.cgi?id=707187
Some of the labels were not marked as no-show-all. But the
code clearly tries to manage their visibility, so gtk_widget_show_all()
should not affect them.
https://bugzilla.gnome.org/show_bug.cgi?id=681484
The child property is watched by the StackSwicther which in turns sets a
needs-attention css class on the corresponding button, so that the theme
can for instance show a throbbing animation if one of the hidden pages
needs the user attention.
https://bugzilla.gnome.org/show_bug.cgi?id=707153
If an icon is in a Fixed or Threshold directory we normally don't
scale it. However, in the case of HiDPI scaling we *do* want to
scale it, to avoid different layouts in Lo/HiDPI. We look up whatever
the size of the icon would have been in LoDPI and scale to that
in the no-scaling case, thus getting the same layout as the
unscaled case.
https://bugzilla.gnome.org/show_bug.cgi?id=708384
