All the other conditionally visible child widgets have this. Without it,
it seems some cases can wrongly reveal it, with a nonsensical home icon.
https://gitlab.gnome.org/GNOME/gtk/issues/1345
There’s a short-path done for focus rectangles, but it can be taken in other conditions, and then fail occasionally to render a dashed line if the border-width is too big.
For building the introspection dumper program on Visual Studio, leave out
the G_LOG_DOMAIN as g-ir-scanner does not like it when it constructs the
compiler command line for Visual Studio.
Also ensure that we are looking for the freshly-built libraries by looking
for the .lib's from the output directories of the Visual Studio project files.
Simplify the styling of sidebar separators by not setting their borders
and margins rather than trying to drop it afterward, which was actually
not working anyway.
Make the selector less greedy to not remove the background on
non-titlebar headerbars contained in non-headerbar titlebars and only to
the ones contained in headerbar titlebars. This avoid issues in some
applications.
Also make dropping the background more agressive to actually remove it.
This is needed to work around headerbar sliding animation issues without
refactoring Adwaita's support of titlebars and headerbars as it may
break applications.
https://gitlab.gnome.org/GNOME/gtk/issues/1264
Let separators be declared as sidebars to have the same style as those
drawn by GtkStackSidebar. This also let them handle the selection-mode
class, whether they are assigned it or they descend from something in
selection mode.
This is convenient when building a custom sidebar using a GtkSeparator
and to extend a sidebar to the title bar.
A number of applications want to track the state of the screensaver.
Make this information available as a boolean property. We only listen
for state changes when ::register-session is set to TRUE.
This is implemented for unsandboxed D-Bus access by talking
directly to org.gnome.ScreenSaver or org.freedesktop.ScreenSaver,
and for sandboxed D-Bus by using a (new) portal API.
A Quartz implementation is missing.
After discussions on IRC, the conclusion was reached that deprecations
only make sense if an action can be taken to not use the deprecated code
that makes the code more current and simplifies a later port to a newer
GTK version.
In this particular case, the suitable action would be adding
gtk_widget_show() calls whenever a widget is created, so that a call to
show_all() is not necessary.
However, in GTK4 these calls would not be necessary and end up just
bloating the codebase unnecessarily.
So it was decided the better solution would be to not deprecate the API
and instead leave this work to be done during potential GTK4 ports of
applications.
This reverts commit 4d71d2303d.
Fixes!1282
When calling PickColor on org.gnome.Shell, we get back an "a{sv}", which
GDBus provides to us as "(a{sv})".
At the minute we're not unpacking this tuple, and so picking fails with
messages like:
GLib-CRITICAL **: 13:38:19.439: g_variant_lookup_value: assertion 'g_variant_is_of_type (dictionary, G_VARIANT_TYPE ("a{s*}")) || g_variant_is_of_type (dictionary, G_VARIANT_TYPE ("a{o*}"))' failed
Gtk-WARNING **: 13:38:19.439: Picking color failed: No color received
Let's unpack it.
In order to make tooltip positioning portable, make use of the
move_to_rect API. Some semantical changes are made, as identical
semantics cannot be implemented using the move-to-rect API.
Primarily the implemented semantics are:
Position the tooltip in the center pixels slightly below (defaults to 4
units below) the tooltipped widget. This is always the case for keyboard
driven tooltips; the case where it tries to avoid the pointer cursor is
not implemented.
For pointer position triggered tooltips, implement the following
additional semantics:
Use the current cursor size to determine the padding used to enlarge the
anchor rectangle. This is to try to avoid the cursor overlapping the
tooltip.
If the anchor rectangle is too tall (meaning if we'd be constrained
and flip on the Y axis, it'd flip too far away from the originally
intended position), rely only on the pointer position to position the
tooltip. The approximate pointer cursor rectangle is used as a anchor
rectangle. Ideally we should use the actual pointer cursor rectangle
(image used as well as hotspot coordinate), but we don't have API to
get that information.
If the anchor rectangle isn't to tall, just make sure the tooltip isn't
too far away from the pointer position on the X axis.
Closes: #134Closes: #432Closes: #574Closes: #579Closes: #878
CSD titlebar are included in the focus-chain. The logic used makes sure that the
initial focus avoids the titlebar, but tabbing around will eventually get there.
This logic fails in case the window has no other focusable widgets apart from
the ones in the header-bar. If this happens keynav focus will be lost. To handle
the above scenario, we need to fallback to focus the header-bar (if any).
Fixes: https://gitlab.gnome.org/GNOME/gnome-software/issues/404
This is a GtkGesture done to deal with stylus events from drawing tablets.
Those have a special number of characteristics that extend a regular
pointer, so it makes sense to wrap that.
This event controller is meant to replace usage from key-press/release-event
handlers all through. Optionally it can be set a GtkIMContext, so interaction
is carried by the controller.
There is a gtk_event_controller_scroll_set_flags() call that's meant
to be called after construction (eg. due to scrolledwindow relayouts
hiding/showing scrollbars). The property shouldn't be construct-only
for consistence.
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.
The opaque region is only set when the background color is opaque. So
we need to do something about it when the background color changes.
However, in the case where a size allocation is going to happen, we
already do this update in size_allocate(), so in that case avoid doing
it twice.
Reverts part of Commit 25b67af3
The 'width' part of the commit is the cause of #628: requisition->width
is first set to priv->layout->width, which already includes
priv->left_border + priv->right_border. It's a bit labyrinthine, but
essentially:
* layout->width is set in update_layout_size() (gtktextlayout.c line 992)
as the maximum line width, and
* the line width is set to display->width in gtk_text_layout_real_wrap()
(gtktextlayout.c line 1183), and
* display->width is set to text_pixel_width + h_margin + h_padding in
gtk_text_layout_get_line_display() (gtktextlayout.c line 2584), and
* h_margin + h_padding is the same as priv->left_border +
priv->right_border.
Adding it again leads to an increase in the size-request, which
results in wider lines; rinse and repeat.
Expanders used to be 16px high. With the move from the gtk2 rendering
to gtk3 rendering they shrunk to 12px, making them hard to see, because
it's now the icon which is 16px high and the icon contains transparent
borders.
This makes the HighContrast theme use 24px icons instead, to restore
16px expanders. This may expander some containers a bit.
Closes#1046
(A) Put a space in "scrolled window" like the other doc comments
(B) Say "i.e." rather than "ie."
(C) Fix grammar from "makes [...] exactly reaches" to "exactly reach"
@open_flags was not documented, and so:
jhbuild/checkout/gnome/gtk+-3/gtk/gtkplacessidebar.c:4743: Warning: Gtk:
incorrect number of parameters in comment block, parameter annotations
will be ignored.
Binds this property to the button's label, allowing a model button to
have text with markup.
This will be convenient for buttons like 'Online Accounts <sup>↗</sup>'.
It has been extremely broken since the move to CSS gadgets/nodes, so
clearly no one is depending on it; nor does anyone seem to want to
resurrect it, and writing a Raleigh-inspired theme from scratch would be
faster if they did. So let's drop the dead weight from the build and lib
Now that we don't have Raleigh, the defaultvalue test has to be changed
to set Adwaita before checking the default values of style properties -
some of which Adwaita overrides in its CSS, meaning those would fail.
Not that it passed before anyway! But it does now after my other commit.
Note that I leave the last reference in gtk-zip.sh.in alone since that
hasn't been touched in 8 years and probably has plenty other problems...
Close https://gitlab.gnome.org/GNOME/gtk/issues/1187
According to the spec compositors were to assume surfaces are CSD until
told otherwise. This means we need to send
org_kde_kwin_server_decoration_request_mode in both cases.
This fixes libreoffice under kwin, which would remove it's own headers
as per the manager's request but not inform kwin leaving it in the even
more broken state of having none.
On Windows HarfBuzz and PangoFT2 are optional, so we need to ensure that
we only build the bits that require HarfBuzz and PangoFT2 when needed.
We may need to see later whether we can get the needed functionality in
gtkfontchooserwidget.c with the Windows APIs without the need of
HarfBuzz nor PangoFT2 (and starting programs on Windows using FontConfig
is very slow).
Reinstate code that was accidentally deleted during the port to
GtkProgressTracker in commit d57ebe2de7.
Without that code, pulsing the progressbar will stop doing anything
after 3 iterations.
This adds a preprocess step to the .ui files to strip them of blank
characters. It also removes the compressed='true' from the .ui files since
that involves creating lots of decompressor objects when creating widgets.
Doing so has runtime overhead and slows down the creation of initial
application windows.
The .ui files are left compressed for the Inspector, since that is not in
the core performance path of application startup.
