This is an automated change doing these command:
git sed -f g gtk_widget_set_has_window gtk_widget_set_has_surface
git sed -f g gtk_widget_get_has_window gtk_widget_get_has_surface
git sed -f g gtk_widget_set_parent_window gtk_widget_set_parent_surface
git sed -f g gtk_widget_get_parent_window gtk_widget_get_parent_surface
git sed -f g gtk_widget_set_window gtk_widget_set_surface
git sed -f g gtk_widget_get_window gtk_widget_get_surface
git sed -f g gtk_widget_register_window gtk_widget_register_surface
git sed -f g gtk_widget_unregister_window gtk_widget_unregister_surface
git checkout NEWS*
Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
This is in preparation of using input streams to show that these
coordinates aren't needed most of the time and can otherwise be saved
during GtkWidget::drag-drop.
Instead of allowing people to pass a uint user-data, insist on them
comparing mime types.
The user data was a uint instead of a pointer anyway, so uniqueness
could not be guaranteed and it caused more issues than it was worth.
And that's ignoring the fact that it basically wasn't used.
Instead, add a function gtk_image_set_icon_size() for the cases where
overriding the icon size is necessary.
Treat icon sizes the same way as pixel sizes, too. So gtk_image_clear()
no longer unsets the icon size.
This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
Since setting a clip is mandatory for almost all widgets, we can as well
change the size-allocate signature to include a out_clip parameter, just
like GtkCssGadget did. And since we now always propagate baselines, we
might as well pass that one on to size-allocate.
This way we can also make sure to transform the clip returned from
size-allocate to parent-coordinates, i.e. the same coordinate space
priv->allocation is in.
This widget is a bit unusual in that it is a box that acts as
the drop target, while the visible content is a child of the box.
Propagate :drop(active) to the child to make the highlight visible.
Its very easy to get extra references to the NativeDialog so that
when you release your last reference any visible dialog is not
hidden. We handle this by adding a destroy method similar to how
you destroy regular toplevels.
The differences between the existing properties and the newly added
GtkWidget:focus-on-click property are minimal (different owner_type
in GParamSpec), so it is extremely unlikely that dropping the former
would break anything.
https://bugzilla.gnome.org/show_bug.cgi?id=757269
GtkFileSystem has a complicated way to handle cancellables.
You keep the cancellable pointer that is returned by
_gtk_file_system_get_info and similar methods so that you can
cancel the operation, but you do not own a reference to it.
The only place where it is ok to unref a cancellable is in
your callback, which gets handed a cancellable that you need
to unref at the end. You are expected to compare it to the
pointer you stashed away to find out if the operation has
already been superseded by a newer call, in which case you
disregard the results.
GtkFileChooserButton was following these rules for most of
the cancellables it keeps around, but it was sometimes unreffing
the cancellables that are stored in the model, which could lead
to refcount confusion and crashes. This commit makes it follow
the rules for that case too, which fixes the crash in the bug
below, and does not show up any leaks in valgrind under light
testing.
https://bugzilla.gnome.org/show_bug.cgi?id=737804
They were updated in style-changed, causing the label to get set to
(None), then to the actual file name again a frame later, both of the
updates cause the GtkFileChooserButton to resize, possibly to the
minimal width, causing the layout to jump. Fix this by only updating
icon/label in style-updated when the icon theme actually changed, which
is the only case we care about here.
https://bugzilla.gnome.org/show_bug.cgi?id=752509
It seems that alternate implementations of GtkFileChooserWidget
never materialized. The split between GtkFileChooserWidget and
GtkFileChooserDefault is awkward. The immediate problem is that
it makes it difficult to document the keybinding signals. So it
makes sense to drop the abstraction and just have one thing.
https://bugzilla.gnome.org/show_bug.cgi?id=723157
We rename the gtk_widget_class_bind_template_child{_internal}
macros by appending a _private to their name. Otherwise, it
would be too magic to pass the 'public' names as arguments,
but affect a member of the Private struct. At the same time,
Add two new macros with the old names,
gtk_widget_class_bind_template_child{_internal} that operate
on members of the instance struct.
The macros and functions are inconsistently named, and are not tied to
the "template" concept - to the point that it seems plausible to use
them without setting the template.
The new naming scheme is as follows:
gtk_widget_class_bind_template_child_full
gtk_widget_class_bind_template_callback_full
With the convenience macros:
gtk_widget_class_bind_template_child
gtk_widget_class_bind_template_child_internal
gtk_widget_class_bind_template_callback
https://bugzilla.gnome.org/show_bug.cgi?id=700898https://bugzilla.gnome.org/show_bug.cgi?id=700896
Using an offset from the struct means you can have children in
both the public and private (via G_PRIVATE_OFFSET) parts of the
instance. It also matches the new private macros nicer.
https://bugzilla.gnome.org/show_bug.cgi?id=702563
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
We've recently a number of classes wholly. For these cases,
move the headers and sources to gtk/deprecated/ and adjust
Makefiles and includes accordingly.
Affected classes:
GtkAction
GtkActionGroup
GtkActivatable
GtkIconFactory
GtkImageMenuItem
GtkRadioAction
GtkRecentAction
GtkStock
GtkToggleAction
GtkUIManager
Deprecate gtk_widget_push_composite_child, gtk_widget_pop_composite_child,
gtk_widget_set_composite_name, gtk_widget_get_composite_name.
This API is just bloat and was never useful, this patch deprecates
it and removes all internal calls to the composite child APIs
Change of plans to match the tests from the previous commit.
The state of the underlying dialog is never reflected by GtkFileChooserButton's API,
as the dialog is a transient thing. The file chooser button only updates its state from the dialog,
and reflects the dialog's state, when the dialog has been confirmed and dismissed by the user.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The idea is that the button will only update its state of the selection and current folder
when changes to those are done either by the calling program (with the filechooser's API)
or when the user actually confirms and dismisses the underlying GtkFileChooserDialog.
If the user makes changes to the dialog but has not dismissed it yet, those changes
will not be reflected in the button (as one would expect).
This commit also makes sure the current-folder-changed and selection-changed signals
are emitted at the right times.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We only emitted that signal when the selection changed through the underlying GtkFileChooserDialog.
To do this when the dialog is not active and the selection is changed by the calling program
(instead of by the user), we need to wait until the GtkFileChooserButton's UI has been updated
via an async callback from GIO. So, we keep track of whether an entry point into the
button's API caused a programmatic change in the selection.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The currently-selected file *is* the selection even in SELECT_FOLDER mode. Do not confuse this
with the current folder.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We assumed that we didn't have to update the combo box if the dialog got cancelled,
as it should simply retain its previous contents. But this assumption doesn't work
as the dialog is brought up with the 'Other...' item - we don't want the
combo box to keep showing 'Other...' if the dialog is cancelled.
The test from the previous commit now passes.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This is surprisingly tricky, since the (None) item *has* to be a visible item while
the combo box is *not* popped up, so that it can show its contents. But the item
has to be *not* visible when the combo box is popped up.
Also, update the whole button's selection, not just the underlying dialog's, when
the combo box changes its selection - based on a patch by Paul Davis in
https://bugzilla.gnome.org/show_bug.cgi?id=691040#c20
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This way the internal labels will show the correct selection even if nothing
has been selected programmatically.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We didn't change it when the file chooser button's dialog was inactive, and so
the actual file chooser button would not visually reflect the current selection.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We do some gymnastics to pull the string out of the GtkButton or the GtkComboBox that is
being used in GtkFileChooserButton to show the current selection when the dialog
is inactive - namely, we look for the subwidget with the correct ATK role, and pull its
accessible name.
Currently the test fails; this is https://bugzilla.gnome.org/show_bug.cgi?id=691040#c18
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
In the case of checking for local_only, g_file_is_native() is not useful, since it
will return FALSE for something in a FUSE mount.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The file chooser button only supports single-selection modes, so
switch the code to a simpler gtk_file_chooser_get_file() to avoid
dealing with GSLists of a single file.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We only emit that signal when the user confirms the button's internal GtkFileChooserDialog,
or when he drags-and-drops stuff into the button.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
If the user didn't explicitly select anything, BUT the file chooser button has
a current_folder set, do the same as what GtkFileChooserDefault would do:
return the current folder as the selection.
This makes the tests in tests/filechooser pass!
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
If no file was originally selected in the GtkFileChooserButton, then its
internal dialog is brought up and cancelled, then we need to restore the
selection back to none. GtkFileChooser, though, doesn't like to
select a NULL file, so call _unselect_all() in that condition.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The button's underlying file chooser dialog should not be used to store the file selection
while the dialog is unmapped. Instead, the file chooser button now stores the
selection itself.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
