For very small page sizes of < 1.0, the effect of pow() is the
opposite of what's intended and the scroll steps become unusably
large, make sure we never get a scroll_unit larger than page_size /
2.0, which used to be the default before the pow() magic was
introduced.
Otherwise, requesting a min size in em where the equivalent in px had a
fractional part would lead to the gadget getting allocated 1 too few px.
You could see this in the CSS property vs. allocation in the Inspector.
Note that margin/border/padding are left alone: the rationale is that we
do as browsers do, and Benjamin said we already do that for those,
whereas his tests on min-(width|height) showed otherwise. My subsequent
analysis indicated it to be far less clear-cut than that, but he remains
unconvinced that we should ceil() all the things! So just do these ones.
https://gitlab.gnome.org/GNOME/gtk/issues/1088
This is the API used by GtkMenu to properly position menus on the screen
without requiring GTK to query the menu window's position or the work
area of where the window is positioned. It makes it possible to position
popup windows properly when using Wayland.
Make this API available to external users so custom popup windows can be
positioned properly as well.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/997
This is meant as an input to the font chooser.
We don't want the user to select a language, but
rather have fonts presented as they would work for
the current language. Therefore, do away with the
lang/script combo on the tweak page.
For some font features, we can figure out affected
glyphs, and show before/after. For some others, we
hardcode typical sequences.
Still to do: figure out how to find ligatures and
show them.
Without enforcement to the expander-size, we can end up rendering icons
rather fuzzy. This uses the expander-size style property to determine
the square for the icon, centered on what was the calculated space for
the expander.
X uses unscaled sizes, so they must be scaled properly. Otherwise
GtkSockets end up twice as big as they should be.
Closes: https://bugzilla.gnome.org/show_bug.cgi?id=765327
Signed-off-by: Jason Zaman <jason@perfinion.com>
Close!165
:climb-rate is not about what you get when you single-click on a button,
as this implied: it's what happens if you hold down a button or a key.
Fix the description of @climb_rate to new(), and while here, mention the
key in the blurb of :climb-rate itself.
We've had it for a long time, and it hasn't really made
a difference. And I don't think we are prepared to turn
this into a hard error. So just drop it.
The last round of patches to get the desired direction of value move in
response to scrolls/keypresses on scales had the inadvertent side effect
of giving the opposite direction on scrollbars. Seeing as gtkrange.c is
already a collection of hacks, add another so that fix only holds if the
instance is a GtkScale, since that is what those patches were aimed at.
Close https://gitlab.gnome.org/GNOME/gtk/issues/1065
These can't be returned as part of the font description,
so we need new api for them. For now, this is just readonly
properties. Maybe these should be writable too, eventually.
GtkTextView scrolls to the insertion point when the text
buffer signals a paste is done. This is wrong when there
are multiple views on the same buffer, and the paste
happened in another view.
To fix this, flip the handling of the scroll_after_paste
boolean to only be TRUE if we know that we want to scroll.
The gtk_app_chooser_dialog_set_heading() function do emit
notify::heading. Since the setter simply calls the function,
the setter itself shouldn't emit a notify signal by itself.
In scroll_event(), there is no need to check whether we are realized
before emitting ::change-value, as we must be when receiving an event.
Git-formatted/rebased/cleaned up by Daniel Boles <dboles.src@gmail.com>
Close https://gitlab.gnome.org/GNOME/gtk/issues/292
• #include <math.h> for the new uses of floor()
• Move the new ints and popdown_data into the scopes where they are used
• Don’t pointlessly init other ints to 0 as they always get reassigned
• Burninate gint
This issue was caused when mouse coordinates were changed to floating
point values in commit e8b38fedbd.
This patch floors the event->x_root and event->y_root values when
setting the navigation region, so the previous behaviour is restored.
https://gitlab.gnome.org/GNOME/gtk/issues/450
gdk_win32_keymap_check_compose() shouldn't be called for
non-W32 displays (i.e. when using broadway or other backends
that could be made to run on Windows).
to retreive paper size specific hard margins and use this
to set the hard margins in the print context.
(modified by Marek Kasik <mkasik@redhat.com>)
https://bugzilla.gnome.org/show_bug.cgi?id=686109
We expect these files to be regenerated even when building GTK+ from a
release tarball, so there's no point in distributing them if they are
going to be ignored.
.linked assumes the container is a GtkBox, which is documented as never
flipping children in RTL, so :first-child is always the left child, etc.
GtkBox does that by reordering its CSS nodes when the direction changes.
But most widgets don’t do that, so :first|last-child are 1st/last ADDED
and swap sides in RTL. GtkPathBar is so, and ignoring that in our themes
meant that in RTL, its left/right buttons got each other’s borders. Yuk!
This patch adds the groundwork for supporting widgets like that, via the
%linked_flippable placeholder, and applies that to override buttons in
filechooser .path-bar.linked > button
so that the correct borders get applied to those buttons when using RTL.
Note that I select only PathBars within a FileChooser because we also
have NautilusPathBar, which also uses widget.path-bar – but *does* flip
its nodes for RTL already, so letting that get affected broke it again!
https://bugzilla.gnome.org/show_bug.cgi?id=772817
Otherwise, if the Popover is destroyed before the MenuButton, the latter
still had a non-NULL but invalid instance and tried to use it in dispose
https://gitlab.gnome.org/GNOME/gtk/issues/199
A user in #gtk+ was confused what to do instead of creating a Button via
gtk_button_new_from_stock(). Our docs could stand to be clearer on this
point; it only costs a few lines. So, link from that constructor* to the
GtkStock doc, and add a banner there telling folk they shouldn’t use it.
* not that most [of these][links] even work right now…
Use g_signal_connect_data() instead of g_signal_connect_object()
to make sure the callback gets disconnected when the data object
is destroyed. This avoids problems in garbage-collected bindings.
https://bugzilla.gnome.org/show_bug.cgi?id=789215
The GVariant we are getting here might not be coming
from GTK+, but rather from some other source. Best to
be forgiving and deal with missing data without crashing.
This was causing the GTK+ portal backends to crash on
print requests from Qt.
Gtkplacesview finalization fixes
See merge request GNOME/gtk!119
(cherry picked from commit e30176a522)
f9452957 gtkplacesview: unset entry_pulse_timeout_id before removing it
4900c3eb gtkplacesview: disconnect from server list monitor changes on destroy
This will be used in subsequent commits to fix the sign by which the
value is changed in response to directional scroll or keypress events.
The idea is: you have a movement to make – in the form of a delta that
follows widget directions, i.e. −1 means left or up, +1 means right or
down – and you want to know whether that delta needs to be inverted in
order to produce the intuitively expected directional change of :value.
The existing should_invert() is not sufficient: it just determines
whether to invert visually, but we need more nuance than that for input.
To answer that – while not doubling up the work for scrolls and keys – I
add a helper should_invert_move(), which considers other relevant state:
• A parallel movement on priv->orientation should just use the existing
should_invert(), which already worked OK for this case (not others).
• Movements on the other orientation now depend on priv->orientation:
◦ For a horizontal Range, always invert, so up (i.e. −ve in terms of
widget coords) always means increase value & vice-versa. This was
done in get_wheel_delta(), but move it here for use with keys too.
◦ For a vertical Range, ignore :invert as it’s only relevant to the
parallel orientation. Do not care about text direction here either
as RTL locales do not invert number lines, Cartesian plots, etc.
This returns TRUE if the delta should be inverted before applying to the
value, and we can now use this function in both scroll and key handlers.
https://bugzilla.gnome.org/show_bug.cgi?id=407242https://bugzilla.gnome.org/show_bug.cgi?id=791802
.set_accel_path(): Use (nullable) instead of (allow-none), and explain
what a NULL means (albeit very briefly)
.set_title(): Annotate @title as (nullable), and explain NULL’s meaning
...from CellRenderer::start-editing, to point people in the direction of
info about the lifecycle of the Editable and how to do generic setup.
https://gitlab.gnome.org/GNOME/gtk/issues/154
Drop the line copied from .activate(), replace it with a description of
what this method actually does, and explain what a NULL result means.
https://gitlab.gnome.org/GNOME/gtk/issues/154
* Note in the intro that we're really thinking about temporary widgets
* Mention a gotcha regarding GtkEntry and how ::focus-out stops editing
* Give some examples of what you'd want to do in ::editing-done
* Be a bit more precise about what ::remove-widget represents
* Summarise the lifecycle between Renderer/Editable in .start_editing()
* Emphasise again there that this should be viewed as a temporary widget
https://gitlab.gnome.org/GNOME/gtk/issues/154
... and use it to not connect anything to the frameclock if it isn't
set.
This gets around the problem that the frame clock is disconnected before
GtkWidgetClass.unrealize() is called but the widget is still marked as
realized and the frame clock is available during the vfunc, which makes
calls like gtk_widget_queue_resize() reconnect to the frame clock.
Closes#168
Redrawing is insufficient: when :role changes to/from NORMAL, the
indicator gadget reallocates, but we didn't reflect that in the widget.
https://gitlab.gnome.org/GNOME/gtk/issues/163
delete_range_cb is set to be called before the text suppression done by
the gtktextlayout (otherwise it does not work properly). But at that
point the cursor position is not yet up to date. We thus need to move
the accessibility cursor notification to after the actual text
suppression, by using another callback.
This fixes cursor position in brltty screen reading.
The second parameter of the text-changed::delete event is to be the length,
not the end position. This fixes spurious text removals in brltty
screen reading.
Like other widgets, this returns a floating reference, so
(transfer full) is wrong. Just omit the annotation as others do,
thus implying (transfer none).
Close https://gitlab.gnome.org/GNOME/gtk/issues/156
If GtkExpander:sensitive was FALSE, the arrow still got the normal fg
colour, which made it look clickable, in contrast to the adjacent label.
Fix this by adding selectors to catch the applicable :disabled states.
Note: Needing these may indicate an oops in generic styles elsewhere,
but I couldn’t see any, so let’s just get it looking right for now.
https://gitlab.gnome.org/GNOME/gtk/issues/146
…the wayland registry.
Wnen _gtk_im_module_get_default_context_id calls
match_backend (context_id) and the default GdkDisplay
is wayland, match_backend() should return TRUE only if
gdk_wayland_display_query_registry (display, "gtk_text_input_manager")
returns TRUE.
When the widget gets finalized it clears the widgetnode and gtk_css_widget_node_get_widget
returns NULL. Guard against gtk_css_widget_node_get_widget() returning NULL like in other
places.
See https://gitlab.gnome.org/GNOME/pygobject/issues/28#note_82862
If @menu_label == NULL, we create a default page->menu_label. This took
@tab_label.get_label() and passed that to page->menu_label.set_text().
This is wrong because we set the plain text of the menu_label from the
rich text of @tab_label. So, if @tab_label used mnemonics or markup, our
menu_label got the raw underline or markup tags shown in it as raw text.
As we call set_text() on the menu Label, the fix is to be symmetric: use
@tab_label’s get_text() as source, as that strips underlines and markup.
It’s not worth making the default Label ‘inherit’ :use-underline/markup;
that’s a slippery slope, and users wanting such things can just create a
fully fledged GtkLabel to pass as @menu_label to suppress the default.
https://bugzilla.gnome.org/show_bug.cgi?id=705509
Otherwise, the + or - button might change sensitivity based on whether
it can be used to wrap, but without ensuring we update its state, the
ability to :wrap isn't reflected until something else triggers a draw.
https://gitlab.gnome.org/GNOME/gtk/issues/88
Realization is done as a side effect of calling
_gtk_entry_completion_resize_popup(), but if this is done before the
GdkScreen of the GtkWindow is set up correctly, it may result in the
widget being unrealized when the screen is updated. This may happen
when the file dialog parent window is not using the default GdkDisplay.
To avoid this issue, realize the popup after the screen has been
properly set up.
Fixes#83 in gtk3
Now that subtitle's default value "Searching" for OPERATION_MODE_SEARCH
is duplicated as it should be, we cannot reassign other strings to it
anymore, as that resulted in the original dupe of "Searching" leaking.
Fix this by only assigning the dup'd "Searching" after trying to get
more specific values, not before. We therefore need to set it to NULL
during its declaration, and that means we needn't in the final else.
Having a FileChooserDialog in location-entry mode then pressing
<primary>f to move to search mode would crash with an invalid free().
In that case, FileChooserWidget.get_subtitle() returned a static string
straight from gettext. This crashed when the GBinding from :subtitle to
FileChooserDialog’s HeaderBar:subtitle shortly tried to free the string.
Fix by duplicating the string before returning it, like all other paths.
https://bugzilla.gnome.org/show_bug.cgi?id=791004
Match "box" instead of "*", as already done for the search bar GTK4 and
for the action box in GTK3. Also clarify which widget property is
causing the margin which needs to be undone.
Includes applications like GNOME Software and GNOME Documents. The
search bar is a composite widget with a revealer inside it, and when the
content of the revealer is hidden, the border lingers. Changed the CSS
to add style to the content of the revealer instead of the search bar
widget itself.
We can't use gtk_widget_get_allocation for either non-anchored widgets
(which happens with the child widget when the expander is unexpanded)
nor toplevel windows since that will include the window decorations.
Fixes#70 in gtk3
Include gtk/gtk.h and gtk/gtk-a11y.h unconditionally,
and gtk/gtkx.h when building with X11. Ensures that
introspection data contains complete set required
headers, which is useful when generating C code based
on introspection data.
Diff for generated gir (when using X11):
```diff
<include name="xlib" version="2.0"/>
<package name="gtk+-3.0"/>
+ <c:include name="gtk/gtk-a11y.h"/>
+ <c:include name="gtk/gtk.h"/>
+ <c:include name="gtk/gtkx.h"/>
<namespace name="Gtk"
version="3.0"
```
Fixes issue #56.
This reverts commit fb0a13b7f0.
It's already reverted in master via
c8a6a1138b, so let's not leave subtle
behavior changes that would make a gtk3->gtk4 migration. And just like
the commit message of the revert already mentions: it didn't really make
anybody happy anyway.
Calling gtk_menu_item_get_label on a GtkSeparatorMenuItem would
otherwise create a GtkLabel child, increasing the vertical size request
to that of the child label.
In PyGObject gdk_init() is called before gtk_init() and thus there is
already a default display open when gtk_init() is called.
The code assigning the display to the debug_flags struct gets only
called when the default display changes, which never happens
when there already is one. As a result GTK_DEBUG=interactive
doesn't do anyting with Python apps.
This makes it call the change callback in case a display is already
there.
See https://gitlab.gnome.org/GNOME/pygobject/issues/166
When we found an icon with exactly the requested size, we'd stop
searching immediately (good), but we'd neglect to set the returned
min_difference to 0 (bad). This caused theme_lookup_icon() to
prefer other, potentially much worse, matches over the exact one.
We link to the HowDoI for GNotification in the class description, but we
should be more verbose in the deprecation notices for each function of
the GtkStatusIcon class.
https://bugzilla.gnome.org/show_bug.cgi?id=743975
This IM context implementation goes through the gtk-text-input protocol,
leaving up to the compositor the actual interaction with IM engines. If
the protocol is not offered by the compositor, GTK+ will fallback to the
IMs as specified through GtkSettings.
The annotation (allow-none) is wrong. Since
gtk_tree_view_is_blank_at_pos() also calls
gtk_tree_view_get_path_at_pos(), the same fields should have the same
annotations.
Due to the recent changes introduced in glibc 2.27 "%OB" is the
correct format to obtain a month name as used in the calendar
header. The same rule has been working in BSD family (including
OS X) since 1990s. This simple hack checks whether "%OB" is supported
at runtime and uses it if it is, falls back to the old "%B" otherwise.
Closes: #9
We are using a lot of deprecated API, and we know it.
Since the selection code is going to be replaced in GTK 4.0, there's no
real point in keeping the warnings enabled in 3.22.
Functional revert of commit 9c4892f291.
Fixes introspection scanner warnings like:
Warning: Gtk: gtk_drag_finish: Methods must belong to the same
namespace as the class they belong to
That is, the gtk_drag_* functions cannot be methods as they have a
"GdkDragContext" as the instance parameter, and that is not a valid
type for the Gtk namespace.
This is not an introspected ABI change, as the generated introspection
data ignores the annotation.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=692152
The problem here is that the CSS machinery expects font sizes to be in
pixels, but gtk_widget_override_font() provides a value in point and the
CSS machinery has no ability to query the DPI and convert.
This patch changes the dconversion DPI we use from a hardcoded 96 to the
default screen's DPI, which should work better than before.
This will of course not listen to changes in the default screen's DPI,
but that shouldn't be a problem.
People who want to workaround this should use gtk_widget_override_font()
with a font that has an absolute size set via
pango_font_description_set_absolute_size (size * PANGO_SCALE *
gdk_screen_get_resolution (screen));
https://bugzilla.gnome.org/show_bug.cgi?id=774248
After commit ffef28a7e8,
gtk-icon-browser was spewing critical warnings when
changing sections. Avoid that by respecting the return
value of gtk_tree_model_get_iter.
GtkGesture is a GtkEventController. gtk_event_controller_dispose() calls
_gtk_widget_remove_controller(). That NULLs the pointer-to-Controller in
our EventControllerData but does not delete said ECData from our GList.
Subsequently, if that same Widget gets unparent()ed, that method calls
unset_state_flags(), which leads to doing reset_controllers() if we are
insensitive. Now, unlike most most other loops over the GList of ECData,
reset_controllers() does not skip nodes whose pointer-to-Controller is
NULL. So, we call gtk_event_controller_reset(NULL) and get a CRITICAL.
This surfaced in a gtkmm program. The Gesture is destroyed before the
Widget. The Widget then gets dispose()d, which calls unparent()… boom.
I didn’t find an MCVE yet but would hope this logic is correct anyway:
The simplest fix is to make the loop in gtk_widget_reset_controllers()
skip GList nodes with a NULL Controller pointer, like most other such
loops, so we avoid passing the NULL to gtk_event_controller_reset().
In other, live cases, _gtk_widget_run_controllers() loops over the GList
and removes/frees nodes having NULL Controllers, so that should suffice.
But this clearly was not getting a chance to happen in the failing case.
https://bugzilla.gnome.org/show_bug.cgi?id=792624
Filter models rely on views taking a ref on every node
they care about. GtkIconView was not doing that. Amazingly,
this has never shown up in a bug so far, until I spotted
the fallout in gnome-font-viewer.
We must notify the font and font-desc properties when the
list selection changes, and return NULL values for them
when there is no selection in the list.
We were failing to change the sort order for the
default sort column in some cases. Fix that, and
add a testcase for this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=792459
Add a testcase for the previous fix
Some emoji fonts (such as Emoji One), render Emoji sequences
such as some of the family variations using multiple individual
glyphs. This rendering is too wide and breaks our grid layout.
Therefore, we will just skip any sequence whose rendering is
more than twice as wide as a simple smiley.
meta-pick of commit c1573a1fda: the
variable gdk_window is used in a check, but we may as well use it again
to avoid calling _gtk_widget_get_window() again unnecessarily.
Putting a combobox in an expander was causing the combo arrow
to go sideways. Increase the specificity with which we address
the expander arrow to avoid that.
Users expect, & previous patches have tried to assure, that scrolling up
over a horizontal Range will cause the value to increase & vice-versa.
But the path using directions was still negating the delta & decreasing
the value on scrolling up. This could be seen on Win32 or X without XI2.
So, only negate the delta when scrolling down (or left), not up, so that
scrolling up (or right) will make the value increase for any event type.
https://bugzilla.gnome.org/show_bug.cgi?id=737175#c5
The only time a style-updated indicates we need
to reload fonts is when it is synthesized by GtkSettings
in response to a fontconfig timestamp change, but
we are listening to those already, anyway.
The code was asserting something that was not always holding
true. We can hit row == NULL here on page-up too. Handle that
case by moving to the first row.
https://bugzilla.gnome.org/show_bug.cgi?id=791549
We need to notify ATK the description changed when the tooltip text associated
with the widget changes and gtk_widget_accessible_get_description() would use
it as the description.
https://bugzilla.gnome.org/show_bug.cgi?id=779009
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.
https://bugzilla.gnome.org/show_bug.cgi?id=791281
The documentation about gtk_file_chooser_set_local_only() states
that "non-native files may still be available using the native
filesystem via a userspace filesystem (FUSE)."
The code that made this possible in GTK+2 was missing from GTK+3 and
that represented a regression for Linux users in numerous applications
(Firefox, Thunderbird, Chromium, ...)
https://bugzilla.gnome.org/show_bug.cgi?id=787128
As the summary says, this allows using g_autoptr(GtkTreePath). This is
useful for API that uses out parameters for GtkTreePath that need to be
freed.
https://bugzilla.gnome.org/show_bug.cgi?id=791234
1) Ensure that any DELETE requests from the target are sent to GDK, even if
both the source and the target are in the same process and it
is therefore possible to use a shortcut and call the handler directly
in GTK layer
2) Ensure that target GDK doesn't do anything when GTK asks it to send
a DELETE request, just report back immediately (the code up the stack
does not check for successfullness when request is DELETE, so not giving
it any data is OK).
The source code already synthesizes a DELETE request, so that side is
also taken care of.
https://bugzilla.gnome.org/show_bug.cgi?id=786509
Massive changes to OLE2 DnD protocol, which was completely broken before:
* Keep GdkDragContext and OLE2 objects separate (don't ref/unref them
together, don't necessarily create them together).
* Keep IDataObject formats in the object itself, not in a global variable.
* Fix getdata() to look up the request target in its format list, not in the
global hash table
* Create target GdkDragContext on each drag_enter, destroy it on drag_leave,
whereas IDropTarget is created when a window becomes a drag destination
and is re-used indefinitely.
* Query the source IDataObject for its supported types, cache them in the
target (!) context. This is how GTK+ works, honestly.
* Remember current_src_object when we initiate a drag, to be able
to detect later on that the data object is ours and use a
shortcut when querying targets
* Make sure GDK_DRAG_MOTION is only sent when something changes
* Support GTK drag cursors
* Ensure that exotic GTK clipboard formats are registered
(but try to avoid registering formats that can't be used between applications).
* Don't enumerate internal formats
* Ensure that DnD indicator window can't accept drags or receive any kind of input
(use WS_EX_TRANSPARENT).
* Remove unneeded indentation in _gdk_win32_dnd_do_dragdrop()
* Fix indentation in gdk_win32_drag_context_drop_finish()
* Remove obsolete comments in _gdk_win32_window_register_dnd()
* Check for DnD in progress when processing WM_KILLFOCUS, don't emit a grab
break event in such cases (this allows alt-tabbing while DnD is in progress,
though there may be lingering issues with focus after dropping...)
* Support Shell ID List -> text/uri-list conversion, now it's possible
to drop files (dragged from Explorer) on GTK+ applications
* Explicitly use RegisterClipboardFormatA() when we know that the string
is not in unicode. Otherwise explicitly use RegisterClipboardFormatW()
with a UTF8->UTF16 converted string
* Fix _gdk_win32_display_get_selection_owner() to correctly bail
when selection owner HWND is NULL (looking up GdkWindow for NULL
HWND always succeeds and returns the root window - not the intended
effect)
* More logging
* Send DROP_FINISHED event after DnD loop ends
* Send STATUS event on feedback
* Move GetKeyboardState() and related code into _gdk_win32_window_drag_begin(),
so that it's closer to the point where last_pt and start_pt are set
* Use & 0x80 to check for the key being pressed. Windows will set low-order bit
to 1 for all mouse buttons to indicate that they are toggled, so simply
checking for the value not being 0 is not enough anymore.
This is probably a new thing in modern W32 that didn't exist before
(OLE2 DnD code is old).
* Fixed (hopefully) and simplified HiDPI parts of the code.
Also adds managed DnD implementation for W32 GDK backend (for both
OLE2 and LOCAL protocols). Mostly a copy of the X11 backend code, but
there are some minor differences:
* doesn't use drag_window field in GdkDragContext,
uses the one in GdkWin32DragContext exclusively
* subtracts hotspot offset from the window coordinates when showing
the dragback animation
* tries to consistently support scaling and caches the scale
in the context
* Some keynav code is removed (places where grabbing/ungrabbing should
happen is marked with TODOs), and the rest is probably inert.
Also significantly changes the way selection (and clipboard) is handled
(as MSDN rightly notes, the handling for DnD and Clipboard
formats is virtually the same, so it makes sense to handle
both with the same code):
* Don't spam GDK_OWNER_CHANGE, send them only when owner
actually changes
* Open clipboard when our process becomes the clipboard owner
(we are doing it anyway, to empty the clipboard and *become* the owner),
and then don't close it until a scheduled selection request event
(with TARGETS target) is received. Process that event by announcing
all of our supported formats (by that time add_targets() should have
been called up the stack, thus the formats are known; just in case,
add_targets() will also schedule a selection request, if one isn't
scheduled already, so that late-coming formats can still be announced).
* Allow clipboard opening for selection_convert() to be delayed if it
fails initially.
* The last two points above should fix all the bugs about GTK+ rising
too much ruckus over OpenClipboard() failures, as owner change
*is allowed* to fail (though not all callers currently handle
that case), and selection_convert() is asynchronous to begin with.
Still, this is somewhat risky, as there's a possibility that the
code will work in unexpected ways and the clipboard will remain open.
There's now logging to track the clipboard being opened and closed,
and a number of failsafes that try to ensure that it isn't kept open
for no reason.
* Added copious notes on the way clipboard works on X11, Windows and GDK-W32,
also removed old comments in DnD implementation, replaced some of them
with the new ones
* A lot of crufty module-global variables are stuffed into a singleton
object, GdkWin32Selection. It's technically possible to make it a
sub-object of the Display object (the way Wayland backend does),
but since Display object on W32 is a singleton anyway... why bother?
* Fixed the send_change_events() a bit (was slightly broken in one of the
previous iterations)
* Ensure that there's no confusion between selection conversion (an artifact
term from X11) and selection transmutation (changing the data to be W32-compatible)
* Put all the transmutation code and format-target-matching code into gdkselection-win32.c,
now this code isn't spread across multiple files.
* Consequently, moved some code away from gdkproperty-win32.c and gdkdnd-win32.c
* Extensive format transmutation checks for OLE2 DnD and clipboard.
We now keep track of which format mappings are for transmutations,
and which aren't (for example, when formats are passed as-is, or when
a registered name is just an alias)
* Put transmutation code into separate functions
* Ensure that drop target keeps a format->target map for supported formats,
this is useful when selection_convert() is called, as it only receives a
single target and no hints on the format from which the data should
be transmuted into this target.
* Add clear_targets() on W32, to de called by GTK
* Use g_set_object() instead of g_ref_object() where it is allowed.
* Fix indentation (and convert tabs to spaces), remove unused variables
https://bugzilla.gnome.org/show_bug.cgi?id=786509
application/x-rootwindow-drop is not useful anywhere else,
so put it under #ifdef GDK_WINDOWING_X11
On W32 this prevents toplevels from automatically becoming valid
drop targets with a useless drop type.
https://bugzilla.gnome.org/show_bug.cgi?id=786509
Similar to GtkEntry, add an "Insert Emoji" context
menu item, and add the same keybindings. We don't
add the icon here, since it is not clear where it
would go.
https://bugzilla.gnome.org/show_bug.cgi?id=790029
Add Since annotations for the stock-* properties.
Add a doc comment for :stock-size in order to link to GtkIconSize.
Document :stock-detail as deprecated. It does nothing & is gone in GTK+4
Whereever we handle long-press for touch, it makes sense to handle
right-click as a faster alternative for mouse-based interaction.
This commit makes right-click work to bring up the variation
selector for Emojis.
g_resources_enumerate_children expects the path to end
in a '/' (even though thats not stated in the docs), and
will copy it if that isn't the case. Avoid the copy
by putting a '/' there to begin with.
g_resources_enumerate_children expects the path to end
in a '/' (even though thats not stated in the docs), and
will copy it if that isn't the case. Avoid the copy
by putting a '/' there to begin with.
It wasn't taking into account whether the sidebar had support for them
or not, resulting in a file chooser with open in new tab/window menu
items when it's not supported.
To fix it, do as with the other menus and check for the availability of
new tab/window flags.
https://bugzilla.gnome.org/show_bug.cgi?id=786123
To avoid copying data from gresources to the heap, we can use
the newly added gtk_file_load_bytes(). That function will check
for resource:// URIs and access their internal data directly.
Other URI schemes will read the contents into memory and return
a GBytes as normal.
https://bugzilla.gnome.org/show_bug.cgi?id=790270
When the duration is set to 0, clamp it to 1us. This way we're almost
correct: We should really instantly finish, but we don't. But we do
respect the delay.
Doing this properly would require some refactoring of how the progress
tracker actually maintains progress, and this is just a quick fix.
commit 475d916eb9 added various paths that
use theme-name for this, but the existing path already used THEME, with
a subsequent description referring to the latter. So use that everywhere
