combo_box_popdown() currently skips popping down our menu if it is NULL.
But the required call to this at end-of-life was in destroy(), by which
point dispose() already NULLed the menu, so Menu::popdown() would never
run, even if it should. Fix this by trying popdown() earlier in unmap().
Also, add a converse assurance that we don’t popup() while not mapped.
Even once we remove all the now-pointless NULL checks, destroy() was the
wrong place to call combo_box_popdown(), and unmap() is the right place.
gtk_init() removed its support for supporting arguments, so we ought to do
likewise for Windows, which actually defines items that call gtk_init()
the old way (and also get rid of argument support in those functions,
since the direction is to not support them).
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Commit fdc0c6426b removed the appears-as-
list style property, & hence the ability to put the ComboBox into list
mode – but it left behind a pile of hijinks that were only used in said
mode & so were now doing absolutely nothing. This commit deletes those.
While doing that, I got carried away…so this also stops pointlessly type
checking popup_widget, as that can never be anything but a GtkTreeMenu.
It still checks for NULL everywhere, which shouldn’t be needed, but (A)
this commit is already too big, & (B) simply removing such checks where
they _seem_ unnecessary causes bad times. I’ll puzzle through that later
Commit fdc0c6426b for removing (partly!)
appears-as-list also deleted the code that propagated wrap-width to the
TreeMenu and thus put us into “grid mode”. This restores that code.
And as Benjamin noted, calling check_appearance() here is wrong, so bye.
We want to simplify our initialization code and remove all commandline
argument handling from it. The first stop for this is to reduce the
number of gtk_init variants we have.
i.e. when wrap-width > 0. This was only being done for non-grid cases.
So, ComboBoxes in grid mode did not indicate their selection when popped
up and required users to keynav from ‘nothing’ (at the top-left) to the
item they wanted to select. By selecting the active item in advance, now
it’s highlighted & acts as the starting point for keynav around the grid
This previously only mentioned its effect on the displayed value, and
even after the previous commit, its rounding of the actual value upon
change still reads like too much of an afterthought. Worse, it wasn’t
mentioned at all in the doc for the @digits parameter. Change this to
emphasise rounding always occurs and the displayed value is secondary.
Whether it should is an open question, but for now, the documentation
should clearly indicate that currently rounding is only applied upon
changes to the value, not to the existing value when ::digits changes.
This is already clear in the doc for the underlying Range::round-digits.
https://bugzilla.gnome.org/show_bug.cgi?id=358970
The documents state that gtk_scale_set_digits() “causes the value of the
adjustment to be rounded off to this number of digits, so the retrieved
value matches the value the user saw.” Note the lack of any condition.
But in fact, if draw-value was false, rounding was disabled on the base
Range, so values that weren’t displayed weren’t rounded. This made the
docs wrong and made an apparently cosmetic detail alter functionality.
Fix by ensuring the number of digits set on Scale is always propagated
along to gtk_range_set_round_digits(), thus rounding to it in all cases
when the value changes, regardless of whether the value is displayed.
This doesn’t address the other idea from Bugzilla: that changing the
number of digits should clamp the _existing_ value if it’s more precise.
This contradicts digits docs in the base Range, but the above from Scale
can be read as implying it’ll happen. For now, that’s an open question.
https://bugzilla.gnome.org/show_bug.cgi?id=358970
GtkFileChooserButton installs a handler for the popped-up signal, which
refilters the menu, in order to hide the “(None)” item from the popup
if it was previously selected in the ComboBox. This oddity means that:
• Until recently, this item would be selected in the menu shell, which
would then be popped up and change the selection away from that item.
This was therefore redundant (more on which below!) but benign.
• After the patch for https://bugzilla.gnome.org/show_bug.cgi?id=771242
however, this causes a critical assertion fail, as now we stash the
originally selected item in a pointer so that it can be selected only
after realisation/popup – but by that stage, the model has just been
refiltered and the previous pointer no longer refers to a valid item.
This commit works around this problem by, after popping up the menu,
getting the active item again, in case a popped-up handler has gone and
invalidated the pointer to the active item that we saved before popup.
If a handler does this, everything done to find/use the original item is
pointless. But this avoids the ugly critical in FileChooserButton, while
not harming every other ComboBox that doesn’t mess with its model while
popping up (hopefully the vast majority), and it’s very difficult to
imagine a way to check if the active item is /going to/ be hidden later)
Previously, for compatibility with GTK 3.0, we allowed specifying
numbers without units and interpreted them as pixels, even when the CSS
specification didn't.
Remove that now that we can break API.
This reverts commit 4875c689a0.
This was a thinko. Writable is not actually settable from the
application side, but only for the user, from the backend side.
Images with just an aspect ratio, but without a size, should be scaled
to be fully visible in the given area.
But we scaled them to completely cover the given area, which made them
partially invisible.
Reftest included.
gtk_snapshot_pop() => removed
gtk_snapshot_pop_and_append() => gtk_snapshot_pop()
So now there is no way to get a rendernode out of the snapshotting API
until you gtk_snapshot_finish().
... and use it.
The function is a bit awkward because it requires 2 calls to
gtk_snapshot_pop(), but once you accept that, it's very convenient to
use, as can be seen by the 2 implementations.
This is a free-form tab that can contain information about the
system environment. To see it, set GtkAboutDialog::system-information
to a non-NULL value.
https://bugzilla.gnome.org/show_bug.cgi?id=776604
We already take ints when setting the translation, so it can't
currently take any other values. Additionally, I was seeing large
costs in int -> double -> int for the rects in
gtk_snapshot_clips_rect(), as all callers really are ints (widget
allocations) and the clip region is int-based.
This change completely cleared a 2% rectangle_init_from_graphene from
the profile and is likely to have nice performance effects elsewhere
too.
The width/height/aspect getters are called a lot, and almost all
callers already verify it from _gtk_css_image_get_concrete_size (),
so just skip these checks.
This means we allocate the collect data with the state, avoiding
an extra allocation. Also, a union means every state object
is the same size and we could reuse the state objects.
Simgle image cross-fade opacity was computed the wrong way, which caused
weird fade-in/out animations, for example in flat buttons.
I messed this up when porting cross-fades to snapshot().
Since the demise of theme engines, we can no longer hit
the case of id >= GTK_CSS_PROPERTY_N_PROPERTIES. So don't
check for this in a very frequently called function.
Using an image() fallback from svg to png doesn't make too
much sense, since the svg is always used (unless librsvg is
not present), while the png icon is faster and cheaper to
load and thus preferable.
Also, "ie" wasn't very clear, but fixing that to "i.e." would cause
truncation of the summary when processed by bindings using doxygen. So,
I replaced it with "in other words", which is no _less_ clear, at least.
It was suggested that the project files to be moved to win32/, so that we can
have one less layer of directories we need to go down into to reach the project files.
So we can set the css name of a widget to something that's not related
to the class name. If the css-name property is set to NULL, we will
still fall back to the one set using gtk_widget_class_set_css_name which
is alwasys non-NULL since GtkWidget itself sets it to "widget".
See the implementation of gtk_entry_create_layout():
pango_attr_list_splice() is used to add the PangoAttrList of the preedit
string. And that is done *after* applying the PangoAttrList of the
"attributes" property.
https://bugzilla.gnome.org/show_bug.cgi?id=776868
We now have GTK_CSS_AFFECTS_CONTENT for properties that have an effect
on content rendering.
Using GTK_CSS_AFFECTS_ICON is wrong for icon-transform and icon-filter
as they don't change the icon, just how the icon is rendered, so we use
GTK_CSS_AFFECTS_CONTENT for those.
We also introduce GTK_CSS_AFFECTS_POSTEFFECT for opacity and filter -
properties that affect the whole drawing of the widget by applying an
effect after everything is said and done.
...which treats the first '.' in doc comments as the end of the summary.
So, e.g., in gtkmm, get_kinetic_scrolling() is currently summarised as
"Changes the behaviour of @scrolled_window wrt." Not very informative!
No need for a period there & anyway, the phrase "wrt to" is superfluous,
and we have space to actually say "with regard to", so just do that now.
Instead of
-gtk-icon-effect: dim;
-gtk-icon-effect: hilight;
we now use
-gtk-icon-filter: opacity(0.5);
-gtk-icon-filter: brightness(1.2);
respectively.
This node essentially implements the feColorMatrix SVG filter. I got the
idea yesterday after looking at the opacity implementation.
It can be used for opacity (not sure if we want to) and to implement a
bunch of the CSS filters.
If the signal handler ends up changing the label text,
the link is no longer around to update the css node.
Check for this possibility to avoid a crash here.
Homogeneous branches repeated the calculation/assignment of the initial
space available to children. This avoids that by shuffling some code.
Perhaps more importantly, in doing that, I ended up with some ambiguous
names, and Company and I realised how vague the pre-existing naming was.
"size" becomes "extra_space", as this is what it represents. Conversely,
"extra" becomes "size_given_to_child" (albeit still given out in two
different ways depending on whether the Box is homogeneous). My hope is
that these sections of code are now somewhat less baffling than before!
Now that every call to GtkCellArea is a snapshot call and no more cairo
calls are left, move the actual differentiation between Cairo and
Snapshot down to the cell renderer.
I had originally thought I'd use GskShadow for box-shadow, but didn't in
the end.
So now it's only used for text-shadow and icon-shadow, and those don't
have a spread.
VLAs are not supported by Visual Studio and possibly other compilers that
are supported by GTK+-3.90+, and probably never will be, although it is a
C99 specification, and it became optional for C11. It is also not a part
of the newer compiler requirements that are listed out for GTK+-3.90.x.
There exist concerns about the implementation of VLAs in compilers that
support them as well, so change it to a g_newa() approach.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
This causes the snapshotting algorithm to dump all widget nodes into
their own container node. We then name that group accordingly (ie
"GtkSwitch<0xdeadbeef>") so you can easily see which node belongs where.
The feature is toggleable in the inspector's visual tab.
There's a few problems with it, becuse GtkSnapshot optimized container
nodes away if they are not needed, so we are losing some widgets...
