This is a reorganization of how value computing should be done.
Previously the GtkCssStyleProperty.compute vfunc was supposed to take
care of special cases when it needed those for computation. However,
this proved to be very complicated in cases where values were nested and
only the last value (of a common type) needed to be special cased.
A common example for this was the fallback handling for unresolvable
colors.
Now, we pass the property's ID along with all compute functions so we
can do the special casing where it's necessary.
Note that no actual changes happen in this commit. This will happen in
follow-ups.
This commit is essentially a large reorganization. Instead of all value
subtypes having their own compute function, there is the general
_gtk_css_value_compute() function that then calls a vfunc on the
subtype.
This hint may be used in text widgets to inhibit their
input methods. The most compelling usecase is calculator
applications, which already have a builtin and better
suited onscreen keyboard.
https://bugzilla.gnome.org/show_bug.cgi?id=651244
This improves the layout of the mount operations dialog to:
* Make primary labels bold in all cases
* Lay out the widgets in a grid
* Put space between the two radio groups to distinguish them
https://bugzilla.gnome.org/show_bug.cgi?id=682552
gtk_widget_insert_action_group (widget, "foo", NULL) is valid, but
g_action_muxer_insert (muxer, "foo", NULL) is not. Use
g_action_muxer_remove() for that case.
First, ensure we always consume floating values, as documented.
Second (and more serious), don't try to query the action if the
action name is not set yet. This will cause crashes...
It's too close to the release so we'll keep _set_menu() around, but
deprecate it, pointing to the new API. It will be removed (and the name
reused) before the 3.6.0 release.
https://bugzilla.gnome.org/show_bug.cgi?id=682235
If a section or submenu item has a "action-namespace" attribute, the
action names of the created GtkModelMenuItems will be prefixed with that
namespace. Namespaces can be cascaded.
There are no remaining users of the GActionMuxer in GtkApplicationWindow
because they've all been ported over to using the one on GtkWidget (via
GtkActionHelper, for the most part).
There are no remaining users of the GtkApplicationWindow API to create
GSimpleActionObserver or to get the GActionObservable (ie: muxer) for
the appwindow. Drop those APIs.
Drop the explicit passing of GActionGroup into the GtkMenu(Bar)
constructors and operate from the action context instead.
With GtkMenuItem implementing GtkActionable, this turns out to be pretty
easy (and most of the code can be removed from GtkModelMenuItem,
including the GActionObserver implementation).
Each GtkWindow with an associated GtkApplication should add this as
"app" to its action context. Each GtkApplicationWindow is its own
GActionGroup, and it should add itself to itself with the prefix "win".
There is now some duplication here because we have the new GActionMuxer
hierarchy managed by GtkWidget, but GtkApplicationWindow still carries
its own muxer. The redundancy will be removed in a future patch.
The current process of implementing GActionObserver is annoying and the
GSimpleActionObserver interface leaves a lot to be desired. Introduce a
new class, GtkActionHelper that gives you pretty much everything you'd
want to do as an implementor of GtkActionable.
The GtkActionHelper also features an "application" mode that is not
associated with a particular GtkWidget but rather with whatever widget
happens to be the active window of the given GtkApplication at a
particular point in time. This will be useful for the Mac OS menubar.
This allows adding a GActionGroup with a given name at an arbitrary
point in the widget tree.
This patch also adds an internal _get_action_muxer() API. Calling this
will create a GActionMuxer associated with the widget. The parent of
the muxer will be the muxer of the widget's conceptual parent. For
non-menus, that is the normal parent. For menus, it is the attach
widget.
In this way, we end up with a hierarchy of GActionMuxer that largely
reflects the hierarchy of GtkWidget, but only in places that the action
context has been requested. These muxers are the ones on which the
inserted actions groups are installed.
A following patch will add a user of this API.
If a muxer does not contain an action group with the given prefix, chain
up to the "parent" muxer to look for it.
This initial implementation is rather inefficient. It will lead to
changes on action groups associated with parent muxers being broadcast
to all children (regardless of if anybody there is interested or not).
An optimised version will follow soon.
-Include fallback-c89.c for the usage of round(), where an implementation
of round() is provided for compilers that don't have it
-Use g_ascii_strtod() instead of strtof as strtof() may not be universally
available.
Call _gtk_entry_get_display_text()from gtkentryaccessible.c to make
sure we always consider the actual text being displayed when
implementing the functions from the AtkTet interface.
https://bugzilla.gnome.org/show_bug.cgi?id=681591
These widgets have ancestors other than GObject which could eventually
implement the notify vfunc for their properties. For correctness, they
should chain up the notify vfunc.
https://bugzilla.gnome.org/show_bug.cgi?id=673478
While shadow-type *properties* can make sense, to opt-out of the
padding/border machinery programmatically, having it as a style
property doesn't make any sense, since we have a better way to change
the bevel style from the theme already.
This commit deprecates the shadow-type style property in GtkToolbar.
This is a regression from commit
d0d21a4f00.
We are requesting the CSS padding twice: once unconditionally and
another time if SHADOW_TYPE != NONE, which is usually the case.
gtk_widget_path_copy() currently calls g_array_append_val() in a loop,
which is inefficient due to reallocating the array's memory. Calling
g_array_set_size() before entering the loop reduces the number of CPU
cycles used by roughly 30%.
Patch by John Lindgren,
https://bugzilla.gnome.org/show_bug.cgi?id=679978
The widget is already calling gtk_render_frame, but is not measuring css
border and padding when negotiating its size. This patch replaces the
already existing get_internal_padding static helper with a function that
sums the old internal-padding value with the values specified via css.
When the tab label gets removed from the notebook on widget
desctruction, we should still unconditionally unparent it from the
notebook, since failing to do so will keep a stray reference alive.
In case applications rely on the tab label being destroyed to release
other references (e.g. because the tab label is a custom object, or
another object's lifecycle is tied to it using g_object_set_data_full()),
this will also possibly cause other references to get leaked.
In Nautilus, the result was we were failing to release the reference to
a NautilusWindowSlot, and other parts of the application relied
on it being destroyed at a specific time instead, causing the
application to crash when closing a window.
This is a regression from commit
325cf071d1.
This commit restores the previous unparenting behavior in case we're not
in a DnD operation.
https://bugzilla.gnome.org/show_bug.cgi?id=680349
We need to do this here so that an explicit gtk_widget_destroy
on either the widget or a container that holds it will kill the
reference to the menu or model.
https://bugzilla.gnome.org/show_bug.cgi?id=680803
We now support independent selection and primary clipboards, and avoid
wiping clipboard on modifying its contents from the same owner. This fixes
most of the interaction issues with clipboard and selection.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
GSequence iterators point at the position between two elements so an
iterator pointing at the N tree model node is actually between the N-1
and N sequence elements. This means that asking for the previous
sequence iterator first and then checking if it is the begin iterator
would yeld true for an iterator pointing at the 2nd tree model node
and make us return FALSE mistakenly.
https://bugzilla.gnome.org/show_bug.cgi?id=679910
This program launches an application specified by its desktop name
optinally taking list of URIs which are passed as arguments.
Uses GdkAppLaunchContext to get proper startup notification and
display handling for graphical apps.
https://bugzilla.gnome.org/show_bug.cgi?id=679342
The code that was trying to limit preview size changes was
running into some width-for-height pitfalls. It turns out
that the dialog behaves quite ok without this code, so just
remove it.
Now that filters may affect sensitivity of rows, we need
to clear the sensitivity column from the cache when the
filter changes. This fixes the problem where selecting a
different filter does not update the sensitivity of folders
until you change directories.
This way we remove paired function calls (compute/set pairs), and also make
it possible to avoid computing a filter twice, as setting the visibility
depends on filteredness.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
It bothers me that we call gtk_file_filter_filter(), then negate the result,
and the return *that* from node_should_be_filtered(). So, rename 'filtered'
throughout GtkFileSystemModel to 'filtered_out' to mean things that didn't
pass the filter.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This was a copy-paste leftover from node_set_visible(). Filters are not
concerned with model freezes, so node_set_filtered() does not
need to handle freezes, either.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Specially in the case of comboboxes, those menus could enable scrolling
even if the contents could fit in the work area, and could show blank
space in order to line up the selected item with the combobox.
When such thing happens, take into account scroll_offset when relocating
the menu contents so contents don't jump directly onscreen, and apply
it so scrolling is allowed in the direction that brings the menu onscreen
and blocked in the opposite direction.
Also, wait for cancelling the scroll operation until the touch is released
even if the scrolling arrows disappeared, so the menu item underneath isn't
selected right away.
https://bugzilla.gnome.org/show_bug.cgi?id=678113
Entries don't expand vertically if they are given pixbufs larger
than the calculated height for the current font, resulting in
cropped icons, so force the pixbuf to be rescaled so it fits
on the entry allocated size.
https://bugzilla.gnome.org/show_bug.cgi?id=678087
If the symbolic icon has other size than 16x16, the embedder
SVG that overrides colors would still force that size, resulting
in clipping instead of resizing. So fetch the original pixbuf
size the first time a symbolic icon is requested for a GtkIconInfo,
and use that size for the embedder SVG so it can be scaled properly
afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=677567
Both GtkListStore and GtkTreeStore had a few methods that allowed
-1 to mean 'append' when specified as a position, but others that
demanded positive position arguments. Make this consistent by
always allowing -1.
https://bugzilla.gnome.org/show_bug.cgi?id=667808
The recently-used.xbel storage for recently used files is located inside
the $XDG_DATA_HOME directory; there's no actual guarantee that the
directory has been created already, even though it's very highly
probable on any modern distribution. We should create it, along with its
intermediate parents, before constructing the file monitor that we use
to get change notifications.
https://bugzilla.gnome.org/show_bug.cgi?id=671817https://bugzilla.gnome.org/show_bug.cgi?id=667808
nitems is never guaranteed to be defined in sys/params.h as it is meant
to be defined within a protected ifdef __KERNEL conditional.
Use G_N_ELEMENTS from GLib which is the proper way of doing this.
In gtk_entry_get_icon_pixbuf() we unreference the pixbuf that
_gtk_icon_helper_ensure_pixbuf() gives us back, since the function
doesn't return a reference, and by doing so we're able to return the
reference owned by the cached icon helper.
Since the icon helper method can return NULL though, if no icon
properties have been set on it, guard for != NULL before unreffing the
pixbuf, as that would cause a critical warning.
https://bugzilla.gnome.org/show_bug.cgi?id=679537
Right now, when we create a GtkModelMenu for a GMenuModel, we listen to
changes to the menu's attach-widget to detect when a toplevel
GtkApplicationWindow becomes available to fetch actions from it.
This unfortunately breaks this simple code:
GtkWidget *application_window = gtk_application_window_new();
GtkWidget *menu_button = gtk_menu_button_new();
GMenuModel *menu_model = get_menu_model();
gtk_menu_button_set_menu_model(menu_button, menu_model);
gtk_container_add(GTK_CONTAINER(application_window), menu_button);
Since GtkMenuButton creates a GtkModelMenu and sets itself as its attach
widget before it's added to a hierarchy containing a
GtkApplicationWindow.
Fix the bug by simply listening for changes in the window hierarchy, and
creating the menu model when the attach widget is added to an
application window.
https://bugzilla.gnome.org/show_bug.cgi?id=679454
When the menu is detached, the attach-widget property changes value to
NULL, so we should notify a property change, like
gtk_menu_attach_to_widget() does.
https://bugzilla.gnome.org/show_bug.cgi?id=679454
This is fallout from commit 257b42e2f9 -
those fields were already getting freed in
gtk_application_shutdown_x11() and my commit caused crashes on quit
instead.
Thanks to Rico Tzschichholz for reporting the bug and testing this fix.
As an addition to 1042372670, themes might
want to avoid using the hardcoded GTK defaults for legacy GtkStyle
values. Add a gtkstyle-fallback style class that can be used by themes
to tweak the legacy GtkStyle defaults.
https://bugzilla.gnome.org/show_bug.cgi?id=679092
Since we explictly call popup_menu with NULL when it's
keyboard-activated, we need to be careful and not access event->device
without checking for event != NULL before.
The signals for the action group were being disconnected when the action
group was explicitly removed from the GActionMuxer but the same was not
being done when it was finalized.
This means that a change in the state of an action group that used to be
associated with a finalized GActionMuxer would result in a crash. This
would happen for stateful application actions after closing a window.
We can't expose colors with alpha in the GtkStyle colors, since
GdkColor has no alpha. Currently we throw away alpha completely,
which fails very badly for completely transparent backgrounds,
which now is the default for most widgets, as it typically
end up with black-on-black.
We handle this by falling back on the default/previous colors for
transparent colors. This is is simple and avoids complete failure.
https://bugzilla.gnome.org/show_bug.cgi?id=671437
When using Shift-Tab to move the focus out of page content onto
the tab label, we end up in a situation where both Tab and Shift-Tab
move focus back into the page, which is not really what is expected
when the notebook is part of a dialog.
Instead, arrange things so that using Shift-Tab with focus on a
tab label moves the focus out of the notebook.
http://bugzilla.gnome.org/show_bug.cgi?id=669986
It turns out that we can end up removing a notebook child while
the tab is still 'detached'. Child removal causes
gtk_notebook_remove_tab_label() to be called on the tab label,
but that function did not deal with the eventuality that the tab
label may be a child of the dnd window.
http://bugzilla.gnome.org/show_bug.cgi?id=677943
Some builders using gtk3 outside of the GNOME cycle want an option to
avoid linking to atk-bridge-2.0. Provide that, and at the same time
ensure we're only looking for it on X11 platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=677491
Make GMountOperation look for an owner of org.Gtk.MountOperationHandler
if possible, and use it instead of the GTK-based dialogs.
This allows applications to use the implementation offered by the
desktop shell, if available, through a DBus private interface:
org.Gtk.MountOperationHandler.
https://bugzilla.gnome.org/show_bug.cgi?id=674963
This gets the current cell area of a particular item. Its similar
to gtk_tree_view_get_cell_area().
The code is extracted from gtk_icon_view_set_tooltip_cell which now
just calls the old code.
https://bugzilla.gnome.org/show_bug.cgi?id=678418
When a widget is app_paintable, its background should not be drawn by
the theme, thus we should not try to override its background again when
style-updated is fired.
This is a bit of a hack, but it fixes gray surfaces observed for DnD
windows with recent GTK+.
As used in Totem and gnome-contacts. The widget
takes either a GtkMenu or a GMenuModel to construct
its menu, and can be given a parent widget to use to
position the drop-down (as used in GtkMenuToolButton).
https://bugzilla.gnome.org/show_bug.cgi?id=668013
If the icon view is empty, we cannot get a reasonable size request from
the cell renderers. So all values we would compute are pretty much
useless.
So we special case it.
This also gets rid of a bunch of crashers from div-by-0 in corner cases.
https://bugzilla.gnome.org/show_bug.cgi?id=677809
This is useful for 2 reasons:
(1) Items actually exist and are clickable
(2) Size computations don't divide by 0
I've not seen problems with this in the wild (mostly because
item-padding defaults to non-0), but noticed this while fixing other
bugs.
Minimum size is necessary so you can see the item. If we can't get that
we need to scroll.
Natural as the maximum is used so that the spacing between items doesn't
increase when resizing the iconview, but empty space is added to the
right/bottom instead.
https://bugzilla.gnome.org/show_bug.cgi?id=677809
While working on the "iconview: Don't shrink items" patch I noticed that
gtk_icon_view_compute_n_items_for_size modifies the natural and minimum
item sizes it got from gtk_icon_view_get_preferred_item_size when
calculating the max number of items which will fit, but later on it
checks against these sizes when calculating the item_size, and these
checks expect these values to be unmodified.
This patch fixes this by modifying the natural and minimum values in
advance and doing all computations with modified values.
https://bugzilla.gnome.org/show_bug.cgi?id=677809
The previous code assumed that the width was always enough for more than
one column, which is obviously not correct when a number of columns is
hardcoded.
With this patch, it will now always check that the width is enough and
otherwise cause scrolling.
https://bugzilla.gnome.org/show_bug.cgi?id=677809
GtkToolbar doesn't have its own GdkWindow to draw on (it calls
gtk_widget_set_has_window(FALSE) in _init), but only an event window
(input-only).
Since gtk_widget_get_window() in that case will return the GdkWindow of
the parent container, by calling gtk_style_context_set_background() here
we're overriding the base background of the container instead of our.
While in most cases this doesn't have any noticeable effect, since
the toplevel GtkWindow will paint its background on top of it at the
beginning of the draw cycle, when the classic window hierarchy is
broken, such as when widgets are rendered through a clutter-gtk
offscreen embedding, the background will become visible, which is
undesirable.
Fix this by having GtkToolbar not call gtk_style_context_set_background
in its style_updated handler.
When I added the versioned annotation, I accidentally backdated
it, so the Deprecated: tag in the docs said 3.4, but the annotation
said 3.0. Fix it so we say 3.4 in both places.
When inline-selection is set, and the completion popup is showing,
pressing left abruptly jumps to the beginning of the entry text.
This is not expected, since the cursor is at the end of the text before
the left key is pressed, and this behavior is completely inconsistent
with how an entry would normally behave.
The behavior can be observed in Epiphany by selecting a completion match
and pressing left.
This patch changes the code so that it just runs the default entry key
press keybindings in such a case.
https://bugzilla.gnome.org/show_bug.cgi?id=677915
Mark the new_order argument as zero-terminated array, even though it does not
need to be zero terminated (it has an implicit length not given by a constant
or another method argument). It does not hurt if bindings append an extra zero
to the array as long as it has enough elements, and this makes the method
introspectable.
https://bugzilla.gnome.org/show_bug.cgi?id=677941
Remove the 'you shall not connect' message from this signal.
While it is a keybinding signal, using it from applications is
fine and, in fact, expected.
There are three bugs here:
- we should check if the value type is transformable instead of being
compatible, since that's all we care about in order to call
g_value_transform()
- the check is only meaningful in the direction
passed-in-type->column-type and not viceversa
- we should init the destination GValue to the column type before
calling g_value_transform on it, or the destination type information
will be missing and the method will fail
Thanks to Jasper St. Pierre and Colin Walters for all the help in
tracking this down.
https://bugzilla.gnome.org/show_bug.cgi?id=677649
There are three bugs here:
- we should check if the value type is transformable instead of being
compatible, since that's all we care about in order to call
g_value_transform()
- the check is only meaningful in the direction
passed-in-type->column-type and not viceversa
- we should init the destination GValue to the column type before
calling g_value_transform on it, or the destination type information
will be missing and the method will fail
Thanks to Jasper St. Pierre and Colin Walters for all the help in
tracking this down.
https://bugzilla.gnome.org/show_bug.cgi?id=677649
gtk_icon_info_load_symbolic checks for the existance of a filename parameter
so it can include it along with the stylesheet. We don't set the filename
parameter when creating the info for a GFileIcon, for some reason.
https://bugzilla.gnome.org/show_bug.cgi?id=676356
This is probably going to be replaced by something different soon, but
in the meantime, fix this annoying bug, visible e.g. in widget-factory
for left/right tab examples.
As used in Totem and gnome-contacts. The widget
takes either a GtkMenu or a GMenuModel to construct
its menu, and can be given a parent widget to use to
position the drop-down (as used in GtkMenuToolButton).
https://bugzilla.gnome.org/show_bug.cgi?id=668013
When we determine the fill rectangle for an image layer, and the image
is not repeating, we should also position the rectangle according to the
values of background-position, or we will always fill a tiny slice at
the top/left of the clip box.
https://bugzilla.gnome.org/show_bug.cgi?id=677109
