Don't call gtk_widget_destroy; instead implement
gtk_window_destroy outselves by removing the window
from the toplevel lista and dropping the reference that
GTK holds.
Since GtkWindowHandle and GtkHeaderBar do it now, it can be removed from
GtkWindow, along with GTK_WINDOW_REGION_TITLE which at this point doesn't
differ from GTK_WINDOW_REGION_CONTENT.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/2689, since
GtkWindowHandle doesn't do that anymore.
Add private gtk_tooltip_maybe_allocate() function
and use it from GtkWindow and GtkPopover.
This will let us stop using the ::size-allocate signal,
without having to redo all the tooltip management first.
That will happen later.
We want to remove GtkBin and GtkContainer as they don't
provide much useful functionality anymore. This requires
us to move get_request_mode and compute_expand down.
Update the accessible implementation to match, remove
remnants of container implementations in GtkWindow
subclasses, and fix livecycle issues around destroy
vs dispose in GtkAssistant.
After this commit, using gtk_container_add on window
subclasses is not allowed anymore, but adding childing
with <child> in ui files still works.
See #2681
Use window title, or custom title widget if it's set. Remove 'title'
property.
Update demos and tests to set the title on the window instead of
headerbar.
The `element-type` annotation is for GList and GSList only, and turns
out adding support for GListModel in gobject-introspection breaks Vala
and the GIR for GIO.
Instead of using `element-type`, we can use the `attributes` annotation,
which is ignored by code generators based on the GIR data.
This function to revoke implicit grabs may be called with a NULL
device, which means all devices should be revoked. Fix the check
so this actually happens.
Fixes implicit grabs (maybe) being unset in result to a GTK grab.
Update the layout when any of the following properties changes:
* modal
* transient-for
* resizable
* deletable
Stop updating it from GtkWindow, make that function static.
Only turn on visible focus when a key event actually leads
to a change in focus location (ie, 'keynav').
Make the visible focus disappear after 5 seconds of no
keyboard interaction, to avoid permanent focus ring
distraction.
As an extra bonus, make it so that we make the focus
visible while the Alt key is pressed. This gives us
a 'find my focus!' shortcut, and goes well with the
prexisting use of Alt for finding mnemonics.
Discussed in: #2644
Add the following actions:
* window.close
* window.toggle-maximize
* window.minimize
Ensure they are disabled when not appropriate, such as for modal windows.
Use them in GtkHeaderBar.
The application menu isn't particular relevant anymore, and the support for
showing fallback appmenu as a headerbar icon is one of the things tying
GtkWindow to GtkHeaderBar.
Remove support for "menu" window decoration element completely, update
GtkHeaderBar docs.
This was only living in gtkcontainer.c for historic
reasons. Move it closer to where it belongs, and
rename it from 'idle' to 'layout', since it is
really about the layout phase of the frame clock,
nowadays.
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
This is used for widgets that contain the focus widget,
reserving the focused state for the focus location itself.
This aligns our focus state handling with
https://www.w3.org/TR/selectors-4/
Make gtk_window_set_focus call gtk_widget_grab_focus internally.
This means that set_focus can now end up putting the focus on
a child of the passed-in widget, and makes the focus-widget
property work for setting initial focus to (the child of) an
entry in a ui file.
We don't get a focus-out on the event controller, when
the surface is losing keyboard focus, since we are not
moving our focus to some other widget, so we are never
unsetting the mnemonics-visible property. Do that in
response to surface state changes instead.
API remains the same, but activation is now done via a
shortcutcontroller.
The code uses a controller with global scope so that the
shortcuts are managed with all the other global shortcuts.
When creating shortcuts, there almost always are a trigger and an action
available for use. So make gtk_shortcut_new() take those as arguments.
Also add gtk_shortcut_new_with_arguments() so people can easily pass
those in, too.
Similar to GtkShortcutTrigger, GtkShortCutAction provides all the
different ways to activate a shortcut.
So far, these different ways are supported:
- do nothing
- Call a user-provided callback
- Call gtk_widget_activate()
- Call gtk_widget_mnemonic_activate()
- Emit an action signal
- Activate an action from the widget's action muxer
This adds an interface for taking care of shortcut controllers with
managed scope.
Only GtkWindow currently implements this interface, so we need to ensure
that we check if any top-level widget we reach is a shortcuts manager
before we call into it.
And use it.
I just added it to GtkWidget just to show that I can.
The real reason I want it is for gamepad/joystick triggers
in games, so that it becomes possible to select 2 different
triggers (gamepad and keyboard) for the same shortcut.
API remains the same, but activation is now done via a
shortcutcontroller.
The code uses a controller with global scope so that the
shortcuts are managed with all the other global shortcuts.
When creating shortcuts, there almost always are a trigger and an action
available for use. So make gtk_shortcut_new() take those as arguments.
Also add gtk_shortcut_new_with_arguments() so people can easily pass
those in, too.
Similar to GtkShortcutTrigger, GtkShortCutAction provides all the
different ways to activate a shortcut.
So far, these different ways are supported:
- do nothing
- Call a user-provided callback
- Call gtk_widget_activate()
- Call gtk_widget_mnemonic_activate()
- Emit an action signal
- Activate an action from the widget's action muxer
- Activate a GAction
This adds an interface for taking care of shortcut controllers with
managed scope.
Only GtkWindow currently implements this interface, so we need to ensure
that we check if any top-level widget we reach is a shortcuts manager
before we call into it.
And use it.
I just added it to GtkWidget just to show that I can.
The real reason I want it is for gamepad/joystick triggers
in games, so that it becomes possible to select 2 different
triggers (gamepad and keyboard) for the same shortcut.
There is no shape combining going on anymore, so
call this just gdk_surface_set_input_region, and
remove the offset arguments too. All callers pass
0 anyway.
Update all callers and implementations.
This is a huge reorganization of GtkDropTarget. I did not know how to
split this up, so it's unfortunately all one commit.
Highlights:
- Split GtkDropTarget into GtkDropTarget and GtkDropTargetAsync
GtkDropTarget is the simple one that only works with GTypes and offers
a synchronous interface.
GtkDropTargetAsync retains the full old functionality and allows
handling mime types.
- Drop events are handled differently
Instead of picking a single drop target and sending all DND events to
it, every event is sent to every drop target. The first one to handle
the event gets to call gdk_drop_status(), further handlers do not
interact with the GdkDrop.
Of course, for the ultimate GDK_DROP_STARTING event, only the first
one to accept the drop gets to handle it.
This allows stacking DND event controllers that aren't necessarily
interested in handling the event or that might decide later to drop
it.
- Port all widgets to either of those
Both have a somewhat changed API due to the new event handling.
For the ones who should use the sync version, lots of cleanup was
involved to operate on a sync API.
It is enough to just set the parent (and make the parent
call gtk_native_check_resize in size_allocate).
This commit removes the relative_to argument to the
constructors of GtkPopover and GtkPopoverMenu, and
updates all callers.
FIXME: Is this necessary?
Could the surfaces just clamp to 1x1 themselves?
We recently declared that surfaces can decide on whatever size they want
so natives need to inspect the size they requested anyway.
Split the focus tracking into a separate
GtkEventControllerFocus, and change the API one more time.
We are back to having ::focus-in and ::focus-out signals.
Update all users.
Add fields for direct descendents to GtkCrossingData,
and populate them when emitting focus change events.
Also add accessors for these fields to GtkEventControllerKey,
and verify that they are set properly in the focus test.
Not done yet: Do the same for pointer crossing events.
Restructure the getters for event fields to
be more targeted at particular event types.
Update all callers, and replace all direct
event struct access with getters.
As a side-effect, this drops some unused getters.
Instead of relying on gdk's antiquated crossing events,
create a new GtkCrossingData struct that contains the
actual widgets, and a new event controller vfunc that
expects this struct. This also saves us from making sense
of X's crossing modes and details, and makes for a
generally simpler api.
The ::focus-in and ::focus-out signals of GtkEventControllerKey
have been replaced by a single ::focus-change signal that
takes GtkCrossingData as an argument. All callers have
been updated.
These don't take a duration, instead they call g_get_monotonic_time() to
and subtract the start time for it.
Almost all our calls are like this, and this makes the callsites clearer
and avoids inlining the clock call into the call site.
When we use if (GDK_PROFILER_IS_RUNNING) this means we get an
inlined if (FALSE) when the compiler support is not compiled in, which
gets rid of all the related code completely.
We also expand to G_UNLIKELY(gdk_profiler_is_running ()) in the supported
case which might cause somewhat better code generation.
usec is the scale of the monotonic timer which is where we get almost
all the times from. The only actual source of nsec is the opengl
GPU time (but who knows what the actual resulution of that is).
Changing this to usec allows us to get rid of " * 1000" in a *lot* of
places all over the codebase, which are ugly and confusing.
These now render the paintable to a cairo surface and convert that
to a texture. This is sort of a hack, but its only used in two
special cases internally and in two hacky test apps.
If icon lookup fails or if loading it fails later, just always
fall back to the built in image-missing icon. Nobody is handling
missing icons in a sane way anyway.
If you *truly* need to handle missing icons, you need to manually
use gtk_icon_theme_has_icon().
While changing the loading code I also fixed an issue where it
was always passing "png" to pixbuf, now it also handles "xpm" if
that is the filename suffix.
We had a pretty complex setup where we tried to avoid scaling up themes from dirs
that specified a size. However, not only was it very complex, but it didn't quite
work with window scales, because when using e.g. a size 32 directory for 16@2x
the dir size is wrong anyway. Additionally it turns out most code either picks
an existing icon size, or uses the FORCE_SIZE flags, so it doesn't seem
like a useful behaviour.
This change drops the FORCE_SIZE flags, and always scales
icons. Additionally it moves the scaling of the icon to rendering,
which seems more modern, and allows us to (later) share icons loaded
for different sizes that happened to use the same source file (at
different scales).
Note that this changes the behaviour of
gtk_icon_paintable_download_texture() is it now returns the unscaled
source icon. However, ignore thats, as I plan to remove this function
and replace it with a way to render a paintable to a cairo-surface
instead.
1. Rename the thing
2. Turn it from a signal to a vfunc
3. Pass the GtkCssStyleChange to it
We don't export any public API about the GtkCssStyleChange yet, it's
just a boring opaque struct.
Most users were just forgetting to set the proper flags.
And flags aren't the right way to set this anyway, it was just
acceptable as a workaround during GTK3 to not break API.
The API encouraged wrong usage - most of the users were indeed wrong.
Use the correct version instead:
gtk_icon_theme_get_for_display (gtk_widget_get_display ())
The reason for this is simply that I want to get hash functions that
have their values close together, so they can fit in a smaller range
(the goal here is 12 bits). By using GQuark, we get consecutive numbers
starting with 1 (and applications have <1000 quarks usually), whereas
interned strings can be all over the place.
As a side effect we also save 64 bytes per declaration.
Previously, we wrapped all GtkCssShadowValues in a GtkCssShadowsValue,
even if it was just one shadow. This causes an unnecessary bloat in
css values.
Make each GtkCssShadowValue able to handle multiple shadows instead, and
use gtk_css_shadow_value* API everywhere.
The differenciation between a literal color value and an RGBA value
caused problems in various situations. Just treat the two the same but
don't allow access to the rgba value of a non-literal color value.
This gets rid of around 1.6k rgba values in the widget-factory.
This might happen if the CSS values of the decoration node are broken,
e.g. if people *accidentally* type large negative values for the
margins.
Fixes#2268
Decoration node for drawing is used only for client side decorated
windows, but corners from opaque region is subtracted also for
normal windows.
Rename function to better reflect what it does and do not subtract
corners if decoration node was not used for drawing.
The "iconified" state is mostly an X11-ism; every other platform calls
this state "minimized" because it may not involve turning a window into
an icon at all.
Unrealize the GSK renderer before destroying children.
This makes the renderer drop any texture caches that
it might have, so that we don't needlessly download
them when releasing the widget-side holder objects.
As a fortunate side effect, this fixes crashes on
exit with GtkGLArea-containing windows under Wayland.
When processing the list of icons for a window to add them to
_NET_WM_ICON gdk_x11_surface_set_icon_list only adds as many
icon sizes as will fit within X protocol limits.
It achieves this by keeping a running total of the number of
bytes taken up by icons already processed and bails as soon
as it goes over the limit.
The problem is, one 512x512 icon is already over the limit,
and so no icons will get added at all if the first icon in
list is 512x512.
Indeed, the code seems to assume the list is sorted from smallest
icon to biggest icon.
This commit changes the caller to sort the list.
With gtk_window_set_position gone, we should never
come up with a new position to set in this code.
Leave a warning in place and remove the gdk_surface_move
calls.
On Windows that call resizes the native window immediately,
and the corresponding GDK event is emitted and processed
before the control is returned to gtk_window_move_resize().
Therefore, update freeze and configure_request_count increment
must happen before the call, not after it.
I can't think of a case where this is the desired
behavior. So, instead of setting an explicit cursor
on all popups, just stop walking the parents at
surface boundaries.
We want to use a gdk_surface_new_popup for popups,
and align the constructor names with the surface
types, so rename
gdk_surface_new_popup -> gdk_surface_new_temp
gdk_surface_new_popup_full -> gdk_surface_new_popup
The temp surface type will disappear eventually.
Now that roots can have parent widgets, we need to
carefully examine all calls of gtk_widget_get_toplevel,
and replace them with gtk_widget_get_root if we want
the nearest root, and not the ultimate end of the parent
chain.
We had code in gtkwindow.c that generated duplicate,
and defective, focus-change events, in the following
way:
- gtkmain.c generates a chain of focus-change events
for moving focus from one window to another
- gtkwindow.c catches a focus-in event in the middle
of this chain and sets itself as 'active'
- and then it proceeds to generate focus-change
events towards its own focus widget without a
related target
This is not necessary since we gtkmain.c already
generates a complete sequence of focus-change events.
So stop doing it.
Export gtk_widget_root/unroot privately,
make them work on roots, and use them in
gtk_window_set_display. This gets us to a
single way to listen for display changes,
the root property.
When a modal dialog is smaller than its parent,
we were keeping the resize cursor from the dialogs
edge all over the parent window, which looks
really irritating, since the resize cursors are
closely associated with the window edge. Fix
this by falling back to the default cursor
outside the grab widgets surface.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/23
Set the cursor on the surface of the target
widget, not the surface of some of its parents.
This does not make a difference currently.
But it will in the future, when we have
parented widgets with surfaces.
Activating this action will replace other
activate_default apis. It is more flexible,
since intermediate widgets can intercept the
action and do their own handling.
This api wasn't used anywhere in GTK. And since
we've dropped the variant for the default widget,
this one should go too. If it is needed, it should
become and action too.
The skip-taskbar, skip-pager and urgency hints were
only ever implemented for X11, and are not very useful
with modern desktops. Relegate the functionality to
x11 backend api, and drop the GtkWindow api.
This will be used to let the inspector and other users
pick insensitive widgets again. For now, update all
callers to pass no flags, preserving the current
behavior.
...and the setter/getter for it.
This is a very old X session management thing, and you
will be hard-pressed to find a session manager that can
make use of it, and even harder-pressed to find apps
using it to their advantage.
Change the all the begin_drag and begin_move apis in
GdkSurface and GtkWindow to expect surface coordinates.
Update the x11 implementation to translate to root
coordinates where it matters. Wayland is ignoring the
coordinates anyway.
When the window gets active / inactive, we
don't propagate events, but just send focus-in / -out
to the current focus_widget. Improve this by updating
its state flags as well.
Emit focus change events in the same way as crossing events.
Also change the code to only emit focus change events for
the master keyboard - we only maintain a single focus location,
so sending multiple focus change events for different devices
seems confusing.
GtkWindow has a focus_widget that points to the current input focus.
GtkWidget has a focus_child that points to the child that contains
the input focus. Following the focus_child chain from the toplevel
always leads to the focus_widget. We never unset focus_child, we only
set it. We bubble focus change events.
After considerable discussion, we came to the conclusion
that the convenience of this API wins over the correctness
of gtk_window_present_with_time(), in particular since we
don't have a good mechanism to carry timestamps from the
events to the places where we present windows.
When 0 or GDK_CURRENT_TIME is passed to gtk_window_present_with_time(),
print a warning so that the application developer knows that this isn't
a supported use of the function, but carry on working for now.
