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
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>
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.
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.
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 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
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.
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...
... 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 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
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.
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.
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
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
If gtkbox is the only object having a reference on one of its child
and that we try to remove it from its container, we endup having a
warning when disconnecting a signal after having unparented the
widget.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=670176
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.
Without any extra supporting code, just adding GTK_SMOOTH_SCROLL_MASK to
the event mask for GtkTextView makes GEdit do the right thing and scroll
smoothly. Lovely.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
https://bugzilla.gnome.org/show_bug.cgi?id=671488
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.
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
