These tests check that a toplevel window ends up with the expected
size after setting default sizes or resizing. It currently passes
on X, but fails with client-side decorations under X and Wayland.
It's not necessary anymore because gdk_display_manager_get() always
succeeds and the value is independant of when it was called as it's no
longer backend specific.
AtkSelection requires that the immediate children of the object are the
selectable items. The combobox however is implemented with just 1 child:
The popup menu.
The popup menu is implementing the selectable interface.
Test are updated to reflect this change.
The gtk-launch tool can be build without gio-unix (although it
will not really do much without an alternative implementation for
g_desktop_app_info).
So there is no need to not build gtk-launch anymore.
This reverts commit 9a1235bf0d.
https://bugzilla.gnome.org/show_bug.cgi?id=682824
Pointed out in https://bugzilla.gnome.org/show_bug.cgi?id=699016
The fix here is slightly different. We make
_gtk_builder_parser_translate return a const char * instead of
a dup'ed string, and fix up the callers.
These tests may have some assumptions on reasonable window manager
behaviour. For now, we just test that the default size of the
window ends up as the allocated size of the content. This test
currently fails with client-side decorations, because we are
not properly discriminating between overall window size and
content size.
Cache the style contexts for the up and down panels, instead of recreating
them each time they are drawn or size requested. GtkSpinButtons were
many times slower to draw than other widgets because of the constant
style matching.
https://bugzilla.gnome.org/show_bug.cgi?id=698682
If a subclass (say a child of GtkButton) overrides the non-baseline
size request methods we need to call these, rather than the new
get_height_and_baseline_for_width method.
In order to handle this we make the default for this method to be
NULL, and instead check at runtime which method to call. If any
non-baseline vfunc has changed in a class but the baseline one
hasn't, then we can't use the baseline one.
We now report any baselines from the child, and allocate it.
Also, in the case of a baselign aligned child we ignore yscale/yalign
as that is not supportable.
Report a baseline based height and baseline whenever there
are children with ALIGN_BASELINE.
Assign baseline to childen in size_allocate. Either the one inherited
from the parent if set, or otherwise calculate one based on any
ALIGN_BASELINE children.
This modifies the size machinery in order to allow baseline support.
We add a new widget vfunc get_preferred_height_and_baseline_for_width
which queries the normal height_for_width (or non-for-width if width
is -1) and additionally returns optional (-1 means "no baseline")
baselines for the minimal and natural heights.
We also add a new gtk_widget_size_allocate_with_baseline() which
baseline-aware containers can use to allocate children with a specific
baseline, either one inherited from the parent, or one introduced due
to requested baseline alignment in the container
itself. size_allocate_with_baseline() works just like a normal size
allocation, except the baseline gets recorded so that the child can
access it via gtk_widget_get_allocated_baseline() when it aligns
itself.
There are also adjust_baseline_request/allocation similar to the
allocation adjustment, and we extend the size request cache to also
store the baselines.
Setting this means baseline aware containers should align the widget
according to the baseline. For other containers this behaves like
FILL.
In order to not suprise old code with a new enum value we always
return _FILL for _BASELINE unless you specifically request it via
gtk_widget_get_valign_with_baseline().
Instead of having three different boxes and style classes, we can just
get away with the regular background box, plus a window-frame, which
contains the external frame, together with the window drop shadows.
GtkWindow now has special code to ensure the backing actual window is
allocated big enough to accomodate the shadows (using the shadow size
calculations introduced in the previous commit). We also use the margin
value to determine the size of the invisible borders (which can then be
different than the shadow).
This reverts commit f4438a1ffc.
The calculation of the delta between parent and child widget
is required in order to automate height-for-width and width-for-height
requests for various GtkBin widgets.
GtkButton, GtkCheckButton, GtkRadioButton, etc, all have different
requests for space around the content which can not be satisfied
with a simple calculation of GtkContainer border-width.
Add separate GtkStack and GtkStackSwitcher widgets that are an
alternative to GtkNotebook. Additionally, GtkStack supports
animated transitions when changing pages.
These widgets were initially developed in libgd.
We still need to respect this border value even when we're not running
under CSD, since we support setting a custom titlebar in all cases.
The border/style magic in gtk_window_draw() really needs to be separated
out into logical pieces soon, but for now let's keep a consistent
behavior with the previous code.
Instead of reparenting the content, use input-only windows to
set cursors and capture clicks on the window frame. This avoids
some of the problems that were introduced by content_window, such
as black flashes and non-working opacity.
Since ::drag-leave gets emitted before ::drag-drop, we can't just remove the drop feedback row
in drag-leave, as we *need* it during drag-drop. So, we use the same trick as in testdnd.c - we
install a timeout handler in our drag-leave callback, and remove the feedback in the timeout callback.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This lets us keep the new_bookmark_index untouched even when the drop state goes from armed to unarmed.
That will in turn let us drop in the right place...
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We used to divide the row in thirds vertically, and use the outer thirds for GTK_TREE_VIEW_DROP_BEFORE and AFTER, respectively.
Now we use *fourths*. This is so that we get equal areas for these:
GTK_TREE_VIEW_DROP_BEFORE
GTK_TREE_VIEW_DROP_INTO_OR_BEFORE
GTK_TREE_VIEW_DROP_INTO_OR_AFTER
GTK_TREE_VIEW_DROP_AFTER
This makes hovering tree rows much more positive.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This makes the feedback accurate and without hysteresis. Haven't I written this code ten times before?
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
For now it is the old, simple call to gtk_tree_view_set_drag_dest_row(). We'll do something
fancier in the following commits.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We want to show a little animation when a DnD operation is happening and the user hovers
between existing bookmarks. The animation should indicate the user that he's about to
create a new bookmark from the file right there.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
It's pretty useless to make a menu without actions behind it and people
who are using gtk_menu_shell_bind_model() directly are probably not
interested in doing it the GtkApplicationWindow way (so they won't get
the "app" and "win" groups for free). People are going to need to call
gtk_widget_insert_action_group(), so mention this in the docs to help
them along.
This is the new GtkPlacesSidebar widget, which is the sidebar used in
GtkFileChooser to display a list of places/folders that the user may
want to use. File managers are encouraged to use this widget for
their own global list of folders.
This is Tristan's *excellent* work, minus the old code for the shortcuts bar - that is all done
in GtkPlacesSidebar now.
The UI gets loaded from a Glade resource; most of the old code to create the UI by hand is gone.
There is still code for save_widgets_create(); this needs to be moved into the UI file, but it
is not a big deal.
gtk_file_chooser_default_init() calls a new post_process_ui() that takes care of all the things
that cannot be done directly in Glade.
Although GtkPlacesSidebar is a public widget, we can't have that in Glade's general catalog
as this branch is not merged into GTK+ proper yet. We'll move the widget to Glade's
catalog when this is done.
