| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
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 comment referenced GTK_TOPLEVEL which has been replaced by
GTK_WINDOW_TOPLEVEL.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This call was forcing needless work since gtk_window_map() already
does a gdk_window_show() which initially sets GDK_WINDOW_STATE_FOCUSED
that we then handle regularly on the widget's window state event
handler.
https://bugzilla.gnome.org/show_bug.cgi?id=673237
|
|
|
|
|
|
| |
When we don't do that, we completely botch sizing popups. Not good.
Fixes remaining failing reftests
|
|
|
|
|
| |
GtkContainer::need_resize and GtkWidget::alloc_needed are the same
thing.
|
|
|
|
| |
Otherwise the inherit properties won't inherit properly.
|
|
|
|
|
| |
Most of these are forgotten :'s and similar details
which gtk-doc now warns about.
|
| |
|
| |
|
|
|
|
|
| |
The attached popup doesn't take ownership of its "parent" widget, so
ref_sink() was wrong, and caused widgets to be leaked.
|
| |
|
| |
|
|
|
|
| |
Based on a patch by Carlos Garcia Campos, bug 668248
|
|
|
|
|
|
|
| |
This call has no effect and with the newly-added restrictions it's
violating the set-application-after-realized rule.
https://bugzilla.gnome.org/show_bug.cgi?id=668203
|
|
|
|
|
|
| |
This reverts commit d4fe912879ce1b19490ba5729f67a27b1cf397c9.
This patch caused some unanticipated compatibility issues.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
gtk_window_get/set_attached_to() is a new API that allows for windows to
be attached to a GtkWidget.
The attachment is a logical binding between the toplevel window and the
widget that generated it; this kind of information is currently used to
propagate style information from the widget to the window, but is also
useful e.g. for accessibility.
https://bugzilla.gnome.org/show_bug.cgi?id=666103
|
|
|
|
|
|
|
| |
This allows subclass to get the value of this property in their constructed
method.
https://bugzilla.gnome.org/show_bug.cgi?id=667628
|
|
|
|
|
|
|
|
| |
'window-unfocused' is too long and mentions "focus" which is historically
loaded with the meaning "input focus".
'backdrop' isn't generally used in GUI speak and still conveys the state the
widgets in an unfocused or background toplevel window are in.
|
|
|
|
|
|
|
| |
This also removes setting the FOCUSED state flag when
gtk_window_has_toplevel_focus() since this effect can now be done with the new
WINDOW_UNFOCUSED flag instead which actually works better regarding X grabs
and modal windows.
|
|
|
|
|
|
|
| |
This reverts commit 730765de9163934d9993b25a87f076f1b36ed271.
This needs more thought, committing it on the same day as filing
the bug was premature.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=667438
|
| |
|
|
|
|
|
| |
This is needed for the prototype of gtk_widget_reset_rc_styles, to avoid
C4013/implicit declaration of ... warnings of that function
|
|
|
|
| |
And advertise their location on the bus using X11 properties.
|
|
|
|
| |
This will allow gnome-shell to reference it.
|
|
|
|
|
| |
This uses the new workarea API to avoid placing popups underneath
panels, docks, etc.
|
|
|
|
|
|
|
|
|
|
|
| |
For maximized windows, titlebars cannot be used to reposition or
scale the window, so if an application does not use it to convey
useful information (other than the application name), the screen
space occupied by titlebars could be put to better use.
Add a new window property which requests from the window manager
to hide titlebars when windows are maximized to account for this.
https://bugzilla.gnome.org/show_bug.cgi?id=665616
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of painting the window background on the grip_window we now
only paint it on the GtkWindow->window, and we make the grip_window
have a transparent background.
We can't really make transparent window handle background optional
via css atm, because the handle color is actually based on the
background color, so if that is set to transparent we won't draw
anything.
|
|
|
|
|
|
|
|
|
| |
gdk_cairo_region_create_from_surface doesn't work correctly on PPC.
This is most prominently seen with the GTK window resize grip, the
shape of which is mirrored every eight pixels horizontally.
At the same time, use an A1 surface for the resize grip shape to
eliminates an A8->A1 surface conversion.
|
| |
|
|
|
|
|
|
|
| |
This allows themes to style widgets differently according to whether the
toplevel window they are in is presented as focused.
https://bugzilla.gnome.org/show_bug.cgi?id=661428
|
|
|
|
|
|
|
|
| |
We have an event, so the correct thing to do is to pass
the device into the function that we are calling. GDK
just grew a variant that takes a device, for this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=663444
|
|
|
|
| |
Remove unneeded variable and delete trailing whitespace.
|
|
|
|
|
| |
Mostly making sure that return values and varargs don't loose
their docs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit introduces a new setting, gtk-visible-focus, backed
by the Gtk/VisibleFocus X setting. Its three values control how
focus rectangles are displayed.
'always' is equivalent to the traditional GTK+ behaviour of always
rendering focus rectangles.
'never' does what it says, and is intended for keyboardless
situations, e.g. tablets.
'automatic' hides focus rectangles initially, until the user
interacts with the keyboard, at which point focus rectangles
become visible.
https://bugzilla.gnome.org/show_bug.cgi?id=649567
|
|
|
|
|
|
| |
While doing this, drop the get_mdi_zorder implementation
that really should come from the window manager side. Dropping
this saves some 500 lines.
|
|
|
|
| |
Nothing is using gtkrc.h functionality any more.
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=651707
|
|
|
|
|
|
|
|
|
|
| |
Don't rely on priv->resize_grip_visible as the code comment in the
variable declaration indicates.
This fixes warnings with GtkPlug, which can cause resize_grip_visible to
be TRUE but grid_window to be NULL - running tests/teststatusicon
reproduces this.
This broke with 7ef113ce56a75641175af31267e2075f634267e0
|
|
|
|
|
| |
Previously, we would also show mnemonics if the user hits
Ctrl+Alt, even though Ctrl+Alt+<x> does not actually trigger.
|
|
|
|
|
|
|
| |
With gtk-auto-mnemonics on, we hide mnemonics on focus out. We should also
check if the modifier is pressed on focus in and if so, show mnemonics again.
https://bugzilla.gnome.org/show_bug.cgi?id=618815
|
|
|
|
|
|
| |
Previously, we were trying to size them by the default size, but then
setting the minimum size as the geometry hints' minimum and maximum
size.
|
|
|
|
|
|
|
| |
Don't use the guessed size when we are interested in the minimum size.
So now we can really shrink menubars.
This reverts parts of 08b2ac1d90b4f3dfa76d6a76fa04ca28c6b7ba12
|
| |
|
|
|
|
| |
Messed something up there...
|