As documented, GtkAppChooser is "typically [used] for the purpose of
opening a file". However given that applications that support neither
opening files nor URLs are filtered out, the chooser is not actual
useful for any other (atypical) usage. Change that by only applying
the filtering if a content-type was set, and use the full unfiltered
list otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=789327
Since focus can now be represented by more than one state,
just looking at the focus_child is no longer sufficient - we
may fail to propagate :focus(visible) if we do so. For now,
just remove the shortcut and always do the work.
__builtin_popcount is a GCCism that is used to count the number of bits
involved, which means any non GCC/CLang compilers won't like the code,
meaning that on MSVC builds we must implement it ourselves.
We first use __cpuid() to check whether the CPU supports the popcount
instruction, if it does, we use the __popcnt intrinsic, otherwise
(untested, since I don't have a system that does not have the
instruction), we use the suggested hacks at
http://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetParallelhttps://bugzilla.gnome.org/show_bug.cgi?id=773299
We still need to access the GdkEvent structure here directly, as using
the GdkEvent getters is likely not worth the trouble involved.
Please see Emmanuele's comment (#97) of the following bug URL.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
These are no longer used, instead we always covert to surface as
early as possible and drop the pixbuf.
This means we never store both the pixbuf and the surface at
for any longer time, which is wasteful. Also, its one step further
to drop GdkPixbufs from generic use in our APIs.
Rather than store the pixbufs as themselves we immediately convert
them to surfaces. In the uncommon case that a pixbuf is read back
from the renderer we generate a new one from the surface data.
This drops the pixbuf property and the pixbuf getters. We keep
gtk_image_new/set_from_pixbuf, but these are small helpers that
immediately convert to a surface, and there is no way to later get
back the pixbuf you passed in.
The from file/resource codepaths are also changed to load a surface
instead of a pixbuf.
Rename the surface getter to peek, following other render
node getters, and make the surface-based constructor private,
since it is not something we want to encourage.
Update all callers.
The gtk_tools variable is an array of arrays; adding a new element
requires to maintain the same type, or we'll get a build failure when
we try to extract the newly added element.
Add the necessary machinery into the Meson definition files so that we
can build for Windows.
Since we don't have Wayland or X support for our use case here, disable
them once we know that we are building for Windows, as they are
(otherwise) enabled by default, and enable the items that need to be
built for Windows builds.
Exclude gtk4-launch from Windows builds as that is something that
is not supported on Windows.
As we won't have gio-unix on Windows, and PangoFT2 is optional, don't use
fallbacks for them when we are on Windows (but do use fallbacks for
gio-win32, as it will be used).
Also, clean up meson.build a bit as we can just force-include
msvc_recommended_pragmas.h from GLib since we depend on GLib, and so we
can handle these warnings from msvc_recommended_pragmas.h instead.
https://bugzilla.gnome.org/show_bug.cgi?id=785210
What is missing is the "allocation" part of x/y coordinates. Since
gtk_entry_realize doesn't call gtk_widget_set_window(priv->text_area),
the coordinates returned by gdk_window_get_origin don't include it.
This patch fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=784509
Bug 737175 aimed to ensure that scrolling up on a horizontal range would
result in its value increasing, as that’s what users intuitively expect.
However, its commit 416c370da1 meant that,
if the event gives scroll deltas, we inverted our delta unconditionally.
So it broke horizontal scrolling: scrolling left moved the slider right…
We must only invert if using dy as delta. dx already has the right sign,
so inverting it was wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=788905
The gtk_widget_get_display call in this if statement is showing up in
profiles. It ends up walking up the hierarchy to the toplevel to get its
GdkScreen, etc. so it is relatively costly. Avoid that call in most
cases by first checking if the RESIZE debugging is enabled for any of
the displays and only then checking if it is enabled for the widget's
display.
If the call to set_parent() failed, we were still adding the child to
the internal list of children, despite that it was not really added.
That meant we could later try to do invalid stuff with that non-child.
Fix that by asserting and giving up if the child that the user is
attempting to add is already parented.
https://bugzilla.gnome.org/show_bug.cgi?id=701296
The language is useful for parsing tools, such as that of gtkmm, which
otherwise assumes these are C snippets and elides them from its
generated documentation.
It was used to mark css properties that affect widgets with text, but it
caused unnecessary invalidations. E.g. 'color' was marked as
AFFECTS_TEXT but changing just the color of a label should not
automatically queue a resize, which is what the code in
gtk_widget_real_style_updated does.
Replace this flag with GTK_CSS_AFFECTS_TEXT_SIZE and
GTK_CSS_AFFECTS_TEXT_CLIP, which GtkWidget can use only if the widget
actually has text.
After a gesture first claims, and later rejects a touch sequence,
a press event will be propagated further along. However propagation
got messed up since we only emitted as far as the toplevel.
It does not hurt us to keep middle clicks doing the same
as shift-primary clicks. This makes the transition from gtk2
less painful in terms of muscle memory.
https://bugzilla.gnome.org/show_bug.cgi?id=787669
Clarifies the code and helps catch invalid enum values before they
propagate further. Also add a comment about why two seemingly legitimate
values are not handled there (they’re handled higher up in the file).
Coverity CID: 1457700
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788787
gtk_box_pack_end will put the label child at the right side of the label
(in LTR orientation), but we want it left, directly next to the icon.
Also remove the spacing from the box child as this is a theme thing.
~Company ╡ so TL;DR: we put the static style in the cache, but then
⤷ ╡ compute a child style from the animated style in the cache
⤷ ╡ and we put the child style also in the cache (because
⤷ ╡ it's not animated)
⤷ ╡ then we run the animation, but reuse the cache every time
⤷ ╡ for both child and parent
⤷ ╡ so after the animation is done, we end up with a cache that
⤷ ╡ has the correct static style for the parent but an
⤷ ╡ incorrect static style for the child
⤷ ╡ because that static style was computed from the
⤷ ╡ initial animated style
This fixes https://bugzilla.gnome.org/show_bug.cgi?id=763517
An empty container has the same effect as transparency
with the cairo renderer, but creates black with Vulkan.
To avoid this, explicitly use a transparent color node.
This fixes the css blendmode example in gtk4-demo with
the Vulkan renderer.
As Timm Baedert pointed out, the previous fix made the
menubar go on top of popovers, which is just wrong. Instead,
make gtk_window_snapshot handle all direct children of the
window, taking care to stack popovers correctly.
This is important since _push_state returns a pointer into a GArray
which could be invalidated and point to garbage after the subsequent
push_state call.
This is used for example in the source tab of gtk4-demo.
It broke because GtkScrollbar no longer is a GtkRange,
but rather has one. So we need to forward the signal.
It was selecting paned separator, which means any separator at any level
of descent within a paned, including the toplevel container in GEdit.
We need to be more specific and only select the relevant separator that
is the direct child of the paned. This is what Adwaita does.
https://bugzilla.gnome.org/show_bug.cgi?id=788573
Nulling priv->button in _unset_tree_view() is asymmetrical: we create
it via init(), not _set_tree_view(), so we shouldn’t null in the latter.
Worse, doing so manifests in criticals + a SEGV easily with basic use of
testtreecolumns, removing the TVC from a TV then trying to add it to one
Finally, the wrong null-out meant dispose() failed to unref the button,
so it leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=728452https://bugzilla.gnome.org/show_bug.cgi?id=788614
This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
GtkCellArea uses event coordinates (thus in treeview relative
coordinates), but calculations used to happen in bin window coords.
We can just offset the cell area by the bin window, fixes cell
renderer activation and edition.
If the column is not clickable, it may make some sense to stop
event propagation here for button events. However motion events
should be left alone.
Fixes treeview column resize pointer cursors, since that's
implemented up the bubbling phase in the treeview.
The operations rely there on bin window relative coordinates, but we
are receiving GtkTreeView relative coordinates there. Fixes clicking
on treeview expanders, which was offset by visible headers.
-Wint-conversion is important because it checks casts from ints to
pointers.
-Wdiscarded-qualifiers is important to catch cases where we don't
strings when we should.
The border and icon highlight are useful feedback that was defeated by
CSS precedence. It worked for .titlebuttons due to their implementation,
but the same was not true for custom .flat buttons. This makes it so.
https://bugzilla.gnome.org/show_bug.cgi?id=788580
When the window was backdropped, they suddenly regained their border.
This was clearly not intentional or of any practical use to anyone.
Shuffle around some selectors so that the backdrop ones do not override
the flat ones and make the borders magically reappear when backdropped.
Note that, whereas standard titlebuttons get the border on :hover, other
.flat buttons in the headerbar do not. That should probably be fixed too
https://bugzilla.gnome.org/show_bug.cgi?id=788580
They were hard-coded to a transparent black, but that is our bg colour
in HC Inverse, so windows stacked on top of each other or a dark
background blended together into a mush.
Fix this by making the $_wm_border* colours relative to the fg colour,
so that HighContrastInverse gets borders that are transparentised white.
https://bugzilla.gnome.org/show_bug.cgi?id=788575
A missing decoration selector meant that we got a solid black background
behind the rounded corners of the dialog.
Copy the equivalent code from Adwaita, including nicely rounding the
focus outline too (& sorry, but this needs more newlines to be readable)
There were various problems, like only selecting on .tooltip and not the
widget node tooltip, not being specific enough for tooltip.csd, etc. So,
specific theming was absent, and default popup window styles got applied
This commit copies in the better working tooltip CSS from Adwaita, but
applies a couple of changes to make it work better in the HC themes:
• Reduce the transparency of the tooltip, so we achieve higher contrast
• Drop the black text-shadow, as it is not useful on this more black bg
Note: we may then need to re-add some of this to the .tooltip class. But
it is unclear what needs done there. While Adwaita is not doing it, we
are better not to confuse by keeping it in HC only; we should try to be
as close as possible, to make it easier for HC to keep up with Adwaita.
https://bugzilla.gnome.org/show_bug.cgi?id=769879
We need
.window-classes decoration
but within the decoration parent selector, we were doing
&.window-classes, which gave us
decoration.window classes
We need to fix this by selecting on .window-classes &
https://bugzilla.gnome.org/show_bug.cgi?id=788496
n_attach_points is the result of g_strv_length(): the index at which the
string vector ends in NULL. So by definition, when i == n_attach_points,
string[i] == NULL, and there is no need to check for the latter. The
fact that we did appears to confuse static analysers, as the dereference
and index check were inverted from what would normally be safe. We could
reverse them, but we may as well just remove the unnecessary NULL check.
https://bugzilla.gnome.org/show_bug.cgi?id=788458
This gives consistent behavior with e.g. Qt, Mozilla's suites and
LibreOffice (with non-truly native backends like "gen" and "gtk",
but unlike "gtk2" and "gtk3" ones that probably use true GTK menus).
This behavior is expected by at least some accessibility users, and
it seems good to behave like other common applications and toolkits
in this area. There should be no issue in doing so either for current
users, as it only enters the submenu instead of not doing anything.
https://bugzilla.gnome.org/show_bug.cgi?id=778811
ComboBox and TreeMenu warned in the doc for :row-span-column that the
value must not exceed :wrap-width, but :wrap-width does not interact
with the number of rows; it’s the :column-span-column that’s relevant.
Also: Warn that spans must be > 0 for rows too, and that column spans <=
:wrap-width are also not useful for items at menu column positions > 0.
Finally, refer to items having spans, not values, as we were already
talking about values in the model (and rows in the menu).
Instead of creating one GPtrArray per GtkSnapshotState and saving nodes
in there, create one GPtrArray per snapshot and assign a
start_node_index to every GtkSnapshotState as well as a n_nodes variable
so every state knows which nodes belong to it.
It's not a GtkCssGadget anymore, it doesn't have any properties or
signals either and it's not public. Further, its lifetime is very clear
the way it's being used inside GTK+.
This showed up in profiles in certain scenarios, so export a
_get_n_shadows getter instead and let callers provide a sufficiently
large allocated array of GskShadows, which we can use with
g_alloc/g_newa.
The GtkFlowBoxCreateWidgetFunc type lacked GObject Introspection
annotations for its arguments. This made gtk_flow_box_bind_model()
unusable from Python as the callback function would be passed useless
values.
The annotations that I've added match those of the similar callback
type GtkListBoxCreateWidgetFunc.
https://bugzilla.gnome.org/show_bug.cgi?id=780758
Those should be interpreted by widget-local gestures, not guessed at a
high level with no notions of the specific context. Users will want
GtkGestureMultiPress to replace these events.
Those worked similarly to those in GtkFlowBox, but would additionally
handle "active" state for child rows. Simplify this to just enabling/
disabling active state on gesture press/release, we don't get the
nice state updates when hovering around with a mouse button pressed,
but the rationale from flowbox applies here, and makes a nice cleanup.
They just maintain priv->in_button and widget state up-to-date, this
basically matters during user interaction, and is already maintained
in the gesture ::update handler. This seems to be sufficient.
Those basically controlled priv->active_child_active, which would
1) trigger a redraw when the pointer enters/leaves it, and 2) ensure
that press/release happen on the same child for it to be activated.
The former is not necessary, and the latter can be simplified by
just checking again the child on the coordinates given by the
::release gesture handler. This makes all enter/leave/motion_notify
event handlers unneeded.
All kinetic scrolling initial velocity calculations are now
taken from the scroll controller. The handling of timeouts
to snap back when overshooting has been also made to just
apply on devices that can't emit ::scroll-begin/end.
This is a GtkEventController implementation to handle mouse
scrolling. It handles both smooth and discrete events and
offers a way for callers to tell their preference too, so
smooth events shall be accumulated and coalesced on request.
On capable devices, it can also emit ::scroll-begin and
::scroll-end enclosing all ::scroll events for a scroll
operation.
It also has builtin kinetic scrolling capabilities, reporting
the initial velocity for both axes after ::scroll-end if
requested.
This change is made for consistency, it doesn't make sense to expose
one-way propagation, as it can only break expectations from GTK+. This
function might be made entirely private in the future, but it still
makes sense to do this in one go for our internal usecases.
This will allow further cleanups and optimizations in capture/target/bubble
event delivery. For simplicity, ATM every widget will receive its own
GtkEventControllerLegacy, it could be desirable to add finer control over
this in the future, so widgets that fully use event controllers for input
management can do away without this legacy piece.
As Benjamin says, ident should only be used if any value
is valid, which is not the case here. So use enums instead,
which should also be more efficient. To handle the more
complicated cases like font-variant-ligatures, we have to
introduce flags-like values.
Clarify that ::destroy, not ::hide*, removes a window from its app, by
replacing the mention of open windows with the blurb on destruction from
:application, completing commit 7db4bee4b6
Also link to the equivalent gtk_application_(add|remove)_window() calls,
since Application.add_window() already links back to Window:application.
* unless you use gtkmm…
https://bugzilla.gnome.org/show_bug.cgi?id=639931
It was never unref()d, either when replacing the existing GObject in
set_property(), cleaning up in finalize(), or becoming a placeholder.
Fix by using g_set_object() and g_clear_object() to unref as needed.
This also drops the check that the newly set object is a valid cloud
provider account, as we don’t do the equivalent for any of the other
object-typed properties, and Carlos didn’t think this was important.
https://bugzilla.gnome.org/show_bug.cgi?id=787600
Drop the current css2-style font-variant property and
replace it with a shorthand as specified in the css3 fonts
module. Currently, we fully support the font-variant-ligatures,
font-variant-position, font-variant-caps, font-variant-numeric
and font-variant-east-asian subproperties. font-variant-alternatives
is only partially supported.
Instead of relying on special values of edge constraints, this
patch adds an internal-only gdk_window_supports_edge_constraints()
function that by default returns FALSE, and is implemented by
GdkWindowWayland and GdkWindowX11.
This way, we can properly detect server-side support for this
feature and adapt accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
The last touch on this patch series is making GtkWindow able to
selectively adjust various UI details based on the different
tiled edges. The main driver here is that we don't want to show
shadows on edges that are constrained.
This patch adds the necessary code to do that, while still
maintaining compatibility with the old ways.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
GTK windows don't have their tiling states really
hooked into the client-side decoration code, and
the only effect it has is disabling the resizing
edges.
With the introduction of per-edge tiling information,
we are backed by much more precise data on how the
window manager wants the app to behave.
This patch, then, fixes GtkWindow to take into account
per-edge tiling information. For compatibility purposes,
the previous tiled field was kept, and thing will just
continue working if no edge information is supplied.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
The outline-{top,bottom}-{left,right}-radius names have been
deprecated for a while, so lets remove them. Everybody should
just use the -gtk-prefixed names for these properties.
The focus outline disappeared as the colour of the swatch got close to
the normal focus outline colour, which is alpha(currentColor, 0.3).
Fix by making the outline an alpha’d version of the tick colour, but
more opaque than normal outlines. 0.6 seems good enough; feel free to
improve it, but at least this ensures the outline can’t vanish anymore.
HighContrast achieves this already because it applies the color property
to the main node, not the overlay. Doing that means the outline is fully
opaque, which is fine for HC obviously but was excessive for Adwaita.
https://bugzilla.gnome.org/show_bug.cgi?id=787757
It used $text_color unconditionally, but in :dark, text is white, so we
overlaid a white tick on any light colours, all the way to white itself.
Using these named colours doesn’t make practical or semantic sense.
Instead, use white/black over dark/light swatches, as in HC, so all
variant–swatch combos work. Light looks the same, & :dark works now.
For backdrop, use alpha 0.5, unlike 0.7 in HC, as that seemed excessive
& different from the current effect. 0.5 is almost identical to how
$backdrop_fg_colour is a 50% mix of $fg_color, & matches backdrop text.
https://bugzilla.gnome.org/show_bug.cgi?id=787531
On Python-3.x, we need to set the encoding when opening files, when this
script is run, as it might contain items that are not supported by the
system's locale (for example, non-English Windows). So, we use a
wrapper to set the encoding on Python 3.x, but open the file as we did
when using Python 2.x, since file encodings are not supported there.
https://bugzilla.gnome.org/show_bug.cgi?id=785210
along the orthogonal orientation. It seems a FlowBox on its own can only
handle being shrunk along its main orientation. The orthogonal requests
a huge min size – reserving what it would need if the main orientation
got its min size, which would flow all children in 1 line orthogonally.
Adding it to a ScrolledWindow (any policy) enables free shrinking, so
size_allocate() can reflow how users in this situation probably expect.
https://bugzilla.gnome.org/show_bug.cgi?id=787021
Without specifically connecting ::delete-event to something, the dialog
will be destroyed when it is closed, for example by pressing Esc. This
meant that when dismissing it this way, unlike by pressing Cancel, any
custom palette would be lost when the dialog was next opened, and so on.
Resolve this by making ::delete-event just do GTK_RESPONSE_CANCEL, so
closing the dialog has the same effect as clicking its Cancel button.
https://bugzilla.gnome.org/show_bug.cgi?id=787444
Make it slightly more obvious when things are about to slide sideways
because a NULL GtkSettings has been returned to a caller. This is a
valid return value, but is rarely handled correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=778382
As reported in https://github.com/ibus/ibus/issues/1944,
typing u201e while holding Ctrl+Shift used to give a „
when letting go of Ctrl+Shift. This broke when we introduced
Ctrl+Shift+e to start Emoji sequences. Fix this by only
looking for Ctrl+Shift+e if we are not already in a hex
sequence.
This commit takes several steps towards rendering text
like we want to.
The creation of the cairo surface and texture is moved
to the backend (in GskVulkanRenderer). We add a mask
shader that is used in the next text pipeline to use
the texture as a mask, like cairo_mask_surface does.
There is a separate color text pipeline that uses the
already existing blend shaders to use the texture as
a source, like cairo_paint does.
The text node api is simplified to have just a single
offset, which determines the left end of the text baseline,
like all our other text drawing APIs.
We were only selecting a section’s button if the adjustment y coord was
within its heading, so scrolling slightly into it unchecked all buttons.
This also fixes how we could end up with the first 2 selected, somehow.
https://bugzilla.gnome.org/show_bug.cgi?id=787172
Add integration of the libcloudproviders DBus API to the
GtkPlacesSidebar by showing name and sync status of the cloud providers.
The exported menu is rendered as a GtkPopover.
The sidebar will be updated if the list of cloudproviders changes e.g.
by adding or removing an account. If any cloud provider changes detailed
information like sync status only the individual sidebar row gets
updated.
Co-authored-by: Carlos Soriano <csoriano@gnome.org>
Co-authored-by: Daniel Boles <dboles@src.gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=786123
Use opacity to differentiate unselected/hovered/selected buttons. It had
assumed bg < border < fg colours, which may be false, as in Adwaita:dark
This also means we do not need to special-case for the backdrop state.
https://bugzilla.gnome.org/show_bug.cgi?id=786956
I see 'out of memory' errors and crashes inside libvulkan when
creating nodes that have empty bounds and end up in the fallback
paths, like a shadow around an empty text node. Prevent this
by not creating text nodes in that case.
in a specific case, which was applying .slider as a class on the parent
switch, instead of correctly selecting on its child node named slider.
This makes the border on the outside of a switch in a selected listbox
row look better in the light variant. Since the code was never removed,
it was clearly meant to work, and making it work is a clear improvement.
The emoji chooser gets disposed already, because it is attached
to the toplevel as a popover. Doing it again when the object data
is cleared is leading to a crash.
https://bugzilla.gnome.org/show_bug.cgi?id=787103
Copy the PangoCairoRenderer into GTK+, rename it to GskPangoRenderer,
and strip it down far enough to build without private pango apis.
This means we currently don't support hexboxes or shapes.
Currently, this lives in gtk, but it might be nicer to put it
in gsk eventually.
• Use disconnect_by_data() to catch both _adjustment_changed() and now
_adjustment_value_changed(), as the latter had been missed until now.
• Also disconnect from indicator_value_changed(), which was not done in
destroy() due to indicator_reset() and remove_indicator() disagreeing.
https://bugzilla.gnome.org/show_bug.cgi?id=775074
Do not connect to get_settings_for_screen() if we have no screen…
Use g_signal_connect(), not connect_object(), to match how set_screen()
makes this same connection, and how finalize() already disconnects it.
https://bugzilla.gnome.org/show_bug.cgi?id=705640
Since the move from button-press to gesture events, Shift-clicking did
not work to start a selection (from none) or truncate an existing one.
This was due to the code being copy-pasted around and some logic being
broken in the process. This makes both of those work as they should, by
shuffling it again so the end result is the same as before. Highlights:
(1) ::button-press if extending due to a single press would call
set_positions(tmp_pos, tmp_pos), which is what made the Shift+click to
create a selection work. That was lost. Add it back to make that work.
(2) ::button-press in the “Truncate current selection” branch would not
execute all the stuff around “extend_to_left”, as that was the else
case. So, set extend_selection = FALSE so we skip over that later on.
(3) BUT! This Truncate case never fired because it was in the else
branch of if (in_selection())! Of course, it must be in the true branch.
(4) The IM context was not reset if the Shift-click occurred within an
existing selection, only if it did not. In ::button-press this was the
first thing done if extending a selection, regardless. Make it so again.
https://bugzilla.gnome.org/show_bug.cgi?id=780750
Themes should not enforce min sizes on blocks in continuous mode; in
this case, the filled block should be as large as it needs to be to
reflect the current value, and no larger or smaller than that. So, the
fact that the minimal size was selected on just levelbar block is wrong:
we should also require the levelbar.discrete class to apply min sizes.
The widget should enforce whatever correct minimum size results from the
above fix, by reapplying commit 78b4885fe8
Except: we should not allocate/draw the filled block if the value is 0,
as in this case, the LevelBar should be empty, not have a min-size fill.
This partially reverts commit 96062ffeae,
as it makes sense to set min sizes for discrete blocks, so keep that in.
https://bugzilla.gnome.org/show_bug.cgi?id=783649
