This patch makes gtk_widget_set_parent_window() undo the toplevelness
of a GtkWindow, GtkWindow then realizes itself as a normal child widget
and behaves like a normal GtkBin by checking gtk_widget_is_toplevel() in
several places (show/hide/map/unmap/draw/size_allocate/check_resize/configure_event).
GtkWindow was only releasing the application in finalize, causing
problems for language bindings. Now we release it already in destroy
(and then again in finalize for good measure).
https://bugzilla.gnome.org/show_bug.cgi?id=638580
The functions to set frames on windows stopped being interesting
when the linux framebuffer port was dropped, many years ago.
Similar functionality may come back with client-side decorations
in the future.
Requires fixes to GtkContainer and GtkWindow to unmap their
children, rather than just withdrawing or hiding the container
window.
Requires fix to GtkHandleBox to chain up to GtkContainer unmap.
Historically we avoided these unmaps for efficiency reasons,
but these days it's a bigger problem that there's no way
for child widgets to know that one of their ancestors has
become unmapped.
In the process of removing all sealed members from headers.
At the same time, add a gtkwindowprivate.h header and move
all internal functions from gtkwindow.h there.
- add slots for damage-event, move-focus and keynav-failed
- reorder signals a bit so related stuff is grouped together
- some indentation fixes in the GtkWidgetClass
- remove the move-focus compat hack from GtkTextView
- turn the move-focus compat hack in GtkWindow into properly
implementing GtkWidget::move-focus()
The gtkprivate.h header contains GtkWidget-specific private symbols that
are not useful except in a handful of cases. Basically everything
includes gtkprivate.h for the GTK_PARAM_* macros.
https://bugzilla.gnome.org/show_bug.cgi?id=632539
Safe space in the private struct, always set the cursor when we
update visibility, since the cursor depends on resizability conditions
too. And don't set the shape needlessly.
This was caused by get_drag_edge() returning -1 to mean 'no drag',
but callers didn't really pay attention. Change get_drag_edge()
to return a boolean instead.
If you set a geometry widget via gtk_window_set_geometry_hints() it
becomes very hard to compute appropriate toplevel sizes in pixels
to make the window a particular size. Synthesizing strings and passing
them to gtk_window_parse_geometry() is possible, but to avoid
avoid such ugliness, add functions:
gtk_window_set_default_geometry()
gtk_window_resize_to_geometry()
That act like gtk_window_set_default_size() and
gtk_window_resize() but are in terms of the resize increments of the
geometry widget.
https://bugzilla.gnome.org/show_bug.cgi?id=631796
gtk_window_parse_geometry() gets the size of the window in order
to interpret the position of the window; calling it before, say,
calling gtk_widget_show_all() on a window is a subtle trap, so
add a warning in the case we can easily detect.
https://bugzilla.gnome.org/show_bug.cgi?id=631794
The geometry widget feature of gtk_window_set_geometry_hints() has
never really worked right because the calculation that GTK+ did to
compute the base size of the window only worked when the geometry
widget had a larger minimum size than anything else in the window.
Setup:
* Move the GtkSizeGroup private functions to a new private header
gtksizegroup-private.h
* Add the possibilty to pass flags to _gtk_size_group_queue_resize(),
with the flag GTK_QUEUE_RESIZE_INVALIDATE_ONLY to suppress adding
the widget's toplevel to the resize queue.
* _gtk_container_resize_invalidate() is added to implement that feature
* _gtk_widget_override_size_request()/_gtk_widget_restore_size_request()
allow temporarily forcing a large minimum size on the geometry
widget without creating resize loops.
GtkWindow:
* Compute the extra width/height around the geometry widget
correctly; print a warning if the computation fails.
* Always make the minimum size at least the natural minimum
size of the toplevel; GTK+ now fails badly with underallocation.
* Always set the base size hint; we were failing to set it
properly when the specified minimum size was overriden, but
it's harmless to always set it.
Tests:
* New test 'testgeometry' that replaces the 'gridded geometry' test
from testgtk. The new test is roughly similar but creates a bunch
of windows showing different possibilities.
* The testgtk test is removed. No need to have both.
https://bugzilla.gnome.org/show_bug.cgi?id=68668
1,936 (112 direct, 1,824 indirect) bytes in 4 blocks are definitely lost in loss record 13,453 of 13,673
at 0x4005BDC: malloc (vg_replace_malloc.c:195)
by 0x69615A1: cairo_region_create (cairo-region.c:196)
by 0x683BFBF: gdk_cairo_region_create_from_surface (gdkcairo.c:455)
by 0x670C882: set_grip_shape (gtkwindow.c:5020)
by 0x670CFBF: resize_grip_create_window (gtkwindow.c:5271)
by 0x670C466: gtk_window_realize (gtkwindow.c:4902)
Signed-off-by: Benjamin Otte <otte@redhat.com>
This is safer, since GtkWindow subclasses may override realize
and end up with has_resize_grip == TRUE, but grip_window still
being NULL - as is the case with GtkPlug.
We need to position the grip window in size_allocate after all,
otherwise the grip ends up in the wrong place when the window
is realized early.
Also, avoid shadowing a variable.
This was another case of making sure size-request was called
before other code was doing get_child_requisition(), now caching
is done via the same api so no need for that line.
Allow any window to display a resize grip, in the south-east or
south-west corner, depending on text direction. This is implemented
as a shaped window that gets overlayed on top of whatever content
is there. We add api that allows widgets to avoid the resize grip,
if desired.
The ::has-resize-grip property controls if a window may display
a resize grip. It will only be displayed if the window is resizable
and not maximized.
The size and visual appearance of the resize grip is under theme
control, using the resize-grip-width/height style properties and
the paint_resize_grip style function.
It doesn't make sense to keep them separate as GtkSizeRequest requires a
GtkWidget and GtkWidget implements GtkSizeRequest, so you can never have
one without the other.
It also makes the code a lot easier because no casts are required when
calling functions.
Also, the names would translate to gtk_widget_get_width() and people
agreed that this would be a too generic name, so a "preferred" was added
to the names.
So this patch moves the functions:
gtk_size_request_get_request_mode() => gtk_widget_get_request_mode()
gtk_size_request_get_width() => gtk_widget_get_preferred_width()
gtk_size_request_get_height() => gtk_widget_get_preferred_height()
gtk_size_request_get_size() => gtk_widget_get_preferred_size()
gtk_size_request_get_width_for_height() =>
gtk_widget_get_preferred_width_for_height()
gtk_size_request_get_height_for_width() =>
gtk_widget_get_preferred_height_for_width()
... and moves the corresponding vfuncs to the GtkWidgetClass.
The patch also renames the implementations of the vfuncs in widgets to
include the word "preferrred".
Add gtk_window_set_visual() and a "visual" property. This allows
changing the window visual to the rgba one and other awesome things
(like implementing the trayicon spec).
The keysyms create a lot of potential namespace conflicts for
C, and are especially problematic for introspection, where we take
constants into the namespace, so GDK_Display conflicts with GdkDisplay.
For C application compatiblity, add gdkkeysyms-compat.h which uses
the old names.
Just one user in GTK+ continues to use gdkkeysyms-compat.h, which is
the gtkimcontextsimple.c, since porting that requires porting more
custom Perl code.
_gtk_window_reposition() was only some extra confusing code, internally
it only calls the public API gtk_window_move()... replaced calls to
_gtk_window_reposition() with direct calls to gtk_window_move() and
removed the redundant internal API (probably there only for some historical
reason).
These have been deprecated and removed from master.
GtkWindow:resizable should be used instead.
This completes commit 1a03a65e36
Reported by Benjamin Otte
Focus out could lead to the widget being destroyed (for example,
in editable cell renderers when DnD starts), so keep the widget
alive while iterating through the devices.
This commit makes a few massive changes to the extended layout
code:
a.) gtkextendedlayout.c --> gtksizerequest.c
b.) _is_height_for_width --> get_request_mode()
c.) get_desired_size(), get_desired_width(), get_desired_height() -->
get_size(), get_width(), get_height()
This is the first partial commit and only effects portions
of the tree that have already been merged in master (in order to
easily cherry pick this commit).
Conflicts:
gtk/Makefile.am
gtk/gtk.h
gtk/gtk.symbols
gtk/gtkextendedlayout.h
This commit changes gtk_extended_layout_get_desired_size() for
per dimension variants. Furthermore this commit reverts the actions
done in size-groups for now as it needs a different approach.
The natural width/height parameters added to aux_info have been changed
for a per width cache for heights and a per height cache for widths.
gtk-demo is still working, currently sizegroups are not taken
into account as mentioned above - size groups need to be alerted both
when the widths and heights are updated independantly and then that
information needs to repropagate also to other extended layout implementors.
GtkWindow now requests the minimum width for the natural height
of its child, or the opposite; depending on ->get_height_for_width.
Currently its not done for GTK_WINDOW_POPUP windows as the menushells
aren't working right yet.
This commit was created using a script that searched for all docstrings
containing a parameter and the string 'or %NULL'.
Gdk backends and demos excluded as they are not part of a public API
https://bugzilla.gnome.org/show_bug.cgi?id=610474
Deprecate widget flag macros GTK_WIDGET_STATE, GTK_WIDGET_SAVED_STATE,
GTK_WIDGET_FLAGS, GTK_WIDGET_TOPLEVEL, GTK_WIDGET_NO_WINDOW and
GTK_WIDGET_COMPOSITE_CHILD.
Also deprecate the type macros GTK_WIDGET_TYPE, GTK_OBJECT_TYPE_NAME and
GTK_OBJECT_TYPE which have become redundant.
Instances of GTK_WIDGET_TOPLEVEL are replaced with gtk_widget_is_toplevel,
GTK_WIDGET_TYPE is replaced with G_OBJECT_TYPE, GTK_WIDGET_COMPOSITE_CHILD
is replaced with use of the "composite-child" property and uses of
GTK_WIDGET_NO_WINDOW are adjusted to use gtk_widget_get_has_window.
Uses of GTK_WIDGET_SAVED_STATE and GTK_WIDGET_FLAGS inside GtkWidget are
changed to direct flag usage.
Documentation is updated to refer to gtk_widget_set_has_window and
gtk_widget_get_has_window.
Gail and tests are updated as well.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=69872
...and show them in menus when navigating the menu with the keyboard.
This is similar to what other platforms do, and reduces visual clutter.
There is a setting to control this. Most of the work on this patch was
done by Thomas Wood. See bug 588554.
This patch adds Since: 2.4 tags to gtk_bindings_activate_event,
gtk_window_propagate_key_event and gtk_window_activate_key.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=604859
Signed-off-by: Javier Jardón <jjardon@gnome.org>
The Gtk-custom.c file in gir-repository contained a number of
introspection annotations. Merge those into the GTK source files.
Some documentation was moved from the tmpl/ files to accomodate
the addition of annotations.
This commit was created using a script that searched for all docstrings
containing a parameter and the string 'or %NULL'.
Gdk backends and demos excluded as they are not part of a public API
https://bugzilla.gnome.org/show_bug.cgi?id=610474
Deprecate widget flag macros GTK_WIDGET_STATE, GTK_WIDGET_SAVED_STATE,
GTK_WIDGET_FLAGS, GTK_WIDGET_TOPLEVEL, GTK_WIDGET_NO_WINDOW and
GTK_WIDGET_COMPOSITE_CHILD.
Also deprecate the type macros GTK_WIDGET_TYPE, GTK_OBJECT_TYPE_NAME and
GTK_OBJECT_TYPE which have become redundant.
Instances of GTK_WIDGET_TOPLEVEL are replaced with gtk_widget_is_toplevel,
GTK_WIDGET_TYPE is replaced with G_OBJECT_TYPE, GTK_WIDGET_COMPOSITE_CHILD
is replaced with use of the "composite-child" property and uses of
GTK_WIDGET_NO_WINDOW are adjusted to use gtk_widget_get_has_window.
Uses of GTK_WIDGET_SAVED_STATE and GTK_WIDGET_FLAGS inside GtkWidget are
changed to direct flag usage.
Documentation is updated to refer to gtk_widget_set_has_window and
gtk_widget_get_has_window.
Gail and tests are updated as well.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=69872
...and show them in menus when navigating the menu with the keyboard.
This is similar to what other platforms do, and reduces visual clutter.
There is a setting to control this. Most of the work on this patch was
done by Thomas Wood. See bug 588554.
This patch adds Since: 2.4 tags to gtk_bindings_activate_event,
gtk_window_propagate_key_event and gtk_window_activate_key.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=604859
Signed-off-by: Javier Jardón <jjardon@gnome.org>
The Gtk-custom.c file in gir-repository contained a number of
introspection annotations. Merge those into the GTK source files.
Some documentation was moved from the tmpl/ files to accomodate
the addition of annotations.
GPOINTER_TO_UINT() *does* drop the upper 32 bits on 64-bit
Windows. After all, it by definition produces a (32-bit) unsigned int.
The GLib commit mentioned in the reverted commit's log message just
means that it does this without any compiler warning about casting
from pointer to integer of smaller size, as it first casts to a 64-bit
integer, then casts that to a (32-bit) int.
We must use the GdkNativeWindow cast here so that on 64-bit Windows
the gpointer data in embedded_list is converted to a (64-bit) native
window handle without going through 32-bit truncation. If ifdefs are
required to avoid compiler warnings on X11, so be it then. Probably it
would be best to introduce a GDK_GPOINTER_TO_NATIVE_WINDOW() macro in
gdktypes.h.
This reverts commit 78151dc7d4.
Zero width/height is unsupported and will magically be turned into one.
For instance, gtk_widget_size_allocate() will eventually do this magic
on the value stored in widget->allocation.
However, if we don't do this magic conversion early, then the value
returned from gtk_window_compute_configure_request() will not be
comparable with whats stored in widget->allocation. (I.E. they will
differ if width or height are zero).
This is dangerous, as we do such a comparison in gtk_window_move_resize().
Currently a change from e.g. 10x1 (current allocation) to 10x0 (new size)
will be expected to produce a ConfigureNotify, when it actually won't,
thus never thawing the frozen toplevel.
Fixes bug #588059
