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.
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
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.
... 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().
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.
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
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
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.
