The way that GtkTextView et al pop up their context menu is to first
query to see if the clipboard has some text, and if so, enable the Paste
menu item. But since the Wayland backend hasn't had the greatest
selection and clipboard code, the callback for the clipboard got dropped
on the floor.
Add some simple code to respond to the TARGETS selection.
This makes right-clicking on a GtkTextView work fine.
Resize grips were introduced for GNOME 3.0, before we had any of the
"new GNOME app" features like invisible borders and CSD. With OS X 10.6
and 10.7, Apple has replaced the classic grips in their applications
with invisible borders as well.
New GNOME app designs don't use resize grips anymore and the new
default theme for GTK+, Adwaita, disables them entirely by forcing their
width and height to 0.
They're past their time. Remove the code to support them. This can
always be reverted if some app relies on them.
We decided in f8412eca34 that
we still need to react to these for a11y reasons, but left
the (then) harmless property deprecation in place. Now, the
deprecation causes runtime warnings for merely reading the
property, so drop it.
https://bugzilla.gnome.org/show_bug.cgi?id=732667
.scrollbars-junction borders were removed by setting border-stylei: none,
it interacted (why?) with the scrollbars on sidebar, making the border
transparent seems not to have side effects there.
When showing and hiding the inspector window repeatedly without
dismissing the dialog, we were hiding the inspector, but not
the dialog, leading to a confusing user experience.
https://bugzilla.gnome.org/show_bug.cgi?id=732443
Applications can call this to determine if they should an app menu.
This will be %FALSE on desktop environments that do not have an
application menu like the one in gnome-shell. It is %FALSE on Windows
and Mac OS.
Applications are completely free to totally ignore this API -- it is
only provided as a hint to help applications that may be interested in
supporting non-GNOME platforms with a more native 'look and feel'.
https://bugzilla.gnome.org/show_bug.cgi?id=722092
We were only setting the state transiently in ::draw, leading
to various drawing anomalies, such as labels not picking up
the appropriate color from BUTTON styles.
This is expected to happen on wayland and other platforms with no primary selection,
and just leads to the selected text being cleared after any attempt to change the
text selection itself through either mouse/keyboard.
This is expected to happen on wayland and other platforms with no primary selection,
and just leads to the selected text being cleared after any attempt to change the
text selection itself through either mouse/keyboard.
When there area explicitly added buttons in the action area,
we were trying to ensure that the action area is visible,
but failed, since we are now hiding the action_box. Fix it
by showing the action_box when things are left in the action
area.
We don't set use-header-bar for message dialogs, since we
want the buttons in the action area, but we do want a nice
rounded csd titlebar. Add back the box that was used before
to achieve this, when appropriate.
Give GtkAboutDialog buttons in the action area instead of hard-coding
use-header-bar to TRUE. This is for environments which don't have the
Gtk/DialogsUseHeader xsetting turned on.
https://bugzilla.gnome.org/show_bug.cgi?id=730893
We use gtk_adjustment_enable_animation to enable animated
updates of the adjustments. Currently, this is enabled
unconditionally, and with a duration that is hardcoded.
https://bugzilla.gnome.org/show_bug.cgi?id=732376
Add a private API that lets widget opt-in to animated updates of
the adjustment value. When enabled, all calls to
gtk_adjustment_set_value will smoothly transition from the old
value to the new value, using a fixed easing function and a
configurable duration. The animation is tied to the frame clock
of the widget.
By implementing this in GtkAdjustment, we can enable animation
for both scrollbars and keybindings, which are often implemented
in the child widget of the scrolled window.
https://bugzilla.gnome.org/show_bug.cgi?id=732376
This makes it possible to look up icons in resources using
the icon theme api, and should be used as a replacement
for installing icons below $pkgdatadir/icons and adding
that location to the search path.
Make icon lookup from resources work without the extra hicolor
component in the path. It is redundant, since we always treat
builtin icons as part of hicolor anyway.
Grabbing on a non-toplevel might not do what we want it to do, since it
will go on the focused widget, not the grabbed widget. Since we don't
focus the widget before clicking on it, that means that putting the
focus somewhere else and then clicking on the accelerator editor will
freeze the app. Additionally, since it's a global system grab that can't
be exited except by a key press that we won't ever get, it effectively
locks up your system as well unless you know how to break the grab or
kill the app. Ouch.
Since doing a device grab on a non-toplevel is generally considered a
bad idea, just don't do it. Use a GtkInvisible and take a grab on that
instead.
When validating the style context, we are copying the animations
from one StyleValues instance to another, and cancel the old ones.
It turns out that sometimes the old and the new StyleValues are
the same, and in this case, we end up cancelling the animations
for good.
One case where breakage from this was observed is that the spinners
in gtk3-widget-factory stop spinning when you open and close a modal
dialog on page 2. This depends a bit on the window manager; the problem
can only be seen if opening the dialog causes a transition to backdrop.
This changes the calculation of activity mode progress in the
same way as was done in GtkProgressBar a while ago, and make it
smooth, using a tick callback.
We want to stop people from using configure events
entirely. GtkDrawingArea synthesizes a configure event, but we can just
make the only user of this functionality stop it, and correct the
documentation to not mention it.
GtkCheckButton sets a different initial value for this property without
actually changing the declared default, and then relies on change notification
to update other properties (such as xalign). This, combined with glades
insistance on putting default values into ui files creates a situation
where we can't remove the redundant notification for ::draw-indicator
without causing lots of checkboxes to suddenly have centered labels.
This was seen in gnome-terminal, evolution, and other applications.
Therefore, keep the extra notification for now. This can be revisited
when we clean up the button hierarchy.
Instead of code that internally does weird things, use the FLAT style
class if has-frame is FALSE and remove it otherwise.
Based on a patch by Benjamin Otte.
https://bugzilla.gnome.org/show_bug.cgi?id=732256
fixup entry
This commit makes button always draw background and frame.
Buttons with relief none get a new style class, FLAT, which
allows themes to style these buttons as they like.
We also (finally) mark GTK_RELIEF_HALF as deprecated. It
has never done anything different from GTK_RELIEF_NORMAL.
https://bugzilla.gnome.org/show_bug.cgi?id=732256
Translate shadow != None into the FRAME style class.
This doesn't change the style classes used for drawing,
it only sets the style class permanently instead of
saving and restoring in draw().
https://bugzilla.gnome.org/show_bug.cgi?id=732256
Translate shadow != None into the FRAME style class.
This doesn't change the style classes used for drawing,
it only sets the style class permanently instead of
saving and restoring in draw().
https://bugzilla.gnome.org/show_bug.cgi?id=732256
Since we have a paint clock, we shouldn't be sending out EXPOSE events
for OR windows inside the ALLOCATE cycle. The idea here was that we
would have to wait for a map to get an OR window to paint to, but since
then this has been abstracted away inside GDK and the paint clock.
We already update the grip position in _gtk_window_set_allocation, which
is done through the size_allocate above. Receiving a ConfigureNotify
also won't ever change a grip's visibility, so there's no point in
refreshing it.
We want to stop people from using configure events
entirely. GtkDrawingArea synthesizes a configure event, but we can just
make the only user of this functionality stop it, and correct the
documentation to not mention it.
The template documentation is lacking inlined examples on how to use the
templates API, like binding children and callbacks. This makes looking
for best practices a bit harder than it ought to be, for a feature this
useful.
If the event triggers GtkGesture::begin, and the handler ends up resetting
the gesture (say, due to taking a grab somewhere else within the handler),
still take the event as "managed", as it actually triggered recognition,
even if just to end abruptly.
https://bugzilla.gnome.org/show_bug.cgi?id=731711
Prevent a segfault in unknown circumstances, and break the ignore
deprecations wrapper out from the if statement so that we don't
cover too much ground by accident.
This reverts commit b875572f2a.
Apps like Abiword, gnumeric and gnome-chess, and toolkits like
ClutterGTK were all using this for various purposes, and this made them
break. Bring back this feature for now.
It still won't work under Wayland.
This functionality is only exercised by gnome-shell, currently.
Therefore, forgetting to copy a field here means an instant
gnome-shell crash :-(. More tests needed.
Recent changes made it a breaking mistake to install symbolic icons
of the wrong size into a theme directory, or into the legacy unthemed
icon location.
Since this change affects many apps, do the extra work to keep these
icons working, but emit warnings, in the hope that this will lead to
cleaning up the mess over time.
The -gtk-icontheme() function not have any automatism for
symbolic or rtl variants built-in, instead, we expect the theme
to use selectors to provide the right icon for each situation.
The recent icon theme scaling changes make the code more
sensitive to mis-sized icons (e.g. application icons in
the app chooser). A single row whose size gets blown out
of proportion by a big icon is never wanted in a list.
We can avoid this situation by telling GtkIconHelper to
force-scale the pixbuf to the requested size.
When force_scale_pixbuf is set, the icon helper will scale the
icon to the requested size (either the pixel size, or the resolved
icon size), so we can just as well instruct the icon theme code
to do the scaling for us.
Reuse the scale information that we have from loading icons
normally, when loading a symbolic icon, so that we apply the
same size constraints.
This commit assumes that svgs have the nominal size of the
directory they are in, which will be true for all current
symbolic icons.
Previously, we were taking thresholds and min/max sizes into
account when choosing the best theme dir, but when it came
to loading the icon, we always scaled icons from scalable
directories all the way, ignoring the min/max size limits.
This commit changes things around so that we now load icons
in Threshold directories at their nominal size, and scale
icons in Scalable directories only up to the specified limits.
To override this and keep the previous behaviour of scaling
all the way to the desired size, use the GTK_ICON_THEME_FORCE_SIZE
flag.
There's nothing better we can do for this case, now that we always
redirect drawing to a temporary pixmap. Maybe since this is already
X11-specific code, we should just do everything with Xlib directly.
gtk_widget_set_double_buffered is now deprecated, and we don't support
non-double-buffered widgets. This means that under normal circumstances,
paints are never outside of a begin_paint / end_paint sequence, which
natively-double-buffered backends like Wayland can't possibly support.
Add /org/gtk/libgtk/icons as a resource path, and ensure
that we always parse an index.theme file for hicolor which
makes the builtin icons available as part of the hicolor theme.
We add a new API, gtk_icon_theme_add_resource_path, which
can be used to add resource path as a base location for
icon theme content, similar to gtk_icon_theme_append_search_path.
We're going to require a complete icon theme, and we have
a test that checks for all the icons we use, so there is
no need to include all these fallback icons.
Regions are done in a very non-css way. They don't fit the DOM in that
they don't integrate into the CSS tree and they have very weird matching
behavior in selectors.
So I'm deprecating them now. GtkNotebook and GtkTreeview will continue
to use them and as long as they do, we can't remove the code for it.
But once those are ported it might be safe to remove the code as it will
clean up lots of places in the code by quite a bit.
The rubberband rendering code was assuming that we just have
a 1-pixel border and the rest of the rubberband is uniform.
That is not a safe assumption to make with css-styled
rubberbands, so remove it.
The rubberband rendering code was assuming that we just have
a 1-pixel border and the rest of the rubberband is uniform.
That is not a safe assumption to make with css-styled
rubberbands, so remove it.
Paradoxically, we were loading svgs at the nominal size when
FORCE_SIZE is specified, while scaling them exactly when it
isn't.
../build/win32/vs10/gtk.vcxproj
When we switched the default for gtk-update-icon-cache to
not include image data, we should have thought about the
builtin icons. For them, we rely on image data being included.
This made the notify test fail in gnome-continuous, where we
build from git and always regenerate the builtin cache.
This pushes the initialization of is_svg to an earlier point
when the GtkIconInfo is created. This is needed because an icon
info doesn't necessarily always have a filename that we can later
extract the suffix from. For instance, builtin icons have NULL
filename.
https://bugzilla.gnome.org/show_bug.cgi?id=721895
We want to have the "-gtk-" prefix for our custom CSS properties. But
we also want to parse names starting with a "-" as style properties.
So make sure that "-gtk-" is treated like a normal property and we emit
errors when somebody uses it wrong.
This is to catch errors with people typing
-gtk-iconsource: none;
instead of the correct
-gtk-icon-source: none;
