This has caused numerous issues for users, especially in the
filechooser, which have not been fixed in all the years since the pixel
cache has been introduced.
If anyone seriously has complaints about the treeview performance (and
those did not exist with the pixel cache), feel free to revert this
commit *and* fix the pixel cache issues.
Closes#503Closes#1691Closes#466
GdkAtom is a typedef to a pointer to an opaque structure. We need to
tell GTK-Doc how to override it, so that the documentation is accurate.
Fixes: #302
It takes half a second on my system to initially
populate the Emoji chooser. That is too long. Do
the work in 8 millisecond chunks to give GTK a
chance to get some frames done.
The http* family of functions was deprecated after CUPS 1.7. We can
conditionally use it when built against a newer version of CUPS. The
additional parameters are taken directly from the fallback values
inside CUPS itself.
GdkWindow::set_startup_id() is NULL on Win32 and would cause a segfault
if called.
While the documentation of the main caller of set_startup_id(),
gtk_window_set_startup_id(), mentions that it's not implemented on
Windows it can still be automatically called via Glade and simply doing
nothing on Win32 is going to be less disruptive than a segfault.
If the cursor coordinates are outside of the content (the GtkRBTree),
gtk_tree_view_bin_draw() will return and not draw the rubber band
rectangle.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1859
A g_object_ref() call was missing, sometimes causing crashes during
drag-and-drop operations. The matching g_object_unref() is at
gdk/gdkdnd.c:261.
The logic in this function is still wrong--it finds the wrong GdkWindow under
some circumstances--but this commit fixes the crash.
Part of #1840.
And update the surface accordingly (eg. scale on hidpi). The mechanism
that did that for wl_pointer has been made generic so it can be shared
with tablets too.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1675
_gdk_wayland_cursor_get_buffer was not initializing
its out variables in the 'not found' case. This
was showing up in protocol traces as garbage hotspots
being sent to the compositor.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1328
Previously, the GDK backend for Wayland would deduce the logical size
of the monitors from the wl_output size and scale.
With the addition of fractional scaling which advertises a larger scale
value and then scale down the client surface, the computed logical size
of the monitors in GDK would be wrong and confuse applications which
insist on using the monitor size and position (like Firefox).
The xdg-output protocol aims at describing outputs in a way which is more
in line with the concept of an output on desktop oriented systems by
presenting the outputs using their logical size and position appropriately
transformed.
Add support for the optional xdg-output protocol so that the size and
position of the monitors as reported by GDK is correct even when using
fractional scaling.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1828
This resulted in -DINCLUDE_IM_ti-et getting passed to gcc resulting in
lots of warnings. Use underscorify() so we get the correct -DINCLUDE_IM_ti_et instead.
Commits a04fef4 and cc7f9c4 inadvertedly broke Visual Studio builds as
it caused the following to show up when configuring:
gdk\meson.build:281:0: ERROR: Invalid Shared library version "vs9.2404.4". Must be of the form X.Y.Z where all three are numbers. Y and Z are optional.
Since we do not set a library version that mingles with the minor and
micro versions, along with libtool current for any Visual Studio builds,
just set those versions as 3 on Visual Studio builds, and things should
work the way they did before.
Since commit 3b2f9395, the frame time may be set into the future, so
only ensure monotonicity, and don't store the offset. This prevents the
frame time from becoming out of sync with g_get_monotonic_time().
Fixes#1612
We also need to ensure that we pass in -DINCLUDE_IM_xxxx when building
the GTK DLL/.so, in addition to building the respective (static)
immodules, so that we did really link in the immodules into the final
GTK DLL/.so.
This ensures that current Visual Studio project files and NMake
Makefiles (which do not use pkg-config files) do not break with the
Meson-built GTK-3.x libraries.
Make it a yes/no/auto combo. "yes" means all modules are built into libgtk,
"no" that none are and "auto" uses the platform defaults, yes on win32,
no otherwise.
If we need more we can always extend it later.
This makes the DLL names match those that are produced by the Visual
Studio projects by default.
This, currently, however, names the .lib files same as the ones that
are produced for other platforms (i.e. <libname>-3.lib). This is
actually not that bad as one can just copy those .lib's into
<libname>-3.0.lib when needed and the binaries that link to those .lib's
ultimately link to the same DLLs, so this should not harm binary
compatibility.
It may be so that Cairo is not found using pkg-config files, so we
cannot just use .name() on the Cairo deps directly.
Since we already have a similar mechanism for generating the GDK .pc
files, re-use and share that mechanism.
It seems that Meson 0.50.0 broke dependency search using CMake for
HarfBuzz at least, so we add a workaround for it to look for the
HarfBuzz headers and libraries manually when we couldn't find HarfBuzz
using the pkg-config and CMake method.
Various adjustments to make the config.h output between autotools
and meson more similar by testing on Linux and Windows/MSYS2.
Setting things to 1 instead of true and shifting things around is motivated
by reducing the diff between the generated files.
getting_started.xml uses relative paths for including code examples
and for some reason the base path is different with meson than with autotools.
Switch both autotools and meson to generate the file and insert the absolute
source path instead.
This also cleans up the content file list: the expand content files have to
be in the content file list as well, so just append them there.
This changes the configure option into two states:
auto: build all that can be build (default)
A list of backend names: build them and fail if we can't
"papi" is missing because it's not in Debian and I can't test it.
The autotools build uses relative filenames here while with meson
we get absolute paths. Switch to basename so we get the same result
for both and don't break reproducible builds with absolute paths
in public headers.
Try to include the same things and in a similar order so differences
are easier to catch.
This also adds the backend specific .pc files for gdk like gdk-x11-3.0.pc
Under autotools the compiled schemas are in the build directory and with
meson they are in the root build dir. Avoid changing the autotools build for
now and add a special GTK_TEST_MESON env var which we can use to differentiate
the two.
See 1253e7bfcb for a similar fix on master.
Build the input modules for GTK+, either as modules or built directly
into GTK. Also provide a configure option to build the specified
immodules, or all, or the backend immodule(s) or none of the immodules
into GTK. Note that for Visual Studio all immodules are built into
the GTK DLL by default, like what is done in the Visual Studio projects.
Note that building the backend immodules for Quartz, X11 and Wayland are
currently untested.
This is so that the post install script will work on environments where
*NIX shell scripts are not supported, such as on Windows cmd.exe for
Visual Studio builds.
This will ensure that the version info is easily visible from the
GDK/GTK+ DLLs, and ensure that the print dialogs will have a more modern
look and feel.
...on Visual Studio builds, as it seems that the linker is optimizing
that symbol out (hence it is not exported in the DLL). This is to
ensure that the introspection files for GdkWin32 build.
PangoFT2 is optional on Windows, so we only really need the fallback if
when it is required.
Along with that, since FreeType does not typically ship with pkg-config
files in its CMake builds, check for the needed headers, .lib and
function and then use the fallback when they could not be found and
PangoFT2 is used.
On Visual Studio builds, since Cairo builds tend not to generate
pkg-config files for us, look for the headers and .lib's, before
attempting to download the Cairo repo (which is quite large) and
building it.
We can simplify this process when Meson gains the ability to check
for the dependencies in a declarative fashion, but before that, this
is what must be done.
Otherwise, it errors out on make distcleancheck in debian packaging
```
ERROR: files left in build directory after distclean:
./gtk/gtktypefuncs.c
make[1]: *** [Makefile:1005: distcleancheck] Error 1
```
Add private API to GDK to move these variables from the environment into
static scope. Also move the DESKTOP_STARTUP_ID validation here to reduce
code duplication.
Use constructors to read them as early as possible; however, do not
unset them until first requested. This avoids breaking gnome-shell and
gnome-settings-daemon, which want to use the DESKTOP_AUTOSTART_ID in
their own gnome-session clients.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1761
The event received in `gdk_wayland_window_show_window_menu()` can
come from widgets with a GdkWindow. In those cases the coordinates
are relative to the widget, not the root window.
This results in a misplaced window menu.
Properly calculate the coordinates by iterating to the toplevel
window as suggested by Carlos Garnacho.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/684
The main one is gdkversionmacros.h which resulted in
GDK_MAJOR_VERSION, GDK_MINOR_VERSION and GDK_MICRO_VERSION not being included
in the Gdk-3.0.gir.
Noticed while diffing girs with the meson port.
The previous version of this patch sent an update message to the
NSOpenGLContext in a GdkGLContext::update vfunc, but that vfunc does not
exist any more.
See: #517
Current problems:
* other widgets in a GL-painted window are low-resolution on Retina
display
* something wrong with paint updates; gdkgears demo only updates every
couple of seconds but reports ~30fps
See: #517
We currently ask for anything above 3.2 GL contexts, but we're still
using GLSL 1.50 shaders all over the place. If a GL driver supports GL
3.2+ and GLSL 1.50 only then we'd be in trouble, but the chances of that
happening are really small.
They're either wrong (when using FALSE because the widgets don't account
for changes to the CSS) or unnecessary (when using TRUE because it's the
default).
Fixes!1777
The above flags in combination with "-fvisibility=hidden" break the
g-i build because it results in the g-i generated dumper executable not
linking against the libraries because they are detected as unused and
thrown out.
Fix by only using -fvisibility=hidden for the library and not g-i.
Look for subdirectories named "gtk-3.x", where 'x' starts as current
minor version and counts down to 14, then drops to 0.
Only look for gtk.css in these directories though. If a theme only
provides gtk-dark.css, it won't be found.
ImmIsIME() doesn't work (always returns TRUE) since Vista.
Use ITfActiveLanguageProfileNotifySink to detect TSF changes,
which are equal to IME changes for us.
Also make sure that IMMultiContext re-loads the IM when keyboard layout
changes, otherwise there's a subtle bug that could happen:
* Run GTK application with non-IME layout (US, for example)
* Focus on an editable widget (GtkEntry, for example)
* IM Context is initialized to use the simple IM
* Switch to an IME layout (such as Korean)
* Start typing
* Since IME module is not loaded yet, keypresses are handled
by a default MS IME handler
* Once IME commits a character, GDK will get a WM_KEYDOWN,
which will trigger a GdkKeyEvent, which will be handled by
an event filter in IM Context, which will finally re-evaluate
its status and load IME, and only after that GTK will get
to handle IME by itself - but by that point input would
already be broken.
To avoid this we can emit a dummy event (with Void keyval),
which will cause IM Context to load the appropriate module
immediately.
- Rather than making labeled buttons inside lists toned down,
only tone down image buttons, so that we don't have to include
icon-only actions. Places like Software can continue using label
buttons with no change without having those less visible.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1748
The problem here was that NSPasteboard would release the clipboard
owner if all data items were transferred. When trying to re-use this
owner at a later point, GTK+ would attempt a retain call on a released
object and crash.
Fix this by not immediately releasing the owner after declaring types,
so by keeping our own reference around.
Closes https://gitlab.gnome.org/GNOME/gtk/issues/529
Gdk sometimes misses crossing events on popups, so the cached toplevel
may be NULL. If it is, find the toplevel under the pointer and set it.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/623
The use of the startup ID is now twofold, we reply back with it to end any
corresponding startup notification, but we also use it on
gtk_surface1.request_focus to acknowledge that the activation might raise
the corresponding window.
We should preserve the startup ID for the second to work properly, so avoid
clearing it here. It is inconsequential if the underlying
gtk_shell1.set_startup_id request happens multiple times on no longer existing
startup IDs, so don't bother preventing that from happening.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1754
It might be too late to do it at GtkApplication::add_platform_data time,
since the envvar may be consumed earlier on if gdk_display_open() happened
to be called before (eg. through gtk_get_option_group(TRUE)).
Stash the envvar in a constructor function, so its ensured to happen before
it can get consumed.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1754
This is named gdkconstructor.h to avoid any possible conflicts. This fixes
the current usages of G_HAS_CONSTRUCTORS, as that header is not installed
by glib.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1029
Should fix most if not all other cases where system-caused changes to
the NSWindow result in the Gdk coordinates not mapping correctly to the
AppKit coordinates.
CREATEPROCESS_MANIFEST_RESOURCE_ID is a macro defined in winbase.h,
so we need an include to resolve that macro to its value, 1.
Without that it stays as a literal CREATEPROCESS_MANIFEST_RESOURCE_ID,
and ends up in the .exe file as-is, and Windows can't find it by that name,
resulting in UAC manifest not working and gtk-update-icon-cache bringing
up UAC prompt.
Every time a new <INCLUDE> directive is used inside a gtk-doc
sections.txt file it overrides the current include header until the next
<INCLUDE> directive. This has the unfortunate effect of making every
single section following the print-related ones to generate
documentation that says to include gtkunixprint.h.
In order to avoid re-arranging the gtk3-sections.txt file, we can tell
gtk-doc what's the default header to include for GTK, and override it
using `@Include` directives directly into the gtk-doc stanzas of the
sections that require a different header.
Fixes: #1746
including when the control modifier is present, i.e. when one is typing
control-I for instance.
Orca would convert them back to the corresponding ASCII letter anyway, and
when pressing control-tab, we do want to pass "tab", not pass "\t" that Orca
would erroneously convert to "control-I".
Fixes#1743
If the query has a non-null location, set the scope to that directory,
otherwise set it to the local computer.
There is unfortunately no way to get Spotlight to search
non-recursively, nor does NSFileManager offer a convenient search of
the contents of a directory's regular files.
Transform GdkQuartzMonitor geometry to Gdk coordinate system.
Move computation of Display geometry from GdkQuartzScreen to
GdkQuartzDisplay and use AppKit coordinates.
Closes https://gitlab.gnome.org/GNOME/gtk/issues/1593
Copy documentation for gtk_clipboard_wait_for_targets from gtk/gtkclipboard.c
to quartz implementation. Primarily to add transfer container annotation as
otherwise pygobject tries to deallocate individual GdkAtoms.
Issue #1584.
So dialogs, pop-ups, etc. behave as expected when parent is in
full-screen.
Tiling is allowed for normal windows and splash screens and disallowed
for others.
Closes https://gitlab.gnome.org/GNOME/gtk/issues/1627
In case the theme doesn't set a height/min-height for the treeview
separator the treeview drawing gets confused and draws rows on top of each
other depending on the redraw area.
This is due to gtk_tree_view_get_row_height() assuming that a node with a
height <= 0 is not set and not a separator and it will default to the
expander size.
Ideally gtk_tree_view_get_row_height() would know if it operates on a separator,
but there are too many calls/levels, so just make sure the separator height
is at least 1 (Adwaita already sets "min-height: 2px", so no change there)
GtkMenu's "accel-group" property setter, gtk_menu_set_accel_group(),
currently returns in failure if the caller passes it a NULL `accel_group`
argument. This argument is annotated with `(allow-none)`. This patch
add support for the NULL case.
When 0 or GDK_CURRENT_TIME is passed to gtk_window_present_with_time(),
print a warning so that the application developer knows that this isn't
a supported use of the function, but carry on working for now.
We now need to link to fribidi.lib explicitly in both GDK and GTK.
Since the Pango we require in 3.24.x already requires a FriBidi
installation, the .lib and DLL should already be available for the
build.
If the column used for the GtkTreeView:tooltip-column contains NULL
we're already skipping a tooltip; let's ignore empty strings as well,
as an empty tooltip is pretty much pointless.
Close#1681
We're using [a-z] ranges with sed and grep, and POSIX does not specify
their behaviour in non-ASCII locales:
In the POSIX locale, a range expression represents the set of
collating elements that fall between two elements in the collation
sequence, inclusive. In other locales, a range expression has
unspecified behavior
-- IEEE Std 1003.1-2017, § 9.3.5 (7)
This can lead to no results, or invalid replacements, which in turn can
lead to broken builds or broken build artifacts.
Fixes: #1662
Specifically it is avoided to be toggled if:
- Just received focus (in order to preserve OSK state across focus changes)
- Moving cursor around. Still allow some jitter as perfect accuracy is not
possible.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1277
When we receive a size from the move-to-rect implementation, force GTK
to continue using that size until reconfigured by move-to-rect, or
when remapped.
Fixes: #1651
On X11, the position of the menu is calculated synchronously by
gdk_window_move_to_rect(). This means that calculating the window size
when showing is too late, as that'd mean the size used when calculating
the position is out-of-date. The first time a menu is mapped, however,
the size is calculated during realization; but a window is only realized
once, so it doesn't work for subsequent maps.
Currently, this is harmless, as a GtkMenu can change its size however it
wants after it has been mapped. This, however, is problematic, as it
means the position calculated by gdk_window_move_to_rect() might no
longer be valid, or constraints made by the same function might no
longer be respected.
Thus, this is a preparation for making GtkMenu popups stay the same size
until they are remapped again at a later point.
Sometimes (read for GtkMenu on X11) it's not enough to resize on show,
and relying on the size to be calculated on realization only works the
first time a menu is popped up, so add an API that GtkMenu can use to
ensure the size of a menu is "refreshed" before passing anything along
to gdk_window_move_to_rect().
This causes window size guessing to always use the remembered size (the
size of the GdkWindow). This will be useful for menus which size is
managed by gdk_window_move_to_rect(), to avoid overriding the size
calculated by the move-to-rect implementation.
We don't need to do it, since g_clear_pointer() will do it for us, and
will also check if the function conforms to a GDestroyNotify. Using an
explicit cast will generate a compiler warning.
When using strncpy() with a buffer we need to account for the
terminating NUL character. GCC 8 started warning when using PPD_MAX_NAME
as the buffer length for strncpy() because the buffer we're copying into
has the same length — which means that the terminating NUL may be
skipped if the source string has a length of PPD_MAX_NAME.
The appropriate way to handle the case where we're copying a source with
a length bigger than of PPD_MAX_NAME is, as reported in the strncpy()
documentation, to copy `PPD_MAX_NAME - 1` bytes, and explicitly NUL
terminate the destination buffer. This has the additional benefit of
avoiding the compiler warning.
This is necessary to give back focus to the Broadway elements when
content is embedded in an IFrame.
Signed-off-by: Mickael Istria <mistria@redhat.com>
Now that we've switched the on and off states to gadgets, we need to
ensure that the widget's clip take into account the clip of every
gadget.
Fixes#1631
Improve overflow arrow buttons drawing on a scrollable dropdown menu:
reduce top button's margin-top to match size of a bottom button, add
margin-top for bottom button to compensate bottom margin (otherwise
button overlaps with menu content).
Closes https://gitlab.gnome.org/GNOME/gtk/issues/1539
There're two issues in GdkQuartzView's NSTextInputClient implementation
causes this bug.
1. The -(NSRange)selectedRange should not return [NSNotFound, 0] if
there's no selection. The accented character window will not show
if returned NSRange's location is NSNotFound. Instead of that, the
NSRange's location should be the caret position in the text input
buffer.
2. The accented character window will invoke
-(void)insertText:replacementRange: with non-empty replacement
range, to replace non-accented character with accented character
after user select it from accented character window. This case is
not implemented in original code. Here I use another gobject data
to pass the information to input module and convert it into
'delete-surrounding' event.
Besides these, there's another bug cause gtk_im_context_filter_keypress()
return wrong value while user press and hold a key. When user press
and hold a key, the accented character window will consume the
repeating key down event. Is this case, gtk_im_context_filter_keypress()
should return TRUE, indicate the key press is filtered by input
method module. But it will return FALSE because
gtk_im_context_filter_keypress() assume that every key press event
will generate some text from input method module.
Fixes#1618
Now that we've switched the on and off states to gadgets, we need to
ensure that the widget's clip take into account the clip of every
gadget.
Fixes#1631
- it's less busy and still clearer without the label
- It may be right that color alone is a poor differentiator,
but labels do still exist for the accessible theme.
- create more contrast against the headerbar background without lowering
contrast with the label and border.
- top border shaded for extra aid of the state being pressed (in the two button scenatio)
Addesses issue #1588
- colorsheme based on the new icon HIG color palette
- new switches
- darker headerbar to contrast with unfocused windows
- raised buttons derived from the icon style
And notify the shell about it. This is done through the
gtk_shell1.notify_launch request added in gtk-shell v3. All the plumbing
on the way to the activated application is already in place to transfer
the startup ID, so the other side just has to reply with
gtk_surface1.request_focus.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/624
This uses the gtk_surface1.request_focus request added in gtk-shell v3,
the given startup ID may be used by the compositor in order to determine
when was the request started, and whether user input happened in between.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/624
This version has 2 new requests:
- gtk_shell1.notify_launch notifies the compositor that the requesting
client shall launch another application. The given ID is expected to
be unique.
- gtk_surface1.request_focus notifies the compositor that a surface
requests focus due to it being activated. The given ID is passed to
this process through undetermined means, if it corresponds with a
current startup ID and there was no user interaction in between the
surface will be focused, otherwise it will demand attention.
- create more contrast against the headerbar background without lowering
contrast with the label and border.
- top border shaded for extra aid of the state being pressed (in the two button scenatio)
Addesses issue #1588
- colorsheme based on the new icon HIG color palette
- new switches
- darker headerbar to contrast with unfocused windows
- raised buttons derived from the icon style
Adapt the Visual Studio project files to output the introspection files
in the same directories where the built binaries are located from the
previous patch.
Also, make the gtk3-introspect project dependent on the gdk-3 and gtk-3
projects only, so that we can build the introspection files without
needing to finish the whole build process. In order to "install" the
built introspection files, the gtk3-install project is now where this is
being done. Note that the introspection builds is still not built by
default at this point.
To avoid confusion, have the NMake Makefiles output the built introspection
files in the same location where the binaries are built for the project
files, according to the Visual Studio version, platform and configuration
where the build is carried out.
Also make generating the introspection NMake snippet portion more robust to
source additions and removals by checking on Makefile changes too.
When a popup is placed using move_to_rect(), it'll get feedback about
the position and size it got assigned. We use this feedback to update
the scroll offset, but while doing so, if the visibility of the arrow
changed, we didn't adapt the offset accordingly.
Fix this by offsetting the provided offset by the height of the arrow,
if it was made visible as a side effect of the scroll offset change
triggered by the feedback.
Related: mutter#105
Closes: #1463
A menu will be clamped to the work area as a side effect of the
move_to_rect() logic if the resize anchor flags was set. For it to work
a second time, the initial size needs to be the actual menu size before
being clamped again. Achieve this by forcing a size recalculation before
showing the menu.
Don't constrain the initial menu size by the work area of some monitor;
instead let the move_to_rect() logic in the backend do the constraining.
This fixes two things:
1) The anchor delta provided to the backend will not be invalid. The
delta is calculated by looking at the active menu item, calculating the
offset given that, but since we clamped the window size before showing
the window, the delta became invalid. This caused visible issues when
the delta was large enough to make the initially calculated popup window
geometry to be placed outside the geometry of the parent window, which
is a violation of the Wayland protocol.
2) The scroll offset to be correct when receiving the positioning
feedback. While the scroll offset was based on the pre-clamped window
size, the feedback, which was used to calculate the new offset, was not,
causing the scroll offset to be clamped as well.
If the size was constrained by the xdg_positioner mechanisms, we handle
the resize by resizing the popup window. What we shouldn't do is
hide/show the popup window so avoid that.
We need to tell the portal what filter is supposed to be selected by
default, or it will just pick the first one, which could be wrong and
annoying.
This will require updated xdg-desktop-portal and xdg-desktop-portal-gtk
to work properly.
Fixes#1492
While the IEC power symbols have been part of Unicode since version 9.0,
released in 2016, not every font supports them.
We can use the old symbols as a fallback, as they seem to have the
better coverage, if not the best appearance.
gtk_file_chooser_set_filter() doesn't work for GtkFileChooserNative. The
code forwards added and removed filters to the delegate dialog, but
doesn't do anything to set the selected one, so the wrong one gets
chosen. So fix that.
This only fixes the fallback dialog. The portal will be fixed in a
subsequent commit.
Partial fix for #1492
Instead of from the IMContextQuartz's client window because the former
is the event window where the text will be inserted. In some cases
they're different and the text may be discarded (because the client
window isn't editable) or misplaced.
Fixes Bug 707945.
The cache key is just the name of the cursor, so if a previously added
cursor had e.g. scale == 1, if we ask for a new cursor with scale == 2,
we might still fetch the scale == 1 cursor from the cache. Avoid this by
making sure the scale of the cached one is correct.
If it isn't, load the cursor as normal, and update the cache entry with
the new properly scaled cursor.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1183
When creating the motion controller, we know the widget that is of interest
based on gtk_event_controller_motion_new(). However, not all incoming
events are guaranteed to be of the GdkWindow associated to that widget.
They may also be for a descendant. Therefore, it is useful to translate
those coordinates into the target widget coordinate space as that is
likely what they care about.
We shouldn't give the icons here the same fg colour as the bg... which
makes them disappear and the buttons look like meaningless flat squares.
Fix by just using the same colour the same as foreground disabled. Note:
insensitive_fg_color is more prominent than !disabled, so clearly wrong.
The +/- buttons are meant to be transparent, showing the base_color,
but when backdropped they were picking up background-image from the base
button, meaning they suddenly became more like theme_bg_color instead,
and jumped out of the spinbutton when in backdrop unlike the rest of it.
This looks strange and achieves nothing (especially not indicating that
they are disabled, which is already served fine by their dim fg colour).
Fix this by explicitly saying we don't want any background-image there.
CGDisplayModeGetWidth returns 0 if mode is NULL; that happens if the
CGDisplay is offline or mirroring another monitor and it leads to a
divide-by-zero crash.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1565
iter_init_common() is used on uninitialized GtkTextIter, and since neither it
nor its callers initiliaze its padding fields, they contain garbage.
This is a problem for Go - which checks that structs passed to C functions do
not contain pointers to Go-allocated memory - when the garbage happens to be
such a pointer. Although Go zero-fills all GtkTextIter that it allocates, this
does not help when GTK functions such as insert_pixbuf_or_widget_segment called
for gtk_text_buffer_create_child_anchor copy garbage from their stack-allocated
GtkTextIter into a clean iter. To work around this a GtkTextIter has to be
discraded after use in text buffer anchor inserting functions:
https://github.com/gotk3/gotk3/pull/307
So it's able to operate properly with the DnD gesture set by
gtk_drag_source_set(). We usually just react on button release,
that's the right time to claim the gesture.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1557
Signal emittion was added in 6f857f87dc commit and it seems that
this is only place where selected_row is set after emitting signal.
Because of this gtk_list_box_get_selected_row currently returns NULL
as selected row if selection mode is set to GTK_SELECTION_BROWSE.
...since one of the "fixes" there was wrong, at least cosmetically:
.get_position() is declared as returning a gboolean, which is in fact an
int in practice, but we should say what we mean, like we already did.
Make sure that the return types of the vfuncs match the ones that are
specified for post-atk-2.11.x AtkTableCellIface, since we already
require atk-2.15.1 and later.
icontheme: Recolor <polygon> elements in SVGs too
See merge request GNOME/gtk!443
(cherry picked from commit 5b049364dc)
284d9093 icontheme: Recolor <polygon> elements in SVGs too
If the revealer is told do animate and then unrealize itself, we do
(correctly) stop the animation, but used to do a shortcut where we
just set the target state as current.
Other things are dependent on the animation properly finishing though,
like the contained widget child visibility. This may lead to inconsistent
state where gtk_revealer_get_child_revealed() returns TRUE but the child
widget is unmapped, or vice-versa.
Fully finish the animation here, so the child state is coherent the next
time the revealer is mapped. We can also skip notifying on the property
since it will be handled by gtk_revealer_set_position().
Closes: https://gitlab.gnome.org/GNOME/gnome-control-center/issues/316
If the child is not (partly) revealed, don’t allocate it, or we spam the
console with warnings about giving negative width to children’s gadgets.
We can check :child-visible, which is FALSE if (current&target)_pos == 0
Close https://gitlab.gnome.org/GNOME/gtk/issues/1057
Tools on the same physical item have the same serial number, so the eraser
and the pen part of a single pen share that serial number. With the current
lookup code, we'll always return whichever tool comes first into proximity.
Change the code to use the hw id in addition to the serial number, this way we
can differ between two tools.
Generic tools (Bamboo, built-in tablets) always have the same serial number
assigned by the wacom driver. This includes the touch tool when the wacom
driver handles the touch evdev node (common where users require the wacom
gestures to work).
When the first device is the touch device, a tool is created with that serial.
All future tools now return the touch tool on lookup since they all share the
same serial number. Worse, this happens *across* devices, so the pen
event node gets assigned the touch tool because they all have the same serial.
Since we don't actually care about the touch as a tool, let's skip any unknown
tool. This captures pads as well.
Any wacom device currently sets the tool type to UNKNOWN. The wacom driver has
a property that exports the tool type as one of stylus, eraser, cursor, pad or
touch. Only three of those are useful here but that's better than having all
of them as unknown.
* We don't output spaces anywhere in the code, unlike the doc suggested.
* CSS explicitly forbids whitespace between function names and lparens:
https://stackoverflow.com/questions/13877198
Calling the accessibility function `grab_focus()` on a `GtkCell` under
Wayland will cause the client to crash.
This is another case of `gdk_x11_get_server_time()` being called
regardless of the actual windowing backend used.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1507
We need to call g_strdup() on the name that we pass in for notifying the
GDK_SETTING event so that when we do gdk_event_free() later we will not
get a crash (stack corruption) that results from attempting to g_free()
something that is not dynamically allocated.
and convertPointFromScreen:, making them handle all MacOS versions
so that all of the if-deffing happens in the function definitions.
This happens to fix issue 1518 because it turns out that contrary
to the annotation in the 10.14 nNSWindow.h, convertPointToScreen and
convertPointFromScreen originate in 10.14, not 10.12.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1518
G_GNUC_END_IGNORE_DEPRECATIONS terminates the if statement and does not
consider the following block to be part of the if. So that block was
always taken irregardless of the pattern.
Fixes#1280
We don't want to set ParentRelative when:
- the parent window is NULL
In that case we are unsure about the depth, so better err on the side
of caution and avoid a BadMatch by accepting ugly output.
- the cairo pattern is in an error status
This should never happen - unless you start up in OOM - but better
be safe than sorry.
Might help with the spurious crashes in #1280.
This reverts commit 5aedfe048b.
It had a typo that broke the build, only replaced half of the uses, and
replaced them with other functions that are also deprecated anyway.
Surface returned from gtk_icon_helper_load_surface can be smaller
then requested pixel size. This happens when icon is embedded in
panel that has bigger size then loaded pixbuf.
Fixes#1280, tray icons not drawing background. This is a magic pattern only
usable for gdk_window_set_background_pattern() that sets the underlying
X window's background to ParentRelative.
`gtk_widget_accessible_grab_focus()` code checks that X11 isenabled at
build time and uses X11 specific functions such as
`gdk_x11_get_server_time()` regardless of the actual backend being used.
Check that we are using an X11 display when X11 is backend enabled, so
we do not crash when running on Wayland
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1507
- based on a patch by frederik.feichtmeier <frederik.feichtmeier@gmail.com>
I'm certain this is something we had initially, but can't recall
why we got rid of it for the more visually distracting dashed line.
We can always revert when Lapo shows up and slams us with that broken
use case. I'm guessing non-white bgs.
- So far it looks way less distracting than the dashed line
Handling more flags, handling them correctly, and emitting the requisite
signals.
Change screen layout to use CGGetActiveDisplayList instead of NSScreens,
eliminating the latency between updating screens and recomputing the
root window.
Moving the initialization of the GdkQuartzMonitors to GdkQuartzDisplay from
the now-obsolete GdkQuartzScreen. Use QuartzDisplayServices for
monitor enumeration and to populate the GdkMonitor properties. This is
better aligned with acting on the Quartz Services callbacks for monitor
changes and with Cairo which also uses CoreGraphics for drawing.
gtk_internal_return_val_if_fail operates only in debug mode,
quartz can call this with a NULL that crashes in
GTK_STYLE_PROVIDER_PRIVATE_GET_INTERFACE.
This makes apps use "Segoe UI 9" by default instead of whatever matches "Sans 10".
It also cleans up the code and uses some new pango API while at it.
This was previously disabled in 9e686d1fb5 because it led to a poor glyph coverage
on certain versions of Windows which don't default to "Segoe UI 9" (Chinese, Korean, ..)
because the font fallback list was missing in pango.
This is about to get fixed in https://gitlab.gnome.org/GNOME/pango/merge_requests/34
so enable it again when we detect a new enough pango version.
- introduce $menu_radius
- use it for menus and context-menus
- use the popover box-shadow also for menus
- use padding for menus to avoid edge overlapping
- remove the background for menus to avoid bleeding out of the round edges
Issue #1495 showed that the docs of GtkGrid retain outdated implications
that (as was once, but is no longer, the case) it is intended to replace
GtkBox, by discussing HfW and widget properties in a way that suggests
GtkBox can't handle them. But of course it does, and it's preferable for
simple single-row/column cases. Worse, we said GtkGrid “provides exactly
the same functionality” for the latter case, but the original point of
that Issues was that it doesn’t, at least for CSS positional selectors!
Box:
• Use an actually meaningful @Short_description.
• Remove unhelpful @See_also references to unrelated containers.
• Remove references to “rectangular area”: it might be another shape
via CSS, or “rectangular” might falsely imply 2 dimensions of children.
• Mention Orientable:orientation.
• Emphasise usefulness of :[hv]align for allocating in the other axis.
• Don’t say that Grid “provides exactly the same functionality” for a
single row or column, since (A) it is overkill for that case and (B)
said Issue proved that it *doesn’t* for CSS child order, for example.
• Note in the child properties that are remove in master that we have
better, preferred alternatives available now in GtkWidget/CSS props.
There’s no nice way to deprecate these, though they’re gone in GTK+ 4.
• Correct a copy-paste-o from the blurb of :expand to :fill.
Grid:
• Remove references to deprecated widgets: GtkTable and Gtk[HV]Box.
• Don’t dwell on widget properties and height-for-width in a way that
wrongly implies that Box can’t handle those (or Grid can better). In
fact, just get rid of that bit altogether: Box handles them fine, and
Table is so old as to be not worth mentioning (in anything except the
2 => 3 migration guide) and points to Grid in its deprecation notice.
• Point to GtkBox as being preferred for the simple row/column use case.
Enables hinting, antialiasing and set the subpixel orientation according to the
active clear type setting. This ensures that font rendering with the fontconfig backend
looks similar to the win32 backend, at least with the default system font.
Append a variation selector to the Emoji sequences,
to force Emoji presentation. Without this, some
Emoji come out with text presentation by default.
Closes: Pango #334
- step back on toning down the borders. Flatness !> legibility.
- darker active state for light
- draw gradinets from bottom up, to keep px sized shading regardless
of button size.
We wrap SVG data from icons within another SVG with extra styling
information. The wrapped SVG may contain characters that cannot be
part of a data: URL (https://fetch.spec.whatwg.org/#data-urls).
Librsvg 2.45 got more strict in its parsing of data: URLs; whereas
previously it ignored '#' characters in them, now it considers them to
be the start of a fragment identifier, which is not allowed in data:
URLs anyway.
To avoid unallowed characters, we now create a data: URL with a
base-64 encoded SVG.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1471
We display a list of supported protocols in the server_addresses_popover.
However, this curated list contains protocols which may or may not be
available, depending on the respective gvfs backend being installed.
So, populate the list only with protocols which are available.
https://gitlab.gnome.org/GNOME/gtk/issues/1476
When the user types an address with a schema that is not supported,
the Connect button doesn't become sensitive, but there is no visible
feedback at all.
This feels unresponsive and leaves the user clueless.
While it doesn't help explain why the address doesn't work, this will
provide a hint that the input was acknowledged but doesn't work.
https://gitlab.gnome.org/GNOME/gtk/issues/1476
GTK widgets expect the scroll deltas to be 1 or -1 and calculate a scroll value from that.
Multiplying the delta by the Windows scroll line setting (which defaults to 3) results
in a much larger delta and vastly different behaviour for running a GTK app on Windows
vs on Linux. For example text view and tree view scroll by 9 lines per scroll wheel tick
per default this way while on Linux it is around 3.
Remove the multiplication for now.
It is permissable to remove a widget using gtk_container_remove from the
gtk_container_foreach callback handler. Document this fact to make it
more discoverable.
Fixes#1461
Gives the same background color to all separators descending from a
title bar than to its direct childrens.
This prevents separators which are in a titlebar but not direct children
from the widget with the titlebar style class from being almost
transparent and hence it prevent them from revealing the clear color of
the window's titlebar (black).
https://gitlab.gnome.org/GNOME/gtk/issues/1231
This is better than nothing at all. The wording is taken from Carlos's
commit message when he added this shortly before 3.12, so add Since too.
Skip the bit from his commit message explaining what this replaced; we
don't need to say all the less good things our convenience API replaces.
Under Wayland, we are currently directly using GSettings
for desktop settings. But in a sandbox, we may not have
access to dconf, so this may fail. Use the new settings
portal instead.
- Selection mode does not get the special devel styling.
- removed teh last-child() selector for it doesn't work anymore.
Better style all section of the headerbar than none. Proper fix pending.
By returning a default surface. The situation where there's no
currentContext arises when GtkCSS is trying to determine the
layout sizes so no actual display is necessary.
Closes: #1411
Commit 1c96b703 changed the way icon
information is given to DnD. Previously an icon helper was kept at
the drag source site. Now an image definition is stored there.
The difference is that icon helper is an object that changes its
state in response to an icon being set, thus the object survived
multiple icon changes. Whereas image definition is destroyed and
re-created from scratch every time a drag icon is changed.
This created a problem where gtk_drag_begin_internal() would receive
the value of site->image_def when a drag just began, then it emits
"drag-begin" signal, in response to which an application can
set drag icon, changing the value of site->image_def. However,
gtk_drag_begin_internal() is unable to know about that change and
continues to use the old value it received from up the stack.
Not only does it prevent drag icon from being set from "drag-begin",
it also can induce a crash, since the old image_def value used
by gtk_drag_begin_internal() points to a freed memory region.
Fix this by only setting a default icon (which is created in-place)
in gtk_drag_begin_internal() if the caller does not care about icons.
Otherwise gtk_drag_begin_internal() will return a boolean that indicates
whether an icon needs to be set. Then the caller can invoke
gtk_drag_set_icon_definition() to set the icon, if needed.
Fixes#1407.
Before this patch, imwayland would assume that text-input enter and leave events follow the general (wl_keyboard) focus, and was unable to handle the situation where they would not be provided at the same time.
gtk_drag_clear_source_info() immediately unrefs the info attached
to the context (the very same info we're in the process of destroying
in gtk_drag_source_info_free()). If that reference was the last one,
then accessing the info object after that is a use-after-free error.
Also, change the order a bit to first free the event, and only then
unref the context.
Fix this by copying all the fields of the info that we need, and
then working with these copies.
According to the XEmbed specification, a window should be created
"elsewhere" and then reparented into the target parent window. Instead,
GTK+ creates the window directly in desired target parent window. This
allows some races to occur.
Another program that does not follow XEmbed is tabbed. XEmbed requires
an _XEMBED_INFO property on the to-be-embedded window, but tabbed does
not check for this property. Thus, as soon as GTK+ creates its window,
tabbed starts managing this window and now GTK+ setting up the window
races with tabbed starting to manage the window.
If tabbed is fast enough to map the window, GTK+ never sees a MapNotify
event, because it did not yet select StructureNotifyMask on its window.
This results in a black window inside of tabbed.
Note that this cannot really be fixed in tabbed, since XEmbed says that
the _XEMBED_INFO property must be already present when the window
appears. Thus, patching tabbed to wait for _XEMBED_INFO to appear is not
something that the spec requires/allows.
Instead, this commit changes GTK+ so that it directly sets the right
event mask when the window is created. This means that there is no more
race between tabbed mapping the window and GTK+ selecting
StructureNotifyMask.
Note that the proper fix would be to do as XEmbed requires: Create the
window elsewhere and then reparent it into the target window. However,
that would require a more invasive patch, so this commit only takes the
"easy approach" of fixing this one race. Hopefully, all the other races
that can occur during window setup are harmless, because the
embedder/socket will hopefully watch for PropertyNotify events as
needed.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/757
See-also: https://github.com/awesomeWM/awesome/issues/2385
Signed-off-by: Uli Schlachter <psychon@znc.in>
This was noticed in Firefox and demonstrated using a GtkBuilder ui file.
buildable_add_child() calls set_tab_label(), but the latter did nothing
to update the menu_label corresponding to that tab with the new text.
Using Builder to populate the tab child, only tabs other than last got
the right non-default labels, and even that was mostly coincidental, as
adding the main child called update_labels() via real_insert_page(), so
it took effect when the 2nd last main child is added, updating the rest
but leaving the last with the default label, not that given in Builder.
Fix by factoring out the code from child_reordered() to a new helper
menu_item_recreate() and calling that in set_tab_label(), so that
whenever the tab_label is updated, so is its corresponding menu_label.
This fixes the reported case and presumably others that we could write.
fixes https://gitlab.gnome.org/GNOME/gtk/issues/1397
Comments matched to reassure the compiler that fallthrough is
intentional are supposed to precede the case or default keywords, at
least in GCC, so the one here did not suppress the warning with GCC. We
can just the if condition and put the comment at the end to solve that.
https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/
Instead we just cache the monitor number and get
out of it the nsscreen when it is needed. This is
a requirement since it nsscreen it is not supposed
to be cached.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1312
Commit c255ba68 inadvertently introduced a regression that broke Korean
text input because the changes there resulted that only the last input
string that we have from ImmGetCompositionStringW() for each time the
commit signal is emitted is kept, and also as a result the final Korean
character that is input by hitting space is also lost as a result, as we
didn't check for whether we are done with preediting.
Fix these issues by doing the following when we receive the
WM_IME_COMPOSITION message with GCS_RESULTSTR from Windows:
-Do not emit the commit signal during WM_IME_ENDCOMPOSITION, and...
-Emit the commit signal anyways, as we did before, c255ba68, however...
-We still save up the string to commit, because we need to re-compute
the cursor position when we do ->get_preedit_string(), which needs to
take the GCS_RESULTSTR string we get from WM_IME_COMPOSITION into
account as well, so that we avoid getting the Pango criticals that
occur during Chinese (and most likely Japanese) input as the cursor
position is out-of-range.
Fixes issue #1350.
The gtk_stack_snapshot_slide() function dereferences the
last_visible_child pointer without proper != NULL ckeck. This might
result in NULL pointer dereference and crash if last_visible_child is
invalid.
Add a != NULL check before dereferencing the pointer.
cherry-picked from https://gitlab.gnome.org/GNOME/gtk/merge_requests/361
Before the recent rework of positioning in GtkTooltip, the widget always
used the cursor_size of the GdkDisplay. That work redid this to instead
take GtkSettings::gtk-cursor-theme-size. But that property's doc says:
> Size to use for cursors, or 0 to use the default size.
and has 0 as its default. This is quite a likely scenario for anyone
whose desktop or settings.ini does not explicitly provide a cursor size,
which is the case for XFCE and win32, to name just two common platforms.
Then, it seems getting a cursor_size of 0 causes GtkTooltip to freak out
and hide/show itself at a very rapid speed, thus making it unusable.
So, we should check whether the Settings return 0 and, if so, still use
gdk_display_get_default_cursor_size (display) to ensure we get a size.
https://gitlab.gnome.org/GNOME/gtk/issues/1371
Do not lie to W32 about the formats that we provide or accept.
Originally the logic behind such lies was that GdkPixbuf allows
us to convert any supported image to BMP or PNG, and therefore
we should announce that we always provide/accept BMP and PNG along
with other formats.
But that's not how it works. The conversion between formats happens
at GTK level in GtkClipboard or, if GtkClipboard is not used, with
gtk_target_list_add_image_targets() to announce all supported image
formats, and with gtk_selection_data_set_pixbuf() to convert from
any GdkPixbuf formats to the format requested by the selection, and
with gtk_selection_data_get_pixbuf() to convert from the selection
format to GdkPixbuf, if supported.
GDK simply does not play any role in this. Therefore W32 GDK backend
should only offer formats that it can actually do conversion for
by itself (such as image/bmp <-> CF_DIB,
or text/uri-list <-> CFSTR_SHELLIDLIST).
This leverages the normal input module switching mechanism in GTK
by making it think that the gtk-im-module setting changed.
The backend returns gtk-im-module value as "ime" if W32
IME API says that an IME is in use. Otherwise it returns
and empty string - this still triggers an input module
loading code, which, not being able to load the desired module
(which is and empty string), falls back to looking at current
keyboard layout.
Paired with the code that signals gtk-im-module change on keyboard layout
switches, this is sufficient to make GTK capable of loading appropriate
input modules at runtime. At least, the kinds of modules that specify
languages for which they are loaded automatically by default, and the
IME module.
Loading other kinds of input modules might still work via specifying
the gtk-im-module setting in gtk ini file, but doing so will likely
make GTK incapable of loading the IME input module that is used
for Korean, Chinese and Japanese (and some other languages).
Until someone figures out a way to actually change gtk-im-module
setting on Windows at runtime with meaningful values, the behaviour
introduced by this commit seems like a sufficient workaround.
GNOME Shell 3.32 will remove support for the app menu
so we need to move its contents to the primary (hamburger)
menu.
widget-factory already had a primary menu.
The only item in the app menu was About.
https://gitlab.gnome.org/GNOME/Initiatives/issues/4
gtk_entry_event's goal is to detect if a specific event concerns one of the two
entry icons. It can happen that this function is called during initialization
and/or before the entry is realized. In this case the entry icons (and the
event) will not yet have an associated window. The code should consider the
aforementioned situation and avoid matching a icon and an event with no
associated windows.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1366
Suggested by Garnacho. Hopefully fixes#1349.
Note: I'm riskily committing this via web UI not because I'm lazy
(though I am :) but because I'm seeing a weird host key when I try to
push or pull from GitLab.
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.
Commit 359df028be changed the
code to send GDK_SCROLL_SMOOTH with deltas instead of
GDK_SCROLL_(UP|DOWN|LEFT|RIGHT).
Windows defines deltas inversed for vertical direction
(positive values mean the wheel was turned forward)
but not for horizontal direction
(positive values mean the wheel was turned towards the right).
This commit fixes behavior as both axes were inverted previously.
Commit 359df028be changed the
code to send GDK_SCROLL_SMOOTH with deltas instead of
GDK_SCROLL_(UP|DOWN|LEFT|RIGHT). Change it again, to send
both the GDK_SCROLL_SMOOTH and the GDK_SCROLL_(UP|DOWN|LEFT|RIGHT)
event separately (with the discrete event marked as emulated),
as this is what other backends (such as wayland) do.
Fixes terminal emulator misbehaviour as outlined in https://gitlab.gnome.org/GNOME/gtk/issues/1316, which was introduced in 49b17e6c. The original commit cleared preedit text by setting it to an empty string, which still counted as existing preedit. The fix sets preedit string to null, which is correctly understood as not present.
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.
There may be situations where this might get called while the
currently focused context just went away (eg. after setting the
text widget unsensitive).
Closes: #1317
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
Let's just use the fact that a window was mapped as a subsurface to
remap it above another transient parent instead of relying on the more
complicated 'should-map-as-subsurface' helper function.
Set delta_x or delta_y for GdkScrollEvent.
HIWORD (wParam) in WM_MOUSE(H)WHEEL is the scroll delta.
A delta value of WHEEL_DELTA (which is 120) means scrolling
one full unit of something (for example, a line).
The delta should also be multiplied by the value that the
SystemParametersInfo (SPI_GETWHEELSCROLL(LINES|CHARS), 0, &value, 0)
call gives back, unless it gives back 0xffffffff, in which case
it indicates that scrolling is page- or screen-based, not line-based
(GDK doesn't support that at the moment).
Also, all deltas should be inverted, since MS sends negative deltas
when scrolling down (rotating the wheel back, in the direction of
the user).
With deltas set the mode should be set to GDK_SCROLL_SMOOTH.
Fixes issue 1263.
If we detect HarfBuzz and PangoFT2, GtkFontChooserWidget uses them. So
we need to add CFLAGS and LIBS of them to GTK_DEP_CFLAGS/LIBS. If we
don't add them, MinGW build fails to link.
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 fixes a potential leak of a PangoAttrList that is set when chaining
up to the parent get_preedit_string(). We check to see if the attr list
was created and reuse it instead of leaking the previous value.
gdk_win32_window_set_transient_for() behaves incorrectly when
called in sequence with the same arguments. This fix ensures it
always operates correctly.
In some cases this function gets called multiple times with the
same arguments, e.g. when tooltips are shown.
See issue #1214
The functions as below are deprecated
- gdk_screen_get_monitor_geometry
- gdk_screen_get_primary_monitor
Instead of them, use functions below
- gdk_monitor_get_geometry
- gdk_display_get_primary_monitor
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.
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.
There is no reason why we shouldn't pass this flag every time
Z-order changes. We have separate routines that are used to
maintain relative Z-order, so it should be completely OK to
pass SWP_NOOWNERZORDER to let the OS know that it shouldn't try
to maintain relative Z-order of the windows when raising them.
Pass SWP_NOOWNERZORDER when rising TEMP surfaces to the top. This ensures that
they don't drag anything else to the top with them. The use-case for this is
a tooltip (which must be on top) appearing for a non-foreground surface,
causing said surface to rise above other surfaces, some of which may
be foreground at the moment.
https://bugzilla.gnome.org/show_bug.cgi?id=784766
Fixes issue #852
2018-06-17 10:44:04 +00:00
677 changed files with 108133 additions and 41643 deletions
- You will need to run the following upon completing install, from the build
directory in the Visual Studio 2008/SDK 6.0 command prompt (third line is not
needed unless -Dbuiltin_immodules=no is specified) so that the built binaries
can run:
for /r %f in (*.dll.manifest) do if exist <gtk_install_prefix>\bin\%~nf mt /manifest %f /outputresource:<gtk_install_prefix>\bin\%~nf;2
for /r %f in (*.exe.manifest) do if exist <gtk_install_prefix>\bin\%~nf mt /manifest %f /outputresource:<gtk_install_prefix>\bin\%~nf;1
for /r %f in (*.dll.manifest) do if exist <gtk_install_prefix>\lib\gtk-3.0\3.0.0\immodules\%~nf mt /manifest %f /outputresource:<gtk_install_prefix>\lib\gtk-3.0\3.0.0\immodules\%~nf;2
- The more modern visual style for the print dialog is not applied for Visual
Studio 2008 builds. Any solutions to this is really appreciated.
for %%s in (16 22 24 32 48 256) do ((mkdir $(CopyDir)\share\icons\hicolor\%%sx%%s\apps) & (copy /b ..\..\..\demos\gtk-demo\data\%%sx%%s\gtk3-demo.png $(CopyDir)\share\icons\hicolor\%%sx%%s\apps))
/* clock went backward. adapt to that by forevermore increasing
* timer_base. For now, assume we've gone forward in time 1ms.
*/
/* hmm. just fix GTimer? */
computed_frame_time=g_get_monotonic_time();
/* ensure monotonicity of frame time */
if(computed_frame_time<=priv->frame_time)
computed_frame_time=priv->frame_time+1;
priv->timer_base+=(priv->frame_time-elapsed)+1;
}
else
{
computed_frame_time=elapsed;
}
returncomputed_frame_time;
}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
