When matching a widget against the set of rules we currently iterate
over *all* rules in the theme, trying to match them until we fullfill
our needs. This takes a pretty long time since themes have a lot of rules.
This is the first step towards making this faster. Every time the
ruleset changes we pre-calculate a decision tree where the nodes are either
list of rules to match against, or checks, such that if the check fails
we can ignore a whole subset of the tree.
The tree is built up in two levels, first we check if certain states must
be set, ignoring whole branches if not. Then in the level below we look
for css classes which are used by many rules.
At the leaf nodes we store references to the full list rulesets. These are
stored as array offset, which are sorted in index order, which means css prio
order, as the rulesets are sorted by that.
With this in place we can quickly prune large parts of the tree and then
merge the non-pruned result into a much smaller list of rules that we
need to do full checking on.
This adds the following private methods:
_gtk_css_selector_get_primary_state_flags
_gtk_css_selector_get_primary_classes
_gtk_css_selector_has_primary_class
They get state and classes for the primary selector (i.e. the rightmost
simple selector). This will be used for some css optimizations.
Its pretty common to have a selector like :selected:active where
two or more state flags appear in a row. Right now we save
these as multiple GtkCssSelectors, but as state is a bitfield we
can easily join them. We do this in the simple case where the
state matchers are directly adjacent by just piggybacking on
a previous pseudoclass if there is one.
When event capturing is enabled, stop propagating scroll events
at insensitive widgets, but don't handle them (don't return TRUE),
so they can bubble up again and reach their handling widgets.
Activate the "hides on deactivate" behavior for splashscreens,
torn-off menus, utility windows, tooltips and notifications: when
another application is brought to the front, these windows are hidden
so as not to obscure it. This is the expected behavior for
application-specific floating windows on OS X.
(cherry picked from commit 0596f5591f)
Render a background with gtk_render_background() in draw() instead.
Note that we still use gtk_style_context_set_background() for the header
window.
https://bugzilla.gnome.org/show_bug.cgi?id=688744
Make it so that the repeating vs normal test only uses sharp color
cutoffs instead of real gradients. That removes rounding errors and
makes the test pass.
so GtkMenu works properly. This is not right, but not more
wrong than always sending GDK_NOTIFY_ANCESTOR either.
(cherry picked from commit 35a9322e45)
Based on a patch from Paul Davis, inject synthetic enter events directly
into the Quartz event stream, instead of trying to synthesize them in GDK.
This seems to magically fix most combo box popup weirdness, I guess
some code is relying on a specfic order of events, or any other state
imposed by the "proper" code path of events coming in the usual way.
The patch also removes _gdk_quartz_events_send_enter_notify_event()
which is now obsolete.
(sortof cherry-pixked from 979e5061a0
but needed manual editing because GdkQuartzWindow.c was renamed
and apparently earlier patches not picked correctly/completely)
so they can appear on top of popup menus. Also, reorder the switch()
statement in window_type_hint_to_level() so it resembles the stacking
order, to avoid confision like this in the future. Fixes bug 688512.
(cherry picked from commit 1a2509a6ab)
Don't try to handle button press events on the window frame, they
have out-of-window coordinates. Also, break grabs on such events
so popup menus go away.
Patch from Kristian Rietveld, fixes bug 684419.
(cherry picked from commit 43e1354b71)
This reverts the size_allocate removal from commit
8449e05865. That code was using
_gtk_window_set_allocation() instead of gtk_widget_set_allocation(). And
that broke glade.
We can set for_size to -1 earlier than we did. Doing so makes sure we
only cache one value (as we should in the first place). In GTK 3.6, this
worked properly, but with Previously, this check was moved further up to
avoid interacting with size groups. But after recent refactorings, size
groups are handled way earlier anyway.
... instead of GtkSizeGroupMode. Orientation is what we're interested in
after all. When we need a GtkSizeGroupMode, we can do the translation
where we need it.
which does not really have a different effect than the previously
used NSPopUpMenuWindowLevel, but is what all code examples I found
are using, and it does make more sense.
(cherry picked from commit 47f0e3f1e1)
Application code can set shortcut folders that are already bookmarks.
This code causes the bookmarks to be refreshed after the shortcut is
added removing any possible bookmark duplicates
https://bugzilla.gnome.org/show_bug.cgi?id=577806
Expose GtkEntry icons as child accessibles of a GtkEntry, and provide
actions to simulate clicking them. Also, refactor the a11y children test
slightly to add a test.
https://bugzilla.gnome.org/show_bug.cgi?id=686347
The bitmasks with the 31st, 32nd and 63rd bit set are added. The make up
the largest bitmasks on 32bit/64bit that can be represented without
allocating and the smallest bitmask on 32bit that must be allocated.
With the fix in 77912a65e2, another bug
got visible: booleans are 32 bits, so if the intersection between the 2
bitmasks happened in higher bits, the return value would be truncated to
FALSE.
This actually made slider handles disappear, so it was pretty visible.
BIG NOTE: We fail on some of these to give the colors defined in the CSS
specs. This is not good, but I'm not sure how to best fix it.
For those cases, I've kept the correct color in the CSS file but added
the correct one next to it.
If lookup->missing is empty we don't need to continue looking.
We short circuit in several places as this can happen
after iteratively makeign lookup->missing smaller.
We need to use the allocated codepath if *any* argument is
allocated, not if one arg is not allocated.
This bug caused unnecessary calls to _gtk_bitmask_is_allocated,
as well as return completely wrong result if both bitmask are
allocated.
What is this bin doing with all these crazy deltas? Company does:
<Company> that can safely be removed
<Company> in general, code that isn't obvious can either be understood
<Company> with a bit of thinking or it can be removed
<Company> if in doubt, go for the 2nd of those :)
Most GtkBin subclasses override this strange garbage anyway, so it's
not like this code is ever *run*, per se. Just make it proxy directly
to the child, and hope nothing goes wrong.
Implement get_preferred_width, get_preferred_height, and size_allocate.
This allows GtkBin subclasses to be quick and easy, without the
author doing the subclassing to have to do much work.
If the "wider" label is the smaller one, use the wider size for both
cases. This can happen when ellipsizing a single character, which is
often smaller than the ellipsizing glpyph(s).
Functions should not have a space before the opening parenthesis. So
change output like
alpha (@color, 0.5)
to
alpha(@color, 0.5)
and do the same for "shade" and "mix".
Tests have been updated accordingly.
This is so newer versions of those libraries don't cause more warnings
with a stable GTK version.
We don't ever want to turn off deprecation warnings for master however,
because that's where we get rid of deprecated API we use.
Note that only glib allows use to easily do this, so nothing is done for
Pango, gdk-pixbuf or Cairo here.
With ellipsizing, the ellipsized text can have a smaller height than the
non-ellipsized text. So the wider text is also higher. Example:
.<big>TEXT</big>
will ellipsize to the small text.
Reported-By: Rico Tzschichholz <ricotz@t-online.de>
We must make sure to remove the weak pointer when disposing the widget
or when resetting the align widget otherwise glib will try to nullify
invalid memory.
This way we don't need a marker on GtkWidgetParivate that needs to be
unset later, so we have all our data in the same place and can avoid
problems with reentrancy and shenanigans like that.
But the main reason I wrote that is cleaner code.
With this function now available, we can do size computation in 2
ways:
(1) Compute size with size groups
(2) Compute size without size groups
And have (1) use (2) instead of setting flags on widgets. This patch
does exactly that.
With size groups now doing hfw, doing the optimization for CONSTANT_SIZE
was done too early. Size groups need to know that it's a hfw request, so
the other widgets in the size group get the correct behavior.
The label code assumed that Pango treats this as "wrap to as much space
as possible and then ellipsize all the lines", but for Pango, ellipsize
takes precedence over wrap. So do the same thing in GtkLabel.
Also updated is the reftest that checked this behavior.
Get rid of all the event boxes in this test. Event boxes need GDK
windows which cost a lot of performance when running the test and they
clip the label output.
Getting rid of the clipping also shows 2 bugs in this test that weren't
visible before. Those will be fixed in a followup patch.
We compute on-demand for size groups anyway, so we can (in theory, this
patch doesn't do that yet) get around costly cache blowing when
invalidating single widgets of a size group this way.
The current approach of using gtk_widget_get_mapped() is broken:
The usual steps taken when showing a window are:
(1) request the sizes
(2) allocate the sizes
(3) show the window in the allocated size
Showing the window with a random size between steps (1) and (2) would of
course
result in extra work and potential flickering when the widgets get
resized to
their proper sizes.
However, as GtkSizeGroup::ignore-hidden uses gtk_widget_get_mapped() to
determine visibility for a widget, the following will happen:
(1) the widget will request a 0 size
(2) the widget will be allocated a 0 size
(3) the widget will be too small when it is shown
gtk_widget_get_visible() however is set in advance. Note that toggling
visibility also causes a gtk-widget_queue_resize() call already so we
take care of changes in here automatically.
Instead of only checking the ignore_hidden flag when getting the
preferred sizes, respect it already when constructing the list of
widgets. This way, widgets don't queue resizes for groups they're
ignored in anyway.
For loops to loop over lists look nicer and actually do the right thing
with "break" and "continue" statements. So they are vastly preferred to
while loops.
This simplifies code and because sizes are cached by the widgets
themselves, it's not a large performance problem (unless people use huge
amounts of widgets in a single size group, but who does that?
The main problem is that we were emitting the row-deleted signal for the model in the middle
of the process that actually deletes the row from the model (remove the row from the array,
update the model->file_lookup hash table, etc.). In the model's caller, one of the row-deleted
callbacks was requesting an iter, which caused the model to revalidate itself - but it did
this while it was in an inconsistent state. This led to an assertion failure later when the
model resorted itself.
The fix in remove_file() is like this:
* The filteredness/visibility of the deleted node is not updated. The
node will simply be gone; we don't need to update those values at
all.
* We invalidate just the node that is being deleted.
* The model->file_lookup hash table is not completely nuked; instead,
we carefully adjust its indices.
* The row-deleted signal is only emitted at the very end, when
deletion is complete and the model is consistent.
Many thanks to William Hua for doing the detective work on this bug!
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
They were in the semi-public API of GtkFileSystemModel, but never actually used outside of it.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This is a function internal to the file system model; let's not pollute the gtk_tree_path namespace.
Also, make the 'i' variable into 'r' as it refers to a row index, not a file-array index (for
consistency with the docs and the rest of the code).
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Right now we support loading and recoloring symbolic GFileIcons, but
only if the underlying GFile has a local path. This breaks when the
GFileIcon is loaded from a GResource, which is a reasonable option for an
application that wants to ship a custom symbolic icon.
This patch changes GtkIconInfo to store a GFile together with the file
path, and changes the symbolic icon lookup code to use the GFile URI,
which transparently makes the code work also for GResources.
https://bugzilla.gnome.org/show_bug.cgi?id=687059
Move variable initialization outside the first code with side effects.
This allows adding some more early returns, including one for code that
used to trigger g_return_if_fail() in certain corner cases.
Old code tried to use the "background-image" proeprty for setting the
default image background. While this used to work in the early days of
GTK3, today it is grossly misleading as the backgronud image may be
resized, repositioned and semi-translucent which causes very weird
artifacts when rendering.
So we use the background-color only instead.
This way we create one provider per settings object instead of stuffing
it into a global unchanging never-deleting hash table.
Also, we now reload the theme when instructed instead of keeping the old
loaded (and possibly stale) data forever.
https://bugzilla.gnome.org/show_bug.cgi?id=683896
This makes sure the full theme loading logic resides in one function and
isn't scattered around.
As a side-effect, the hash table kept by gtk_css_provider_get_named()
will now be populated with fallback themes. This will not be a problem
after the next commit though.
Split maintaining the global themes hash table and the theme loading
code into two functions.
This also fixes leaking the provider when loading a theme from a builtin
resource.
libxkbcommon has had some changes to its API. However, it now has a
stable release (0.2.0), so this makes the necessary changes, and
replaces all uses of the deprecated API.
Signed-off-by: Ran Benita <ran234@gmail.com>
Themes may want to render handles differently depending on whether
the widget is in selection mode (2 handles enclosing a selection) or
cursor mode (one handle pointing out the insertion cursor).
This improves both interaction and theming, as it allows
arbitrary handle shapes while just being draggable from
the visible areas.
This way themes can set up handles with the hotspot visually
displaced from the horizontal center, as long as the hotspot
lies centered in the image/svg asset.
The check on the handle to be drawn on the mask was based on the yet to
be set priv->windows pointers, pass explicitly the handle position to
have the shape correctly initialized on non-composited environments
The GtkNotebook drag-motion event handler may install a timeout when
hovering over a tab, in order to switch to it.
On the other hand it's desirable for applications to use the empty tab
area as a drop target, so the drag-motion handler returns FALSE
(also in case it installs the switch tab timeout), as explained in
https://bugzilla.gnome.org/show_bug.cgi?id=350665.
Unfortunately, applications can use the tab label widget (or a child
of it) as a different drop target area, and install their own
drag-motion handler there.
In this scenario, the timeout will still be installed by GtkNotebook's
handler, but since it returns FALSE, it will never get the matching
drag-leave event, causing it to trigger also when the mouse pointer
moved elsewhere before it expired.
Fix this by returning TRUE from drag-motion when the event is over a
tab. Note that this makes automatic tab switching not work anymore when
drag and drop is handled in the tab label widget; applications are
expected to also handle tab switching if desired in such a case.
https://bugzilla.gnome.org/show_bug.cgi?id=684415
GtkScrollbar used to rely on style-updated being emitted every time
after the widget was created in order to set the right values from its
style properties on GtkRange.
Nowadays we try to be smarter and avoid emitting style-updated at
creation time, so we need to manually initialize the GtkRange values.
This fixes a regression from 35e36b9fe5.
https://bugzilla.gnome.org/show_bug.cgi?id=686280
Currently we use gtk_style_context_set_background() when the state flags
change in order to propagate the background color to the overshoot
window, but this is actually only needed because the window doesn't get
expose events, since we always draw a full background in draw().
This also fixes some problems when the GdkWindow of the scrolled
window's child is composited, as seen in oxygen-gtk3.
https://bugzilla.gnome.org/show_bug.cgi?id=686265
The implementation of transition for GtkCssShadowValue can return NULL
at least when the two values have a different inset; all other parts of
the GTK/CSS machinery (e.g. GtkCssArrayValue) handle this by returning
NULL too. Instead, GtkCssShadowsValue was returning an invalid value,
where "len" was set, but some values in the array were NULL, which would
lead to a segfault when this value is later evaluated by the compute
function.
Fix this by making GtkCssShadowsValue return NULL if a shadow transition
fails, like GtkCssArrayValue does.
https://bugzilla.gnome.org/show_bug.cgi?id=686013
Don't use a repeating linear gradient, since it can't be easily
reftested against a non-repeating one for the reasons described in the
test header.
Instead, add a separate test for repeating gradients (against another
repeating gradient).
This makes the test pass, so it can be added to the Makefile now.
Parsing a shorthand background property was running into unexpected
errors when trying position values where there were none. To fix this,
introduce a try_parse variant of the position parse function that
silently returns NULL.
Move instance fields to a private struct, in preparation
for installing a11y headers.
This also required removing access to GtkWidgetAccessible innards
from several accessible implementations.
Move instance fields to a private struct, in preparation
for installing a11y headers.
This also required removing access to GtkToplevelAccessible innards
from the GtkWindowAccessible implementation.
Move instance fields to a private struct, in preparation
for installing a11y headers.
This also required removing access to GtkRendererCellAccessible innards
from various cell accessible implementations.
Move instance fields to a private struct, in preparation
for installing a11y headers.
This also required removing access to GtkContainerCellAccessible
innards from the GtkCellAccessible implementation.
Move instance fields to a private struct, in preparation
for installing a11y headers.
This also required removing access to GtkContainerAccessible innards
from the GtkMenuItemAccessible implementation.
Before we used a window's background color, which resulted in corrupted
display in some cases, presumably because we didn't reset the active
pattern. This patch seems to eliminate the observed corruption.
(cherry picked from commit 0e42cf81f1)
This avoids a case where the display has been opened, but calling
gdk_display_get_default() in the callback doesn't work.
Reviewed-by: Benjamin Otte <otte@redhat.com>
... instead of from the intrinsic value. This way, we respect running
animations.
Note that the concept of "reversing" transitions is not implemented yet.
Otherwise, that value will never get reset and remain frozen in time.
This is problematic for example when the value is inherited and the
parent changes the value.
When positioning the scrollbar we were doing several miscalculations
when accounting for CSS paddings and borders. This also fixes a number
of problems with RTL and when scrollbars-within-bevel is FALSE.
https://bugzilla.gnome.org/show_bug.cgi?id=685449
I'm adding a bunch of fixes for gcc complaining about
-Wmissing-declarations after finding a bunch of cases today where I
had forgotten to make functions static in the CSS code.
This patch fixes the tests in gtk/tests.
After this last patch, the gtk/ subdir should now compile without
warnings when this flag is enabled.
This is part of a bunch of fixes for gcc complaining about
-Wmissing-declarations.
It puts functions into headers and includes those headers both where the
functions are defined and where they function are used.
Also remove the starting underscore from function names where
appropriate, as those functions are static now and not exported anymore.
This is part of a bunch of fixes for gcc complaining about
-Wmissing-declarations.
I'm adding a bunch of fixes for gcc complaining about
-Wmissing-declarations.
This set of patches makes private classes in gtk/*.c that use
G_DEFINE_TYPE() safe by adding definitions for the get_type() function
that can't be made static.
I'll add a bunch of fixes for gcc complaining about
-Wmissing-declarations after finding a bunch of cases today where I had
forgotten to make functions static in the CSS code.
A thorn in those patches is G_DEFINE_TYPE() which doesn't allow making
the get_type() function static, so I added definitions for that function
above the G_DEFINE_TYPE().
After those patches, GTK should compile without warnings when this flag
is enabled.
It seems we missed updating this since GTK+3, widgets cannot be
allocated less than the size they requested in thier request
phase, and explicit sizes are used only to grow the size request.
This is intended mainly to speed up the current situation with spinners
on debug kernels. Because we now don't use a cross-fade to draw the
transition but instead have a real gradient that we draw, we don't need
to use the slow cross-fade code.
https://bugzilla.gnome.org/show_bug.cgi?id=684639
We need to store the border widths independant of them being set to 0 by
border styles, because otherwise we'd need to track that dependency and
recompute on changes, and I don't want to add more entries to
GtkCssDependencies just for this special case.
By moving the code that does the setting to 0 from the compute stage to
the query stage, we can achieve this.
Now we need to just be aware that the actual value stored is not set to
0 when we use gtk_css_computed_values_get_value().
By calling XSync in _gdk_x11_display_after_process_all_updates we
effectively make gdk rendering sync, which avoids problems with the
client animations running faster than the Xserver rendering, thus
filling up the X rendering pipes and essentially "locking up" the
Xserver (i.e. you can't even close the offending window because the
WM is starved too).
I verified this worked by making GtkSpinner paint multiple times on my
intel driver (which has some issue making this rendering slow atm),
and without this patch i get severe lag where even window dragging
stops for 5 seconds when i drag the mouse around. However, with the
patch everything is smooth.
https://bugzilla.gnome.org/show_bug.cgi?id=684639
GDK_WINDOW_XID() has the side-effect of turning a window native;
this in turn can have unexpected effects such as black backgrounds.
Avoid this by using the XID of the toplevel.
https://bugzilla.gnome.org/show_bug.cgi?id=682395
Otherwise the evil widgets that don't chain up their map and unmap
vfuncs will not get updated style contexts. This is in particular true
for GtkWindow and the CSS Theming / animated backgrounds demo in
gtk-demo.
Here's the shortest description of the bug I can come up with:
When computing values, we have 3 kinds of dependencies:
(1) other properties ("currentColor" or em values)
(2) inherited properties ("inherit")
(3) generic things from the theme (@keyframes or @define-color)
Previously, we passed the GtkStyleContext as an argument, because it
provided these 3 things using:
(1) _gtk_style_context_peek_property()
(2) _gtk_style_context_peek_property(gtk_style_context_get_parent())
(3) context->priv->cascade
However, this makes it impossible to lookup values other than the ones
accessible via _gtk_style_context_peek_property(). And this is exactly
what we are doing in gtk_style_context_update_cache(). So when the cache
updates encountered case (1), they were looking up the values from the
wrong style data.
So this large patch essentially does nothing but replace the
context argument in all compute functions with new arguments for the 3
cases above:
(1) values
(2) parent_values
(3) provider
We apparently have a lot of computing code.
The garbage would be visible if any widget enabled the toplevel
NSView's CALayer in order to do custom native rendering.
(cherry picked from commit 92ea94af5f)
This is needed for the SELECTION_NONE mode where nothing is ever
selected, but its also needed for CTRL-<key> keynav that moves the
focus without changing the selection.
https://bugzilla.gnome.org/show_bug.cgi?id=684984
Currently the GdkWindow used for dragging is created once when
the first drag starts, and the reused identical each time.
Instead, just recreate it for each drag, with the correct size.
This reverts commit f2cb8f1270.
The patch actually didn't work for at least text. I currently have no
clue why, but I suspect it requires investigating Cairo code and
recording surfaces, and I'll not do that right now.
Split out the blurred shadow rendering in three steps:
- creation of a surface of the appropriate size - we use the clip
rectangle as a good measurement for the size, since we won't render
out of it anyway
- painting the unblurred shape on the surface - this is responsibility
of the single shadow implementations
- blur the surface and compose the result back on the original cairo_t
This means we can share code between the implementations for the first
and third steps; it also makes the code independent of the rendered
size, so we can avoid passing down a cairo_rectangle_t with e.g. the
icon coordinates.
The code accesses pixels in a chunks of 4 bytes, so we must only support
formats where the size of a single pixel is 4 bytes.
Fix RGB24 to be 4 bytes (the alpha channel is ignored) and disallow A8.
We were adding one child too much to the style context path when
generating it for the internal buttons, which in turn caused sibling
selectors from the theme such as :first-child to apply to both buttons
under certain circumstances. Spotted by Lapo Calamandrei.
As long as we don't have an API for explicitly inverting the bar, it
makes more sense for the progress in vertical orientation to fill from
the bottom.
In the event that a GtkAccelKey was present for the closure but it
contained a keyval of 0 the previous code would show "". After the
recent adjustments, "-/-" would be shown in this case.
It turns out to be a pretty common case, so fix the logic to stop using
'0' as a magic value to mean "don't have an accel" and add a separate
boolean for that purpose.
This reverts commit 1f5dea9eba,
since it was causeing noticable behaviour changes.
Previously, GTK_DATA_PREFIX=/ ./gtk3-demo would start
gtk3-demo with the Raleigh theme. With that change, it
was starting with no theme at all (i.e. all black).
While regular animations should always be created, transitions should
not. This patch allows to express this by passing NULL as the values to
transition from.
It also adds a gtk_style_context_should_create_transitions() function
that returns TRUE when transitions should be created.
... that actually was both wrong, a performance failure and has been
there since the original checkin.
Updating the cached style data absolutely does not mean clearing all
cached style data first. There's nothing to update then.
This will be useful to not trigger updates all the time when nothing is
happening (ie due to animations being paused or due to them having
reached their final value).
This adds the GtkCssAnimation class and the code needed to hook it into
GtkStyleContext. It takes the values out of the CSS "animation"
properties and does animations. See
http://dev.w3.org/csswg/css3-animations/
for details.
Note that the code for starting and stopping animations with widget
visibility doesn't work yet.
This change is necessary because the old code did not accound for corner
cases (like translucent child windows), which could stop
gtk_widget_queue_resize() to not trigger redraws.
Make the main (and only) entry-point to gtkmodelmenu.c the now-public
gtk_menu_shell_bind_model().
Move the convenience constructors (gtk_menu_new_from_model() and
gtk_menu_bar_new_from_model()) to their proper files.
Remove the private header file.
Simplify the code a bit by making the initial populate part of the
bind() call.
https://bugzilla.gnome.org/show_bug.cgi?id=682831
Add an API to GtkAccelLabel for hardcoding the accel key to be displayed
(ie: allowing us to bypass the GtkAccelGroup lookup).
Use that from the GMenuModel-based GtkMenu construction code instead of
passing around the accel group.
This makes accel labels work in bloatpad again.
This patch effectively removes any hope of automatic runtime accel
changes in GMenuModel-based menus without additional application
support but it leaves the door open for this to be supported again in
the future (if we decide that it's important).
https://bugzilla.gnome.org/show_bug.cgi?id=683738
Add support for a stateful action associated with a submenu. The action
state is set to TRUE when the menu is shown and FALSE when it is
unshown.
This is useful to avoid unnecessary processing for menus that have
frequently-changing content.
A possible future feature is to add support for asynchronously filling
the initial state of the menu by waiting until the action actually emits
its state-change signal to TRUE before showing the menu.
A silly example has been added to Bloatpad to demonstrate the new
feature.
https://bugzilla.gnome.org/show_bug.cgi?id=682630
In gtk_menu_bar_draw, the check for shadow type != none
disables rendering of the background instead of the frame.
The check should be moved down to gtk_render_frame.
Patch by Peter de Ridder,
http://bugzilla.gnome.org/show_bug.cgi?id=670390
A button is highlighted if the private variable in_button is TRUE.
This variable is set when the pointer is over the button and cleared when
it left the button. When a button is hidden while there is the pointer over
it, GTK generates a leave notification event, in_button is set to FALSE.
But when a button is removed from a container but not destroyed, it is
unrealized and loose its window. It cannot receive the leave notification
event and in_button stay TRUE. So when the button get a new parent it is still
highlighted.
https://bugzilla.gnome.org/show_bug.cgi?id=676890
Scroll to the selection when setting it so the selected font is
visible on screen. This is especially useful if an initial font is
set for the user to see it.
https://bugzilla.gnome.org/show_bug.cgi?id=684156
Previously, we would avoid setting the prelight state flag when
button_down was TRUE and draw_indicator = FALSE, which is the normal
case of a GtkToggleButton during a mouse press.
It looks like this behavior was introduced a long time ago with commit
b94e6c0a80. I believe the reason was that
a widget in GTK2 couldn't have more than a single state (e.g.
hover+active) at a given moment.
https://bugzilla.gnome.org/show_bug.cgi?id=684038
Apply patch from Kristian Rietveld which addresses two issues
in gdkeventloop-quartz.c:
This patch moves the autorelease pool drain and introduces protection against
the invalidated ufds. Basically, when we suspect ufds has been invalidated by a
recursive main loop instance, we refrain from calling the collect function.
(cherry picked from commit 79b3326eaa)
After my recent fix for this, nautilus was still having problems
telling keeping F10 and Shift-F10 apart. With this change, we are
treating levels with the same symbol like inactive levels, ignoring
them entirely.
The widget-factory was pretty much overflowing, so I've
made it page, and started to fill the second page with
vertical spin buttons. New examples and widgets should
be added to page 2 now.
Be a bit more careful in get_pango_attr_list() and
get_utf8_preedit_string() to ensure that the client_window is properly
created before proceeding, to avoid access violation/segfault crashes on
Windows with IME installed, especially when running the pickers demo.
https://bugzilla.gnome.org/show_bug.cgi?id=682919
Don't hook on the widget style context and set up instead
a widget path for itself. Also use a common style class
for both handles, with an extra top/bottom class for each
handle.
This is to allow animating arrays properly. I'm not really thrilled
about this solution (we leak propertys into the values again...), but
it's the best I can come up with - I prefer it to having N different
array types...
I want to get away from the ability to have 0-length arrays, all css
arrays are single element.
Even if the element is "none", it is still a "none" element.
GtkTextHandle is used to indicate both the cursor position
and the selection bound, dragging the handles will modify
the selection and scroll if necessary.
Backwards text selection is also blocked for touch devices,
so the handles don't get inverted positions and possibly
obscure portions of the selected text.
GtkTextHandle is used to indicate both the cursor position
and the selection bound, dragging the handles will modify
the selection and scroll if necessary.
Backwards text selection is also blocked for touch devices,
so the handles don't get inverted positions (This is more
important though on GtkTextView, as inverted handles may
obscure portions of the selected text, good for consistence
though)
This is a helper object to allow text widgets to implement
text selection on touch devices. It allows for both cursor
placement and text selection, displaying draggable handles
on/around the cursor and selection bound positions.
Currently, this is private to GTK+, and only available to
GtkEntry and GtkTextView.
GtkTextHandle creates temporary override redirect windows, but still
hook to the text widget for events, so those are effectively captured
by GtkScrolledWindow if a text widget is within it
A change in xkeyboard-config 2.4.1 made it so that function keys
now have a shift level which has the same symbol, but 'eats' the
shift modifier. This would ordinarily make it impossible for us
to discriminate between these key combinations.
This commit tries harder to discriminate in 2 ways:
- XKB has a mechanism to tell us when a modifier should not be
consumed even though it was used in determining the level.
We now respect such 'preserved' modifiers. This does not fix
the Shift-F10 vs F10 problem yet, since xkeyboard-config does
not currently mark Shift as preserved for function keys.
- Don't consume modifiers that do not change the symbol. For
the function keys, the symbol on the shift level is the same
as the base level, so we don't consider Shift consumed.
For more background on the xkeyboard-config change, see
https://bugs.freedesktop.org/show_bug.cgi?id=45008https://bugzilla.gnome.org/show_bug.cgi?id=661973
Showing mnemonics immediately on modifier press can be annoying and
distracting when the user is just trying to Alt+Tab into another
application/window since the mnemonic will show up and quickly vanish
again when we receive the focus out event.
https://bugzilla.gnome.org/show_bug.cgi?id=672431
The file type radio group has a mnemonic on its label, but
activating it did not work, since GtkPrinterOptionWidget did
not know to forward the activation to one of the buttons.
* This patch gets rid of the separated
fields for selecting a print to file
target by removing the folder selection
button and the entry. It is replaced by
a browse button, which opens a file
selection dialog, that can select both
the path AND the filename.
* If the filename is relativ to the home
folder it will substitute ~/ instead of
the home folder. Additionally if the
resulting filename is longer than 30
characters, it cut of the first part
and replace it by '...' so that
the button text never gets too long.
https://bugzilla.gnome.org/show_bug.cgi?id=682129
The file chooser is asynchronous, so doing 'select_file (old_file)' and subsequently querying
the file for updating the labels is not going to work. However, the underlying file chooser
will emit 'selection-changed' as appropriate when it finishes restoring the old file. So,
we only need to update the labels when the file chooser dialog is confirmed, not cancelled.
This commit moves all the entry completion implementation
into gtkentrycompletion.c. It also gets rid of an unnecessary
completion_device member in GtkEntryPrivate.
When compiling gtk on Win32 then the file gtkdbusgenerated.c also needs to be
compiled and linked into the gtk library as it's needed for GtkMountOperation
https://bugzilla.gnome.org/show_bug.cgi?id=682825
- don't poke at the children's background pattern at draw time, but just
call gtk_render_background()
- we should propagate rendering of the background to the overshoot
window when the state flags or the style changes, or it won't respond
to e.g. focused/backdrop changes correctly
https://bugzilla.gnome.org/show_bug.cgi?id=682854
GTK_CSS_DEPENDS_ON_EVERYTHING was used as a placeholder when
implementing dependencies. Now that dependencies are completely
implemented, it's no longer necessary.
... in the case where no change of the DOM tree actually happened.
We don't do anything yet with that information, this patch just
correctly computes it.
When values are computed, they might depend on various other values and
we need to track this so we can update the values when those other
values change. This is the first step in making that happen.
This patch does not do any dependency tracking at all, instead it uses
GTK_CSS_DEPENDS_ON_EVERYTHING as a sort of FIXME.
Both _gtk_css_style_property_print_value() and
_gtk_css_style_property_compute_value() aren't necessary anymore and are
replaced by _gtk_css_value_print() and _gtk_css_value_comptue()
respectively.
This gets rid of the public function
_gtk_css_rgba_value_compute_from_symbolic().
The fallback is now handled using a switch statement instead of letting
the caller pass the function.
This is a reorganization of how value computing should be done.
Previously the GtkCssStyleProperty.compute vfunc was supposed to take
care of special cases when it needed those for computation. However,
this proved to be very complicated in cases where values were nested and
only the last value (of a common type) needed to be special cased.
A common example for this was the fallback handling for unresolvable
colors.
Now, we pass the property's ID along with all compute functions so we
can do the special casing where it's necessary.
Note that no actual changes happen in this commit. This will happen in
follow-ups.
This commit is essentially a large reorganization. Instead of all value
subtypes having their own compute function, there is the general
_gtk_css_value_compute() function that then calls a vfunc on the
subtype.
This hint may be used in text widgets to inhibit their
input methods. The most compelling usecase is calculator
applications, which already have a builtin and better
suited onscreen keyboard.
https://bugzilla.gnome.org/show_bug.cgi?id=651244
This improves the layout of the mount operations dialog to:
* Make primary labels bold in all cases
* Lay out the widgets in a grid
* Put space between the two radio groups to distinguish them
https://bugzilla.gnome.org/show_bug.cgi?id=682552
We no longer support modifying GdkWindow hierarchies during
expose events. This is not working anymore anyway as the
flush operation now does not push already rendered pixels
in the flushed window from the double buffer to the window.
https://bugzilla.gnome.org/show_bug.cgi?id=679144
Avoid copying back partially drawn double-buffer data
when flushing to avoid flicker. This means non double
buffered widgets must draw opaque pixels in its expose
handlers, and that you are not allowed to use direct
rendering (or modify GdkWindow pos/size/order) from
inside the expose handler of a double buffered widget.
See https://bugzilla.gnome.org/show_bug.cgi?id=679144 for more
details
gtk_widget_insert_action_group (widget, "foo", NULL) is valid, but
g_action_muxer_insert (muxer, "foo", NULL) is not. Use
g_action_muxer_remove() for that case.
The code was calling _gdk_window_ref_cairo_surface in a few places
where the intent was not to read/write to the surface, but just look
at its type (to e.g. create a similar surface). This is bad, as that
operation causes a flush which may cause unnecessary work and/or
flashing. Instead we just get the impl surface in these cases.
get_time_from_ns_event(): apply patch from Michael Hutchinson which
makes sure the returned guint32 wraps correctly on 32 bit machines
when the uptime exceeds 2^32 ms.
First, ensure we always consume floating values, as documented.
Second (and more serious), don't try to query the action if the
action name is not set yet. This will cause crashes...
It's too close to the release so we'll keep _set_menu() around, but
deprecate it, pointing to the new API. It will be removed (and the name
reused) before the 3.6.0 release.
https://bugzilla.gnome.org/show_bug.cgi?id=682235
If a section or submenu item has a "action-namespace" attribute, the
action names of the created GtkModelMenuItems will be prefixed with that
namespace. Namespaces can be cascaded.
There are no remaining users of the GActionMuxer in GtkApplicationWindow
because they've all been ported over to using the one on GtkWidget (via
GtkActionHelper, for the most part).
There are no remaining users of the GtkApplicationWindow API to create
GSimpleActionObserver or to get the GActionObservable (ie: muxer) for
the appwindow. Drop those APIs.
Drop the explicit passing of GActionGroup into the GtkMenu(Bar)
constructors and operate from the action context instead.
With GtkMenuItem implementing GtkActionable, this turns out to be pretty
easy (and most of the code can be removed from GtkModelMenuItem,
including the GActionObserver implementation).
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 current process of implementing GActionObserver is annoying and the
GSimpleActionObserver interface leaves a lot to be desired. Introduce a
new class, GtkActionHelper that gives you pretty much everything you'd
want to do as an implementor of GtkActionable.
The GtkActionHelper also features an "application" mode that is not
associated with a particular GtkWidget but rather with whatever widget
happens to be the active window of the given GtkApplication at a
particular point in time. This will be useful for the Mac OS menubar.
This allows adding a GActionGroup with a given name at an arbitrary
point in the widget tree.
This patch also adds an internal _get_action_muxer() API. Calling this
will create a GActionMuxer associated with the widget. The parent of
the muxer will be the muxer of the widget's conceptual parent. For
non-menus, that is the normal parent. For menus, it is the attach
widget.
In this way, we end up with a hierarchy of GActionMuxer that largely
reflects the hierarchy of GtkWidget, but only in places that the action
context has been requested. These muxers are the ones on which the
inserted actions groups are installed.
A following patch will add a user of this API.
If a muxer does not contain an action group with the given prefix, chain
up to the "parent" muxer to look for it.
This initial implementation is rather inefficient. It will lead to
changes on action groups associated with parent muxers being broadcast
to all children (regardless of if anybody there is interested or not).
An optimised version will follow soon.
-Include fallback-c89.c for the usage of round(), where an implementation
of round() is provided for compilers that don't have it
-Use g_ascii_strtod() instead of strtof as strtof() may not be universally
available.
-Turn on Whole Program Optimization for all Release builds.
-Disable Incremental Linking for all Release builds.
-Use MultiByte character set for all configurations for consistency.
-Enhance optimization by turning on WholeProgramOptimization for all
Release builds
-Disable IncrementalLinking for all Release builds
-Make sure we are using MultiByte character set, to be consistent across
the board for all configurations
Call _gtk_entry_get_display_text()from gtkentryaccessible.c to make
sure we always consider the actual text being displayed when
implementing the functions from the AtkTet interface.
https://bugzilla.gnome.org/show_bug.cgi?id=681591
Translating "ON" as "EK" (verb prefix for beginning of an action) and
"OFF" as "FOR" (away) is suboptimal. Just use the suggested 1/0 glpyhs
instead.
The previous translator was clearly insane.
These widgets have ancestors other than GObject which could eventually
implement the notify vfunc for their properties. For correctness, they
should chain up the notify vfunc.
https://bugzilla.gnome.org/show_bug.cgi?id=673478
While shadow-type *properties* can make sense, to opt-out of the
padding/border machinery programmatically, having it as a style
property doesn't make any sense, since we have a better way to change
the bevel style from the theme already.
This commit deprecates the shadow-type style property in GtkToolbar.
This is a regression from commit
d0d21a4f00.
We are requesting the CSS padding twice: once unconditionally and
another time if SHADOW_TYPE != NONE, which is usually the case.
gtk_widget_path_copy() currently calls g_array_append_val() in a loop,
which is inefficient due to reallocating the array's memory. Calling
g_array_set_size() before entering the loop reduces the number of CPU
cycles used by roughly 30%.
Patch by John Lindgren,
https://bugzilla.gnome.org/show_bug.cgi?id=679978
Not defining these macros at all causes harsh build breakages.
Better to leave them defined (but documented as deprecated) for now.
Everybody will still get the deprecation warnings for the underlying
gdk_threads_enter/leave.
We can hide the macros again later on when the world has had some
time to port off GDK threads.
The widget is already calling gtk_render_frame, but is not measuring css
border and padding when negotiating its size. This patch replaces the
already existing get_internal_padding static helper with a function that
sums the old internal-padding value with the values specified via css.
Use $(AM_V_GEN) for generating man pages, and set some parameters
for the XSL stylesheets. Among other things, don't generate AUTHORS
and COPYRIGHT sections.
The story is slightly different for applications vs libraries;
make it clear that libraries should continue using the lock so
we don't break applications that haven't been ported to the
'single thread' model yet.
When the tab label gets removed from the notebook on widget
desctruction, we should still unconditionally unparent it from the
notebook, since failing to do so will keep a stray reference alive.
In case applications rely on the tab label being destroyed to release
other references (e.g. because the tab label is a custom object, or
another object's lifecycle is tied to it using g_object_set_data_full()),
this will also possibly cause other references to get leaked.
In Nautilus, the result was we were failing to release the reference to
a NautilusWindowSlot, and other parts of the application relied
on it being destroyed at a specific time instead, causing the
application to crash when closing a window.
This is a regression from commit
325cf071d1.
This commit restores the previous unparenting behavior in case we're not
in a DnD operation.
https://bugzilla.gnome.org/show_bug.cgi?id=680349
We need to do this here so that an explicit gtk_widget_destroy
on either the widget or a container that holds it will kill the
reference to the menu or model.
https://bugzilla.gnome.org/show_bug.cgi?id=680803
This commit deprecates gdk_threads_init, gdk_threads_enter,
gdk_threads_leave and gdk_threads_set_lock_functions. Using GTK+
from multiple threads does not work at all on Windows, and is
problematic on other platforms as well. We want to move to a world
where all GTK+ calls are made from the main thread.
Use g_main_context_invoke, g_idle_add and related functions if you
need to schedule GTK+ calls from other threads.
http://bugzilla.gnome.org/show_bug.cgi?id=680754
These are just wrappers for the functions, and we want to
deprecate them. Stopping to use them internally is a good
first step. Also define GTK_COMPILATION so we can keep using
gdk_threads_enter/leave without causing deprecation warnings.
Remove the "-win32-" from the output file names for the GDK and GTK+ DLLs,
like what is now done for quite a while on other platforms
(and MinGW builds), for consistency reasons. This is due to GDK/GTK+
are buildable with multiple backends.
Note: For references, the Windows build only builds the Win32 backend
for the time being.
If we don't have a wl_seat - because a grab hasn't been initialised by GTK+
then fallback to making the shell surface transient to the parent rather than
a popup surface.
We now support independent selection and primary clipboards, and avoid
wiping clipboard on modifying its contents from the same owner. This fixes
most of the interaction issues with clipboard and selection.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
GSequence iterators point at the position between two elements so an
iterator pointing at the N tree model node is actually between the N-1
and N sequence elements. This means that asking for the previous
sequence iterator first and then checking if it is the begin iterator
would yeld true for an iterator pointing at the 2nd tree model node
and make us return FALSE mistakenly.
https://bugzilla.gnome.org/show_bug.cgi?id=679910
Review comment: I think the implementation of the vfuncs in gdkkeys-wayland.c
depend on that we're using the keysysm as the hardware keycode. I think that
needs to be evaluated for the future. But for now this patch gives reasonably
complete keyboard input.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
This is then logically associated with the input device since each (keyboard)
input device has its own keymap.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
Although GDK expects the keymap to be associated with the display under
Wayland this is really associated with the input device so expose this by
finding the first keyboard device.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
This program launches an application specified by its desktop name
optinally taking list of URIs which are passed as arguments.
Uses GdkAppLaunchContext to get proper startup notification and
display handling for graphical apps.
https://bugzilla.gnome.org/show_bug.cgi?id=679342
The code that was trying to limit preview size changes was
running into some width-for-height pitfalls. It turns out
that the dialog behaves quite ok without this code, so just
remove it.
Now that filters may affect sensitivity of rows, we need
to clear the sensitivity column from the cache when the
filter changes. This fixes the problem where selecting a
different filter does not update the sensitivity of folders
until you change directories.
This way we remove paired function calls (compute/set pairs), and also make
it possible to avoid computing a filter twice, as setting the visibility
depends on filteredness.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
It bothers me that we call gtk_file_filter_filter(), then negate the result,
and the return *that* from node_should_be_filtered(). So, rename 'filtered'
throughout GtkFileSystemModel to 'filtered_out' to mean things that didn't
pass the filter.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This was a copy-paste leftover from node_set_visible(). Filters are not
concerned with model freezes, so node_set_filtered() does not
need to handle freezes, either.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Specially in the case of comboboxes, those menus could enable scrolling
even if the contents could fit in the work area, and could show blank
space in order to line up the selected item with the combobox.
When such thing happens, take into account scroll_offset when relocating
the menu contents so contents don't jump directly onscreen, and apply
it so scrolling is allowed in the direction that brings the menu onscreen
and blocked in the opposite direction.
Also, wait for cancelling the scroll operation until the touch is released
even if the scrolling arrows disappeared, so the menu item underneath isn't
selected right away.
https://bugzilla.gnome.org/show_bug.cgi?id=678113
Entries don't expand vertically if they are given pixbufs larger
than the calculated height for the current font, resulting in
cropped icons, so force the pixbuf to be rescaled so it fits
on the entry allocated size.
https://bugzilla.gnome.org/show_bug.cgi?id=678087
If the symbolic icon has other size than 16x16, the embedder
SVG that overrides colors would still force that size, resulting
in clipping instead of resizing. So fetch the original pixbuf
size the first time a symbolic icon is requested for a GtkIconInfo,
and use that size for the embedder SVG so it can be scaled properly
afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=677567
This replaces the wl_input_device with wl_pointer, wl_keyboard, wl_touch all
tied together under a wl_seat.
This is quite a radical change in protocol and for now keyboard handling is
disabled.
This requires the SHM object be initialised - therefore this is the most
logical (if slightly ugly place.)
We also need to make sure that we do something clever to load the correct
cursor theme.
Both GtkListStore and GtkTreeStore had a few methods that allowed
-1 to mean 'append' when specified as a position, but others that
demanded positive position arguments. Make this consistent by
always allowing -1.
https://bugzilla.gnome.org/show_bug.cgi?id=667808
The recently-used.xbel storage for recently used files is located inside
the $XDG_DATA_HOME directory; there's no actual guarantee that the
directory has been created already, even though it's very highly
probable on any modern distribution. We should create it, along with its
intermediate parents, before constructing the file monitor that we use
to get change notifications.
https://bugzilla.gnome.org/show_bug.cgi?id=671817https://bugzilla.gnome.org/show_bug.cgi?id=667808
The builder XML description has an action for "win.parse" but the
application is looking for "win.paste". Rename the label to
"_Paste" and the action to "win.paste" in the window action XML.
https://bugzilla.gnome.org/show_bug.cgi?id=678829
nitems is never guaranteed to be defined in sys/params.h as it is meant
to be defined within a protected ifdef __KERNEL conditional.
Use G_N_ELEMENTS from GLib which is the proper way of doing this.
In gtk_entry_get_icon_pixbuf() we unreference the pixbuf that
_gtk_icon_helper_ensure_pixbuf() gives us back, since the function
doesn't return a reference, and by doing so we're able to return the
reference owned by the cached icon helper.
Since the icon helper method can return NULL though, if no icon
properties have been set on it, guard for != NULL before unreffing the
pixbuf, as that would cause a critical warning.
https://bugzilla.gnome.org/show_bug.cgi?id=679537
Right now, when we create a GtkModelMenu for a GMenuModel, we listen to
changes to the menu's attach-widget to detect when a toplevel
GtkApplicationWindow becomes available to fetch actions from it.
This unfortunately breaks this simple code:
GtkWidget *application_window = gtk_application_window_new();
GtkWidget *menu_button = gtk_menu_button_new();
GMenuModel *menu_model = get_menu_model();
gtk_menu_button_set_menu_model(menu_button, menu_model);
gtk_container_add(GTK_CONTAINER(application_window), menu_button);
Since GtkMenuButton creates a GtkModelMenu and sets itself as its attach
widget before it's added to a hierarchy containing a
GtkApplicationWindow.
Fix the bug by simply listening for changes in the window hierarchy, and
creating the menu model when the attach widget is added to an
application window.
https://bugzilla.gnome.org/show_bug.cgi?id=679454
When the menu is detached, the attach-widget property changes value to
NULL, so we should notify a property change, like
gtk_menu_attach_to_widget() does.
https://bugzilla.gnome.org/show_bug.cgi?id=679454
This is fallout from commit 257b42e2f9 -
those fields were already getting freed in
gtk_application_shutdown_x11() and my commit caused crashes on quit
instead.
Thanks to Rico Tzschichholz for reporting the bug and testing this fix.
As an addition to 1042372670, themes might
want to avoid using the hardcoded GTK defaults for legacy GtkStyle
values. Add a gtkstyle-fallback style class that can be used by themes
to tweak the legacy GtkStyle defaults.
https://bugzilla.gnome.org/show_bug.cgi?id=679092
Since we explictly call popup_menu with NULL when it's
keyboard-activated, we need to be careful and not access event->device
without checking for event != NULL before.
The signals for the action group were being disconnected when the action
group was explicitly removed from the GActionMuxer but the same was not
being done when it was finalized.
This means that a change in the state of an action group that used to be
associated with a finalized GActionMuxer would result in a crash. This
would happen for stateful application actions after closing a window.
We can't expose colors with alpha in the GtkStyle colors, since
GdkColor has no alpha. Currently we throw away alpha completely,
which fails very badly for completely transparent backgrounds,
which now is the default for most widgets, as it typically
end up with black-on-black.
We handle this by falling back on the default/previous colors for
transparent colors. This is is simple and avoids complete failure.
https://bugzilla.gnome.org/show_bug.cgi?id=671437
Don't use ASCII control characters to denote the input of Esc, Tab,
Return/Enter, Backspace and Delete, as it seems that it is not how
Windows handle them, and they cause weird characters to appear in the
input field on GTK+3 programs in non-English Windows. Instead, let
these keys be handled as-is on Windows, like what is done in GTK+-2.x.
Checked with mclasen on IRC, and thanks to the people who verified the
patch to not break anything on English Windows.
When using Shift-Tab to move the focus out of page content onto
the tab label, we end up in a situation where both Tab and Shift-Tab
move focus back into the page, which is not really what is expected
when the notebook is part of a dialog.
Instead, arrange things so that using Shift-Tab with focus on a
tab label moves the focus out of the notebook.
http://bugzilla.gnome.org/show_bug.cgi?id=669986
It turns out that we can end up removing a notebook child while
the tab is still 'detached'. Child removal causes
gtk_notebook_remove_tab_label() to be called on the tab label,
but that function did not deal with the eventuality that the tab
label may be a child of the dnd window.
http://bugzilla.gnome.org/show_bug.cgi?id=677943
Some builders using gtk3 outside of the GNOME cycle want an option to
avoid linking to atk-bridge-2.0. Provide that, and at the same time
ensure we're only looking for it on X11 platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=677491
Make GMountOperation look for an owner of org.Gtk.MountOperationHandler
if possible, and use it instead of the GTK-based dialogs.
This allows applications to use the implementation offered by the
desktop shell, if available, through a DBus private interface:
org.Gtk.MountOperationHandler.
https://bugzilla.gnome.org/show_bug.cgi?id=674963
This gets the current cell area of a particular item. Its similar
to gtk_tree_view_get_cell_area().
The code is extracted from gtk_icon_view_set_tooltip_cell which now
just calls the old code.
https://bugzilla.gnome.org/show_bug.cgi?id=678418
gdk_device_list_slave_devices only makes sense to call on master
devices, yet its g_return_if_fail check made it reject such devices.
Pointed out by monty.
When a widget is app_paintable, its background should not be drawn by
the theme, thus we should not try to override its background again when
style-updated is fired.
This is a bit of a hack, but it fixes gray surfaces observed for DnD
windows with recent GTK+.
As used in Totem and gnome-contacts. The widget
takes either a GtkMenu or a GMenuModel to construct
its menu, and can be given a parent widget to use to
position the drop-down (as used in GtkMenuToolButton).
https://bugzilla.gnome.org/show_bug.cgi?id=668013
If the icon view is empty, we cannot get a reasonable size request from
the cell renderers. So all values we would compute are pretty much
useless.
So we special case it.
This also gets rid of a bunch of crashers from div-by-0 in corner cases.
https://bugzilla.gnome.org/show_bug.cgi?id=677809
This is useful for 2 reasons:
(1) Items actually exist and are clickable
(2) Size computations don't divide by 0
I've not seen problems with this in the wild (mostly because
item-padding defaults to non-0), but noticed this while fixing other
bugs.
Minimum size is necessary so you can see the item. If we can't get that
we need to scroll.
Natural as the maximum is used so that the spacing between items doesn't
increase when resizing the iconview, but empty space is added to the
right/bottom instead.
https://bugzilla.gnome.org/show_bug.cgi?id=677809
While working on the "iconview: Don't shrink items" patch I noticed that
gtk_icon_view_compute_n_items_for_size modifies the natural and minimum
item sizes it got from gtk_icon_view_get_preferred_item_size when
calculating the max number of items which will fit, but later on it
checks against these sizes when calculating the item_size, and these
checks expect these values to be unmodified.
This patch fixes this by modifying the natural and minimum values in
advance and doing all computations with modified values.
https://bugzilla.gnome.org/show_bug.cgi?id=677809
The previous code assumed that the width was always enough for more than
one column, which is obviously not correct when a number of columns is
hardcoded.
With this patch, it will now always check that the width is enough and
otherwise cause scrolling.
https://bugzilla.gnome.org/show_bug.cgi?id=677809
GtkToolbar doesn't have its own GdkWindow to draw on (it calls
gtk_widget_set_has_window(FALSE) in _init), but only an event window
(input-only).
Since gtk_widget_get_window() in that case will return the GdkWindow of
the parent container, by calling gtk_style_context_set_background() here
we're overriding the base background of the container instead of our.
While in most cases this doesn't have any noticeable effect, since
the toplevel GtkWindow will paint its background on top of it at the
beginning of the draw cycle, when the classic window hierarchy is
broken, such as when widgets are rendered through a clutter-gtk
offscreen embedding, the background will become visible, which is
undesirable.
Fix this by having GtkToolbar not call gtk_style_context_set_background
in its style_updated handler.
When I added the versioned annotation, I accidentally backdated
it, so the Deprecated: tag in the docs said 3.4, but the annotation
said 3.0. Fix it so we say 3.4 in both places.
When inline-selection is set, and the completion popup is showing,
pressing left abruptly jumps to the beginning of the entry text.
This is not expected, since the cursor is at the end of the text before
the left key is pressed, and this behavior is completely inconsistent
with how an entry would normally behave.
The behavior can be observed in Epiphany by selecting a completion match
and pressing left.
This patch changes the code so that it just runs the default entry key
press keybindings in such a case.
https://bugzilla.gnome.org/show_bug.cgi?id=677915
Mark the new_order argument as zero-terminated array, even though it does not
need to be zero terminated (it has an implicit length not given by a constant
or another method argument). It does not hurt if bindings append an extra zero
to the array as long as it has enough elements, and this makes the method
introspectable.
https://bugzilla.gnome.org/show_bug.cgi?id=677941
Remove the 'you shall not connect' message from this signal.
While it is a keybinding signal, using it from applications is
fine and, in fact, expected.
There are three bugs here:
- we should check if the value type is transformable instead of being
compatible, since that's all we care about in order to call
g_value_transform()
- the check is only meaningful in the direction
passed-in-type->column-type and not viceversa
- we should init the destination GValue to the column type before
calling g_value_transform on it, or the destination type information
will be missing and the method will fail
Thanks to Jasper St. Pierre and Colin Walters for all the help in
tracking this down.
https://bugzilla.gnome.org/show_bug.cgi?id=677649
There are three bugs here:
- we should check if the value type is transformable instead of being
compatible, since that's all we care about in order to call
g_value_transform()
- the check is only meaningful in the direction
passed-in-type->column-type and not viceversa
- we should init the destination GValue to the column type before
calling g_value_transform on it, or the destination type information
will be missing and the method will fail
Thanks to Jasper St. Pierre and Colin Walters for all the help in
tracking this down.
https://bugzilla.gnome.org/show_bug.cgi?id=677649
gtk_icon_info_load_symbolic checks for the existance of a filename parameter
so it can include it along with the stylesheet. We don't set the filename
parameter when creating the info for a GFileIcon, for some reason.
https://bugzilla.gnome.org/show_bug.cgi?id=676356
This is probably going to be replaced by something different soon, but
in the meantime, fix this annoying bug, visible e.g. in widget-factory
for left/right tab examples.
As used in Totem and gnome-contacts. The widget
takes either a GtkMenu or a GMenuModel to construct
its menu, and can be given a parent widget to use to
position the drop-down (as used in GtkMenuToolButton).
https://bugzilla.gnome.org/show_bug.cgi?id=668013
When we determine the fill rectangle for an image layer, and the image
is not repeating, we should also position the rectangle according to the
values of background-position, or we will always fill a tiny slice at
the top/left of the clip box.
https://bugzilla.gnome.org/show_bug.cgi?id=677109
Many themes want to render the trough background/stroke thinner than the
full height/width (which is constructed around the value of the
'slider-width' style property).
Read and apply the CSS margin from the theme on the trough component, so
that themes can make it smaller at their will without the need to
override the render_background, render_frame and render_activity methods
of GtkThemingEngine.
https://bugzilla.gnome.org/show_bug.cgi?id=676196
This was showing up when using a combo box in list mode. After popping
up the list, the keyboard grab appeared stuck. What was stuck here is
only the client-side grab, since we forgot to clean up our grabs
when receiving an UnmapNotify.
This bug was introduced in 1c97003664.
https://bugzilla.redhat.com//show_bug.cgi?id=812035 has
a stacktrace that shows recursion via
free_node -> unref -> dispose -> ui manager api
which ends in a crash, since we run free_node over the entire
tree and it leaves lots of dangling pointers behind.
So, better be careful by setting all pointers to NULL after
freeing them.
And update/fix it for the new shorthand parsing, since the old test did
a couple of things wrong:
- it erroneously flipped background-clip and background-origin when
testing
- it was missing default initial values for background-size and
background-position from the generated test output
When the toplevel is a GdkOffscreenWindow which doesn't
implement the set_device_cursor() vfunc, we would have
crashed. Implement a dummy ->set_device_cursor vfunc.
https://bugzilla.gnome.org/show_bug.cgi?id=675809
To make setting output directory and filename simpler in the PrintToFile
dialog two gtkprintsettings have been added GTK_PRINT_SETTINGS_OUTPUT_DIR
and GTK_PRINT_SETTINGS_OUTPUT_BASENAME.
This will reduce the code needed to implement a better name than "output.pdf"
and actually makes more sense than the existing setting
GTK_PRINT_SETTINGS_OUTPUT_URI which doesn't work seamlessly with
GTK_PRINT_SETTINGS_OUTPUT_FILE_FORMAT like the new settings do.
https://bugzilla.gnome.org/show_bug.cgi?id=657322
Before, right click events were still let through into GDK. In this
case, also middle/right button events with x-coordinates in the range
[-3, 0] are processed, resulting in failures/crashes in the window
finding code because no GdkWindows are present in this range.
Not setting a URI but catching the activate-link signal is a
valid use of GtkLinkButton, but we shouldn't allow showing a
popup menu which offers to copy the URI if there's none.
Turn dead_doubleacute plus space into '"' and not into a double
acute because that's the way to enter double quotes on the
US-International keyboard layout.
(cherry picked from commit 71164e57b9)
Code was using different places to compute the icon size when layouting
and when doing size requests. This resulted in non-matching behavior in
obscure cases. And that lead to iconviews that were too small.
This makes sure that if the gtk-im-module setting changes we update
our internal state immediately on the next event whichever it is.
In particular this fixes the case of the gtk-im-module setting
changing while the user is typing and the slave context remaining the
same, effectively ignoring the setting change.
https://bugzilla.gnome.org/show_bug.cgi?id=675365
Commit cdf473ec10 deprecated the style
properties associated with the container border width and box spacing of
the action and content areas, in favour of using
gtk_container_set_border_width() and gtk_box_set_spacing() on the
widgets themselves, but failed to initialize those values to the
defaults.
Makes name consistent with other quartz-only modules and makes it clear that this works with the GMenuModel system rather than the older GtkMenu system.
The window's role is 'GtkFileChooserDialog', so that window managers can match it
for positioning.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Instead, always use PKG_CHECK_MODULES(). That macro actually gets it
right. In particular the erroring out part when you miss xkbcommon or
wayland-client.
This ensures that items stay left-aligned instead of slowly expanding into
empty space when widening the iconview. It's also what the iconview did
pre-refactoring.
Note that for cases where natural width != minimum width, the cells
might still expand and shrink back.
Always assume max-columns and min-rows. The old approach was kinda
insane.
As an example, try to write an algorithm that optimizes the minimum size
for infinite (take a reasonably large number like 2520) word-wrapped
Monospace text cells containing the text "XXXXX XXX XXX XXXXX" (keep in
mind that this is the easy problem, because it's assuming equal cell
renderers). There's 4 ways to reasonably lay out this text:
19 glyphs (19x1):
XXXXX XXX XXX XXXXX
18 glyphs (9x2):
XXXXX XXX
XXX XXXXX
21 glyphs (7x3):
XXXXX
XXX XXX
XXXXX
20 glyphs (5x4):
XXXXX
XXX
XXX
XXXXX
The best thing to do usually is using the 9x2 approach, but that's
neither the one using the natural nor the one using the minimum size.
As a side note, this does not include spacing and padding, which might
also influence the decision. Nor does it include height-for-width
considerations. Look at this table (numbers given in glyphs, not pixels,
as for pixel-sizes it gets even more interesting):
given best solution
width columns sizing glyphs per cell
6 1 6x4 20
7 1 7x3 21
8 1 7x3 24
9 1 9x2 18
10 1/2 9x2/5x4 20
11 1/2 9x2/5x4 22
12 1/2 9x2/5x4 24
13 1/2 9x2/5x4 26
14 2 7x3 21
15 3 5x4 20
16 3 5x4 21.3
17 3 5x4 22.7
18 2 9x2 18
19 1/2 19x1/8x2 19
20 1/2/4 19x1/8x2/5x4 20
21 1-4 any 21
22 1-4 any 22
23 1-4 any 23
24 1-4 any 24
25 5 5x4 20
26 5 5x4 20.8
27 3 9x2 18
28 3 9x2 18.7
29 3 9x2 19.3
30 3/6 9x2/5x4 20
Now of course, nobody wants the number of columns to randomly change in
inexplicable ways while they enlarge or shrink an iconview, so we not
only have to optimize for smallest or other size measurements, but we
also have to optimize for "most pleasing to the eye".
And last but not least, I'd like to once again remind you - if you kept
up until now - that this discussion was for identically-sized cells
only.
Instead of just returning the last allocated numbers, we now compute the
proper sizes from scratch. This is a bit less trivial, but it results in
proper height-for-width handling.
This is a huge quest to remove all caching from GtkIconview to simplify
the code. As it turns out, iconview performance is a joke, so the caches
are kinda unnecessary.
If we need caching, we can add it in a useful way later.
If we use
&item->cell_area
instead of
(GdkRectangle *) item
there is no need anymore to keep the cell_area as the first member of
the the item. And we cget compile-time checks for changes to the item
struct.
It's wrong to hardcode the slider lines here; those should be rendered
as an additional background layer using background-image if the theme
specifies so.
https://bugzilla.gnome.org/show_bug.cgi?id=652304
Instead of setting it on the child scrolled window. This is needed
because the whole window's allocation must be equal to the one of the
entry (in case the popup-set-width property is TRUE); if we set the size
request on a children of the window, there might be other children with
borders/paddings in between the toplevel and the child we set the size
request too, which will break alignment.
https://bugzilla.gnome.org/show_bug.cgi?id=672947
GDK_EVENT_2BUTTON_PRESS and GDK_EVENT_3BUTTON_PRESS can't be used from
some bindings because they'd translate to something syntactically
invalid. Add GDK_EVENT_DOUBLE_BUTTON_PRESS and
GDK_EVENT_TRIPLE_BUTTON_PRESS aliases to work around that.
https://bugzilla.gnome.org/show_bug.cgi?id=671025
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
Since themes might want different paddings around the color sample
according to where it's being used, don't hardcode a 16px one here.
The theme can specify a padding to get the same effect.
Reported by Christian Persch <chpe@gnome.org>
Add a fallback-c89.c for the gdk/ subdirectory as there is code that uses
functions that are introduced by C99. This currently adds fallback
implementations for MSVC for isnan() and isinf()
Dist this "new" source file as well
nearbyint(), isinf() and isnan() are C99 functions, so check for them.
Also clean up configure.ac a little bit as the checks for rint() and
round() can be a bit simpler, according to Matthias' suggestions.
On Windows, gtkwin32themeprivate.h is needed as
_gtk_win32_theme_get_default() is called on that platform to avoid C4013
warnings/errors (aka implicit declaration of ... for GCC folks).
See inline comments for what it does. Its main use is figuring out if
something has been caused by GTK's caching of CSS properties or if it's
a different problem.
.. instead of the previous stable version.
This ensures that if we use GDK_DEPRECATED_IN_3_6, it will actually emit
a warning in GTK 3.5, and not wait with that until GTK 3.7. This is
particularly useful for stuff that gets deprecated right now. This code
should emit warnings right now, so we know what we're doing while
deprecating.
GApplication now makes the session bus and object path available as a
public API on the application instance. Use that instead of trying to
guess values for ourselves.
This causes this version of Gtk+ to depend on GLib 2.32.2, so bumping
version dependency accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=671249
We currently have a couple of cases where GtkApplication assumes that
the session bus will be non-NULL causing critical error output or (in
the case of trying to publish menus) an infinite loop.
Three fixes:
- if the session bus is NULL due to not having registered the
GtkApplication yet then give a g_critical on the entry point to the
menu setters instead of going into an infinite loop. Document this.
- check for NULL session bus even when calling the menu setters at the
right time in order to prevent the infinite loop for
non-programer-error cases (ie: because we had trouble connecting to
the session bus)
- check for NULL session bus when publishing the X11 properties on the
GtkApplicationWindow and skip publishing them if we're not on the bus
https://bugzilla.gnome.org/show_bug.cgi?id=671249
The way we use these style properties to set regular properties on
containers accessible from the public API is really just broken, and
could lead to undefined values for the spacing and border-width
container properties (since they could be set from public API and then
changed from under in a style_update handler from GTK).
Take this as an occasion to deprecate these style properties, which do
not make a lot of sense anyway, now that GtkInfoBar supports regular CSS
padding and border.
GtkPlug directly handles X KeyPress/Release events, instead of using
translation in GDK (which expects XI2 events for XI2). When this
was done, the handling of the group was stubbed out and never replaced.
Export gdk_keymap_x11_group_for_state() and gdk_keymap_x11_is_modifier()
so we can fill out the fields correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=675167
InfoBar must take into account the border and padding when requesting
its allocation, since it is then drawing them. Besides, the border and
background should always be drawn, even when the message type is OTHER.
These need to be made independent of the xkb configuration somehow.
As things are now, they will either fail when run on a naked X
server in make check, or fail when run in my session.
If the PPD is not available when the printer is loaded then the PPD options are
not available and we can't get the correct qualifier to use with colord.
When the PPD becomes available, refresh the profile title to reflect reality.
https://bugzilla.gnome.org/show_bug.cgi?id=674890
Shift-click in the slider now starts a drag in 'fine adjustment'
mode, where we move the slider 10-times slower than the mouse.
This can be very helpful when scrolling through a very long document
or webpage, and moving the scrollbar even a single pixel already
jumps too far in the content.
https://bugzilla.gnome.org/show_bug.cgi?id=563688
It seems to be general consensus that button 1 should do the jumping,
so we now jump to the clicked position on primary button clicks and
page on secondary button clicks. Touch behaves like primary.
https://bugzilla.gnome.org/show_bug.cgi?id=563688
Symbolic icons use a "-symbolic" suffix to distinguish themselves from
highcolor variants. Note that the dash character here has a different
meaning than the specificity level defined in the icon-naming-spec [1],
as it identifies a property of the icon itself.
Since they might be provided by a parent theme (e.g. the HighContrast theme
relies on the gnome icon theme for them), when we are looking up one we
should first escape the generic icon inheritance mechanism defined in the
icon-naming-spec [1], and privilege a symbolic icon, if it exists in a
parent theme, before applying the inheritance evaluation.
This fixes symbolic icons not working properly when used in the
HighContrast theme with the GTK_ICON_LOOKUP_GENERIC_FALLBACK flag set.
[1]
http://standards.freedesktop.org/icon-naming-spec/latest/ar01s03.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=674806
Avoid doing useless translations/rotations, since themes will most
likely set different CSS gradients using left/right/top/bottom style
classes, or use a plain color.
https://bugzilla.gnome.org/show_bug.cgi?id=674809
This allows combo box popup windows to appear in the correct place. This is a
workaround emulating root coordinates by calculating the offset for a chain
of windows that that are relative to each other.
This was broken since before GTK+ 3.0, when we replaced
a use of requisition by allocation. Fix this by using the
requisition height, that is already cached by the menu code.
The math is not quite right here; if you page all the way
down a long menu, you end up on the second-to-last menuitem.
But at least, page up/down let you move up and down the menu
again.
https://bugzilla.gnome.org/show_bug.cgi?id=668931
Having refactored cups_request_printer_list_cb so that the cups
version-dependent block size is small enough to be handled in a single ifdef,
make the ifdef HAVE_CUPS_API_1_6 block.
So that it can be passed as a single parameter to functions as we extract-function to make cups_request_printer_list_cb more manageable.
Note that not all of the affected variables are changed in this changeset. Those are in extracted functions and will be addressed in the next two changes.
Since the event will be ignored anyway after it's translated (slave
devices are disabled), don't let it run in the smooth scroll code path,
as it will burn our caches for the actual event we're interested in.
https://bugzilla.gnome.org/show_bug.cgi?id=673644
Of course, we must pass coordinates in the NSWindow coordinate system
when creating an NSEvent. This fixes drag icon positioning and makes
the icon slide back to the correct position when the drag is
canceled.
Due to the way the tests are structured, a missing libXext will give a
warning about a missing libX11 (even if libX11 is installed). This is
confusing to people who are trying to build Gtk.
https://bugzilla.gnome.org/show_bug.cgi?id=674200
Instead of overriding the font theme settings, just set the Pango
attributes we want on the label. This fixes message dialogs growing on
style_update after recent GTK+ changes.
Instead of using 1 global queue for both resizes and style validation,
use 2 queues. This makes the code a lot simpler and fixes a bug where we
could accidentally stop restylying for very delayed restyles.
We now animate the core style information (see comment in
gtk_style_context_save()). A lot of widgets save + set custom style
classes/states during drawing and so can't be animated. It does work for
labels, menus and buttons though.
This is a GtkCssComputedValues subclass. So it's essentially a store for
computed CSS values. But it can be animated by advancing it to a certain
timestamp.
A StyleAnimation is an immutable object used to track the state of CSS
values. I'd have liked to make it fully immutable - ie not have the
timestamp in there - but couldn't find a place to sanely store the
timestamp.
This is an abstract base class. Implementations for this will be added
later (for both CSS3 transitions and animations, potentially for
animated images).
Actually aplying the information in this object will be done by a
different object commtted later.
This has two goals:
1) Move invalidation code out of a nested if branch. Invalidation is
actually the most important thing this function does.
2) Have the changes bitmask available. It will needed for invalidate
calls to children later.
The design principles were:
- synchronized
If multiple style contexts are animating, they should all do an
animation step at the same time.
- degrades well
Even when there's thousands of style contexts all animating at the same
time, the animation steps don't starve the CPU. This is achieved by
making sure the timeout is really fast. It just sets a bunch of flags.
- no hidden bottlenecks
Turning animatability on or off on a style context is O(1).
So far it is unused.
This is only a small performance boost by itself, but it's necessary
for animations, so we need it.
Benchmark numbers for my Glade benchmark for interested people:
GTK 3.4.0 last commit this commit
Raleigh
real 0m41.879s 0m10.176s 0m9.900s
user 0m41.394s 0m9.895s 0m9.628s
sys 0m0.111s 0m0.096s 0m0.102s
Adwaita (*)
real 0m51.049s 0m13.432s 0m14.848s 0m12.253s
user 0m50.487s 0m13.034s 0m13.218s 0m11.927s
sys 0m0.117s 0m0.151s 0m0.147s 0m0.107s
Ambiance (patched to not use private GTK APIs)
real 0m52.167s 0m13.115s 0m13.117s 0m12.944s
user 0m51.576s 0m12.739s 0m12.768s 0m12.651s
sys 0m0.119s 0m0.137s 0m0.136s 0m0.118s
(*) Adwaita and unico currently use custom properties, and
_gtk_css_value_compare() for custom properties always returns FALSE,
which makes this optimization never trigger. So I modified
_gtk_css_value_compare() to return TRUE for these properties instead and
reran the benchmark. Those are the numbers.
Add an internal API that allows GtkStyleContext to create a widget path
for the widget and with that bypassing gtk_widget_get_path() and that
function caching the path.
Instead, look up the variable upon use. This is more correct (for when
the engine changes due to save/restore() shenanigans.
And it removes code that doesn't use the standard code paths.
Equality tests are done with _gtk_css_value_equal(). There is no need to
do it per-property, equal values will still be equal.
This essentially reverts 24f5d54329e028347bd76af42e86ed190c1229a2 and
92c7a7171e1240b6d961ee5b6f9ab6b596e98904.
... and Make this new value be a real GValue, as we don't need to save
performance for these anymore (it's just used for custom properties).
And I'd rather have code work for all values then be optimized for no
reason.
Deprecate public API where appropriate and make it no-ops.
Remove all calls to it.
Get rid of the 'transition' css property.
For now, this means spinners don't animate anymore.
Instead of keeping a custom GPtrArray, keep it as a GtkCssArrayValue of
GtkCssStringValue. This way, we gain equality comparisons and print
functions for free.
All the properties now are a GtkCssArrayValue of GtkCssSadowValue.
GtkCssArrayValue already does everything we want, so no need to
duplicate its funtionality.
When a parent style context exists, there's no need to queue_resize() on
the widget, because the parent widget will call
gtk_style_context_validate() on us and _then_ we can call queue_resize()
if we have to.
Only the ones that can be animated are marked of course. So more work is
needed.
This is important for
transition-property: all;
because it'll just animate all the properties that can be.
So instead of using
_gtk_css_style_property_get_id (GTK_CSS_STYLE_PROPERTY
(_gtk_style_property_lookup ("name")))
one can now use
GTK_CSS_PROPERTY_NAME
Esaier, eh?
Returns a value that transitions between start and end or %NULL if the
values cannot be transitioned.
So far, all implementations but numbers and rgba return NULL.
Note: custom CSS properties still use the default GtkCssValue and always
will.
So there is a difference in css values used between those, even though
they both carry a GdkRGBA payload.
The compute_value fallback path is only needed for custom properties,
the real style properties have custom compute functions if they need
them already.
This is in preparation for removing the specified type and computed type
properties from GtkCssStyleProperty, which is in preparation for really
using GtkCssValue classes and not GTypes.
For now, we return FALSE for all default css values, so this is not very
useful.
I also think of this as an optimization equal, not a guaranteed equal,
because we don't even have a notion of what "equal" means.
For example, for background-repeat, "repeat, repeat" and "repeat"
are functionally equivalent. But the cssvalue has no idea that it's used
for background-repeat.
As a more complicated example, "repeat, no-repeat" and "repeat" are
equal to what one sees as long as there's only one image listed
background-image-source. But once you start transition'ing to an image
with 2 sources, it's different...
This change isn't strictly correct, but I can't be bothered until we get
a tokenizer that can really differentiate between allowed values and
invalid syntax.
... and actually set the widget on the style context. Note that this
function does not take a reference on the widget, which is a very good
reason to keep it private.
This matcher always matches only on some relvant things and ignores the
rest. This allows you to match only on name and class, but ignore state
and parents/siblings for example.
We now track the position as a (type,a,b) tuple where the numbers make
up the an + b formula from CSS3 nth-child.
Also, the get_sibling() and get_sibling_index() vfuncs were replaced by
a has_position() vfunc. This is mostly so that the matcher can always
return TRUE. And I need that for the everything matcher.
This way, we don't have to do magic inside GtkStyleContext, but have a
real API.
As a cute bonus, this object implements GtkStyleProvider itself. So we
can just pretend there's only one provider.
This change adds --enable-wayland-cairo-gl which turns on the define used in
the Wayland backend to determine whether to use EGL surfaces with Cairo GL or
whether to use the Cairo image backend with an SHM surface (the default).
Part of the fix for: https://bugzilla.gnome.org/show_bug.cgi?id=672361
This moves the freeing of the icon_helper from the destory to the finalize
function to avoid segfaults when trying to access a destroyed object before it
is disposed. This often happens in signal handlers which get called
asynchronously after destroy.
https://bugzilla.gnome.org/show_bug.cgi?id=674050
Try to fetch the name from the application desktop file for the
fallback menu if possible, instead of forcing applications to use
g_set_application_name or hardcoding "Application".
https://bugzilla.gnome.org/show_bug.cgi?id=673882
In the Quartz backend, there are two methods by which windows are
resized. The first method is fully handled by Quartz and does not appear
in the event stream the application resizes. The second method is when
we resize windows by ourselves. In OS X this happens when a GTK+ resize
grip is used. This resize grip is larger than the Quartz resize grip.
When the resize is started outside the "Quartz area", we have to handle
it by ourselves.
This patch fixes this manual window resizing by ignoring events while we
are in the process of resizing (such that the events actually arrive at
the sendEvent handler of GdkQuartzWindow where this resize is handled).
When the resize has finished we break all grabs such that GDK is not
stuck thinking the cursor is still in the resize window.
gtk_entry_completion_set_property() was setting many properties by
directly modifying priv values, bypassing notification invocation and
possibly another actions done by gtk_completion_entry_set_xxx ()
functions. Fix by invoking set_xxx() instead of setting the property
value directly.
The real bug observerd was that setting text-column property using
g_object_set() caused SIGFPE later when entry completion was about to
appear. gtk_entry_completion_set_text_column () apparently does way
more important things than just setting priv->text_column member.
https://bugzilla.gnome.org/show_bug.cgi?id=673693
Instead, just draw the children. The cairo code will keep track of
things, so there's no need to track things.
Also, the old code was doing it wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=672544
Style properties should not be cached, they should be queried live.
Also, this fixes the case where the expander size wasn't set when
constructing the widget which caused expanders to go missing.
This can cause lagging when scrolling as it causes us to repaint
on every scroll event. This wasn't historically a great problem,
but with smooth scrolling we get a lot more events, so this
now creates visible lagging on slower machines.
_gdk_x11_moveresize_configure_done() isn't called for wmspec
moves/resizes so we don't have a way to notice when a wmspec
move/resize ends and consequently untrigger the sending of
_NET_WM_MOVERESIZE_CANCEL which results in this message always being
sent on the next button release event. In that case we are marking
that event as handled so it isn't processed further which breaks
button press/release event handling in several widgets.
To fix this we simply allow the normal event handling machinery to run
after sending the _NET_WM_MOVERESIZE_CANCEL message.
https://bugzilla.gnome.org/show_bug.cgi?id=673328
Since the order in which _NET_WM_STATE and _NET_WM_DESKTOP are set, or
even *if* they are set, isn't defined, we could end up unsetting
GDK_WINDOW_STATE_FOCUSED given that both handlers for these two X
properties end up doing window state changes for all states. As we
want GDK_WINDOW_STATE_FOCUSED to be set by default we need to set its
master flag by default as well.
https://bugzilla.gnome.org/show_bug.cgi?id=673125
Don't handle mouse button events greater than 5 so
they can bubble up to be used by the application.
This was causing nautilus list view to not go forward
and backwards when pressing the extra mouse buttons
designated for that.
Fixes bug 673441
Signed-off-by: Nelson Benitez Leon <nbenitezl@gmail.com>
This is not ideal, we should have a real classic windows theme,
but at least its better than everything being pink, which is what
happens otherwise when theming is not enables.
We now have a proper MASTER/SLAVE input device split, where
the masters are virtual core input devices and we add fake hw
slave devices for the system pointer and real slave devices for
wintab devices.
We also set the proper source_device on the events so you can
tell which device sent it and properly decode the axis info.
gtk_application_set_app_menu(), gtk_application_set_menubar():
Mention that you probably want to call this in the startup signal
handler. If you do it earlier you will likely get a warning about
a missing D-Bus connection, because doing it earlier does not
make sense anyway.
Since we check for !list->next (and !list->prev for RTL) to set the
GTK_REGION_LAST flag, we have to filter out invisible columns before
looping; if we don't do that we might end up assigning GTK_REGION_LAST
to an invisible column.
https://bugzilla.gnome.org/show_bug.cgi?id=672937
When a homogeneous grid has no visible children, we were
accidentally doing a division by zero. Instead, just bail
out early in this case, there is nothing to allocate anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=672763
The code for calculating the per-monitor workarea was ignoring
the fact that the EWMH workarea property can only handle rectangular
workareas, and thus can't really do justice to general monitor
arrangements. As a workaround, we ignore it for anything but
the primary monitor. And we ignore it for the primary monitor
as well if it does not even cover it.
https://bugzilla.gnome.org/show_bug.cgi?id=672163
We want to use Alt+Print for screenshot keybindings, so we have to avoid
translating it into SysRq, since that's what the keymap would dictate.
After talking with Owen, it sounds like doing this generically would be
a lot of work and quite hairy code, so hardcoding this should be OK.
https://bugzilla.gnome.org/show_bug.cgi?id=671006
When we are re-setting the same text for internal reasons
(e.g. when applying the mnemonics-visible change upon Alt press),
we should not needlessly loos the selection.
https://bugzilla.gnome.org/show_bug.cgi?id=671588
Commit de62a1096 broke win32 as it removed the HAVE_X11R6 checks for
building xim, but did not replace them with USE_X11. This made
it try to build xim on non-X targets.
We only support the preview state for checkboxes for GtkButton
because it gave problems when used in treeview where the prelight
state affects all checkboxes in the row.
When GtkPrinterFunc always returns FALSE, for example when looking for
a non existent printer, if print list is done for all backends or print
backend status is UNAVAILABLE, gtk_enumerate_printers() finishes with an
empty backend list and destroy function is never called. We need to
check the backend list again after calling list_printers_init for all
backends and finish the enumeration if it's empty.
https://bugzilla.gnome.org/show_bug.cgi?id=672125
As we don't give out information about the group or level when
giving back keycodes, we should prioritise group-0, level-0, followed by
level-0 only, and then any keycodes.
This fixes "q" being pressed when the Wacom tablet code in
gnome-settings-daemon is supposed to generate an "a" ("uk" keymap
in group-0, "fr" in group-1).
https://bugzilla.gnome.org/show_bug.cgi?id=671065
When the scrolled window has a frame (and the scrollbar is within the
bevel), we should take into account the CSS border/padding of the frame
and offset the scrollbars junction rendering with it.
It seems XP doesn't handle drawing non-alpha theme parts
on alpha destinations. We fix this by using alpha bitmaps only when
needed.
However this means any non-drawn area by the theme part is now draw
black, so we must take more care to only draw where the theme part draws,
so we find the theme part size when available.
We now store the symbolic colors as a GtkCssValue which means that
we can reuse the color when resolving and storing the color in
the computed values in the style context.
Additionally we keep a last_resolved GtkCssValue cache in the
GtkSymbolicColor, and if resolving the color returns the same as
last time we reuse the old value. This further increases sharing
of Css Values.
va_copy() is not universally available, and we already have a G_VA_COPY
macro that emulates the behaviour of va_copy() when it's not available, or
simply calls va_copy() if it's there
Also, in places where we're computing a new CssValue based on an
old one, make sure that if nothing changes we're returning a reference
to the old one, rather than creating a new identical instance.
Some people destroy their widgets in ::response, so trying
to access dialog internals from the class handler that is
running afterwards has the potential to cause problems.
Instead, we can reset the ::show-editor property every
time we map the dialog.
We want to avoid handling focus events for the private focus window,
otherwise the keyboard grab taken by for example buttons will cause a
spurious FOCUS_OUT/FOCUS_IN on the toplevel.
The code that did this seems to have been lost in the XI2 transition for
GTK3.
This patch reapplies db4a6040af which was
backed out in 18406b7b04 to give
developers a chance to get their X servers fixed. As we want to get this
bugfix in for 3.4, we need to commit it now.
https://bugzilla.gnome.org/show_bug.cgi?id=657578
Check for the XIScrollClassInfo struct in addition to the existing
check for XIAllowTouchEvents() because Ubuntu Oneiric seems to
have an incomplete backport which has one but not the other.
Based on a patch by Murray Cumming,
https://bugzilla.gnome.org/show_bug.cgi?id=671453
Scroll events report normalized deltas in terms of an abstract
'scroll unit' now, so our job is to determine a suitable scroll
unit here. Since we are changing the value of the adjustment,
the allocation of the widget does not factor into this at all.
XI2 provides us with an increment for each scroll valuator,
and by dividing the delta by the increment, we obtain normalized
values in some abstract 'scroll unit'.
For mouse wheels, the evdev driver reports an increment of -1,
so doing this division fixes the inverted scrolling with wheels
that we've seen recently.
When doing homogeneous allocation in the presence of
overlapping spanning children, we need to avoid uneven
line allocations, otherwise, the final homogenization
will blow up the size request of the grid.
https://bugzilla.gnome.org/show_bug.cgi?id=671170
In particular gtksettings.h and gtkstylecontext.h needed to be included
in lots of places now.
Also, I order the includes alphabetically in a bunch of headers.
Support long press for customizing, and short press for
selecting/activating. This is simpler than the generic
press-and-hold support in the multitouch branch; we don't
display any feedback, and the timeout is currently hardcoded
to 1 second.
GtkRange was using GDK_POINTER_MOTION_MASK, and it was not
getting any emulated motion events, because we only translate
from GDK_BUTTON_MOTION_MASK to GDK_POINTER_MOTION_MASK, but not
the other way around, and emulated_mask only had
GDK_BUTTON_MOTION_MASK in it. Now we put GDK_POINTER_MOTION_MASK
in emulated_mask and successfully match for windows that
have GDK_POINTER_MOTION_MASK or any of the button motion masks
selected.
This fixes range sliders not following the finger and jumping
to the last position upon release.
If the Window Manager supports the _NET_WM_STATE_HIDDEN, we use it to use
the _NET_WM_STATE protocol when de-iconifying windows (iconification is
unchanged, via XIconifyWindow). Additionally, we no longer interpret all
UnmapNotify events for our window as the result of iconification.
(Based on patch by Tomas Frydrych <tf@linux.intel.com>)
Previously we kept a Selector object for every "simple selector" (term
from CSS spec). Now we keep one for every match operation. So given the
selector
".a b:focus"
we will have 4 elements:
- pseudoclass ":focus"
- element "b"
- match any desendant (the space)
- class ".a"
Each of those is represented by a "selector class" which is basically
the collection of vfuncs for this selector.
NSEvent -scrollingDeltaX and -scrollingDeltaY aren't defined before
10.7, so objc assumes that they return a pointer. Trying to cast to a
float generates a compiler error.
If delta_x/y information is provided in scroll events, use it
to modify the underlying adjustment in steps proportional to
the deltas provided.
If the child widget of a scrolledwindow doesn't set
GDK_SMOOTH_SCROLL_MASK, regular scroll events will be dispatched,
and still handled by these 2 widgets.
XInput >= 2.1 allows for implementing smooth scrolling,
reporting the different scrolling axes as valuators.
Any change in those will be reported as GdkEventScroll
events with delta_x/y information.
the older kind of scroll events is still handled, and
emulated in devices able to provide smooth scrolling,
setting _gdk_event_set_pointer_emulated() in that case.
nsevent scrollingDeltaX/Y (available on OSX >= Lion) is used to
provide the smooth scrolling values. In any case, old fashioned
events are still sent, setting _gdk_event_set_pointer_emulated()
if the event contains both smooth and non-smooth values.
Events of type GDK_SCROLL will be received if the client side window
event mask has either GDK_SCROLL_MASK or GDK_SMOOTH_SCROLL_MASK.
GDK_BUTTON_PRESS_MASK has been removed from type_masks[GDK_SCROLL]
as that bit is often set for other-than-scrolling purposes, and
yet have the window receive scroll events. In GTK+, this forces
non-smooth events bubbling, even if the widgets above want smooth
events, and legitimately set GDK_[SMOOTH_]SCROLL_MASK.
If a device provides both smooth and non-smooth events, the latter will be
flagged with _gdk_event_set_pointer_emulated() so the client side window
receives one or the other. If a device is only able to deliver non-smooth
events, those will be sent, so both direction/deltas may need to be handled.
get_event_window() just checked on GDK_TOUCH_MASK, including for emulated
pointer events, so at the very least those should also match evmasks with
no touch events whatsoever
If an active grab kicks in on a different window, _gdk_display_has_device_grab()
would still find the former implicit grab for the window below the pointer, thus
sending events to an unrelated place.
If a grab with GDK_TOUCH_MASK kicks in due to a touch sequence emulating pointer
events, don't mutate the sequence into emitting touch events right away.
Create the backing GdkTouchGrabInfo for touches even if the pointer
emulating touch sequence is already holding an implicit grab on a
window that didn't select for touch events.
the backing GdkTouchGrabInfo will be needed if the overriding device
grab finishes before the touch does in order to send events back to
the implicit grab window. Instead, wait until the touch is physically
finished before removing the matching GdkTouchGrabInfo
GDK will only receive touch events when dealing with a multitouch
device, so these must be transformed to pointer events if the
client-side window receiving the event doesn't listen to touch
events, and the touch sequence the event is from does emulate
the pointer.
If a sequence emulates pointer events, it will result in a
button-press, N motions with GDK_BUTTON1_MASK set and a
button-release event, and it will deliver crossing events
as specified by the current device grab.
These are equivalent to an implicit grab (with !owner_events), so
if the touch leaves or enters the grab window, the other window
won't receive the corresponding counter-event.
If the touch sequence happens on a window with GDK_TOUCH_MASK set,
a GdkTouchGrabInfo is created to back it up. Else a device grab is
only created if the sequence emulates the pointer.
If both a device and a touch grab are present on a window, the later
of them both is obeyed, Any grab on the device happening after a
touch grab generates grab-broken on all the windows an implicit
touch grab was going on.
Touch events don't generate crossing events themselves, so
do not rely on these to determine whether the button release
happened within the event window.
This widget is too narrow to make touch interaction tricky enough, so
don't add the penalty of having the slider run farther from the touch
coordinates if it happens to miss the slider.
This is so submenus stay open as the parent menu item is
pressed/released, since the user would typically lift the
finger in order to select a submenu item.
This makes kinetic scrolling work with viewports where the
content does not otherwise select for button or touch events,
such as testscrolledwindow's label.
Kinetic scrolling is only done on touch devices, since it is
sort of meaningless on pointer devices, besides it implies
a different input event handling on child widgets that is
unnecessary there.
If the scrolling doesn't start after a long press, the scrolling is
cancelled and events are handled by child widgets normally.
When clicked again close to the previous button press location
(assuming it had ~0 movement), the scrolled window will allow
the child to handle the events immediately.
This is so the user doesn't have to wait to the press-and-hold
timeout in order to operate on the scrolledwindow child.
The innermost scrolled window always gets to capture the events, all
scrolled windows above it just let the event go through. Ideally
reaching a limit on the innermost scrolled window would propagate
the dragging up the hierarchy in order to keep following the touch
coords, although that'd involve rather evil hacks just to cater
for broken UIs.
Anytime a touch device interacts, the crossing events generation
will change to a touch mode where only events with mode
GDK_CROSSING_TOUCH_BEGIN/END are handled, and those are sent
around touch begin/end. Those are virtual as the master
device may still stay on the window.
Whenever there is a switch of slave device (the user starts
using another non-touch device), a crossing event with mode
GDK_CROSSING_DEVICE_SWITCH may generated if needed, and the normal
crossing event handling is resumed.
This patch adds a capture phase to GTK+'s event propagation
model. Events are first propagated from the toplevel (or the
grab widget, if a grab is in place) down to the target widget
and then back up. The second phase is using the existing
::event signal, the new capture phase is using a private
API instead of a public signal for now.
This mechanism can be used in many places where we currently
have to prevent child widgets from getting events by putting
an input-only window over them. It will also be used to implement
kinetic scrolling in subsequent patches.
http://bugzilla.gnome.org/show_bug.cgi?id=641836
We automatically request more motion events in behalf of
the original widget if it listens to motion hints. So
the capturing widget doesn't need to handle such
implementation details.
We are not making event capture part of the public API for 3.4,
which is why there is no ::captured-event signal.
We don't want to fallback for 'random' touch sequences, since
that could lead to all kinds of pairedness and other violations.
Since the X server already tells us what touch events it would
have used for emulating pointer events, we just use that information
here.
Translate XI_TouchBegin/Update/End to GDK_TOUCH_BEGIN/UPDATE/END
events.
At the same time,
set pointer-emulated flags on button events with XIPointerEmulated
and on touch events emulating the pointer.
This commit introduces GDK_TOUCH_BEGIN/UPDATE/END/CANCEL
and a separate GdkEventTouch struct that they use. This
is closer to the touch event API of other platforms and
matches the xi2 events closely, too.
We introduce GDK_SOURCE_TOUCHSCREEN and GDK_SOURCE_TOUCHPAD
for direct and indirect touch devices, respecively. These
correspond to XIDirectTouch and XIDependentTouch in XI2.
GtkButton currently draws itself as active (pressed down) in case we're
pressing and holding the mouse pointer outside its bounds; this is
misleading though, since we won't activate the button unless the mouse
is released inside the button itself.
Fix this by only setting the ACTIVE state flag when the button is
actually pressed down.
https://bugzilla.gnome.org/show_bug.cgi?id=668141
This does nothing but turn all GtkBitmask functions into static inline
functions that call the gtk_allocated_bitmask_*() equivalent.
The implementation of the static functions has also been put into a
private header, to not scare people who want to see how things are
implemented.
My previous fix for this broke the progress bar in epiphany. This fix
makes it work again, and keeps the gimp bug fixed.
Basically, whenever we do a non-double-buffered rendering we have to
flush the entire window as it might be drawn outside the double
buffering machinery.
When we're allocating children of GtkOverlay, compare their allocation
with the overlay one, and set left/right/top/bottom style classes if the
overlaid widget touches one or more of the overlay edges.
https://bugzilla.gnome.org/show_bug.cgi?id=669342
gtk_widget_translate_coordinates() can fail in case the widget is not
realized or there's no common ancestor. Don't use the x/y values
returned by that method in that case, since their value is undefined.
If there's a junction between the two scrollbars (i.e. they're both
visible), draw a background with a style class there, so the theme can
style it.
https://bugzilla.gnome.org/show_bug.cgi?id=669335
If the display server or GDK hides the window - fire the "deactivate" signal
to ensure that the internal state is consistent.
This patch also ensures that the "deactivate" signal will not be fired for a
menu that is not active.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=670881
Since GtkCellRendererText moved to WFH requests, our get_size
implementation is ignored. We should override get_preferred_width
instead. This fixes the accel renderer being clipped to a wrong size
when trying to edit its shortcut.
Once we've made them popup windows we must also implement the popup_done event
handler on the shell surface listener. The best we can currently do is to hide
the window. This will then signal up to GTK which could then deactivate the
appropriate menu (see https://bugzilla.gnome.org/show_bug.cgi?id=670881)
This allows us to get the device if we need to make the window a popup. This
relies on the side effect that GTK calls into GDK to take a grab before the
popup window is shown.
Since it's generated, we install the header by putting it into
gdkinclude_HEADERS, so it's wrong to put it again into
gdk_public_h_sources.
This fixes the build.
This patch changes all uses of GDK_DEPRECATED(_FOR) in gtk headers
by the versioned variants, GDK_DEPRECATED_IN_3_x(_FOR). At the same
time, we add GDK_AVAILABLE_IN_3_x annotations for all API additions
in 3.2 and 3.4.
This patch changes all uses of GDK_DEPRECATED(_FOR) in gdk headers
by the versioned variants, GDK_DEPRECATED_IN_3_x(_FOR). At the same
time, we add GDK_AVAILABLE_IN_3_x annotations for all API additions
in 3.2 and 3.4.
These macros follow the recent changes in GLibs deprecation
setup. We now annotate deprecated functions with the version
they were deprecated in, and you can define the macro
GDK_VERSION_MIN_REQUIRED to cut off deprecation warnings for
'recent' deprecations.
At the same time, we introduce version annotations for new API
and allow you to avoid 'recent' API additions by defining
GDK_VERSION_MAX_ALLOWED.
The message-type css classes must be in the widget context all the time,
not only when drawing, otherwise they are not propagated to the
children, for instance a label in the InfoBar must inherit the
color. Add a corresponding reftest.
https://bugzilla.gnome.org/show_bug.cgi?id=670555
The widget window is usually covered by the bin_window.
Its background color will become relevant when we introduce
kinetic scrolling with overshooting.
The widget window is usually covered by the bin_window.
Its background color will become relevant when we introduce
kinetic scrolling with overshooting.
The widget window is usually covered by the bin_window.
Its background color will become relevant when we introduce
kinetic scrolling with overshooting.
_gtk_widget_set_device_window() is suppose to make accounting of
the topmost widget under the device at each time, so avoid setting
it on virtual crossing events as the device is already in another
window.
The implicit grab on priv->event_window already warrants that this
widget is the only one getting events while the button is pressed,
so avoid the extra GTK+ grab here.
This last slave device (stored per master) is used to fill
in the missing slave device in synthesized crossing events
that are not directly caused by a device event (ie due to
configure events or grabs).
Store the device, and unset private fields whenever the device
is shadowed by another GTK+ grab, so popping up menus while
selecting (i.e. press-and-hold) doesn't leave the entry in a
confused state.
* Restores the old padding
* Prelight on spin buttons
* Don't have a generic prelight background selector, as that got
picked up by things like images that should have a transparent bg.
The F keys have no unicode mapping, and UCKeyTranslate() returns
a bogus 0x10 as mapping to unicode. Instead of checking for this
random and undocumented return value, simply assign all function
keys explicitly. This patch also splits the ill-named "known_keys"
array into "modifier_keys" and "function_keys" which is much
more obvious.
(cherry picked from commit 55f9e5cbaf)
Move g_return_if_fail() stuff from the backends to the public
functions in gdkscreen.c itself, and some fixes for ugly formatting in
the various gdkscreen-backend.c files.
No need to subtract focus line width again, since the progressbar is
rendered starting at (0, 0).
This also fixes the entry-progressbar-coloring reftest.
The file "installation" part needed a long-overdue update, especially
as some headers were simply moved into gtk/deprecated and some new headers
were introduced, and a new .gschema.xml file needed to be processed.
Instead of firing a 'quit' signal and expecting the application to do
something that will cause it to quit, just call the new
g_application_quit() API for ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=670485
This seems a bit "too powerful" and unlikely to be used by most
applications. Remove it from now, until someone comes up with a strong
desire for it.
https://bugzilla.gnome.org/show_bug.cgi?id=670485
Instead of having an input/output GdkWindow, make the widget no-window,
and use a separate input-only window for events, and paint on the parent
window directly.
When a subclass of GtkEntry (e.g. GtkSpinButton) resizes the available
text area (by overriding the get_text_area_size vfunc), we need to
ensure we don't draw a possible progressbar over the part that got
removed from the text area.
This fixes drawing a progressbar in GtkSpinButton and in its subclasses,
such as GimpSpinScale, and makes Mitch happy too!
_gdk_x11_keymap_key_is_modifier() never tries to set min/max_keycode
if they haven't been set before, meaning that until another function
sets those, all the keys will be seen as non-modifiers.
This causes GdkKeyEvents to be wrongly tagged with "->is_modifier = 0"
when in actual fact the key is a modifier. This fixes keyboard
shortcuts captured with GtkCellRendererAccel in "raw" mode thinking
a modifier without any actual keys is a valid shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=670400
We used to set a flushed boolean whenever we flushing double buffered
areas to the window due to a non-db draw. We then read back from the
window if this was set. This broke when we were doing multiple paints
of the same area after a flush as we were re-reading the window each
time, overdrawing what was previously draw.
Subclasses of GtkEntry could set a larger height request, so we need to
apply the same calculations to the insertion cursors than we do on the
PangoLayout to render it centered under all circumstances.
Instead of GtkDrawingArea, since that calls in realize
gtk_style_context_set_background(). We don't want that to happen, given
that we do all the painting ourselves in _draw().
Instead of special-casing Adwaita, apply the half-width logic for themes
that have a scale slider with vertical proportions.
Also, simplify the rendering code a bit by factoring out the trough
sizing logic.
Instead of going GtkAlignment->GtkFrame->GtkAlignment, just pack a
GtkDrawingArea inside the button, and use halign/margin properties to
get the desired layout.
Since we only allow a single row there, it's better to just use a
GtkBox, and use :first-child, :last-child and :only-child to style
swatches in there.
Instead of calling gtk_render_check() there, just render a symbolic
icon, falling back to a built-in one if the icon is not available.
Also, add a style class for the active badge on the swatch:
"color-active-badge".
Themes might want to set different colors on the badge if the displayed
color is light or dark. Use a style class for this when we set a color
on the swatch.
Rename get/set_color to get/set_rgba and show_alpha to use_alpha,
to match existing GtkColorButton API and let GtkColorButton implement
GtkColorChooser.
Implement popups in the editor, fix window sizing, fix RTL flipping.
GtkColorPlane is now using adjustments, and GtkColorEditor is using
adjustments as its model as well.
The custom colors are now pushed over to the right as new ones
are added, and everything beyond the 9th row gets dropped.
Customized colors are added to the custom colors array.
There's no reason this should be a focus ring rather than an actual
frame. In the past this was probably used to get a dashed effect, but
now we even support that natively for borders.
This fixes issues where the new default bg of transparent
didn't work, making offscreen windows black.
I don't think this is a practical performance problem.
Offscreen windows are rarely used and generally used for
graphics tricks like alpha anyway.
use direct access to the RBTree instead of fiddling with the path.
Removes the lat caller of get_index() and with it count_rows(), so those
are gone now.
Refcounting behavior kinda requires that we track of accessibles until
the row goes away. This is necessary for reference handling and for some
assumptions that atk-bridge does.
When moving a page around, all children changing their position
need to be notified.
There are still other places where proper notification is missing
(drag 'n drop, etc.)
https://bugzilla.gnome.org/show_bug.cgi?id=669116
Unsetting the widget causes events to get emitted and we want to
(a) really emit that event to our signal handlers
(b) still be recognized as a real GObject while doing that
https://bugzilla.gnome.org/show_bug.cgi?id=669794
Otherwise we fail to link, seeing this:
/usr/bin/ld: gtk3_widget_factory-widget-factory.o: undefined reference
to symbol 'gdk_pixbuf_new_from_resource'
This implements the following part of the EWMH spec:
"The special value _NET_WM_MOVERESIZE_CANCEL also allows clients to cancel the
operation by sending such message if they detect the release themselves
(clients should send it if they get the button release after sending the move
resize message, indicating that the WM did not get a grab in time to get the
release)."
In particular, it fixes the case of clicking widgets that use
gdk_window_begin_[resize|move]_drag*() and the click "sticking", i.e. the
mouse button getting released but the resize or move operation remaining in
effect.
https://bugzilla.gnome.org/show_bug.cgi?id=669208
It was problematic to maintain Raleigh going forward, as any
changes in it affected all themes. Also, its more robust if
each theme is a full standalone css rather than relying on
an inherited css base.
So, this changes Raleigh to a standalone theme that we can tweak
without accidentally breaking other themes, and makes the
default theme empty. In fact, we don't even add the default
provider anymore as its always empty.
Sometimes we need to read back the window content into our double
buffer due to rendering a window with alpha when there is
no implicit paint or it has been flushed due to non-db drawing
before.
However, in this case we can't use gdk_cairo_set_source_window as
it might trigger an implicit paint flush as we detect what we
think is a direct non-double buffered window draw operation, which
will flush the implicit paint operation that we're just setting up.
To fix this we use the raw gdk_window_ref_impl_surface operation
to get the source surface.
There was a sign issue in a coordinate transform that made us
flush the wrong region when flushing an implicit paint.
The non-double buffered drawing would then be drawn over the
right area, but then at the end of the implicit paint this
would be overdrawn with the area we didn't properly remove
from the implicit paint.
Also, the translation from window coords to impl window
coords is now done before removing any active double
buffered paints, as these are also in impl window coords.
With the changes in default CSS to make the default background transparent
we ran into issues where intermediate GdkWindow (for instance the
view_window in GtkViewport) where we didn't set an explicit background
(because before they were always covered). So instead of showing throught
the transparent windows were showing the default backgroind of the intermediate
window (i.e. black).
With this change we also needed to fix GtkViewport, as it was previously
relying on the bin and view windows to cover widget->window so that the
border was not visible if shadow_type was NONE.
NULL is an actual useful value for
gtk_action_group_set_translation_domain, but this information is buried
in g_dgettext() documentation.
Be extra redundant, to make it obvious that NULL is ok.
https://bugzilla.gnome.org/show_bug.cgi?id=669636
If called with arguments, it looks for the specified modules. The arguments
may be absolute or relative paths.
</para>
<para>
Normally, the output of <command>gtk-query-immodules-3.0</command> is written
to <filename><replaceable>libdir</replaceable>/gtk-3.0/3.0.0/immodules.cache</filename>, where GTK+ looks for it by default. If it is written to some other
location, the environment variable <linklinkend="gtk-im-module-file"><envar>GTK_IM_MODULE_FILE</envar></link>
can be set to point GTK+ at the file.
to <filename><replaceable>libdir</replaceable>/gtk-3.0/3.0.0/immodules.cache</filename>,
where GTK+ looks for it by default. If it is written to some other location,
the <envar>GTK_IM_MODULE_FILE</envar> environment variable can be set to point
GTK+ at the file.
</para>
</refsect1>
@@ -55,19 +69,28 @@ can be set to point GTK+ at the file.
</variablelist>
</refsect1>
<refsect1><title>Environment</title>
<para>
The environment variable <linklinkend="gtk-path"><envar>GTK_PATH</envar></link>
can be used to prepend directories to the input method module path.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.