This commit toggles the big switch. We now don't run size_allocate()
from the toplevel up anymore in cases where we don't need to.
Things might be broken in subtle ways as a result of this commit. We'll
have to find them and fix them.
Widgets that already have a resize queued don't need to walk the whole
parent chain and queue another resize. It's enough to do it once per
resize.
This also means that sizegroups cannot use the shortcut of just
invalidating the first widget in the group anymore. That widget might
already have a resize queued while others don't.
This happens way too much, so it's disabled unless GTK_DEBUG=geometry is
on.
Also, we can't detect it in the call to queue_resize() yet, only during
size_allocate(), so the warning comes after the signal emission.
... and API to set and unset it.
It is set when gtk_widget_queue_resize() is called.
It is unset when gtk_widget_get_preferred_width/height() is called.
So far it is not used.
Before this commit, a widget tree like this:
Window
AnyContainer (part of SizeGroup1)
GtkClutterEmbed
SomeWidget
when calling gtk_widget_queue_resize(SomeWidget), would invalidate
SizeGroup1, when it should have stopped at the GtkClutterEmbed (which is
a RESIZE_IMMEDIATE child).
This is so widgets can queue a rerun of their allocation logic, but
without triggering resizes everywhere.
For now, it just calls gtk_widget_queue_resize().
Ignore the geometry widget passed to gtk_window_set_geometry_hints().
Usind the widget itself was a hack that complicates the size request
machinery.
It is also incorrect in that it doesn't respect height-for-width.
Last but not least, it was only used by gnome-terminal and that
application can easily work without it.
And remove the API to set that variable.
If you want the entry to not fill its whole allocated area,
gtk_widget_set_valign (entry, GTK_ALIGN_FILL);
will give you the old behavior.
Passing GTK_ICON_LOOKUP_GENERIC_FALLBACK to the icon lookup doesn't work
for GIcons, so we have to make sure we use the right GThemedIcon.
Fixes image-icon-name-use-fallback reftest.
After figuring out what the actual problem is, name the reftest
properly.
The actual problem is that the use-fallback property is ignored when
using an icon-name on GtkImage.
Fallback seems to be working in the GtkIconTheme test suite, but fails
in GtkImage itself.
This is a test for a bug in the Bluetooth settings. An icon named
"phone-apple-iphone" should fallback to "phone" if the
gnome-icon-theme-extras package isn't installed.
If the shared context is in legacy mode, or if the creation of a core
profile context failed, we fall back to an EGL context in compatibility
mode.
Since we're relying on a fairly new EGL implementation for Wayland, we
don't fall back to the older EGL API, and instead we always require the
EGL_KHR_create_context extension.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
If GLX has support for the GLX_ARB_create_context_profile extension,
then we use the GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB; if it does
not, we fall back to the old glXCreateNewContext() API.
We use the shared GdkGLContext to decide whether the GLX context should
use the legacy bit or not.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
If we're using modern GLSL, then we should stop using deprecated
modifiers, like 'varying' and 'attribute', as well as deprecated global
variables, like 'gl_FragColor'.
On the other hand, with legacy contexts we should be using older GLSL
shaders, to maximize compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
We want to have the ability to fall back to legacy GL contexts when
creating them. In order to do so, we need to store the legacy bit on the
GdkGLContext, as well as being able to query it.
Setting the legacy bit from outside GDK is not possible; we cannot
create GL contexts in 3.2 core profile *and* compatibility modes at the
same time, and if we allowed users to select the legacy mode themselves,
it would break the creation of the GdkWindow's paint GL context.
What we do allow is falling back to legacy GL context if the platform
does not support 3.2 core profiles — for instance, on older GPUs or
inside virtualized environments.
We are also going to use the legacy bit internally, to choose which GL
API we can use when drawing GL content.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
If the last tag toggle is the end iter, the function returned the wrong
tag toggle.
This resulted in some bugs where the view wasn't relayout/redrawn
correctly.
The function also always returned TRUE, probably because the return
value is used nowhere. But for consistency with
_gtk_text_btree_get_iter_at_first_toggle(), it's better to keep the
return value, and also because otherwise the function would be wrong (it
doesn't always return a tag toggle, if there is none).
https://bugzilla.gnome.org/show_bug.cgi?id=755413
keyboard_handle_leave() might be called with a NULL surface resource
(for example if the surface was destroyed after the event was sent). If
so, we should still deal with the keyboard focus lost event, otherwise
we will both leak (the keyboard_focus GdkWindow reference) and miss
stopping the key repeat timer.
https://bugzilla.gnome.org/show_bug.cgi?id=755927
_gtk_accessibility_init() only gets called if the default
display changes, but in case gdk_init() is called before gtk_init()
the default display is already set and no property notification occurs.
This can happen quite easily in pygobject where
"from gi.repository import Gdk, Gtk"
will call gdk_init() followed by gtk_init() in the Python overrides.
This fixes it by checking for a default display in all cases.
Removing pages from the assistant with gtk_widget_destroy() used
to work. It broke with the recent interposition of a box between
each page and the notebook. Fix this by cleaning up when the box
child is removed.
https://bugzilla.gnome.org/show_bug.cgi?id=756042
In fact there were two issues:
1. GtkFlowBoxChild with "can-focus"==FALSE should pass the focus
to its child immediately.
2. GtkFlowBox with "can-focus"==FALSE should cease its custom keynav
implementation and fall back to the default GtkContainer behavior
which is more natural.
Thanks to these changes the flow box can act as a better replacement
for GtkGrid and similar containers.
https://bugzilla.gnome.org/show_bug.cgi?id=753371
Replace checking if the NSView is really a GdkWindow, which will crash
in the likely event it's not a GObject, with ensuring that the parent
GdkWindow is really a GdkWindowQuartz.
Move focus to list when search results appear to make it
possible to select the first search result by just hitting
Enter. To keep this from interfering with keynav, we need
to make sure that we still handle Escape to search. And when
search comes up empty, we need to move the focus back to the
entry.
https://bugzilla.gnome.org/show_bug.cgi?id=755926
The stack calls gtk_widget_grab_focus on the last focus widget,
which selects the text in the entry, so we need to make sure to
move the focus there first to keep that from happening.
https://bugzilla.gnome.org/show_bug.cgi?id=755931
Once a window is maximized/fullscreen, resize increments should be
ignored otherwise the window may appear smaller than the screen size.
That also applies to configure requests as well.
https://bugzilla.gnome.org/show_bug.cgi?id=751368
We were calling gtk_container_should_propagate_draw
twice for each child. We can avoid this by splitting
out an gtk_container_propagate_draw_internal function.
Almost all callers of _gtk_widget_draw already did their own
cairo_save/restore, so drop the save/restore calls inside
_gtk_widget_draw and instead fix the last caller, gtk_widget_draw,
to do the same.
Call gtk_popover_update_position instead which will pick up the new
transition_diff value and pass it on to
_gtk_window_set_popover_position, which in turn will move the window
correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=755435
Check whether the given popover even changed size in
_gtk_window_set_popover_position. If not, just move its GdkWindow
without calling gtk_widget_queue_resize. Using popover_get_rect here is
still relatively costly, but popover_size_allocate would be doing that
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=755435
We can use gdk_window_peek_children here, instead of copying
the list. Note that we preserve the bottom-to-top ordering by
iterating the list from the end.
gdk_window_get_children_with_user_data was doing a list
reversal while filtering the list.
The string we were using is the representation of the internal text
in the popover entry. However that can be freed before setting the
bookmark label, if i.e. the row is destroyed and therefore the popover
as well.
To avoid that, duplicate the label in a local variable.
One of the consequences is that for those people using development version
we migth screwed its bookmarks file, since the bookmark manager wrote
garbage from the already freed label.
https://bugzilla.gnome.org/show_bug.cgi?id=755215
Update the notes that this is also used for Visual Studio 2015 support,
and correct the MSVC_VER_LONG for MSVC 2015, which is 14, not 2015.
Also add a note that this can be used for other projects that have
Visual Studio build support.
We are passing widget coordinates to gtk_text_view_window_to_buffer_coords()
which expects coordinates to be relative to the text window in this case.
This may result in drop coordinates being displaced if the side windows to
the top/left sides are visible and taking space, so the DnD indicator will
point to the wrong position.
This can be seen on gnome-builder and gedit when displaying line numbers.
Some distributions (MSYS2, Debian) call autoreconf on a tarball because
they change the autotools artifacts.
In order to rebuild the Broadway generated files, we need to ship the
scripts that we use when disting a release.
The row and rename popovers are always relative_to a row.
We also keep a pointer to them so we can interact with them in
callbacks.
However, if the row is destroyed its associated popovers will be
destroyed as well as relative_to destroyes and frees memory of its
associated widget when its relative_to widget is destroyed.
If we, for example, update the places while the popover is shown we are
going to access and invalid widget on the next time.
To avoid that, connect to the destroy signal of the popovers and clean
the sidebar pointers when that happens.
https://bugzilla.gnome.org/show_bug.cgi?id=755444
The patch did not check for Visual Studio 2008 correctly, plus it
would break the build on later Visual Studio versions, as it should
be __popcnt(), not __popcount(). Fix that.
The popcount builtin was added in GCC after version 4.2 (which is what
some *BSDs are using), which means we need to be more specific when
using it than just asking for GCC.
While we're at it, we can improve the compiler detection, and use a
builtin popcount on Clang ≥ 3.1 and MSVC 2008.
https://bugzilla.gnome.org/show_bug.cgi?id=755455
Instead of handling the horizontal and vertical peers separately
(and often, duplicatively), collect all peers in one go. At the
same time, avoid creating and destroying hash tables more often
than necessary.
The recent changes to build/win32/vs9|10/Makefile.am fixed 'make distclean'
but broke 'make -jN dist', so fix that by listing the *.headers and using
that list as a dependency and to remove those files in one single command
right after we generate the gtk-install.vsprops template, so that we don't
have to worry about them in 'make distclean'.
At the time we populate the model "initially" in constructed(),
it has already been filled and cleared a couple of times (we do
that every time one of the construct properties gets set). So
we can't assume that the model is empty, and have to clear it
first. Otherwise, we add duplicates to the list.
https://bugzilla.gnome.org/show_bug.cgi?id=748080
Plug and Socket require X11 windowing. Often times this is compiled
on systems with both wayland and x11, but not always. Quartz is an
example where it is usually not compiled.
GTK cannot depend on libcanberra-gtk which depends on GTK. This causes
a circular dependency and is especially neat if installed GTK is
different enough from uninstalled GTK.
The default event bubbling paths are prone to just running event controllers
even after the widget was potentially unrealized/destroyed in an event
handler callback, so bail out early if that's the case.
https://bugzilla.gnome.org/show_bug.cgi?id=755352
To GtkGesture machinery, if an event triggers a controller/gesture signal,
and gesture reset/cancellation as a result, the event has been managed
after all.
Commit e3bd895667 effectively changed the return value of the
wrapping gtk_event_controller_handle_event() function, which broke some
paths (eg. gtk_popover_button_press() wouldn't while the GTK+ grab was
active for this reason because the button press event was consumed early
on gtk_window_check_handle_wm_event()).
That patch is not too off-track given potential child widgets' behavior,
we want nonetheless to distinguish the denied vs cancelled paths here
(because GtkWindow itself relies on the GtkGesture behavior described in
the first paragraph on the begin_move/resize paths), so just reset
gestures after the event has already gone through the GtkEventController
so the return value is unaffected.
This updates the Visual Studio Project GUIDs so that they don't repeat with
the GTK+-2.24.x ones, as the 3.x projects can be used with the 2.24.x in a
all-in-one solution file (such as when one wants to use a complete GTK+2
and GTK+3 stack when porting Windows applications from GTK+2 to GTK+3), and
each project in a solution file is expected to have an unique GUID.
Traditionally a sequence is set to GTK_EVENT_SEQUENCE_DENIED state when
it is to be ignored, which means it is dormant, but still managed by the
gesture (accounting, "denied" sequences still make "slots" in multitouch
gesture busy, etc...).
This gesture will run for all button presses and releases in the window
though when presses happen on the "window content" region, and we can't
account for every children to be as educated as setting the proper mask
on every window, or ensuring events will be propagated as they should.
In order to cater for this, just reset the gestures, we can live without
such accounting in these specific GtkGestureSingle gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
We do not know what happened to this surface outside of GDK.
Especially for foreign windows, they will have been modified
by external applications.
So be on the safe side and tell Cairo to clear all its caches.
https://bugzilla.gnome.org/show_bug.cgi?id=754952
Instead of using a fixed size, use a factor of the surface size. This
helps in situations where animations of surrounding widgets are used
and cause a rapid rate of surface destroy/create cycles.
gdk_wayland_device_update_window_cursor() is inconsistently returning
TRUE/FALSE, despite the timeout being always replaced for new cursor
frames. This could end up in these timeouts being "leaked" and running
as long as the window has an animated cursor.
Fix this by making it really sure we return G_SOURCE_REMOVE, although
now we keep track of animation delays, so the timeout will be reused
for constant time animations.
It makes no sense to skip denied sequences here, the gestures are
still carrying out the accounting for these, which must be also put
to an end if we're possibly not receiving any further events from
this sequence.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
At the time event_check_cancel_sequence_on_hierarchy() is called, the widget
has been already unparented. Given the widget itself is being destroyed,
cancellation on it is impending in one way or another, we still must
propagate cancellation across all parents, so retrieve it early before
possible widget destruction.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
Otherwise it's attempted through a timeout, which gets cancelled early after,
and the slider disappears after a while with no mouse activity despite the
ongoing implicit grab.
Once the grab is finished, check_update_scrollbar_proximity() will be called
again on both scrollbars, and the fade out animation will be triggered as a
result.
https://bugzilla.gnome.org/show_bug.cgi?id=754745
When right-clicking in an empty folder, you should get a context
menu, not a crash. The code for positioning the popover was not
handling the eventuality of no row under the pointer. Just position
the popover right at the click location in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=755021
A lot of time was spend rendering the shadows on windows with CSD, in
particular the corner pieces, since they are the largest parts. This
patch catches this particular case and caches the pre-rendered blur
masks.
This makes the shadow code go from 25% to 8% of the time when resizing
gtk3-demo.
"Add" Visual Studio 2015 projects by what we did before: Copy the Visual
Studio 2010 project files and replace the items in there as needed, as
the formats of the 2010 and 2015 projects are largely the same.
We need to rename the projects so that when these projects are added
into an all-in-one solution file that will build the GTK+ 2/3 stack,
the names of the projects will not collide with the GTK+-2.x ones,
especially as GTK+-2.x and GTK+-3.x are done to co-exist on the same
system. This is due to the case that the MSVC projects are directly
carried over from the GTK+-2.x ones and was then updated for 3.x.
We still need to update the GUIDs of the projects, so that they won't
conflict with the GTK+-2.x ones.
Use the common automake module from the previous commit in the
Makefile.am's, which means that the Makefile.am's in gdk/ and gtk/ can be
cleaned up as a result. As a side effect, the property sheet that is used
to "install" the build results and headers can now be generated in terms of
the listing of headers to copy during 'make dist', where we can acquire
most of the list of headers to "install", so that we can largely avoid the
situation where the property sheet files are not updated in time for this,
causing missing headers when this build of GTK+ is being used.
Also use the Visual Studio Project file generation for the following
projects:
gtk3-demo
gtk3-demo-application
gtk3-icon-browser
gdk-win32
gdk-broadway
gail-util
So that the maintenace of these project files can be simplified as well.
https://bugzilla.gnome.org/show_bug.cgi?id=681965
This adds a common autotools module that can be used by various projects to
generate the Visual Studio projects as needed, and if necessary, generate
the headers listings to "install" for that project, based on items passed
in to this. This is modeled on the Makefile.introspection autotools file
that is used by many GNOME projects to generate the introspection files.
https://bugzilla.gnome.org/show_bug.cgi?id=681965
Initially the subsurface will be in synchronized mode and we will leave
it like this until the first time the parent surface has been committed.
The reason for this is because the subsurface position will be applied
as part of the parent surface state, and we need to synchronize the
initial position with the initial frame, so that we don't accidentally
draw the subsurface at the default position (0, 0) which would happen in
desynchronized mode if the subsurface content is committed before the
next parent surface commit.
https://bugzilla.gnome.org/show_bug.cgi?id=754839
The GtkEventController event mask is private, and set early by GtkGesture
implementations. Being this private data, there is no corresponding
property, so this code is a no-op, there is just no need to listen to
changes there.
We use to rely on grab broken events for most of the event sequence
lifetime, this breaks though on GDK_BUTTON_RELEASE/GDK_TOUCH_END, as there's
no longer a grab at that time.
For these cases (and all others where there's destroy/unrealize calls
involved during event dispatching), catch this on the late
WIDGET_REALIZED_FOR_EVENT calls on widget event handling functions.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
This avoids a lot of overhead in the common case where a signal
is not connected and we're just using the class vfunc (which is true
for all in-libgtk widgets). Additionally it makes backtraces in
debuggers and profiles much much nicer to look at.
https://bugzilla.gnome.org/show_bug.cgi?id=754986
These days exposure happens only on the native windows (generally the
toplevel window) and is propagated down recursively. The expose event
is only useful for backwards compat, and in fact, for double buffered
widgets we totally ignore the event (and non-double buffering breaks
on wayland).
So, by not setting the mask we avoid emitting these events and then
later ignoring them.
We still keep it on eventbox, fixed and layout as these are used
in weird ways that want backwards compat.
There is no need to ref the windows we're ignoring, so collect and ref
only the affected child windows. Also, use a on-stack array rather
than allocating a linked list.
Also, we don't need to ref during the event emissions too, as we
already hold a ref.
https://bugzilla.gnome.org/show_bug.cgi?id=754687
It turns out that xgettext does not understand translatable="1",
so don't make gtk-builder-tool produce this, even though
GtkBuilder can parse it just fine.
https://bugzilla.gnome.org/show_bug.cgi?id=754928
This changes textview to share the style context with the pixelcache.
Doing so allows pixel cache to optimize the surface creation and use
a CAIRO_CONTENT_COLOR instead of CAIRO_CONTENT_COLOR_ALPHA when
appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=754658
We can take a fast path if the background for a widget is opaque by using
a CAIRO_CONTENT_COLOR instead of a CAIRO_CONTENT_COLOR_ALPHA surface. Most
blit'ing backends have a fast path for this, including Pixman and Quartz.
https://bugzilla.gnome.org/show_bug.cgi?id=754658
This new private API, _gtk_style_context_is_background_opaque(), is meant to
be used by internal Gtk+ wigets to optimize fast paths for cases where
applicable. One such use would be to use a CAIRO_CONTENT_COLOR surface
instead of CAIRO_CONTENT_COLOR_ALPHA.
https://bugzilla.gnome.org/show_bug.cgi?id=754658
This avoids a bunch of allocations, and additionally it has better
cache behaviour, as we don't follow pointers to the separate GList
node memory areas during traversal.
From Christian Hergert:
This machine is a Retina mac book pro so I've been working on getting
GtkTextView (GtkPixelCache) up to our performance level on
X11/Wayland. I'm seeing a jump from about 43 FPS to about 50 FPS.
https://bugzilla.gnome.org/show_bug.cgi?id=754687
Merge it into GtkWidgetPrivate. In my measurements, about half
of all widgets have a non-default auxinfo struct, and we use this
information in size allocation, so it is nice to avoid the gdata
overhead.
We only use widget paths for a few widgets nowadays (notebook,
treeview, pathbar, combobox), so we can save some space by
not having this field in GtkWidgetPrivate.
The hash table is only accessed at creation and destruction time,
and many widgets don't use templates at all, so no need to have
this permanently occupying space.
This reverts commit 3eacfa88f2.
Apart from the patch not being correct, we don't want to expose private
structures in header files if we can avoid it.
And this type-checking overhead is not an optimization that is even
measurable.
https://bugzilla.gnome.org/show_bug.cgi?id=754932
Statistics for the gtk3-demo listbox example show that the
vast majority of calls to _gtk_allocated_bitmask_resize go
from a size of 2 to 2. Don't needlessly call realloc() in
this case.
The previous code was crashing when used as the returned classes array
would have been invalid after the first deletion. So if a 2nd class
would be deleted, invalid memory might have been referenced.
In order to retrieve the user options for a printer, the respective
printer name is used.
This fixes the comparison of printer names to avoid that the options of
another printer are accidently read whose name starts with the same
letters, but is longer (e.g. "myprinterlongername" instead of
"myprinter").
This fixes Bug 753628.
This function is getting called a lot. Statistics for the gtk3-demo
listbox example show most calls with 0-4 classes. Unrolling the cases
a bit brings the instruction count in callgrind from 93M to 52M.
The same trick that was applied to _gtk_css_change_for_child in
the previous commit can be applied to _gtk_css_change_for_sibling
as well, and that is what this commit does.
With both functions converted, gtk_css_change_translate is no
longer needed and gets dropped.
The function to translate GtkCssChange enum values to the PARENT
ones is called very frequently. This patch speeds it up tremendously.
The callgrind instruction count for this function in the listbox
demo goes from 108M to 7M.
My statistics show that more than half of all calls end up
with 0 matches, so we can avoid some overhead by not allocating
an array at all in this case.
We are dealing with really short lists here.
95% are < 10 matches, and the longest I've been able to record was 19.
So just do away with the hash table and do sorted insertion in
the array directly.
Otherwise the outer loop control variable is messed up, and we end
up with uninitialized axes if there were any more valuators after
the XIKeyClass one.
This bug was sneakily introduced by fdb9a8e14, many thanks to
Carlos Soriano for helping spot the source of this bug.
https://bugzilla.gnome.org/show_bug.cgi?id=753431
The logic here is that G_ENABLE_DEBUG is for compiling out
debug spew that can be triggered at runtime with the GTK_DEBUG
environment variable, while G_ENABLE_CONSISTENCY_CHECKS is for
consistency checks that are applied unconditionally.
Use a separate G_ENABLE_CONSISTENCY_CHECKS define to guard internal
consistency checks that are applied unconditionally if they are enabled,
such as the widget invariants checking. Interactive debug spew that can
be triggered at runtime with the GTK_DEBUG environment variable is still
guarded by the G_ENABLE_DEBUG define.
The mapping from enable-debug levels to defines is as follows:
yes: G_ENABLE_DEBUG G_ENABLE_CONSISTENCY_CHECKS
minimum: G_ENABLE_DEBUG G_DISABLE_CAST_CHECKS
no: G_DISABLE_CAST_CHECKS G_DISABLE_ASSERT G_DISABLE_CHECKS
The speed-up in 7da1f8a1ce was wrong in
certain conditions, even though it didn't trigger the existing
testsuite.
New testcase /bitmask/invert_range_hardcoded included.
Add a --run option which takes the name of an example and
launches it. Also add a --autoquit option which can be used
to quit after a given number of seconds.
If we are using gl for drawing, we don't have a shm surface,
so don't assert that we do. Instead, only call shm-specific
apis when they make sense.
This fixes a crash when showing popovers over a GtkGLArea,
as seen in gdkgears.
https://bugzilla.gnome.org/show_bug.cgi?id=754143
Instead, inherit style from toplevel (because that's the default way,
not because it makes lots of sense).
This way, popovers don't inherit the styling from the widget that popped
them up, which is a problem in selected listbox rows, selection-mode
headerbars.
It also doesn't inherit styling where we might want it, like the osd.
But we can only have one of the two things.
- reshuffled the stylesheet to easily allow having a thicker
border, but decided to keep the 1px borders on entries
as it makes easier to spot the buttons despite being flat.
https://bugzilla.gnome.org/show_bug.cgi?id=753129
If the position of the children is always relative to the box
then we should not take the allocation of the box into account
when flipping the children for RTL text direction.
This patch also removes unused assignments to child_allocation.
https://bugzilla.gnome.org/show_bug.cgi?id=754559
Same as we did for the entry in the previous commit.
Previously, we just hid the cursor if a key event was adding text,
but not when you used backspace, or Ctrl-V. Rearrange things so that
we obscure the cursor whenever the buffer contents change while we
are handling key events.
https://bugzilla.gnome.org/show_bug.cgi?id=754535
Previously, we just hid the cursor if a key event was adding text,
but not when you used backspace, or Ctrl-V. Rearrange things so that
we obscure the cursor whenever the buffer contents change while we
are handling key events.
https://bugzilla.gnome.org/show_bug.cgi?id=754535
When the places view is finalized before the network loading
is finished, the async operation is cancelled, and the callback
accesses the places view while it is already in a state of
disrepair. Avoid that access.
When receiving a selection or when a drag icon enter a window, it was
targeted at a specific window. Lets emit the GDK_OWNER_CHANGE event
only for this window, instead of broadcasting.
Broadcasting has some nasty side effects. For example, if there was n
GdkWindows, and one would for every "owner-change" signal handler
receive n signals about the owner being changed.
An example of where this went a bit out of hand was gnome-terminal,
which added one listener per terminal window. This meant that if
one had m number of terminal windows, each time any one would loose or
gain keyboard focus, O(m^2) owner-change events would be emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=754158
The purpose of this patch is to fix regressions in GtkTextView
scroll behaviours due to commit d138156.
( addition of padding and margins to the view )
Adding some padding is done by, for example, in inspector css tab with:
GtkTextView {
padding: 10px 10px 10px 10px;
}
and adding margins, by changing one of *-margin properties
( * standing for left/right/top/bottom ) or the corresponding
accessor functions.
Understand that none of these bugs are easy to trigger.
What's happened is that a old and wrong version of the code of the code
( lost in the mean time ) was pushed.
These bugs are best seen with wrap mode set to off.
The commit 8baab8f fix a first regression.
This one is about:
- Cursor going out of the view at line ends instead of being visible
or triggering the horizontal scroll.
- Padding not displayed correctly
when moving cursor at beginning/end of lines
- When horizontal scroll position not at left, cursor can make scroll
by more than one character (you need left padding to see this )
- Moving the cursor arround, the rendered text can be shitted in x or y.
( fixed by converting adjustment float values
to integer before calculations )
It can be observed by going down with the cursor more
than the view height then going up
- retval return value of _gtk_text_view_scroll_to_iter wrong in some cases
In addition, this patch re-factor priv->top_border
in screen_dest.y calculation
Of course, all GtkTextView and GtkSourceView based app were impacted
by these bugs ( gedit for example, see bug 754147 )
https://bugzilla.gnome.org/show_bug.cgi?id=753815https://bugzilla.gnome.org/show_bug.cgi?id=75815
This is a 'developer mode' feature, and it can and does interfere
with preexisting key bindings in some applications, so keep it
off by default in stable releases, at least.
http://bugzilla.gnome.org/show_bug.cgi?id=754115
Until now the code was not very clear about why the loading property is
needed, since we didn't forced all the async operations to mark the
view as loading. This cause that clients are not aware when the view
is busy on those situations.
For instance Nautilus uses the property for a few things, one of it
is to show a busy spinner on the tab title.
To improve the situation, mark as loading when a volume operation,
a mount operation or a connect to server operation is being performed.
https://bugzilla.gnome.org/show_bug.cgi?id=754150
We are showing a GtkSpinner on the networks header to provide feedback
to the user if we are fetching networks, therefore we have to modify
the spinner state when doing it.
However GtkListBox doesn't give guarantees about the widgets
set by gtk_list_box_set_header, and we could access an invalid
widget.
To avoid to access invalid widgets, bind the fetching networks
view property to the networks header spinner active property instead
of modifying directly the spinner in the private structure.
Not having the spinner in the private structure also makes the code
cleaner.
https://bugzilla.gnome.org/show_bug.cgi?id=754150
We were filtering out placeholders if the list box filters
while not searching, which is not what we want, since placeholders
should only be hidden if the view is searching.
https://bugzilla.gnome.org/show_bug.cgi?id=754150
The application demo had a "Blue" and a "Bold" menuitem both with
the Ctrl-B accel. This is confusing, since only one of them works.
Change the accelerator for bold to Ctrl-Shift-B, so they both work.
Make this function harmless to call without an open display connection.
This happens during gobject introspection, which instantiates GTK+
types without calling gtk_init.
It needs to open a display connection, which is obviously going to fail
miserably on any headless build machine.
Instead, we need to find where we started requiring to initialize GTK
when calling a get_type() function, and stop doing that.
This commit and commit 15cc85db29 fully
revert commit 6838861d26.
GCC will not do the right thing, and it will just break the build when
trying to include gtk.h first.
We'll have to live with the warning from the compiler about a missing
gtk_init() — though it would be better not to have to init GTK at all to
generate the introspection data.
This commit unbreaks the build in GNOME Continuous introduced by commit
6838861d26.
Having these extra spaces in the accel string is a bit awkward,
since they will be included in text decorations such as underlines.
Removing them has no visible effect.
Calling our get_type functions without prior gtk_init() is not ok,
and causes warnings now. Avoid that by teaching g-ir-scanner to
put a gtk_init() call into its generated code.
Otherwise, we end up using different metaphors in the place view
and in the sidebar, and nobody is going to know what the disconnect
icon means in this context.
http://bugzilla.gnome.org/show_bug.cgi?id=754022
The code in _gdk_wayland_window_dispose was not safe against
being called twice - it would call g_hash_table_destroy twice
on the known_globals hash table, the second time operating on
freed memory. It was also leaking the list of async_roundtrips.
After fixing both of these issues, the displayclose testcase
now works on Wayland.
We call gdk_wayland_window_hide_surface when the window gets
destroyed, and in this case, the frame clock might not exist
anymore.
This was showing up in the displayclose testcase.
While we do not have subwindows in Wayland, we do create an
artificial root window. When the display is closed, the root
window gets destroyed, causing recursing to be true for the
toplevel windows.
Since being 'activatable' istead of 'button' now that reset
is not needed anymore, the patch is pretty noisy since sass
interpreter changes, those look innocuous though.
A * selector applies to all widgets, so even GtkBox or GtkGrid - and
most importantly GtkListBoxRow - need to recompute their style because
of the * selector.
By using a more specific one, these common cases aren't affected
anymore.
Fixes slowdowns in gtk3-demo's listbox demo and in gnome-software.
That way, the GTK engine doesn't think that the general .button CSS
might potentially apply to it.
And because combobox button is overly complex and stupid, it cannot be
cached.
So buttons thought they cannot ever cache anything because they might
suddenly end up inside a combobox without noticing and then they'd need
to round their corners differently. Of course they're just regular
"Remove" buttons like all the other 100s of "Remove" buttons in
gnome-software. But hey, better not cache anything for them and
recompute their CSS every time the :hover state changes on one of the
rows.
We can actually share :first-child/:last-child related things now,
because we special case them. So the only positions we cannot cache are
nth-child/nth-last-child.
This should take care of a lot of Adwaita's styling.
This example populates a flow box with buttons, and makes the
flow box children unfocusable, with the intention that the focus
moves directly between the buttons. Currently, keynav does not
work at all in this case.
This way, we can live without row references.
A side effect is that opening the inspector on the gtk-demo list box
example now only takes 0.5s instead of the previous 3 minutes.
Instead of queueing a new idle handler every time we call
gtk_window_update_debugging(), only queue one if none is queued that.
Saves a lot of work, in particular when templates create context menus
for every row in a large listbox as in the gtk-demo listbox example.
Do not use .button anymore.
This is for 2 reasons:
1. The styling is seperate in our themes, so it doesn't make sense to
share the style class.
2. Due to the shared styling of .buton, listbox rows inherit all the
special case styles that exist for buttons - such as linked buttons,
header buttons, entry buttons, spinbutton buttons, etc. This means
that the code has to check all these special cases all the time and
for listbox rows, this is very slow.
Defer a11y initialization until we have a display. A11y initialization
causes widget classes to be initalized, which in turn needs some
backend-specific information about modifier masks that can't be
obtained before we have a display.
https://bugzilla.gnome.org/show_bug.cgi?id=736125
Add all 388 tweets of the @GTKtoolkit account. This shows the
performance behavior of the listbox (not good with that many rows) and
allows us to quickly notice when things get worse (or better).
And just so I have a place where I can dump how I generated this file:
First, I got Timm Bäder to download me the json for the twitter feed
into a file gtk.json, then I ran the jq tool on it like this:
jq ".[] | if .retweeted_status then .retweeted_status.user.name + \"|\"
+ .retweeted_status.user.screen_name else .user.name + \"|\" +
.user.screen_name end + \"|\" + .text" gtk.json | cat -n | sed
"s/\\s*\([0-9]*\)\t\"\(.*\)\"/\\1|\\2/" > messages.start
jq ".[] | .created_at" gtk.json | sed "s/\"\(.*\)\"/\1/" | while read
in; do date +%s -d "$in"; done > dates
jq ".[] | \"0|\" + if .retweeted_status then .user.screen_name else \"\"
end + \"|\" + (.favorite_count | tostring) + \"|\" + (.retweet_count |
tostring)" gtk.json | sed "s/\"\(.*\)\"/\\1/" > messages.end
paste -d\| messages.start dates messages.end > messages.txt
This whole machinery of going through 3 intermediate files was only
necessary to onvert the dates from ISO format to unix timestamps,
otherwise this could have been a single line.
If we manually enter an unaccessible path in the entry, e.g
"/root/foo.txt", we should receive an error saying that the
folder is not accessible instead of showing the replace
confirmation dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=753969
Previously we were assuming that only list box rows could occur
as focus children of a list box, and would crash if that wasn't
the case. This commit handles this case, and integrates focusable
headers into directional keynav and the focus chain.
The typical case of using separators as headers is not affected
by this change.
https://bugzilla.gnome.org/show_bug.cgi?id=753694
State that the overlays are placed wrt to the GtkOverlay, not
with respect to the main widget. This makes a difference for
small main widgets which are not configured to fill the entire
GtkOverlay.
When an operation is cancelled it's never safe to access
the object itself or the private struct, since it could be
called (and probably is) during finalize.
In case the operation is cancelled, just bail out to fix
the crashes.
Add a spinner when networks are being fetched and make
the network section permanent and show a placeholder with
a message that no networks were found in case there are no
networks. In this way users from previous versions won't be
confused with the fact that no networks are shown.
https://bugzilla.gnome.org/show_bug.cgi?id=753786
Previously we had a network item in the sidebar, which now
is replaced by the network section on other-locations view.
However we were not exposing the networks in network:///.
Fetch them and add them in the network section of other-locations
view.
https://bugzilla.gnome.org/show_bug.cgi?id=753786
As the protocol is still considered unstable (meaning not backward
compatible), we should, as stated in the protocol, only bind the version
advertised is the version we implement.
https://bugzilla.gnome.org/show_bug.cgi?id=753856
Code exists in the wild that calls this function after the widget has
been destroyed (and the pixel cache released). Simply check that the
pixel cache exists to preserve the existing state.
When you move line by line, only padding is
automaticly shown and you need to use Page key to show margin.
This commit also fix cursor going out of the screen bug.
The extra reference will be held from GdkEventPrivate data, so there's
a common place to all events. Without this, events queued after devices/
capabilities disappear (eg. on TTY switch) might hold invalid pointers.
Windowing level operations on those devices (queries, grabs...) are
expected to fail at that time, but we should hold meaningful data for
the regular event handling paths.
https://bugzilla.gnome.org/show_bug.cgi?id=753185
In order to play along with child widgets that use scroll events for anything
else than scrolling, it will be better to do this in the bubble phase, so
the child widget has an opportunity to GDK_EVENT_STOP the event before we
trigger kinetic scrolling.
This of course won't work for widgets that choose to reimplement scroll event
handling themselves, they should be smart at resorting to GtkScrolledWindow's
scroll event handling.
This fixes kinetic scrolling kicking in too pervasively on widgets that eg.
implement zoom on scroll events.
https://bugzilla.gnome.org/show_bug.cgi?id=753495
By assigning an URI to Other Locations item, we
can programaticaly select it. Fixes a bug in Nautilus,
where the Other Locations item is unselected imediately
after being clicked.
GtkPrintOperation was emitting paginate only if a signal was
connected, this meant that subclassing and overriding the
paginate vfunc lead to the unexpected result that paginate did
not run.
Instead we always emit the signal and use a custom accumulator:
if there is a signal we just run that and avoid the default
handler, otherwise we run the default handler which can be the
one by the subclass or the default handler that just skips
pagination.
Patch by Yevgen Muntyan, fixes#345345
Prior to this patch, the ID of the GtkApplication was always used for
clients which were GtkApplications. This would only be guaranteed to be
correct for D-Bus activatable programs. As a result, all
non-D-Bus-activatable applications would set the wrong ID making the
shell unable to find the corresponding .desktop file.
This change makes it so that the GDK backend always uses the name
passed to g_set_prgname, or the default value if not explicitly set, as
this more often corresponds to the .desktop file.
This means that in order to make D-Bus activatable applications set the
correct application ID, they must, for now, manually call
g_set_prgname() with their application ID (basename of the .desktop
file).
If g_get_prgname() returns NULL, fallback to gdk_get_program_class()
even though it will most likely never be correct according to the
xdg_surface.set_app_id specification.
https://bugzilla.gnome.org/show_bug.cgi?id=746435
We were not allowing to cancel the operation at all, and at
most the operation was cancelled only when clicked connect again.
Also due to gvfs bug 753735 we actually weren't cancelling
at all, and therefore creating multiple dialogs.
We don't want to leak references if the widget created to represent the
item in the model does not have a floating reference — which is usually
what happens in bindings, as they automatically sink references when
creating new instances.
See commit 6e03e7e8 for the similar change in GtkListBox.
Sorry, the last commit added a generated file instead of the
template.
G-I has been updated to not require a Windows GCC installation
anymore to generate the .gir files, so update the NMake Makefiles
that are used for this purpose.
As a result, it is no longer necessary to define time_t for the .gir
generation as we are on the same compiler throughout the process.
G-I has been updated to not require a Windows GCC installation
anymore to generate the .gir files, so update the NMake Makefiles
that are used for this purpose.
As a result, it is no longer necessary to define time_t for the .gir
generation as we are on the same compiler throughout the process.
GTK+ now uses pango_attr_foreground_alpha_new, pango_attr_background_alpha_new,
PANGO_ATTR_FOREGROUND_ALPHA, PANGO_ATTR_BACKGROUND_ALPHA,
pango_renderer_set_alpha, pango_renderer_get_alpha, which were all added
after 1.37.2.
wl_log() currently logs using G_LOG_LEVEL_ERROR
(which is fatal). The wayland client library doesn't
expect this behavior. It uses wl_log to log recoverable
errors.
This commit changes the log level to G_LOG_LEVEL_DEBUG
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=753635
On wayland, the gestures protocol defines a wl_pointer_gestures global
object, that will match in number with wl_seats, swipe and pinch
interfaces can be obtained from it, which events are translated into
GdkEventTouchpadSwipe/Pinch events.
These will be mutually exclusive with touch events, so it won't
be possible to trigger gestures through mixed input and whatnot.
The accounting of touchpad events is slightly different, there
will be a single internal PointData struct, stored in the hashtable
with the NULL event sequence/key (same than pointer events in
this regard), just that the events stored will be GdkEventTouchpad*,
so will hold information about all fingers at once.
But this difference is just internal, the GtkGesture API doesn't
make explicit assumptions about the number of points (the closest
to a per-point query API is gtk_gesture_get_sequences()). All
signals emitted just contain the last changed GdkEventSequence,
and API takes GdkEventSequences, so everything is consistent with
sequence=NULL for touchpad events.
Along the code, we're basically asking for 1) the total count of
touchpoints, and 2) the number of active touchpoints (not denied
nor ended).
Wrap both usecases into a _gtk_gesture_get_n_physical_touchpoints(),
and replace all occurrences.
The gestures that don't want touchpad gesture events are majority,
even those that want such events will only listen to subsets (eg.
pinch, swipe,...).
So it makes sense to ignore touchpad events by default, and let
subclasses opt those in.
This will be used right before handle_event() in order to filter
out events, useful to make the previous "no touchpad events" behavior
the default, and have gesture subclasses include manually the touchpad
events they handle.
For all other events, we run the bubble phase deep in the specific
::motion/button-press/release/touch handlers.
For touchpad events, it doesn't make sense to use GtkWidgetClass
slots if the intended way to deal with these are gestures, so we
run the bubble phase directly from gtk_widget_event_internal().
Each gesture type has its separate GdkEvent struct, and begin/update/
end/cancel event types.
There is support for multi-finger swipe (3-4 fingers), and 2-finger
rotate/pinch gestures.
Do not call _gtk_icon_helper_clear explicitely when the properties
are set, since the corresponding _gtk_icon_helper_set_* method
already calls clear internally.
While at it rename the reset function to make it clear that it
is calling notify for the previous image type and avoid the
notification if the image type is not changing.
We have a testcolorchooser test, with a --edit option. It was
supposed to make the color chooser come up in edit mode, but
it didn't work ever since we dropped the ::response handler.
Fix it by resetting show-editor on unmap, instead of on map.
This way, users can set show-editor before showing the dialog,
and it will take effect.
Since we're dealing with networks, terms like "Eject" or
the eject button are misleading, since we're not actually
ejecting but disconnecting.
Fix that by showing the appropriate icon and tooltip.
We are not showing the URL of network locations
anymore, since they are distracting and not
necessary.
The code, however, forgot to cleanup the URL,
so we are still showing the URL for network
locations.
Fix that by properly cleanup the URL for network
locations.
The .button:link .label selector matches any label "inside" a
link button. And a label inside the context menu counts as inside
for this purpose. This causes the text-decoration property to
leak into the context menu, even though the property is not
inherited. Avoid this by tightening the selector to
.button:link > .label.
https://bugzilla.gnome.org/show_bug.cgi?id=753451
When we connect to a server, the default and expected
behavior is going to the default location, which usually
is the home directory or a writable directory.
GtkPlacesSidebar behaves properly, while GtkPlacesView
doesn't.
Fix that by jumping to the default locations instead of
the root location.
Don't use gtk_widget_show_all() on row widgets because that would
unconditionally show all of its children. This might be unwanted in case
the row implementation wants to keep some of its children hidden.
This commit changes it to use show() instead of show_all() and relies on
the row widget to control the visibility of its children itself as
appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=753392
GtkFileSystem has a complicated way to handle cancellables.
You keep the cancellable pointer that is returned by
_gtk_file_system_get_info and similar methods so that you can
cancel the operation, but you do not own a reference to it.
The only place where it is ok to unref a cancellable is in
your callback, which gets handed a cancellable that you need
to unref at the end. You are expected to compare it to the
pointer you stashed away to find out if the operation has
already been superseded by a newer call, in which case you
disregard the results.
GtkFileChooserButton was following these rules for most of
the cancellables it keeps around, but it was sometimes unreffing
the cancellables that are stored in the model, which could lead
to refcount confusion and crashes. This commit makes it follow
the rules for that case too, which fixes the crash in the bug
below, and does not show up any leaks in valgrind under light
testing.
https://bugzilla.gnome.org/show_bug.cgi?id=737804
The recent change to the enum declaration for GtkCssChange actually
relied on compiler-dependent behavior, which also breaks the build on
some non-GCC compilers, such as Visual Studio. As noted in the
G_STATIC_ASSERT line just beneath this declaration, we need to change
this enum declaration to #define's, in order to fix the build in such
situations.
https://bugzilla.gnome.org/show_bug.cgi?id=752814
It works just as well here as it does in the file chooser, and
this lets us unify the right-click and long-press behavior a bit.
We used to switch directly to the editor on long-press, now we
can show the popover, just as we do on right-click.
Only a drag context which was created with 'drag_begin' will be
guaranteed to have a source window at all times. Thus, in finalize we
cannot assume we can retrieve a GdkDisplay from the source_window
pointer since it may be NULL. Though, the display is only needed for
contexts created via 'drag_begin' thus we can retrieve it after
checking that is the case.
https://bugzilla.gnome.org/show_bug.cgi?id=749339
This is implicitly done for us in the case of grabs on windows from other
groups, but we must perform this check explicitly for grabs with
owner_events=True on windows from the same group, in that case the window
would handle the events as if there was no grab.
https://bugzilla.gnome.org/show_bug.cgi?id=752327
We need to be mapped to have a gtk_surface and thus be able to do
requests on it so we need to save the modal hint and apply it when we
get mapped so that code that sets the hint before showing a window
doesn't get ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=753138
We only load thumbnails when we find that the row is in the visible
range of the treeview. It seems that animated scrolling makes it so
that the bottommost row stays out of the visible range until it is
too late. To work around this, extend the range by one row in each
direction.
http://bugzilla.gnome.org/show_bug.cgi?id=753142
Properties like transition-property might change when hovering over
something, even if the property itself does not change. These properties
don't affect drawing, so don't queue redraws for them.
Since a lot of Adwaita sets transition: all, it's easy to end up in a
state where we're making dummy transitions for all of the icons, most of
which we'll never be showing.
Interpret a unmodified primary click on the selection like a double
click. This makes it possible to activate a file or open a folder
without using double-click.
The visibility toggling happening on ::click() relied implicitly
on the popover animation, but breaks on disabled animations. The
recursion happening within gtk_toggle_button_set_active() (which
triggers ::clicked when changing state) makes this vfunc to run
again, inverting the visibility of the popover in result.
Fix this by explicitly checking about recursion, we want the
button to be toggled to the right state, but we don't want the
callback running again.
https://bugzilla.gnome.org/show_bug.cgi?id=752577
Instead of putting it inside the button manually, put it there properly
by adding a box containing the cell view and the arrow.
Do the same thing in list mode, instead of creating an event box that
tries to behave as a button.
This is unnecessary - all the recent files are in the model already.
It also leads to duplicates, since our duplicate filtering is based
on g_file_equal, which does not consider recent:///blabla with
target-uri=/my/example to be the same as file:///my/example.
The "Computer" row from places view is an abstract volume
that represents the root of the current partition. As such,
it cannot be mounted or unmounted.
Remove the related item on context menu for Computer row.
We were previously mixing the model used when filtering with an iter that
has been resolved to the backing model.
This results in both an invalid row index as well as an invalid
iter->stamp.
Since we started adding a persistent Computer item,
all the code related to the view modes became obsolete,
since the view is never empty anymore. So, drop this
dead code and use the plain stack to manage the empty
search results view.
Also, this patch fixed a very annoying keyboard navigation
issue where we couldn't go from the On This Computer to Networks
lists, because they were two separate widgets. Merge the two
lists into a single one, and update headers accordingly.
The places sidebar rows' labels were missing a proper
xalign, which caused the labels to keep shaking while
the sidebar was resized.
Fix that by setting the label's xalign to 0.
The GFile containing the Computer item was not
properly dereferenced, so plug that leak by both
dereferencing it and adding some reference management
on GtkPlacesViewRow.
GtkPlacesView widget manages persistent locations,
factoring out GtkPlacesSidebar functionality.
It, however, does not completely shows all sidebar
locations, since Computer is still missing.
Add a Computer item, adjusting some internal behavior
to make that possible.
The doc for gtk_places_view_get_search_query was being
set twice, while gtk_places_view_set_search_query was
never set.
Fix that by correcting the wrong getter documentation.
Use the same explanation of why GtkPlacesSidebar::show-connect-server
was deprecated and its replacements on getter and setter.
Also, fix a mistakenly deprecated function.
When dealing with selection events, we might see windows from
other screens in the requestor field. The current x11 backend
code fails to wrap these in a foreign GdkWindow, since we
don't have the corresponding GdkScreen anymore. Work around
this by creating such 'foreign screens' on demand. We still
maintain the 1:1 relation between the display and the screen
returned by gdk_display_get_default_screen().
https://bugzilla.gnome.org/show_bug.cgi?id=721398
GtkCssProvider was using the wrong unref function for GtkCssKeyframe
objects. Funnily, this didn't crash at all, the refcount was at the
same place in the struct - it just didn't free all the memory, causing
valgrind to complain.
Instead of storing the dnd icon as a pixbuf store it
as a cairo surface and transfer the device scale
when converting it to a NSImage. In the pixbuf/stock/named
setters convert to a surface instead (no hidpi support yet)
The shadow will be drawn in the wrong place in those cases so all we can
do is disable it. This fixes double shadows drawn around menus, popups
and tooltips.
https://bugzilla.gnome.org/show_bug.cgi?id=734984
Previous commits removed from places sidebar the code related
to displaying the Computer item, which should be shown when
the sidebar is not displaying the Other Locations item.
Add back the item when the sidebar is not in Other Locations'
mode.
Make GtkSearchHit carry a GFile instead of an uri. Most of the
search engines already have the object around, and converting
to an uri and back is unnecessary extra work.
Add a helper function that says whether a location should be
considered remote. To determine this, we look at the filesystem
type reported by gvfs, and say 'remote' for sftp, webdav, ftp,
nfs and cifs.
It is a bit pointless to have the file chooser get a uri from an
existing GFile to put in the query, only to have some of the search
engines reconstruct a GFile from it.
It was a special case and it's not used by themes anymore.
Plus, in the CSS world, if a theme wants a separator, it can just
style the button's border to create one.
If a drag ends inside a known window, set the dest_window field
in the drag context. This information is needed to implemented
notebook tab dragging.
https://bugzilla.gnome.org/show_bug.cgi?id=752638
Without properly cleaning up GtkMenu private attach state
(GtkMenuAttachData) when the attached widget is freed, we would end up
with an invalid pointer to a freed widget. Trying to detach from that
widget would cause a segmentation fault.
https://bugzilla.gnome.org/show_bug.cgi?id=752761
-1 means that we have no specific preference for an initial
fullscreen monitor, and -1 is less than the number of monitors,
so we would end up accessing invalid memory. Prevent that.
https://bugzilla.gnome.org/show_bug.cgi?id=752875
Call chain:
- input_data_cb
- broadway_server_read_all_input_nonblocking (input)
- broadway_input_free (input)
(now input is invalid)
attempt to use input->active -> use-after-free
Make broadway_server_read_all_input_nonblocking return a boolean, TRUE
if the input was valid, FALSE otherwise. This allows input_data_cb to
detect whether the input was gone or not.
https://bugzilla.gnome.org/show_bug.cgi?id=741685
Rewrite gtk_places_sidebar_set_show_enter_location docs, add
references to the relevant signals, remove mentions of
GtkPlacesView from the docs, since it is not public at this point.
https://bugzilla.gnome.org/show_bug.cgi?id=752633
The deprecated and a11y sources of GTK+ were spun off some time ago into
their own Makefile.inc, which is then included by gtk/Makefile.am. Fix the
generation of file sources for the GTK+ .gir.
When the dialog is as narrow as possible, we still want some
space between the entry and the search button, so use margins
around the entry and label instead of box spacing.
This ensures that windows appear in the inspectors tree when
they are created, and it prevents GTK_DEBUG=interactive from
coming up with an empty object tree.
https://bugzilla.gnome.org/show_bug.cgi?id=752664
The previous fix was falling into the crack between
realized and mapped - we would apply the state when a window
is just realized, then unset the _initially flag, and then
when the window gets mapped, we'd undo the state. To fix
this, go back to the way things were when these flags were
first introduced.
https://bugzilla.gnome.org/show_bug.cgi?id=752765
Windows does not send any release key event for one of the shift keys
when both shift keys were pressed together. This commit solves
the problem by sending the extra release key event for the shift key
which was released as first, when the other shift key is released.
Other modifiers (e.g. Ctrl, Alt) do not have this problem.
https://bugzilla.gnome.org/show_bug.cgi?id=751721
So a window can be maximized/zoomed again after being moved away from
its maximized position. This makes the zoom button on non-CSD windows
work as before.
Instead of using the default zoom behaviour use the internal
maximized state for selecting our own zoom target. This makes
zooming work for CSD windows where for some reason the
given default zoom target is the current window frame itself
resulting in a shadowless window of the same size.
While this makes the zoom button behave a bit different as expected
it makes things more consistent with other platforms and fixes CSD
zooming.
When using the location popup to complete to a directory name
(with a trailing /), we should not punish the user by making the
Open button insensitive and preventing the Enter key from doing
the expected thing (switching to that directory).
https://bugzilla.gnome.org/show_bug.cgi?id=752708
Make sure entering the three special strings ".", ".." or "~" in
the location entry works as expected. They already worked correctly
if you append a '/' to force them to be recognized as the 'folder'
part, but that should not be necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=752707
Go back to use these variables only for pre-mapped state changes.
Their use got muddied over the years, and it was hard to keep track
of what is acutal state, and what just a queued request.
The save_widgets_create function was not safe against
being called multiple times in save mode, calling
gtk_file_chooser_set_create_folders was a way to trigger
this crash.
Previously, we would pango_font_describe() every time the code ran and
we wouldn't ever hit the optimized quick exit.
The code now is a lot more complex because the
compute-actual-value-when-required-the-first-time approach is not
supported out of the box in GtkTreeModel (or GValue).
When the search is cancelled, we may end up with a tracker
dbus reply coming in after the GtkSearchEngine object is
already gone, and bad things happen. Prevent this by
using g_signal_connect_object instead of g_signal_connect.
We generally have const getters for strings, and the two users
of this API were promptly leaking the (unexpected) copy they
got from gtk_query_get_location and gtk_query_get_text.
I invadvertendly introduced a dependency on a recent GLib recently,
by cherry-picking a fix that used new GLib API. This commit will
help catching such errors before release, by using the versioned
deprecation machinery to turn such events into build-time
warnings.
Makefile.decl does not work well with scripts that stay
in srcdir, so generate test-simplify from test-simplify.in,
just os that it ends up in builddir.
I forgot to clean up the long press gesture, and in additon, creating
the rename popover from the ui template was causing the tree view
to not be disposed when the file chooser goes away. Work around this
by manually unsetting the relative-to widget of the popover in dispose.
Prior to this patch, the hotspot would be passed in buffer coordinate
space. Where this were ever tested, i.e. in a patched mutter, the
server interpreted them incorrectly, which meant it went undiscovered.
In the updated mutter patches the incorrect behavior in GTK+ was
discovered due to the behavior in mutter was corrected.
In the themed cursor case, the dimensions were not correctly scaled
either, but this had no negative visible effect because the dimension is
only used for reporting damage tracking, and passing a bigger damage
region than surface has no negative visible effects.
https://bugzilla.gnome.org/show_bug.cgi?id=752616
We are trying to scroll the header in view together with the
focus row. The way this is implemented works fine when scrolling
up, but falls short when scrolling down. Fix this by making sure
that both the row and the header bar visible.
We automatically pick up an adjustment from our parent
scrollable, but we failed to update it when it changes.
This is happening in the places sidebar, and it was causing
the focus-tracking to fail there, letting the focus move
out of view. With this change, the focus remains visible.
Remove the code in the sidebar keypress handler that imperfectly
reproduces what GtkListBox already does: moving selection and
focus in response to arrow keys.
1. This confuses the code as it's using the old type hint with the new
type hint on GDK window creation
2. It only existed as a workaround for old code that directly accessed
window->type_hint which hasn't been possible since 3.0.
I believe that first_column can only ever be NULL here if
last_column is NULL too, in which case we'd exited already.
But coverity doesn't see that, so add an explicit exit.
We don't care about the error here, but we were relying on
g_resources_get_info to zero the size even in case of error.
No need to do that, we can just check the return value. Plus,
it makes coverity happy.
The way this code is written, we know that there is an item in
the hash table and the iter_next call will give it to us, so
no need to check the return value. Annotate the call to tell
coverity.
Previously, the (1<<31) value evaluated to the 64bit value
0xFFFFFFFF80000000
instead of
0x0000000080000000
Avoid this by explicitly casting the value to unsigned long long.
Also cast all values to unsigned long long to achieve consistency
and hopefully in the future get new values added the same way.
We "fix" this signal the same way we did for GtkEntry and
GtkTextView: slightly change the signature so that the passed
widget may be a container other than a GtkMenu, and add a
property to explicitly opt in to receiving the signal in
this case.
With the name entry being in the header bar now, we no longer
get bindings working by just letting the key event bubble up,
we have to explicitly apply them on key events that the save
entry is not handling.
They were updated in style-changed, causing the label to get set to
(None), then to the actual file name again a frame later, both of the
updates cause the GtkFileChooserButton to resize, possibly to the
minimal width, causing the layout to jump. Fix this by only updating
icon/label in style-updated when the icon theme actually changed, which
is the only case we care about here.
https://bugzilla.gnome.org/show_bug.cgi?id=752509
"Yo, we heard you like traversing NULL-terminated arrays to operate on
them, so we called g_strv_length() as the for condition, so you can
iterate the array while iterating the array."
Instead of making famed rapper and television producer Xzibit proud, we
should avoid calling g_strv_length() on an array while looping on the
array, to avoid quadratic complexity.
We do this in various places that deal with arrays of strings that we
cannot really guess are short enough not to matter — e.g. the list of
CSS selectors in the inspector, or the required authentication
information for printing.
Previous commits changes the behavior of GtkPlacesSidebar, as it stops
handling persistent devices and only manages mounted networks, XDG
directories and bookmarks.
By radically breaking the previous behavior, we may have trouble
since we provide no alternatives to that besides the private widget
GtkPlacesView.
Fix that by showing the persistent devices when not showing Other
Locations item.
We need to check on realize if we have access to a GL context, before
calling GL functions. We use gtk_gl_area_get_error() for that.
We also need to tear down the resources during unrealization, instead
of leaking them.
Commit 7db399d975 introduces
the Other Locations item, as well as some behavioral changes
to GtkPlacesSidebar. It, howevers, wrongly changes the section
of code that handles the Connect to Server item, with various
side effects depending on the environment setup.
Fix that by adding the Connect to Server at the right section
of code.
gtk_css_node_set_after/before() are now called
gtk_css_node_insert_after/before().
This brings them in line with other similar APIs (ie GtkListStore). And
it allows easier usage of the API (see changes to gtkbox.c).
Previous patch modified places sidebar widget to stop handling
fixed devices by adding an "Other Locations..." item. Up to now,
however, these changes are isolated from each other since the
bundled file manager widgets ignore the sidebar requests for
external management of fixed devices and networks.
To fix that, make the file chooser widget be aware of the
GtkPlacesSidebar::show-other-locations signal and, when requested,
show places view to manage the fixed devices and networks.
https://bugzilla.gnome.org/show_bug.cgi?id=752034
Places sidebar is a widget that enabled the user to select
XDG directories, bookmarks and mounted network locations,
as well as manages permanent and removable devices.
The new design that aims to look less clutered makes the
sidebar display only removable devices, as well as mounted
networks, bookmarks and XDG directories, and delegates the
management of permanent devices such as hard drive partitions
to GtkPlacesView, a newly introduced widget for this specific
purpose.
To delegate it, add an "Other Locations..." item to notify
when the permanent devices manager is required. Besides that,
don't show these fixes devices on the sidebar itself, as they
are not supposed to be handled by the sidebar anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=752034
Places sidebar shows XDG directories, mounted and unmounted devices,
connected networks, bookmarks and actions like 'Connect to server'
and 'Insert location', which causes the sidebar to grow very quickly
and look cluttered. Because of that, new mockups for the sidebar try
to simplify it.
To make the sidebar simpler, the new mockups propose that it should
only handle connected networks and removable devices such as flash
drives and USB devices, and delegates other devices for external
widgets through the 'Other Locations' item.
To handle fixed devices and manage network connections, add a new
widget named GtkPlacesView, based on Nautilus mockups to keep
consistency between GNOME file management tools - in this case,
between Nautilus and the bundled Gtk's file chooser.
https://bugzilla.gnome.org/show_bug.cgi?id=752034
When using frame times from _NET_WM_FRAME_DRAWN and _NET_WM_FRAME_TIMINGS, we
were treating them as local monotonic times, but they are actually extended-precision
versions of the server time, and need to be translated to monotonic times in the
case where the X server and client aren't running on the same system.
This fixes rendering stalls when using X over a remote ssh connection.
https://bugzilla.gnome.org/show_bug.cgi?id=741800
With the previous approach, we could only show the spinner
before we had any results. With the new approach, we can just
leave the timeout in place and always show the spinner until
the search is done.
We were showing things like "Searching in (null)" if the current
folder is not in the sidebar. Avoid that by falling back to using
current_folder.
Pointed out by Carlos Soriano.
Avoid using a stale timestamp (from the last user interaction with the
application) when a message arrives from D-Bus requesting that a new
window be created.
In this case the most-correct thing that we can do is to use no
timestamp at all.
We modify gdk_x11_display_set_startup_notification_id() to allow a NULL
value to mean "reset everything" and then call this function
unconditionally on receipt of D-Bus activation requests. The result
will be that a missing desktop-startup-id in the platform-data struct
will reset the timestamp.
Under their default configuration metacity and mutter will both map
windows presented with no timestamp in the foreground. This could
result in false-positive, but there is very little we can do about that
without the original timestamp from the user event.
https://bugzilla.gnome.org/show_bug.cgi?id=752000
Lots of applications often use GtkFrame as a giant toplevel container,
and that means that they get size allocated often. When frames get size
allocated, they invalidate their entire widget tree, even if they
haven't changed size or anything like that happens at all. This is
because the shadow / label needs to be redrawn if the child changes
size. We can optimize this out and only mark ourselves for a redraw if
the child has actually changed its size.
GtkButtonBox adds the "linked" class to its style context when its
layout is set to GTK_BUTTONBOX_EXPAND. It shouldn't ever make sense to
have spacing between buttons in that case, as themes generally draw
linked elements with a continuous border.
Thus, always set spacing to 0 and ignore GtkDialog's button-spacing
style property when the layout is set to EXPAND.
Also remove the now-redundant css rules which set button-spacing to 0
for message dialogs.
https://bugzilla.gnome.org/show_bug.cgi?id=752131
Change things around so that warp-to-click and jump-by-pages are
bound to left-click and shift-left-click, depending on the value
of gtk-primary-button-warps-slider. Autoscrolling is bound to
right-click.
To achieve this, reorganize gtk_range_multipress_gesture_pressed
so that the functions are clearly separated.
Make shift right-click on the trough start autoscrolling. The
autoscrolling is similar to the way steppers operate now, with
the difference that we vary the scrolling speed based on the
distance of the pointer from the widget.
Clicking on steppers does different things depending on which
button you use. We used to scroll to the end on secondary click
and use high-speed autoscrolling on middle-click. Switch these
two around, since the scroll-to-end functionality is less likely
to be useful, and the seconary button makes the autoscrolling
more easily available.
Even if we only ever hit the code with a singleton selection,
calling gtk_tree_selection_get_selected is not ok if the tree
selection mode allows multi-selection. Replace all calls to
gtk_tree_selection_get_selected in the file chooser code with
callback loops iterating over the selection. This problem
was introduced with the recently added rename and delete
menuitems.
Whenever we change directories, we unset the model, and then
we set a new model. This causes several emissions of
GtkTreeSelection::changed, for each of which we do a bunch
of work to update the path bar, the location entry, etc.
We can savely ignore some of these signals, and do less work.
There is no need to animate things when we are just setting up
the startup mode, so disable transitions in the revealer and
the stack. Pointed out by Carlos Soriano
There was some code that lead to the places sidebar loosing track
of the row being dragged if a motion event came in between letting
go of the button and the drag snap-back animation ending. This would
cause us to not show the row again, giving the appearance that it
was 'lost'.
https://bugzilla.gnome.org/show_bug.cgi?id=751448
If we don't find Xft values in the X resource db, simply fall
back to the values that are hardcoded in /etc/X11/Xresources
anyway. Extra trickery with likely-made-up screen dimensions
is not going to yield better results, and only makes for a
deeper rabbit hole when debugging.
Support was added for GDK_HINT_ASPECT in
gdk_quartz_window_set_geometry_hints though with one restriction:
min_aspect and max_aspect have to be equal, which I believe corresponds
to the most common usage. A warning will be printed if this condition is
not met but min_aspect will be used anyway.
The menu tracker does a better job of this than we can, so move over to
using it instead.
This fixes issues with './testgmenu --import' not properly displaying
the language submenu.
https://bugzilla.gnome.org/show_bug.cgi?id=752016
The current widget lookup code bails out on insensitive widgets, there's
however legit cases where we want DnD handled by a parent of the insensitive
widget, so just keep going upwards in that case.
We also use now the widget state flags, because get_sensitive() doesn't
propagate across hierarchies, so we could conceivably find a drop site
inside an insensitive widget.
https://bugzilla.gnome.org/show_bug.cgi?id=751793
This behavior has been made optional on add_popover() time, text handles
will keep being able to overflow the window, in order to allow text
selection on views too close to the window edge.
Regular GtkPopovers are reinstaurated to the previous size positioning
logic though, that is, limited by the visible area of the window.
For now assume that if those flags change for a node, they also changed
for all sibling nodes. This is not strictly true but simplifies
invalidation.
The reason it simplifies invalidation is that when removing or adding a
node, we can just invalidate the first node (for NTH_LAST_CHILD) and the
new node (for NTH_CHILD) and all the other nodes will be invalidated
automatically.
Instead of GTK_CSS_CHANGE_POSITION we now have 4 values:
GTK_CSS_CHANGE_FIRST_CHILD, GTK_CSS_CHANGE_LAST_CHILD,
GTK_CSS_CHANGE_NTH_CHILD and GTK_CSS_CHANGE_NTH_LAST_CHILD
Nobody is using them directly yet.
The warning is not intended to disable the Create button and must only be shown
when the folder is not found, so this is implemented in the folder name exists
callback.
A "name" entry was added to FileExistsData to pass the filename to the callback
https://bugzilla.gnome.org/show_bug.cgi?id=751800
Allow the name and location columns to be resized, but arrange
for their sizing to be reset when the column layout changes (either
by the location column appearing/disappearing, or by the time
column changing between mtime and atime. This gives a decent
compromise between good automatic sizing and user control.
The code for getting the selected files was assuming that
we are always in browse mode, and was causing warnings when
hitting Ctrl-L twice, right after opening the file chooser.
The fix is to simple use the model that is passed into the
callback.
Avoid reloading models unnecessarily, e.g. when the user
switches to search and back without starting a search.
Keep the current list contents visible until a search is
actually started. Also, synchronize any changes in the
column layout with the corresponding model changes.
This search engine reuses the GFileInfo that is already loaded
for the file list, to ensure that hits from the current directory
always appear promptly.
Don't show Recent in the sidebar when we are in save mode.
We also ignore the startup-mode = recent in save mode now - we
don't want to populate the file list with recent files if Recent
is not on the sidebar. If you really want to go there, you can
still enter recent:// in the location entry.
https://bugzilla.gnome.org/show_bug.cgi?id=751653
In save modes, the entry is really more for entering a name than
entering a full location, so don't go there eagerly when '.', '/'
or '~' are pressed. Make Ctrl-L work better in this mode too.
Use the same code that brings up the location entry on '/',
'~' or '.' also when the focus is not on the file list. This
prevents those key presses on the sidebar from ending up in
the search entry.
Some internal containers were erroneously taking focus, interrupting
the flow of tab keynav, and using arrow keynav to go from the file
list to the sidebar did not work anymore, after the recent sidebar
rewrite.
Make the file chooser entry optionally capture Escape
and emit a signal. Make the file chooser widget hide the
entry on that signal and go back to the path bar.
This gives us a two-level undo:
location entry -> path bar -> dialog close.
When the location entry is permanently displayed in the
header for save mode, we still let the first Escape close
the dialog.
Arrange things so that hitting Escape during a running
search stops the search, but leaves the search results
around, and hitting Escape again leaves the search mode.
The location column did not work for search results in recent://.
Fix that by looking at the target uri in this case. Show the location
column in recent mode. And make it more similar to nautilus by
showing the full path if it is not below $HOME.
The places sidebar already does all the work to determine the
right label to use for the current location of the filechooser.
We want to use the same label in the headerbar subtitle, so
add some private API to get it.
Under Wayland, fullscreen/maximized windows may not cover the entire
area when a size increment is specified.
Ignore size increments for fullscreen/maximized windows just like most
window managers do under X11 so that windows with size increments can
still be fullscreen or fully maximized under Wayland as well.
https://bugzilla.gnome.org/show_bug.cgi?id=751368
Since 740bcf5, we use these properties to properly compute shadow widths
for unmapped windows. If a client calls gtk_window_maximize and a window
manager unmaximizes a window, we should draw borders, so we need to
reset these when we get the property notification.
This queues an unnecessary resize on the toplevel, and is not needed
anymore, now that GtkWidget does not call
gtk_style_context_set_background() on the window's GdkWindow anymore.
And wrap it with G_GNUC_IGNORE_DEPRECATIONS.
Unfortunately we can't stop rendering the background altogether here.
Also, refactor some common code in a single function.
And wrap it with G_GNUC_IGNORE_DEPRECATIONS.
Unfortunately we can't stop rendering the background altogether here.
Also, gtk_style_context_set_background() should really be called every
time the style is updated. Fix that.
We used to "invalidate" scroll valuators, so the next scroll event could
be used as the base for the next scroll deltas. This has the inconvenience
that it invariably consumes the first event received after enter and,
due to interactions with WM overeager passive button grabs, there's a
possibility we don't scroll at all if we receive interleaved "smooth
scroll" XI_Motion events and XI_Enter events (Normally triggered by regular
scroll wheels in mice).
In order to fix this, and at the expense of some sync-call overhead on
XI_Enter events (one XIQueryDevice call per slave device), query the
current scroll valuator state for all the slaves of the entered pointer,
so we do know beforehand the right base values. If new devices are plugged
while the pointer is on top of the client, the initialized scroll values
will match the valuators'.
https://bugzilla.gnome.org/show_bug.cgi?id=750994https://bugzilla.gnome.org/show_bug.cgi?id=750870
It has the unintended effect of picking the suggested action from the
context, which conflicts with the (possibly 0) status we set on our
::drag-motion handler.
Given this widget is not interested in listening to DnD from every
possible target, it is safe to just disable it.
gdk_x11_device_xi2_window_at_position() may attempt to push/pop
a few error trap pairs while traversing the window tree. Move it
outside the server grab, and around the multiple XIQueryPointer
calls we may do here.
https://bugzilla.gnome.org/show_bug.cgi?id=751739
This allows a widget to override global font_options, such as hinting and
subpixel order. The widget's PangoContext is updated when this is set.
Some update code from gtk_widget_update_pango_context was moved to
update_pango_context so that gtk_widget_update_pango_context runs it.
http://bugzilla.gnome.org/show_bug.cgi?id=751677
The WM isn't aware of O-R (popup) or offscreen windows. If somebody
maps an offscreen or a popup GTK+ window before the main window, we'll
complete the sequence before a "real" window is mapped. Make sure to
ignore these for startup notifies.
In case the X11 backend is not enabled, we still need to include the
pangofc-fontmap.h header file, as we use the Pango/FontConfig API in
both the X11 and Wayland case.
https://bugzilla.gnome.org/show_bug.cgi?id=751625
We mistakenly forced the "STRING" type, which was able to confuse higher
layer helpers like gtk_selection_data_get_uris(). This fixes a crash
happening anytime a drop is attempted on a GtkPlacesSidebar.
Currently, due to the lack of progress information in the Wayland DnD
protocol, we assume a DnD operation is finished after the first
data_source.send is finished (It's either that or leaving stuck grabs).
This however breaks previous assumptions that dest widgets can request
the data multiple times, even in response to GtkWidget::drag-motion.
This leaves us with a NULL owner for the DnD atom when we aren't
finished receiving wl_data_source events yet, causing a crash.
This commit fixes the crash, the behavior left is still far from
desirable though...
Previously, the unpremultiplied values from the GdkRGBA were taken. Now
we premultiply the color values as specified by the CSS specs.
This is only relevant when transitioning with translucent colors.
An example is the halfway transition between transparent (0, 0, 0, 0)
and white (1, 1, 1, 1). Previously, all 4 values where transitioned
separately and the result was semi-transparent gray (0.5, 0.5, 0.5,
0.5).
By depending on the alpha value, the result is now semi-transparent
white (1, 1, 1, 0.5) which is what one would naively expect.
New reftest: color-transition
And force the ungrab on it, instead of the slave, in the case of
local DnD drop. This avoids confusions on the pointer events spawn
from DnD, as GDK doesn't think anymore those are from a slave device.
Most namely, it fixes the stuck grab when finishing DnD on the
same app it was started from.
We currently only hold the last offer received, which is wrong, as both
are independent and have different life cycles.
This means we have to store per-selection wl_data_offer and targets, and
maintain these as appropriate from the clipboard/DnD specific entry points.
Setting these properties has the side-effect of setting the
corresponding -set properties, which makes GTK+ behave subtly
different. So don't mess with these.
gtk_image_set_from_resource was setting the resource_path,
only to have it overwritten again before returning. That
is not as it should be, so change things to set the resource
path late.
https://bugzilla.gnome.org/show_bug.cgi?id=751443
This oddly can be reproduced with weston+weston-dnd, when dragging
anything from GTK+ into weston-dnd, it will insist on picking its
custom application/x-wayland-dnd-flower mimetype, and this request
forwarded by the compositor, even if GTK+ didn't announce it on
its wl_data_source mimetype list. (What should probably happen here
is that the request is silenced, and/or weston-dnd picks (null))
This should be harmless, we are leaking though the fd in that case,
because the emission of GdkEventSelection on an unhandled mimetype
results in NOP. In order to avoid this, we should check whether the
mimetype is supported at all on the backend code and possibly close
the fd, this involves storing these in the first place.
https://bugzilla.gnome.org/show_bug.cgi?id=751414
If the other peer requests data too fast (too rare/unlikely though),
we might receive multiple gdk_wayland_selection_request_target() calls
with no ending gdk_wayland_selection_check_write(), in which case the
fd is leaked as no GOutputStream was created to take over it.
https://bugzilla.gnome.org/show_bug.cgi?id=751414
We weren't catching all the places where the AsyncWriteData operation
should be cancelled, which could happen if we repeatedly request the
same target on different fds.
https://bugzilla.gnome.org/show_bug.cgi?id=751414
At the moment we create the AsyncWriteData, the ownership of the
fd is granted to the GOutputStream, and the fd set to -1, so at
this moment we're just silently getting EBADFD.
This partially reverts 25885ca600, the initialization of .fd
to -1 is valid and stays though.
https://bugzilla.gnome.org/show_bug.cgi?id=751414
On X11 this is something the windowing system does for us, which the
wayland backend should emulate, being grabs completely client-side.
So, if the grab and current focus windows differ, make sure we emit
focus/crossing events as it corresponds to the grab device.
This was being done so only on pointers. Internally, a GdkDeviceGrabInfo
is kept for each of the master pointer/keyboard, failing to do this for
keyboards results in a stuck keyboard grab.
https://bugzilla.gnome.org/show_bug.cgi?id=748892
The fd must be closed on async_write_data_free(), but we should also
initialize it to -1 so gdk_wayland_selection_check_write() doesn't wrongly
pick the stdin fd.
https://bugzilla.gnome.org/show_bug.cgi?id=751414
Don't add the container border to the title request size; it
is only used for the child widget.
Don't call gtk_widget_get_preferred_width_for_height() for
the title bar with an unrelated height and subtract the title
bar height before querying the child widget width.
Guard against negative size requests after substracting the
borders/shadows and the title bar.
https://bugzilla.gnome.org/show_bug.cgi?id=751341
The minimum title width affects the minimum window width
for CSD windows. To allow smaller windows like without
CSD reduce it a bit (276px vs 156px min width)
https://bugzilla.gnome.org/show_bug.cgi?id=751341
In the non-CSD case we checked for 0x0 window size requisition
and replaced it with 200x200 so the window was still visible.
This no longer works in case of CSD as the shadow and title bar
are always added to the requisition resulting in a titlebar/shadow
only window in case there is no child widget (this is currently
visible under wayland or when setting GTK_CSD=1).
Instead of special casing the final window size, special case
the child requisition paths instead. This gives us the same
requisition in both, CSD and non-CSD cases (the header bar
has a too large minimum width atm so the resulting window is
still not the same)
https://bugzilla.gnome.org/show_bug.cgi?id=751341
Try harder not to push the scale out of balance by marks. With
this change, the remaining difference in the drawing is down
to asymmetric assets and margins coming out of the theme.
To fully support such asymmetric rendering, we need implement
baseline alignment for scales.
https://bugzilla.gnome.org/show_bug.cgi?id=749650
Request "output-bin-supported" and "output-bin-default" attributes through
IPP if there is no PPD for selected printer.
Pass "output-bin" option with other options in printer_get_options().
Translate standard IPP values of "output-bin" option.
https://bugzilla.gnome.org/show_bug.cgi?id=725441
This error resulted in warnings like
"pixman_region32_init_rect: Invalid rectangle passed"
In case the window is smaller than handle_size * 2 the resulting
edge window got a negative size. Prevent that by limiting the
handle size to half the respective edge length. This also
prevents the corner windows from overlapping in case the window
is too small.
When the stack is destroyed we do not want to waste time running
animations and notifying listeners about which is our current
visible child.
This is not only an optimization, but it is important for the stack
switcher widgets: since they are in another branch of the hieratchy
we do not want to get notifications while the stack is being destroyed.
Based on a patch by Paolo Borelli
https://bugzilla.gnome.org/show_bug.cgi?id=724506
The calculation to update the initial slider position on zoom
changes was not working correctly when using keys to toggle
zoom on and off for scales. Avoid it by updating the position
beforehand.
Moving the mouse while pressing one of the steppers was making
the slider jump to the end, unexpectedly. This was caused by the
drag gesture kicking in when it shouldn't. Fix this by making
all drag gesture signal handlers only do something if we are in
a drag thats started on the slider.
https://bugzilla.gnome.org/show_bug.cgi?id=751050
The filter combo box in the file chooser was stretching to match
the height of the extra widgets next to it. Since, stretched combo
boxes are not a pretty sight, make it stick to the top instead.
Patch by Caolán McNamara,
https://bugzilla.gnome.org/show_bug.cgi?id=751227
Marking these as "Since: 3.14.1" may be more accurate, but
it causes gtk-doc to not put these symbols in any versioned
index at all (it generates an unused index for 3.14.1). So,
lets lie a little, and say these symbols were added in 3.14.
After the recent change thta introduced boxes between the pages
and the notebook, we were no longer careful enough when disposing
the assistant. Fix that up.
Since demos.h is now generated according to the platform for which GTK+ is
built, don't distribute it. Generate a Windows-specific demos.h.win32 and
distribute that instead, in which the Visual Studio build files will copy
it to demos.h, so that the build will proceed normally.
https://bugzilla.gnome.org/show_bug.cgi?id=749622
Add a destroy notify for the data of the callback, so we don't
end up leaving a dangling pointer behind for a short while if
the native engine is finalized before the simple one. This
was showing up as crash when typing and backspacing in the
search entry of the file chooser.
Implement the IsIndexed callback for tracker. This requires
reading settings of the tracker file miner. We are careful
to avoid a hard dependency on the tracker schemas.
Add a flag for recursive search, and implement non-recursive
search in both the tracker and simple search engines.
This is not currently used in the file chooser.
When the search engine provides hits with GFileInfo, use that
to add the hits to the model directly, without going through
another round of async get_info calls.
To do this, we add a batched variant of the
_gtk_file_system_model_update_file call that takes lists of
GFiles and GFileInfos. Again, we can avoid repeated resorting
that happens when the files are updated individually.
Add a batched version of gtk_file_system_model_add_and_query_file
that takes a list of files and avoids resorting the model for each
individual insertion. The querying is still done one-file-at-a-time,
so more optimization is certainly possible.
The old should_use_csd() function would return FALSE if the GTK_CSD
environment variable is unset; the change in commit c5e5ee6749
made it return TRUE if GTK_CSD is unset. This has a cascade effect
on the window size, which causes invalid rectangles to bubble down
to Pixman.
https://bugzilla.gnome.org/show_bug.cgi?id=751140
I was assuming that GtkVolumeButton and GtkScaleButton could only
contain a icon, now they get the image-button padding by default,
but if the text-button class is applied it is not overridden.
Use a revealer to manage the visibility of the header area where
we show the pathbar, the location entry or search. This is a bit
smoother, and makes search more similar to a search bar.
Popovers may be spawn when there's GTK+ grabs somewhere else (eg.
text selection popover/handles in an entry in a modal popover). When
this happens, events go to the grab widget (in this case the modal
popover) and are effectively ignored by the event widget, even though
it's can be conceptually a child of the grab widget.
To get away with this, tweak a bit gtk_main_do_event(), so events going
to popovers that are related to grab_widget or a child of it are received,
as it would happen with regular children of grab_widget.
https://bugzilla.gnome.org/show_bug.cgi?id=750993
This will be the widget that the popover relates to (::pointing-to in
GtkPopover, ::parent in GtkTextHandle).
Additional API to check the popover/parent relationship between widgets
has been added, which will be useful wherever this is necessary in a
generic manner.
https://bugzilla.gnome.org/show_bug.cgi?id=750993
A subsurface positioning operation only takes effect when the parent
surfaces state is applied. If a subsurface is mapped and positioned, but
the parent surface state is not immediately committed, the relative
position of the subsurface is undefined and may be placed incorrectly.
To avoid this undefined state, always request that the parent surface
should be committed after mapping a subsurface so that the position
operation will take effect.
https://bugzilla.gnome.org/show_bug.cgi?id=751098
GtkTreeView has a particularly expensive drawing path. This can cause
issues when part of animated widget sequences. Caching the content while
a model is attached helps reduce the number of full redraws during
exposure greatly.
https://bugzilla.gnome.org/show_bug.cgi?id=751082
Some widgets have very expensive drawing paths. So caching the content
can be useful even when not scrolling.
This can help speed up widgets that are part of animation sequences and
thereby go through spurious expose events.
https://bugzilla.gnome.org/show_bug.cgi?id=751082
Background patterns are often updated when style changes. In many cases,
the new pattern will match the previous. We can optimize out the
invalidation that will occur upon resetting the same pattern.
We were using GTkTreeView in a simple list. Also, as we know,
GtkCellRenderers are not the best way to theme and manipulate
widgets.
So instead use a GtkListBox to modernize the GtkPlacesSidebar,
and in the way clean up some parts of the code (like headings)
which were not used anymore.
Also we don't use a model anymore, since the data is simple
enough to manage it in a subclass of the row itself.
It is convenient to allow applications to show all the drop
targets at once. This improves the user experience with drag
an drop.
The new API allows the application to set the gtkplacessidebar
in a mode where invalid drop targets are insensitive and it
adds a "new bookmark" row. This mode is intended to be set
when the application is aware of a dnd operation and needs to
be stopped kwhen the application is aware that dnd operation
was cancelled or ended in a different part than gtkplacesisdebar.
The context parameter is unused in this patch, but will be
used in next patches when the sidebar will use a GtkListBox.
The reason of being unused now is just convenience.
https://bugzilla.gnome.org/show_bug.cgi?id=747793
GtkInspector is opening a separate display connection, which makes
it more likely that gtk_get_current_event() returns an event from
the "wrong" display.
We were getting ourselves in trouble by casting touch events
to GdkEventButton and poking directly at their internals. Instead,
use GdkEvent API to get what we need.
This fixes a crash when using the gear menu in epiphany with
touch. The same crash also occurred in testmenubutton.
An pass_through window is something you can draw in but does not
affect event handling. Normally if a window has with no event mask set
for a particular event then input events in it go to its parent window
(X11 semantics), whereas if pass_through is enabled the window below
the window will get the event. The later mode is useful when the
window is partially transparent. Note that an pass-through windows can
have child windows that are not pass-through so they can still get events
on some parts.
Semantically, this behaves the same as an regular window with
gdk_window_set_child_input_shapes() called on it (and re-called any
time a child is changed), but its far more efficient and easy to use.
This allows us to fix the testoverlay input stacking test.
https://bugzilla.gnome.org/show_bug.cgi?id=750568https://bugs.freedesktop.org/show_bug.cgi?id=90917
In this case we have a bunch of interactive main children
of the overlay, and then a centered overlay that contains both
non-interactive (labels) and interactive (entry) widgets.
This shows off a problem where the non-interactive parts (the labels)
steals input from the overlay main children (breaks button click and
hover effects).
https://bugzilla.gnome.org/show_bug.cgi?id=750568https://bugs.freedesktop.org/show_bug.cgi?id=90917
For functions that take state flags as an argument we need to special
case the situation where the passed in flags don't match the current
state.
Previously we would create a copy of the style info, change its state
and do the lookup from there.
Now that GtkCssNode has replaced style infos, this doesn't work as well
anymore as copying a GtkCssNode is not possible.
However, unike style infos, GtkCssNodes are instant-apply, so we don't
need to copy anymore, we can just change the state of the node.
This causes some invalidations to be queued, but we can take that
performance hit as this is fallback code.
https://bugzilla.redhat.com/show_bug.cgi?id=1228852
Instead of having padding outside the notebook containing
all pages, put each page in an extra box and add the padding
there. This is in preparation for allowing pages without
padding.
We can't add properties to the interface, since it breaks
3rd party implementations of the GtkFontChooser interface.
These exist, for example in gnumeric.
So, instead of a new property, add getter/setter vfuncs.
The font chooser delays creating the font description from the font face
as long as possible (it's slow). Because we use fixed height mode, we
only have to create font descriptions for rows we are actually going to
show.
This was achieved by looking at the font description column and if it
was NULL, we created a font description and gtk_list_stiore_set() it.
Unfortunately this caused a "row-changed" signal to be emitted and this
emission could happen during the cell data func.
And that caused infinite loops with accessibility when you were unlucky.
This change replaces the NULL font description with an empty one and
instead of setting the correct font description, we
pango_font_description_merge() it in. This way, the list store doesn't
change and no signals are emitted.
https://bugzilla.redhat.com/show_bug.cgi?id=1197267
Due to popover modality itself, there's quite high chances the popover
stealing focus has been triggered from within, so stay friendly to it.
Hiding the popover here will only hide the grabbing popover too if this
happens.
https://bugzilla.gnome.org/show_bug.cgi?id=750741
When recoloring symbolic SVG, do not modify the original width and
height of the passed-in file; the function later will scale the image
through gdk_pixbuf_new_from_stream_at_scale(), but we should still
use the original size to create the proxy SVG, or the image will
possibly be doubly-resized or blurry.
https://bugzilla.gnome.org/show_bug.cgi?id=750605
show_or_hide_handles() tries to disable visibility when the popover is
shown, although it triggers a bit late, and lets the handles flash briefly
if both popover and handles try to show at the same time (eg. when
pressing on the selection of a previously unfocused textview, the handles
were previously hidden, so they try to show again on focus in).
The handles might fall outside the visible area, and shouldn't be shown
then. Just call gtk_text_view_update_handles() which will perform these
checks, and keep the handle conveniently hidden.
This was leading to unexpectedly visible handles (and in the
wrong/previous position, the handle code doesn't relocate the widget
it's about to hide) when "select all" was selected in the popover on
a textview needing scrollbars.
and extending the selection beyond the view above and/or below.
The check used to hide the popover if the pointed area fell partly out of
the widget allocation, textviews now can trigger that with text selections
too close to the visible edge, as a small extra area around is now reserved.
The check has been changed to only hide the popover if the pointed area
falls completely outside the widget allocation.
The button and menu item icons settings are deprecated; application
developers should control whether or not a widget should show an icon,
using the existing API.
https://bugzilla.gnome.org/show_bug.cgi?id=750718
So objects connected by g_signal_connect_after actually get
the signal.
This was causing an issue in the dnd highlight, since there
a cairo rectangle is draw using g_signal_connect_after on the draw
signal.
If a menu was not attached to any widget, we try to calculate its
position given where the grabbed pointer is and what window has its
focus. Previously we failed to do so if a "transfer window" was used
for the grab, and this patch adds a code path that, if the menu window
itself didn't have the grab, look for the transfer window and get the
grab device from there.
https://bugzilla.gnome.org/show_bug.cgi?id=748951
If a position was already explicitly set, don't try to guess the
position of popup menus by looking at the pointer position, just use
the set coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=748951
According to the xdg-shell protocol specification the (x, y) coordinates
passed when creating a popup surface is relative to top left corner of
the parent surface, but prior to this patch, if the parent surface
was an xdg_surface, we'd position it relative to top left corner of the
window geometry of that xdg_surface.
https://bugzilla.gnome.org/show_bug.cgi?id=749717
When we are close the window edge, we need to shrink the 'invisible
border' around the handle to avoid mispositioning it. A fiddly
calculation, but it works.
The buttons on the popover where stealing the focus from the text
view on click, causing the popover to be dismissed before the action
was taken. Fix this by making the buttons not take focus on click.
The buttons on the popover where stealing the focus from the text
view on click, causing the popover to be dismissed before the action
was taken. Fix this by making the buttons not take focus on click.
- use dark theme assets for the checkboxes and radios
- darken the popover for legibility (white bg/black text is
really the most problematic background to have).
unfortunatley in terms of SCSS structure this is further digging us into the
hole of specificity. It would be much nicer to set the .osd class on the popover
and have everything just work. I'm sure we'll end up using OSD styled popovers
outside the touch context.
https://bugzilla.gnome.org/show_bug.cgi?id=750396
After the recent changes, we could end up calling
gtk_entry_update_handles in cases where the text_handle
has not be created (e.g. when dragging text from an entry).
Avoid that.
Also make them more scary so people really really don't use it as a
random knob when trying to make things go fast.
//bugzilla.gnome.org/show_bug.cgi?id=750505
The changes in commit 13e22e2030 made
_gtk_window_check_handle_wm_event() indirectly depend on
gtk_get_current_event_time() which relies on the current event being
available on the current_events stack.
Since the current event is only pushed on the stack afterwards we get
an invalid timestamp which breaks ewmh window moving.
This fixes the issue by pushing the current event before we start
relying on it being there in gtk_main_do_event() and, as a byproduct,
also fixes a potential memory leak when we have a rewritten event and
return early due to _gtk_window_check_handle_wm_event() being TRUE.
https://bugzilla.gnome.org/show_bug.cgi?id=750384
Use the drag-started signal to differentiate between drags that
move a handle and taps on a handle. Show the touch selection popup
for the latter, but not the former.
Hide the handles when the popover appears, and brind them back
when it disappears. This will need revisiting if we start using
the popover for mouse interaction as well, where we may not
want handles to show up.
We don't want the popup to appear spontaneously, so eventually
the timeout may go away altogether. For now, shorten it to 50ms,
to avoid rewriting all the places where the timeout is set or
unset.
Use the drag-started signal to differentiate between drags that
move a handle and taps on a handle. Show the touch selection popup
for the latter, but not the former.
Hide the handles when the popover appears, and brind them back
when it disappears. This will need revisiting if we start using
the popover for mouse interaction as well, where we may not
want handles to show up.
We don't want the popover to appear spontaneously, so eventually
the timeout may go away altogether. For now, shorten it to 50ms,
to avoid rewriting all the places where the timeout is set or
unset.
Add bold/italics/underline styling to the context menu of
the 'Lorem ipsum...' text view in page 1. The point is not
to show good UI for this kind of styling, but to demonstrate
custom actions in the context menu / touch selection.
Update style for touch selection in GtkEntry and GtkTextView
according to https://wiki.gnome.org/Design/OS/Selections
Add 'Select All' to the default actions, change actions
to use icons and move the popover to the bottom. If there is
no selection, just offer to paste.
Since nautilus merge, we were not showing 'Recent' in the sidebar
if GIO did not support the recent: scheme. But the file chooser
can show recent files independent of gvfs - it loads the recent
files manually. This is relevant on Windows and OS X, where gvfs
is typically not used.
This commit adds a show-recent property which can be used to override
the recent: scheme check. We use it in the file chooser.
https://bugzilla.gnome.org/show_bug.cgi?id=750068
- use consistent widget style. unfortunately using assets
- light/dark variant
- new assets for text selestions, using existing slider asset for
insertion point
https://bugzilla.gnome.org/show_bug.cgi?id=750396
We don't want scale marks to affect scale sizing and positioning,
so draw them inside the range recangle. This avoids size changes
for marks that don't have labels, at least.
https://bugzilla.gnome.org/show_bug.cgi?id=749650
The change in 03213b9509 changed the rules
as to when CSD can be enabled, but it also unconditionally enables CSD
with the implicit assumption that client-side shadows were the real
issue, and that we could work around that by drawing our own borders.
This also means that setting a titlebar for a GtkWindow will enable CSD
unconditionally.
In reality, some window managers (like Matchbox) *only* support
server-side decorations, and will ignore all hints to the contrary, to
the point of drawing decorations at random locations on top of the
window.
Since CSD are enabled unconditionally, the GTK_CSD environment variable
is also not a suitable escape hatch.
In the grand tradition of asking ourselves if we should do something
just because we can, we should split the environment checks from the
checks on what the user requested; by doing that, we can also check
when enabling client-side decorations, and ideally bail out if needed.
https://bugzilla.gnome.org/show_bug.cgi?id=750343
On wl_keyboard.key/modifiers, we're just forgetting about currently
pressed mouse buttons. Fix this by storing button and key modifiers
separately, and put these together when creating the GdkEvents.
Text insertion/pasting might trigger scroll, so we'd have to wait
until the text was revalidated and the scrolling truly happened
before we can check the new handle(s) position.
Nowadays (and for quite some years now) we rely on GdkEventGrabBroken
events to be received. This fake button event seems a remnant of
the early Gtk 2.x days, and is currently even inconsistent with our
event delivery model, so just remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=749737
When recent files are not supported in gvfs, or turned off by
settings, we should not try to load them even if the startup
mode says so. This prevents inconsistency with the places
sidebar where 'Recent' will not appear in this case.
This applies the proper CSS child ordering semantics using GtkCssNode to
GtkListBox. You can now use :first-child, :last-child, :nth-child(), and
:last-nth-child() selectors.
For example, this allows styling row separators using CSS while ignoring
the separator on the last row.
GtkListBoxRow {
border-bottom: 1px solid @borders;
}
GtkListBoxRow:last-child {
border-bottom: none;
}
When the sort ordering of the listbox changes, we also update the CSS
node ordering.
When interpolating the stack size, we compute the current size by using
the prefered/minimum current size and the last size. We can't use the
last_visible_surface_allocation because that is not available until the
first _draw call and it doesn't include the child's margins.
the drag_begin() vmethod is meant for this, and the internal DnD code
will set up a drag icon if ::drag_begin didn't do so, which means
we are first getting a "default" icon, and then replacing it with the
text surface.
This is completely harmless in X11, but causes issues on wayland as
the DnD icon window is expected to remain unchanged during DnD there.
https://bugzilla.gnome.org/show_bug.cgi?id=748763
The drag destination might be empty, we shouldn't be checking whether
it contains pages at all. Instead, check the source notebook, which
ought to have a selected page if you're dragging something from there.
https://bugzilla.gnome.org/show_bug.cgi?id=749893
To generate the icon cache files.
We want to avoid a dependency loop if possible; additionally, on some
Debian-based systems gtk-update-icon-cache maps to the GTK2 version of
the utility and the GTK3 version is renamed to
gtk-update-icon-cache-3.0.
To avoid a build dependency on GTK2, use the binary that we just built
in-tree.
https://bugzilla.gnome.org/show_bug.cgi?id=749593
On some slower machines (e.g. an ARM OBS builder), this test is failing
with a race condition where we're trying to fetch the style before it's
applied.
https://bugzilla.gnome.org/show_bug.cgi?id=749593
gtk_tree_view_set_tooltip_column() specifies that markup in the text
should be escaped.
This fixes critical warnings when hovering over items in the sidebar for
bookmarks that have markup characters in their names.
https://bugzilla.gnome.org/show_bug.cgi?id=719683
The libinput driver will send a 0/0 scroll event on touchpads and other
devices where it knows scrolling stopped for sure. Use these events to
trigger kinetic scrolling from there.
The mechanism is similar to GtkGestureSwipe, we keep a backlog of the
latest dx/dy till a previous point in time, and calculate the final
velocities from there, with the difference we're dealing with scroll
units, and not pixel distances.
https://bugzilla.gnome.org/show_bug.cgi?id=749770
If a GtkScrolledWindow is just unmapped and promptly mapped again, the
indicators are left in a semi-visible state, so the GdkWindow isn't raised
properly above scrolledwindow content. This inconsistent state went away
the next time the indicator is hidden.
So, reset all state about indicator window visibility, animation
progress and conceil timer on ::unmap, this will be enough to make the
indicators start out hidden like on newly created scrolledwindows.
This patch introduces support for using the newly introduced
monitor objects in the XRandR protocol. These objects are meant
to be used to denote a set of rectangles representing a logical
monitor, and are used to hide details like monitor tiling and
virtual gpu outputs.
This uses the new objects instead of crtc/outputs objects when
they are available to create the monitor lists. X server 1.18
is required on the server side for randr 1.5.
https://bugzilla.gnome.org/show_bug.cgi?id=749561
Just use the last coordinates given on XdndPosition/drag_motion() in
order to trigger scrolling.
When running on Xwayland, the pointer position is unknown at this
stage on the X11 side, so the coordinates given here are bogus.
This change avoids both roundtrips and this situation.
https://bugzilla.gnome.org/show_bug.cgi?id=749679
Just use the last coordinates given on XdndPosition/drag_motion() in
order to trigger scrolling.
When running on Xwayland, the pointer position is unknown at this
stage on the X11 side, so the coordinates given here are bogus.
This change avoids both roundtrips and this situation.
https://bugzilla.gnome.org/show_bug.cgi?id=749679
Just use the last coordinates given on XdndPosition/drag_motion() in
order to trigger scrolling.
When running on Xwayland, the pointer position is unknown at this
stage on the X11 side, so the coordinates given here are bogus.
This change avoids both roundtrips and this situation.
https://bugzilla.gnome.org/show_bug.cgi?id=749679
Load themed cursors from the same places they are loaded on freedesktop systems,
but use W32 API functions to do so (works for .cur/.ani cursors instead of X
cursors).
Refactor the code for cursor handling. Prefer loading cursors by name.
Do not load actual cursors when loading the theme. Find the files and remember
the arguments/calls for loading them instead. Keeping HCURSOR instance in the
hashmap would result in multiple GdkCursors using the same HCURSOR. Given that
we use DestroyCursor() to off them, this would cause problems (at the very
least - DestroyCursor() would fail).
Store GdkCursor instances in a cache. Update cached cursors when theme changes.
Recognize "system" theme as a special (and default) case. When it is set,
prefer system cursors and fall back to Adwaita cursors and (as a last resort)
built-in X cursors. Otherwise prefer theme cursors and fall back to system and
X cursors.
Force GTK to use "left_ptr" cursor when no cursor is set. Using NULL makes
it use the system default "arrow", which is not the intended behaviour when
a non-system theme is selected.
Ignore cursor size setting and query the OS for the required cursor size, as
Windows (almost) does not allow setting cursors of arbitrary size.
https://bugzilla.gnome.org/show_bug.cgi?id=749287
In particular this means that cursors are disposed of by the way of
g_object_unref(), not DestroyCursor (which is documented to not to be
used on certain kinds of cursors, and we can't tell which is which).
It should also alleviate any concerns about destroying cursors that
are still in use by other windows, except for cases where we would
somehow get our hands on a HCURSOR that someone else is using and we
make a GdkCursor out of it and later unref and finalize it while it
is still in use.
It also removes the need to call CopyCursor(), which makes animated
cursors into non-animated ones as a side-effect (supposed to be a bug,
but try explaining that to MS). Now cursors should be animated (if
the are set up as such in the OS).
https://bugzilla.gnome.org/show_bug.cgi?id=697477
Some features need certain globals to initialize. In order to deal with
these dependencies, add a way to postpone closures that depend on a
certain set of globals, that later will be invoked when required
globals are all received.
https://bugzilla.gnome.org/show_bug.cgi?id=719819
Instead use asynchronous round trips that is synchronized in the end of
the initialization. This makes it easier to track state, as we won't
dispatch arbitrary Wayland messages while processing globals.
https://bugzilla.gnome.org/show_bug.cgi?id=719819
Even if a window doesn't support client side shadow
(gtk_window_supports_client_shadow returns FALSE), don't assume the
shadow width is zero, as CSD may have been enabled anyway (meaning
priv->client_decorated is TRUE). In that case we still need to report
the correct width.
https://bugzilla.gnome.org/show_bug.cgi?id=749451
Only "wait" and "all-scroll" are not implemented properly. OS X does not
seem to have a proper interface to either cursor. Approximations are used
instead; see the code.
See bug 749178.
Not everything has a replacement in the API, as the drawing model
changed considerably; nevertheless, this should help out developers
porting from the deprecated GtkStyle API.
It's now needed by gtk-launch, so it's just the case to enable it for all the
builds except the win32 one, instead of adding it for every unix backend.
https://bugzilla.gnome.org/show_bug.cgi?id=744086
Add parameter for specification of port to gtk_cups_connection_cups_new().
Use default port returned by ippPort() if the given port is lower than 0.
https://bugzilla.gnome.org/show_bug.cgi?id=693738
The ordering of globals in connection setup under weston
is different from mutter, and we end up creating a the
dnd window before any outputs are present. Don't cause
a critical warning in that case.
Even when the program itself calls gdk_set_program_class(). There's
currently no way for this function to be called without breaking gdk's
--class command line option, because you cannot call it before
gtk_init().
https://bugzilla.gnome.org/show_bug.cgi?id=747634
If CSD is enabled with shadow even though it "shouldn't"*, the width
should still be calculated correctly. This fixes a regression caused by
b1e5ad469c.
* gtk_window_should_use_csd () returns false
https://bugzilla.gnome.org/show_bug.cgi?id=748615
Synchronizing the visible child with the switcher's toggle buttons can
lead to GtkButton::clicked being emitted twice. Once for the button
that was active before, and once for the button that we just activated.
This leads to notify::visible-child being called twice and one of
them is with the wrong child.
Let's deal with this in the same way we handle the visible child
changing underneath us.
https://bugzilla.gnome.org/show_bug.cgi?id=749021
The window state 'client_decorated' will only be set the window is being
realized. If anyone tries to get the shadow size before that it'd get
the with as if there always was no shadow.
This avoids negative sized opaque regions caused by the allocation being
smaller than shadow.
https://bugzilla.gnome.org/show_bug.cgi?id=748615
If we have a GObject property that is also a GObject, we should be able
to view additional information on that object (even if the param spec
is read-only).
We were relying on indirectly getting notify when fontconfig
configuration changes, by GtkSettings translating the timestamp
change into a style-invalidation, which gets fed through the
css invalidation machinery. That machinery has gotten good enough
at optimizing away redundant changes that it no longer emits
::style-updated in this case.
So, instead make the font chooser listen directly to what it
cares about: the fontconfig change notification from GtkSettings.
We can use the GtkSettings:gtk-fontconfig-timestamp property to decide
whether or not we should reload fonts on style and screen changes. This
should avoid doing a lot of work with large font collections when only
the theme has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=748782
This is purely to support gdk_cursor_new_from_name().
In particular, its counterpart, gdk_cursor_new_for_display(), will not
be affected, because there's no GDK_LEFT_PTR_WATCH cursor type,
and because i don't have a fallback cursor bitmask for gdk/win32/xcursors.h
Add a new API, gtk_popover_set_default_widget, that can be
used to make a widget act as default while the popover is
shown. This is useful in dialog-like popovers.
http://bugzilla.gnome.org/show_bug.cgi?id=747664
We interpret buttons 4-7 as old-school scroll events, so it does
not make sense to add these to the mask. Also fix an off-by-one
in the loop here, buttons_mask is 1-based.
Making a container focusable is rarely the right thing to do.
It typically breaks the focus chain, and makes the container
contents unfocusable, as was the case here.
We have a number of cases where properties should have their
default value overridden in a subclass, but haven't because thats
annoying to do. We also have properties where the absence of
an explicit value has context-dependent meaning.
Add a list of exceptions for these cases.
The previous commit removed default-valued properties,
but apparently that has a negative effect for grid
packing properties, so put the explicit value back.
Just using tracker does not work well if you are searching in
non-indexed locations, such as git checkouts or network mounts.
Ideally, we'd decide the 'best' engine to use for each location.
Since that is not easy to do, just run them in parallel for now,
which is the same strategy that nautilus uses.
We now have proper checks for gdk_screen_is_composited() and a proper
implementation for gdk_screen_get_rgba_visual() for Windows, so we
can remove the comments in this file stating that they aren't
available for Windows.
Catch an error that indicates the file looks like a template,
and then try again, this time with the template parsing API
of GtkBuilder. This is a little iffy, since we need to create
a 'fake' type and instance to pass in, but it works ok in
simple tests.
Add the class and parent class name to the error message.
gtk-builder-tool will parse the error message and use the
class names for trying again to parse the file as a template.
I was getting really weird values for scale for the blank cursor used
when hiding the cursor in a GtkEntry when typing, this was caused
by gdk_wayland_device_update_window_cursor sending random values
when the returned buffer was NULL.
We fix this by just not sending any buffer or scale updates in this
case.
Requires Vista and newer.
* Create surfaces with cairo_win32_surface_create_with_format
* Provide an rgba visual that can be distinguished from the system visual
* Make rgba visual the best available visual
* Enable alpha-transparency for all windows that we control
* Check for appropriate cairo capabilities at configure time
(W32 - 1.14.3 newer than 2015-04-14; others - 1.14.0)
* Check for composition support before enabling CSDs
* Re-enable transparency on WM_DWMCOMPOSITIONCHANGED
Windows that were created while composition was enabled and that were CSDed
as a result and will look ugly (thick black borders or no borders at all) once
composition is disabled.
If composition is enabled afterwards, they will return back to normal.
This happens, for example, when RDP session is opened to a desktop where a GTK
application is running. For W7/Vista windows will only re-gain transparency after
the RDP session is closed. For W8 transparency will only be gone momentarily.
Windows that were created while composition was disabled will not be CSDed
automatically and will use SSD (WM decorations), while windows that are CSDed
manually will get a thin square border.
If composition is enabled afterwards, these windows will not change.
This is most noticeable for system menus (popup menus are often generated
on the fly, system menus are created once) and some dialogues (About dialogue,
for example).
https://bugzilla.gnome.org/show_bug.cgi?id=727316
Without this change, out-of-tree distcheck doesn't get very far.
Similarly, allow *.vcxproj, *.props to be in either the builddir or
the srcdir.
Finally, since I'm touching these lines anyway, eliminate some
useless uses of cat: "cat x | sed 's/foo/bar/' > y" is
equivalent to "sed 's/foo/bar/' < x > y".
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=748176
Reviewed-by: Chun-wei Fan <fanchunwei@src.gnome.org>
Add a convenience function that is like gtk_builder_get_object()
but stashes away a GError if a lookup fails. To make the error
message informative, the function takes a line/column pair.
Doing things this way is necessary because the custom_tag_end,
custom_finished, and parser_finished vfuncs don't take a
GError parameter, despite being called from a place where
we can report a GError back.
GdkKeymap already has support for _get_num_lock_state() and
_get_caps_lock_state(). Adding _get_scroll_lock_state() would be good
for completness and some backends (Windows?) could take advantage of
this.
We want to clear the style property cache whenever things change in the
tree, not as we previously did only when those changes actually lead to
a different CSS style.
isatty() on MSYS2 returns non-zero if the fd is stdout and is redirected
to /dev/null. That lets xgettext to produce colorized output and leads
to an assertion failure during terminal type detection.
Although the problem should be fixed in MSYS2, isatty() could behave
wrongly in many ways on Windows. Since gtk+ doesn't need colorized
output, it would be safer to bypass the terminal dependent code.
See also:
https://lists.gnu.org/archive/html/bug-gettext/2015-04/msg00004.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=748346
Instead of issuing g_warning, fill the provided GError.
This lets us test this error handling, and is the right
thing to do. Use the new GtkBuilder helpers and
g_markup_collect_attributes to do so.
Instead of issuing g_warning, fill the provided GError.
This lets us test this error handling, and is the right
thing to do. Use the new GtkBuilder helpers and
g_markup_collect_attributes to do so.
Instead of issuing g_warning, fill the provided GError.
This lets us test this error handling, and is the right
thing to do. Use the new GtkBuilder helpers and
g_markup_collect_attributes to do so.
Instead of issuing g_warning, fill the provided GError.
This lets us test this error handling, and is the right
thing to do. Use the new GtkBuilder helpers and
g_markup_collect_attributes to do so.
Instead of issuing g_warning, fill the provided GError.
This lets us test this error handling, and is the right
thing to do. Use the new GtkBuilder helpers and
g_markup_collect_attributes to do so.
Instead of issuing g_warning, fill the provided GError.
This lets us test this error handling, and is the right
thing to do. Use the new GtkBuilder helpers and
g_markup_collect_attributes to do so.
Instead of issuing g_warning, fill the provided GError.
This lets us test this error handling, and is the right
thing to do. Use the new GtkBuilder helpers and
g_markup_collect_attributes to do so.
Instead of issuing g_warning, fill the provided GError.
This lets us test this error handling, and is the right
thing to do. Use the new GtkBuilder helpers and
g_markup_collect_attributes to do so.
Instead of issuing g_warning, fill the provided GError.
This lets us test this error handling, and is the right
thing to do. Use the new GtkBuilder helpers and
g_markup_collect_attributes to do so.
Instead of issuing g_warning, fill the provided GError.
This lets us test this error handling, and is the right
thing to do. Use the new GtkBuilder helpers and
g_markup_collect_attributes to do so.
Instead of issuing g_warning, fill the provided GError.
This lets us test this error handling, and is the right
thing to do. Use the new GtkBuilder helpers and
g_markup_collect_attributes to do so.
Instead of issuing g_warning, fill the provided GError.
This lets us test this error handling, and is the right
thing to do. Use the new GtkBuilder helpers and
g_markup_collect_attributes to do so.
Add two new requests to the gtk_surface interface: set_modal and
unset_modal. The server will currently not do anything special with
input focus, and its up to the client to ignore events on the parent
surface.
This commit bumps the gtk_shell interface version to 2. By connecting to
a Wayland server with another gtk_shell interface version any features
depending on the gtk_shell protocol will not be available.
https://bugzilla.gnome.org/show_bug.cgi?id=745721
cairo_rectangle_int_t was replaced by GdkRectangle in commit
552c29b488, but the type of the pointing-to
property was not changed.
To avoid breaking old code that sets or gets the property with a GValue
of type CAIRO_GOBJECT_TYPE_RECTANGLE_INT, transformation functions between
CAIRO_GOBJECT_TYPE_RECTANGLE_INT and GDK_TYPE_RECTANGLE are registered on
the first call to gdk_rectangle_get_type().
https://bugzilla.gnome.org/show_bug.cgi?id=723394
gdk_wayland_drop_context_set_status() can't do much else currently besides
picking a mimetype (the first one is currently chosen). This may incorrectly
unset the mimetype chosen on .receive(), so the transfer is cancelled before
it even starts.
At the time drop_reply happens, we should have already picked a mimetype
along the way, so only cover for accepted=FALSE in order to unset it.
During drag operations from another client, we currently set no window as
the DnD source. There's paths in upper layers though that rely on it being
set, just that we don't trigger these yet.
Make use of pattern rules when generating the Visual Studio 2012/2013
Projects from the Visual Studio 2010 projects, which will help to clean up
the file and also avoid problems when running items like 'make -jN dist'.
This reverts commit 24d3f3fcb2.
Sorry, I am going to re-commit this very shortly with a new
commit message, as I found the commit message to be quite
wrong and misleading.
The current GdkScreen->is_composited() is a stub as we were having Windows
XP being supported, which does not support Desktop Window Manager (DWM),
which is used by Windows for composition.
Windows Vista and later support DWM, and it is always enabled on Windows 8/
Server 2012 and later.
Please note that as we are dropping XP support in this cycle, this is the
commit that would say goodbye to Windows XP support for GTK+-3.x, by
linking directly to dwmapi.dll. This means, we only check whether we are
on Windows 8 or Server 2012 (or later) to see whether we unconditionally
have composition enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=741849
To calculate the shadow width, we look at the value of priv->fullscreen
and priv->maximized.
Those fields will have the actual value only after GTK receives back a
window state event though, so they will be wrong in _realize(). Look at
priv->fullscreen_initially and priv->maximize_initially too, to avoid
the size changing right after realize, which would make the window
flicker if maximized at startup.
https://bugzilla.gnome.org/show_bug.cgi?id=747808
Libinput will use 0.0f on the "scrolling finished" event, so check for this
instead of rounding (<1 values are sort of frequent on touchpads). This
impedes bug #745315 to resurface after commit d563b943ed.
When the scrolledwindow receives scroll events, it ensures the timeout to
maybe start the "snap back to edges" animation is reset, but it does nothing
about the animation source. It must be reset just the same, to maybe be
started after the timeout fires up.
Added another :not() to fix the first and last swatches in the
first section of colorpicker.
Dodge the artifacts due to stacked anti-aliased rounded corners by
increasing the radius of the base object by 1px.
We were only updating window buttons when the headerbar was
a direct child of the window. That is not the case in more
complicated situations, such as the split headers in gedit
or polari. To fix such cases, make the headerbar itself listen
for state changes on its toplevel.
https://bugzilla.gnome.org/show_bug.cgi?id=747805
This used to do the right thing, practically ignoring those event
if they went all through the event handler, unless this motion event
triggered the cancellation of this gesture from the event handler
of another controllers.
In this case, the controller would be reset, but the motion event
would still go through its handler, setting again
current_button/sequence as the motion event has buttons in its
modifiers. This leaves GtkGestureSingle with inconsistent data
that may interfere with future runs.
https://bugzilla.gnome.org/show_bug.cgi?id=747469
The code managing scrollbars visibility was too pervasively checking for
mouse devices, leaving pen/eraser/cursor devices with no scrollbars at
all. Relax these checks a bit, and actually toggle full-width scrollbars
on pen/eraser devices, so it is an easier target.
https://bugzilla.gnome.org/show_bug.cgi?id=747608
XSetWindowBackgroundPixmap() will throw BadMatch only in the case of a
different parent window depth. Different visuals are fine and actually
expected in Gtk+ 3.16 (since we don't stick to the system default visual
but try to pick a better one).
https://bugzilla.gnome.org/show_bug.cgi?id=747524
Since windows can be intermediate containers this is somewhat redundant,
plus gtk_window_size_allocate() will do additional things like allocating
the popovers, which was mistakenly skipped by local plugs not chaining up.
https://bugzilla.gnome.org/show_bug.cgi?id=747553
This is a workaround for atspi-atk behaviour.
atspi-atk uses signal emission hooks. So it to already catches
signal emissions on creation of objects, before anyone could even
think of g_signal_connect()ing.
https://bugzilla.gnome.org/show_bug.cgi?id=746706
gtk_application_shutdown clears the impl member, so all
callbacks, signal handlers, etc that might still be triggered
between a shutdown call and the return from the mainloop
better be prepared to deal with impl being NULL.
strcasecmp() is unfortunately not universally available, along with
strings.h. Fix the build by replacing strcasecmp() with
g_ascii_strcasecmp(), and remove the strings.h include.
https://bugzilla.gnome.org/show_bug.cgi?id=747604
When we open the connection, we get the wl_output object,
but we return before all the information such as monitor
geometry has arrived, which causes us to misinform early
users of this information. Do a roundtrip here that causes
us to wait until the information is complete. Do the same
for seats, just in case.
https://bugzilla.gnome.org/show_bug.cgi?id=747471
When a treeview is destroyed while rubberbanding is going
on, we crash because the rb tree is nuked before we want
to access it to stop the rubberbanding. To avoid this crash
end the rubberbanding early in destroy().
See
https://bugzilla.redhat.com/show_bug.cgi?id=1173904
It can apparently happen that we get focus in events
on windows after gtk_application_shutdown() has been
called. Avoid an unnecessary crash in this case.
See
https://bugzilla.redhat.com/show_bug.cgi?id=1176339
The coordinate translations here were not working properly
for window widgets inside the scrolled window, as can be
seen e.g. for the horizontal scrollbar of the 'Tree View'
example in gtk3-demo.
https://bugzilla.gnome.org/show_bug.cgi?id=747406
When moving over a non-expanded indicator from the outside, we were
not expanding it, due to on_scrollbar being true. This can be seen
e.g. when moving from the content pane over to the sidebar indicator
in gtk3-demo. We must still ensure that the indicator is expanded
when receiving motion events over the indicator.
https://bugzilla.gnome.org/show_bug.cgi?id=747407
The gtk_label_set_text() and gtk_label_set_markup() functions have
various side effects that ought to be documented, especially for
non-C developers using properties directly.
https://bugzilla.gnome.org/show_bug.cgi?id=747121
Use cursor names instead of font cursors, so we can also show
cursors that are not represented in the X cursor font and thus
don't have a value in the GdkCursorType enumeration.
This path is only intended to be triggered on events directed towards the
child of the scrolledwindow, so make it explicitly so. This avoids scrollbar
"over" state flashing when dragging finishes within the slider.
https://bugzilla.gnome.org/show_bug.cgi?id=746961
The "app_id" of a xdg_surface should be the ID that can potentially be
used to get the DBUS name or the .desktop file.
For GtkApplication programs this is often the ID passed when creating the
GtkApplication object, so when available lets use that.
As fallbacks, first try g_get_prgname as it often corresponds to the
basename part of the .dektop file for non-GtkApplication programs.
Otherwise use gdk_get_program_class, even though that string usually
doesn't conform to the expectations of xdg_surface.set_application_id.
https://bugzilla.gnome.org/show_bug.cgi?id=746435
If the icon happened to come from the drag site icon helper (ie. set through
gtk_drag_source_set_icon*), it would be referenced on the GtkDragInfo,
but not hooked into its context. This results on non visible drag windows,
until set_icon_helper() happened to be called on some path.
GtkRadioButton had a deficient copy of the focus sort code
in GtkContainer, causing focus to jump over the next button
in the list. Just use _gtk_container_focus_sort() here,
which fixes the bug _and_ saves 80 lines of code.
https://bugzilla.gnome.org/show_bug.cgi?id=746817
As of 74405cc, progress bars use a new design with values drawn on top
(or to the left) of the through instead of inside of it. This change
brought a number of regressions: the min-horizontal-bar-height and
min-vertical-bar-width style properties are not respected anymore. For
vertical progress bars, the value was drawn too close to the bar and not
centered vertically.
Fix this by respecting the style properties and drawing the value label
at the correct position.
Also, the xspacing and yspacing properties didn't server any apparent
purpose. Change their semantics to mean "the spacing between the label
and the bar". Hence, they only need to be added to the size request when
showing the label. Since we are changing semantics anyway, reduce their
default values from 7 to 2, to avoid and excessive gap.
https://bugzilla.gnome.org/show_bug.cgi?id=746688
Make it possible to control libcanberra support so we don't risk ending up with
a cyclic dependency when using packages: gtk+ -> libcanberra-gtk3 -> gtk+
https://bugzilla.gnome.org/show_bug.cgi?id=746904
As it is, GtkListBox model binding will work nicely as long as your
create_widget_func returns a floating reference on the newly-created
widget.
If you try to return a full reference (as any higher-level language
would do) then you will leak that reference.
Fix that up by converting any floating references into full references
and then unconditionally releasing the full reference after adding to
the box.
https://bugzilla.gnome.org/show_bug.cgi?id=746893
If the GLX_EXT_texture_from_pixmap extension is not available when we
did the extensions check, then there's no point in using the backend
specific code paths that rely on it.
Use screen workarea to *also* set the position of a maximized window,
not just its size. Without this the window position defaults to 0:0
(the topleft corner), which is wrong when taskbar is position along the
top or left edge of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=746821
I managed to stall recent files today while trying to save a GTK
testcase in glade that contained enough spinning spinners that the CPU
was saturated just redrawing things.
I had to navigate the filesystem!
The direction in which the slider moves can be inverted by setting the
inverted property. But the draw method does not check this, instead it
checks if the direction of the widget is set to be right to left.
Call the should_invert function in order to determine if the direction
of the range should be inverted. It too checks the widget's direction,
but also checks the "inverted" property, and allows the range to be
drawn inverted even if it is vertically oriented.
https://bugzilla.gnome.org/show_bug.cgi?id=746712
Put the equality check in front. This allows better detection of when an
insert or delete needs to be emitted.
Also, only emit text-changed:delete if the deleted text is not the empty
string. Only emit text-changed:insert if the inserted text is not the
empty string.
https://bugzilla.gnome.org/show_bug.cgi?id=746706
Compute the new text and its length in advance. This way those
computations will not confuse us when they happen in the middle of the
actual action.
https://bugzilla.gnome.org/show_bug.cgi?id=746706
Compute the proportion of the range that should be filled to match the
fill level, and use it to compute the starting point and length of the
area between the slider and the fill level.
https://bugzilla.gnome.org/show_bug.cgi?id=734741
When recomputing CSS, we need a correct widget path in the fallback mode
where we're still using widget paths.
So we need to invalidate it everytime it actually changes, and not just
when emitting the style-updated signal.
Fixes css-match-regions reftest.
Clang complains that this check can never be true. Since this
is a argument range check which we do to catch bad input,
convince clang to not complain instead of taking it out.
clang complains that the expression involving sqrt() is not
constant, and thus refuses to accept it as a case label. So,
use precomputed values instead.
https://bugzilla.gnome.org/show_bug.cgi?id=746468
Break out a setter that manages the weak pointer, and
use it in finalize. This also fixes a bug where we were
forgetting to disconnect the right signal handler in
some cases.
The other Radio* widgets have this convenience method that removes the
memory management of the opaque GSList used to handle the group from the
API usable from language bindings (especially the ones not based on
introspection).
This commit adds gtk_radio_menu_item_join_group().
https://bugzilla.gnome.org/show_bug.cgi?id=671362
Some arguments, like the group and the label of a RadioMenuItem, can be
NULL: the RadioMenuItem has all the code to deal with them. The argument
validation is too strict, though, for instance doing:
return_if_fail (IS_RADIO_MENU_ITEM (foo))
if (foo != NULL)
set_foo (foo)
Which is obviously incorrect.
This commit also modifies the annotations of the API, to ensure that
language bindings do the right thing.
https://bugzilla.gnome.org/show_bug.cgi?id=671362
If we create a RadioMenuItem without a group, and then set a group, the
menu item will still be set as active, which means an inconsistently
drawn radio menu item - as the RadioMenuItem will set the active flag on
itself, but then it won't reset it when it gets a new group.
https://bugzilla.gnome.org/show_bug.cgi?id=671362
It turned out that using mwm hints to instruct wms to
create border-only decorations is not really working
universally. So, instead of doing this, render a solid
frame without shadow on the client-side to handle this
case.
https://bugzilla.gnome.org/show_bug.cgi?id=746222
Signed-off-by: Olivier Fourdan <fourdan@xfce.org>
If the widget has been destroyed since a DBus message had been sent,
we could be in a condition that the widget pointer exists but it does
not have a window.
This bails as if the widget didn't exist if there is no available
GdkWindow.
We also set the extents to 0 to be defensive since this is a vfunc
implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=746586
Since these part really are the same in all of the x or y direction
and we don't blur in that direction we can just blur one line and
repeat it during drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=746468
There is no need to e.g. blur in the x-direction for the top part
of a box shadow. Also, there is no need to extend the mask in the
non-blurred direction.
https://bugzilla.gnome.org/show_bug.cgi?id=746468
For radius 1px the current implementation rounds down to a 1 px box
filter which is a no-op. Rather than creating useless shadow masks
in this case we bail out blurring early.
Another alternative would be to make radius 1px round up to a 2 px box
filter, but that would change the rendering of Adwaita which is probably
not a great idea this late in the cycle.
https://bugzilla.gnome.org/show_bug.cgi?id=746468
gtk-reftest already had an --output=DIR option to tell it where
to save all the resulting images. Now you can combine this with
the --compare-with=DIR option in a second run to make gtk-reftest
compare the .out.png files from the first run with the .out.png
files of the current run, instead of producing .ref.png files.
The intended use for this is to verify that changes do not affect
the generated output.
During copy/paste, it may be common that we receive several property changes
around the selection atom, this results in warnings when cancelling the previous
write attempt. We already honor the last request properly, so we should just
cancel silently.
Sometimes path nodes can survive longer than the style context that
created them. Don't crash in those cases.
Fixes startup of mutter.
Testcase included.
https://bugzilla.gnome.org/show_bug.cgi?id=746407
This allows monitoring the CSS tree. For now, moving a child to a
different position relative to its siblings while keeping the same
parent will cause a child-added + child-removed emission.
We need to properly track if a node needs to propagate invalidation
state information to its children. We didn't do this properly before and
that could lead to us forgetting to invalidate nodes in corner cases.
Do not propagate the TIMESTAMP change through the node tree, as that
causes lots of uneeded markings of nodes as invalid.
Instead, walk the node tree and find the nodes that have a non-static
style and only invalidate timestamps on those.
Only invalidate timestamps if the node is marked as invalid. We overload
the meaning of "invalid" as "tracks timestamps".
While I don't like the way this is written, it is an important
optimization because 95+% of nodes don't animate so timestamps don't
matter to them. But timestamps are invalidated 60x per second.
We don't return a NULL style to mean "no changes" anymore, instead
we check new_style == old_style to mean that.
Make sure the code reflects this, otherwise we'll send
GTK_CSS_CHANGE_PARENT_STYLE invalidations everywhere and screw up
performance.
Now that the widget node recomputes styles on update_style() we can just
call it during validate(). That way, we don't need the widget node to
manually compute its style.
If CSS values are queried from a widget, recompute them if necessary. Do
not emit style-updated until the validation phase however.
This way, we don't run into performance traps when style-update causes
invalidations that cause new style-updated to be emitted.
... and pass it to the API that computes new styles.
A special timestamp of 0 means "please don't animate" and is used when
no frame clock is available for a node.
This is mainly an attempt to merge the update_style() and validte()
vfuncs. Code is not there yet, but that's the idea.
Also, gtk_css_node_set_style() should not be public. And this gets
closer to that goal, too.
After measuring it, I realized the optimization never triggers for
Adwaita and rarely ever triggers for simple themes. So it is not
useful to keep it around.
This allows adding more API for it.
It also includes code that tracks modifications and invalidates siblings
and their positions whenever nodes get added or removed.
If we know the parent's get_path_for_child() implementation is safe to
be used with GtkCssNode because it doesn't do anything special, we do
that. Unfortunately that requires whitelisting vfuncs because the vfunc
is public API so anyone can override it.
Instead, use gtk_widget_get_path() which makes GtkWidget cache the path.
This is a temporary solution until we can get rid of widget paths.
This increases memory usage quite noticably.
The node declaration has the same functionality as
gtk_css_node_declaration_add_to_widget_path(). So instead of using that
function on a path, you can use the original path and the declaration in
a matcher.
So far the vfunc is kinda quirky (the path argument is an out argument
for something you have to free when you're done with the matcher), but
I'm about to change that.
We don't want to add the current classes to the widget path - which
might potentially be different after a gtk_style_context_save() - but
the root node's ones. So what better thing to do than actually using the
root node?
Instead of directly requesting the layout phase, register a tick
callback. This is what the docs suggest for animations and it's what we
need for the next commit.
... to a bunch of functions.
This requires a tiny change to the heuristics for the style cache - we
now cache styles when they have the same style provider as their parent
instead of when they have the default provider - but that change doesn't
have any effect in practice.
The parent refs the child, so gtk_css_node_set_parent() adds/removes a
reference.
We should probably refactor this so that we name the function
parent.add(node) instead of node.set_parent(parent) - makes the
refcounting more clear.
Instead of passing the style declaration, take the node's style
declaration. Add arguments to allow overriding the state for the one
case where this didn't work.
The code is confusing the stylecontext=>node transition, so I'll remove
it.
WIth the recent introduction of the parent style cachen, I'm not sure
it's worth it at all. Some crude benchmarking suggests a slight speedup
when removing the cache.
So no guarantees about adding it back later.
- GtkCssWidgetNode
for style contexts owned by a widget
- GtkCssPathNode
for style contexts using a GtkWidgetPath
- GtkCssTransientNode
for nodes created with gtk_style_context_save()/restore()
The functionality of it is supposed to grow, so better put it in a
custom file early.
This is just a naive split so far, the next patches will split things
further.
The wl_data_source may be the clipboard's. Looking up the drag context in
order to get the display isn't going to fare well there. So, just use the
default display, and only look up the drag context when we know we need it.
https://bugzilla.gnome.org/show_bug.cgi?id=746386
This commit adds the GtkTextTag:underline-rgba and :strikethrough-rgba
properties and the necessary plumbing to apply these colors in GtkTextLayout.
With this change, you can alter the color of underlines including those
of type PANGO_UNDERLINE_ERROR.
You might want to alter the underline color to differentiate between
spelling and grammer mistakes. In code editors, it is convenient to
differentiate between errors and warnings.
Note that the GtkTextAppearance struct is public ABI and has no spare
room for new fields, so we are resorting to some tricky packing to store
the colors in the unused pixel field of the fg_color and bg_color structs.
This packing is accomplished by the macros in gtktextattributesprivate.h.
Signed-off-by: Christian Hergert <christian@hergert.me>
https://bugzilla.gnome.org/show_bug.cgi?id=402168
It has been a long-standing request to interpret scroll events
with Shift held down as horizontal instead of vertical, and
some applications are already doing this on their own.
https://bugzilla.gnome.org/show_bug.cgi?id=132197
This causes pixman warnings, or worse.
Clearly, something is not quite right here, if we end up
redrawing tabs at a time when the allocation is set to (1, 1).
For now, avoid straining the error handling in the lower layers.
https://bugzilla.gnome.org/show_bug.cgi?id=746301
On popover_unmap(), perform the gtk_widget_unmap() call last, so the
GtkWindowPopover data is ensured to be alive throughout the function
if the popover widget is destroyed right on ::unmap.
https://bugzilla.gnome.org/show_bug.cgi?id=745829
This ensures the widget data stays live long enough to perform invariants
check after emission if the widget happens to be destroyed on a callback.
https://bugzilla.gnome.org/show_bug.cgi?id=745829
We are testing -gtk-icon-style and assume the theme doesn't touch it.
But HighContrast forces symbolic icons. And that breaks the reference
images.
So explicitly set "requested" for everything.
Support scaling of cursors created from themes. The default scale is
always 1, but if the pointer cursor surface enters an output with a
higher scale, load the larger version of the cursor theme and use the
image from that theme.
This assumes the theme size is set to one that fits with an output scale
= 1.
https://bugzilla.gnome.org/show_bug.cgi?id=746141
The setting of the the surface scale even when the surface is not
created from a surface was introduced due to a crash when getting the
buffers when dividing by the scale. The only reason I can see this is
that we get the buffer from a non-existing surface when the wl_cursor
has not yet been set.
Instead, use the name field to avoid trying to use the non-existing
surface, effectively avoiding the division-by-zero that way.
https://bugzilla.gnome.org/show_bug.cgi?id=746141
`bundle install` command on fedora 21 was failing
with following message:
Your Gemfile has no gem server sources. If you need
gems that are not already on your machine, add a line
like this to your Gemfile:
source 'https://rubygems.org'
After adding that line it worked again.
https://bugzilla.gnome.org/show_bug.cgi?id=746205
With the 3.0 transition, this code went from just querying the entry's
height request to doing a full size request.
Then it got code to revert the features that a full size request does.
And then it grew code that manually computed the baseline.
Avoid this and just do what happened back in the days: Do a regular
height request.
This changes the semantics of the get_frame_size() vfunc wrt its
behavior towards subclasses overwriting the get_height() vfuncs, but I'm
happy to live with that.
Applications forget to set the follow-state property and then some
themes used a style where normal symbolic icons have the same color as
prelit or selected backgrounds and that suddenly made icons invisible
and who wants that?
https://bugzilla.gnome.org/show_bug.cgi?id=746201
Rework the way we assign an accessible name to menu buttons,
to make sure we pick up a label, should the button contain
one, and only override the name with "Menu" as a fallback.
It seems to be buggy in ways that make the test fail
with a critical when the test bus is brought down.
At the same time, drop manual settings of environment
variables that we can set globally.
This reverts commit 63f59dde3a.
It turns out, the state was not just necessary for style computation,
but also for tracking RTL and LTR. And so it broke the reftests.
gtk_tree_selection_real_modify_range() has a g_return_if_fail() if the
start or end paths passed to it do not correspond to real tree nodes.
However, GtkTreePaths inherently do not have to be valid, so it should
be acceptable to call gtk_tree_selection_select_range() with
non-existent paths. Replace the g_return_if_fail() by a silent return,
and add a unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
The gtk-shell Wayland protocol extension is not meant to be backward
compatible right now, so avoid binding to any version that is not the
one supported.
https://bugzilla.gnome.org/show_bug.cgi?id=745721
We need to filter out platform-specific sources from the files that we
use with the introspection scanner.
In this specific case I could have moved the gtkclipboard-quartz.c and
the gtkdnd-quartz.c files out of the $(gtk_base_c_sources) variable, but
doing a filter-out on the variable itself is more resilient in case we
eventually add files and we forget about the result.
Now that this is split in two separate gestures, both must be reset
when the WM grabs the pointer. Also, do on resize drags like on move
drags, and claim the gesture before resetting, so the ownership is
properly transferred across any other widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=745969
gtk_entry_set_completion() (and _gtk_entry_completion_connect underneath)
may happen when the entry has no toplevel yet. This window acts as the
"parent" for subsurface windows on wayland, and is indispensable to create
its backing wl_subsurface, so this resulted in non-visible popups there.
Fix this by ensuring transient_for is set before showing the popup.
https://bugzilla.gnome.org/show_bug.cgi?id=745463
This reverts commit fb9a6bb6d8.
In a recent test, I've found that Xfce and Mate now support
this, so they will not be affected by this requirement. And
adding the check back will solve the 'client-side shadow'
problem in KDE.
The page_setup of a GtkPrintContext or GtkPrintUnixDialog is nullable,
so all reference count changes to it have to be guarded against NULL
values.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
_gtk_rbtree_first() can potentially return NULL if the RB tree is empty,
which would result in NULL pointer dereferences in the GtkTreeSelection
code. Gracefully handle them.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
These vfuncs cannot be NULL: implementations are provided by GtkEntry,
and subclasses should not set them to NULL. Instead of conditionalising
the calls to the vfuncs, assert that they’re set and call them
unconditionally.
This prevents the possibility of a subclass setting the vfunc to NULL
and then a gtk_entry_get_*_size() call returning undefined values in its
out variables.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
gdk_window_ensure_native() can end up with a NULL parent pointer, which
it passes to find_native_parent_above()…but that expects a non-NULL
parent.
Found with scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
If auth_info_required is only set to "negotiate" the
request password dialog is shown anyway for each print
job without any input fields. As the request_password
dialog only handles username, password and domain.
https://bugzilla.gnome.org/show_bug.cgi?id=669008
They are a bit terse, and they should point to the preferred way of
overriding the theme, i.e. using a GtkStyleProvider for your
application, and custom style classes.
When the scrollbars are overlayed, the size requisition of the
scrolled window should not depend on whether the scrollbars are
visible or not. This was not quite the case, because we forgot
one case where scrollbar size was still added to the requisition.
This is somewhat tricky to work out, so put some example
code here for future reference. The tricky part is that
GtkAccelLabel tries to be smart about hiding the accel
if there's not enough space, so we have to make sure to
pack the label with expand=TRUE and set align=GTK_ALIGN_FILL,
or things won't work.
Make sure that variables are declared at the top of the block.
Break up one of the sincos() calls into individual calls to sin() and cos()
so that we do not have to complicate the initialization of the following
GLfloat array.
If the user requests a version less than 3.2 the version is forced to 3.2.
Previous checking code have an inconsistent behavior depending on which
minor version number was specified. This is avoided now by temporarily
converting the major/minor pair into a single integer.
https://bugzilla.gnome.org/show_bug.cgi?id=744288
There was an added check in configure.ac for sincos() for gtkgears.c, where
that function is actually a GCC- and glibc-specific extension, which is
not available on Windows. Reflect on this in config.h.win32.in for the
Visual Studio/Windows builds.
"Install" the .pdb files that were generated along with the build, to make
it easier for people to develop and debug GTK+, especially when used as a
stack, and as the .pdb files are already generated with all builds.
Also make the copy of the .dll, .lib and .exe files more selective so that
we do not accidently copy files that are not meant to be "installed", or
end up making extra copies of plugin DLLs in the wrong places, when the
projects here are included as a part of a grand solution that is used to
build the entire GTK+ stack, for example.
For Visual Studio 2010 and later, the .pdb filename needs to be explicitly
specified so that it will match the filename of the target, if the project
name differs from the filename of the target. Make sure that is the case
for the 3 DLLs that we build for Visual Studio 2010 and later.
Postpone until the last moment whether the target widget still
potentially uses updates from this sequence, or window dragging
actually applies because all gestures on the target went to denied
state.
This fixes window dragging on empty space in a headerbar that is
contained in a paned (as in e.g. gedit).
https://bugzilla.gnome.org/show_bug.cgi?id=745562
These types are not covered by g_test_register_all_types,
and having the types registered when a print dialog is used
helps in cases where GTK+ is dlopened.
https://bugzilla.gnome.org/show_bug.cgi?id=745065
GtkPlacesSidebar applies a sorting function on
the tree model that does not consider the case
of bookmarks, which are sorted by their indexes.
By adding the bookmarks corner case and comparing
then by their indexes, GtkPlacesSidebar can sort
the bookmarks properly in the order they're saved.
https://bugzilla.gnome.org/show_bug.cgi?id=744589
This signal can be emitted by GtkSearchEntry after search has been
cancelled, and other operation mode is set. It doesn't make sense to
populate the search model in that state anymore, so just avoid doing it.
https://bugzilla.gnome.org/show_bug.cgi?id=745479
The object might be destroyed when mid operation, causing crashes as the
query callback still expects the object pointer to be valid. Also, remove
the gdk_threads_enter/leave pairs, the callback will be executed on the
caller (UI) thread, so this is not necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=745479
The search engine might stay alive longer due to extra temporary refs, so
the signal handlers should be removed for the filechooser to ignore these
properly.
https://bugzilla.gnome.org/show_bug.cgi?id=745479
Use the /MP compiler option, where the build time for release builds can
be cut down by quite a bit. This will however cause a brief warning with
debug builds due to the use of /Gm, but the code will otherwise build
normally. Unlike the Visual Studio 2010+ builds, we can't use /d2Zi+ as
Visual Studio 2008 does not support that, so we can't get a better
debugging experience for release builds here.
Use Multiprocessor compilation which can cut down build times by quite a
bit and use the /d2Zi+ flag to have better debugging info being logged to
the .pdb for release builds.
These are only applicable for Visual Studio 2010/2012 and later.
This file now uses round(), which was not available until C99, so include
fallback-c89.c instead of math.h, which includes math.h and does a fallback
implementation of round().
Instead of using glxgears, which still uses OpenGL 2.1 and the fixed
pipeline, we use a slightly modified es2gears, OpenGL 3.2, and the
programmable pipeline.
Avoid scrolling animation when scrolling to where we want
to insert the new folder, since adding the entry doesn't
do the right thing if the treeview is still scrolling.
An alternative would be to wait for the animated scrolling
to reach its target before starting the editing, but this
is easier.
https://bugzilla.gnome.org/show_bug.cgi?id=729366
And use these for the missing axes if the valuator mask is incomplete.
This used to work fine on tablets because the Wacom driver ensures all
valuators are sent, which is not true if using the evdev driver.
https://bugzilla.gnome.org/show_bug.cgi?id=703610
This is not specified specifically by the attached controllers, so let
the scrolledwindow set the mask, as motion events with no buttons pressed
are interesting to it.
https://bugzilla.gnome.org/show_bug.cgi?id=745344
When a window is hidden, its surface and all its roles are destroyed,
if this happens when we already issued a wl_surface_commit and are
awaiting for a frame callback, the clock will remain frozen for the
next time the window is shown.
To avoid this, keep track of the wl_surface_frame() calls issued,
and ensure the clock is thawed after hiding. If we happen to receive
the frame callback, it is just ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=743427
The gesture is hooked to the capture phase, so it works for buttons in
header bars and whatnot. In order to be friendly to the widget it is
capturing events from, an ugly hack is in place to avoid capturing
events when the target widget has a gesture that would consume motion
events.
This happens on button release, which is more convenient if the gesture
can be consumed by something else (eg. window dragging), and already behaves
correctly wrt cancelled gestures, broken grabs, etc.
This also allows us to unify pointer and keyboard behavior, popping up the
menu widget in a single place.
There are two scenarios. A widget sub-class owns a GtkEventController
and passes itself to it, or a controller owned by something else is
passed a widget.
In the second case, if the widget is destroyed before the controller,
we will have a crash when destructing the controller because we will
be accessing invalid memory. Adding a weak reference on the widget
addresses that problem.
This leads to a crash in the first case. When the widget is getting
destroyed, it will drop the reference to its own controller. The
controller will skip touching the widget because the weak reference
would have turned it to NULL. However, when the widget sub-class chains
up to GtkWidget it will try to free all the controllers in its list.
Unfortunately, all these controllers have already been destroyed. So
we need to guard against this too.
https://bugzilla.gnome.org/show_bug.cgi?id=745225
We were trying to start search when the user types anything,
but this is annoying more often than helpful, and interferes
with the location entry. So, stick with explicitly enabled
search (via the search button or Alt-S) for now.
We were just throwing the request away if the app asks to
fullscreen or maximize a window before it has been mapped.
This is something the GdkWindow API explicitly supports,
so make it work by saving the state until the surface exists.
This fixes things under weston. There are bugs in mutter
that keep this from working correctly with gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=745303
When the Wayland compositor vanishes, all applications connected will
receive a SIGPIPE as soon as they try to use wl_display_dispatch().
Do not use g_error() to terminate the applications when this occurs,
g_error() means an error in the application while here it's not truly
the case.
Use g_warning() and exit() instead.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=745289
Although gtk_list_box_row_grab_focus() is not a public function
it can be easily called by gtk_widget_grab_focus() with a row argument
which has been removed from the list box and has box == NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=744879
The height of the text buttons depends on the font height,
whereas the search button has a fixed-size icon in it...
Prevent unevent heights by putting them all in a size group.
https://bugzilla.gnome.org/show_bug.cgi?id=745263
The height of the text buttons depends on the font height,
whereas the search button has a fixed-size icon in it...
Prevent unevent heights by putting them all in a size group.
Before this patch, we'd always allocate a full size SHM buffer via
the wl_shm_pool, even though it would never be used. Instead allocate a
logical 1x1 cairo image surface.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
In order to support window scales for EGL windows, resize the
wl_egl_window to the window dimension multiplied with the window scale,
just as with SHM window buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
When the preferred surface scale changes, for example when entering a
wl_output with a higher scale than any previous entered output, recreate
the shm surface and redraw the window content with the new window scale.
Before this patch, the internal scale would be changed, but the shm
surface would not be recreated given the new scale, i.e. we'd attach a
buffer for a different scale than wl_surface.set_scale specified.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
If the compositor is too old for handling surface buffer scales, never
tyr to set change it. This will effectively always leave it to its
initial state, i.e. 1.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
Don't try to paint onto an error surface. This happens for example when
gdk_cairo_set_source_pixbuf() is called with a pixbuf that is too big
for Cairo to handle.
Spotted by Christian Boxdörfer
If a scrollbar is not shown (because of policies, or because it isn't
necessary), it doesn't make sense to start fade animations on its window
on captured motion events.
This was added a few years ago, as a way to have _no_ im context
at all. But it didn't actually work. Make it work, and streamline
the handling of none by moving it all to gtkimmodule.c.
As part of this, add context to the translated names of all
im modules we ship.
In order to provide a constant mtime between OS build and deploy time,
while also maintaining a hardlink content-addressed model independent of
timestamps, ostree sets all mtimes to 0.
The icon cache code currently ignores directories with mtime 0, assuming
they don't exist.
Track directory existence in a more precise way.
https://bugzilla.gnome.org/show_bug.cgi?id=745052
When loading SVGs from ICON_THEME_DIR_UNTHEMED GtkIconInfos,
such as those created for a GLoadableIcon, the size of the pixbuf to
load is set as a product of icon_info->scale.
But a few lines above, icon_info->scale is set to -1 for
ICON_THEME_DIR_UNTHEMED GtkIconInfos, so we'll end up always passing a
negative size to the GdkPixbuf loader, which is interpreted as the
nominal size of the image file.
Instead load the SVG at the desired scaled size in that case.
This fixes blurry icon in the notification panel in gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=744991
When loading a GResource-backed GFileIcon into a GtkIconInfo we
currently fail to populate the is_resource private field.
Also, since is_svg is set by looking at the filename, and
g_file_get_path() returns NULL for a GResourceFile, is_svg was always
FALSE.
https://bugzilla.gnome.org/show_bug.cgi?id=744991
Add a way to set a delay factor that can be used
to make the long press more or less sensitive.
Making this a factor instead of exposing the delay
itself preserves the value of the setting as an
overall 'slow down long press' setting.
As Sebastian pointed out, just resetting the initial slider
position was an incomplete fix, because it does not cause the
delta to be recomputed, which is important in this scenario,
because you've likely travelled some distance over the slider
before the long press kicks in.
Instead, explicitly record both the slider position and the
delta.
We record the starting position on button press, but only
start the zoom mode when the long press timeout kicks in.
Depending on circumstances, this can cause a noticable jump.
Avoid this by resetting the recorded starting position after
the long press timeout. Suggested by Sebastian Keller.
First, attributes can be NULL (which is always the case when calling
gdk_window_ensure_native) so do not unconditionally dereference it.
Then the window_type should be taken directly from the GdkWindow as
in other backends (such as the X11 one for example).
https://bugzilla.gnome.org/show_bug.cgi?id=744942
While a popover is hiding, the modal grab is already gone and the toggle
button is clickable again, but clicking again at that time will result in
gtk_widget_show() trying to show an already shown widget (although fading
out and hidden soon) and the toggle button activated.
So let the menubutton set the active status only if the menu/popover
widget wasn't already shown, and ensure this doesn't get triggered by
double/triple button press events.
As an implementation detail, the popover hooks the fade out animation
on ::hide. Destroying the popover right away here is not a problem, but
prevents the animation from actually running. ::unmap will be run after
the animation is finished, so destroy the popover there.
These have the same visual effect and timing than the gnome-shell ones.
During the hide animation, the popover has been made to take focus
elsewhere, and refuse to take any pointer/keyboard input until the popover
is shown again.
This has been based on work from Timm Bäder.
https://bugzilla.gnome.org/show_bug.cgi?id=741405
gtk_scrolled_window_allocate_scrollbar was calling
gtk_scrolled_window_allocate_child just to get the relative
allocation, overlooking the fact that that function is only
safe to call if the scrolled window _has_ a child. Unfortunately,
gtk_scrolled_window_allocate_scrollbar will sometimes get called
when that is not the case. Since we are really only interested
in the relative allocation, just get that directly. This
fixes a segfault in the style-properties-nth-child reftest.
Also try and clarify a few things about event propagation. Move
input-handling.xml into gtk-doc’s expand_content_files variable so it
automatically links to widget documentation. Add links from
gtk_widget_add_events() and friends to the new documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=744054
It will be useless to check the source window on the destination side,
it's at the moment always NULL. Fetch the display from the device instead,
which will be set for every GdkDragContext.
At the time of creating the indicator window, the scrollbar allocation is
poked and reused as the initial window dimensions. This usually happens
on two circumstances, either initially (so a ::size-allocate is emitted,
relocating the windows in the right places), or post-initialization when
calling set_overlay_scrolling() (so the scrollbars already have a valid
size allocation)
However, if the scrolledwindow is unrealized, and later re-realized again,
the scrollbars will already have a valid allocation, although 0,0 based
due to being contained in the previous indicator window. This comes out
wrong then, and the indicator window is given 0,0 based coordinates too.
Fix this by refactoring the scrollbar allocation code out of size_allocate,
and also use that given size at the time of creating the indicator windows,
this will provide the right widget-relative allocation anytime.
Currently, GtkGLArea will leak GError instances set during the context
creation, if an error is set.
If any error is set post-context creation, it should be displayed even
in the case a GL context exists; for instance, we can use the error
display facility for shader compilation errors.
Make that variable go from 0.0 to 1.0 where 0.0 means inactive (slider
is on the left) and 1.0 means active (slider is on the right).
The math is simpler that way and most importantly the value is
independent of size.
Add a button to allow restricting search to the current
folder (and subdirectories). This makes the search more
useful, and makes the file chooser more similar to
nautilus.
In search, we show files from differnt locations, and it makes
sense to show where they come from. This makes the file chooser
more similar to nautilus, too.
Folders that show up among search results were unexpectedly
returned even for GTK_FILE_CHOOSER_ACTION_OPEN. Change things
around so that we switch to the folder instead, which is the
behavior we had in GTK+ 2.x.
https://bugzilla.gnome.org/show_bug.cgi?id=744204
Some compositors might not offer wl_seat 4 resulting in GTK+ clients not
working on that compositor.
wl_seat 4 introduces keyboard repeat information, but when that information
is missing it is retrieved from settings, hence there's no reason to
require wl_seat 4.
This patch was tested against QtCompositor (5.5, dev branch)
and Weston 1.6.1.
Reviewed-by: Daniel Stone <daniels@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=744172
This is necessary to avoid unwanted drag cancel animations,
now that GtkNotebook is careful about cancelling a drag
when the dragged tab disappears unexpectedly.
The existence of OpenGL implementations that do not provide the full
core profile compatibility because of reasons beyond the technical, like
llvmpipe not implementing floating point buffers, makes the existence of
GdkGLProfile and documenting the fact that we use core profiles a bit
harder.
Since we do not have any existing profile except the default, we can
remove the GdkGLProfile and its related API from GDK and GTK+, and sweep
the whole thing under the carpet, while we wait for an extension that
lets us ask for the most compatible profile possible.
https://bugzilla.gnome.org/show_bug.cgi?id=744407
Store the OpenGL version when we first do the extensions check; this
allows client code to check the available GL version without requiring a
call to gdk_gl_context_make_current() and epoxy_gl_version().
When using GDK_GL_PROFILE_3_2_CORE, we are not only specifying that the
GDK should create a core profile; we are also specifying that the
minimum required version of OpenGL is set to 3.2.
We should also specify that the GDK_GL_PROFILE_DEFAULT profile is an
alias for GDK_GL_PROFILE_3_2_CORE.
Now that we have a two-stages GL context creation sequence, we can move
the profile to a pre-realize option, like the debug and forward
compatibility bits, or the GL version to use.
gtk_list_box_bind_model() binds a GListModel to a GtkListBox.
This is a first step towards having GListModel support in Gtk. It's not
useful for large models, because GtkListBox always creates all widgets
for all rows.
Emit an error if the profile is different.
This is a follow-up commit to commits cc45e82 (x11/gl: Ensure we use the
3.2 core profile) and 2d9081d (wayland/gl: Ensure we use the 3.2 core
profile), so that we do the same on GDK-Win32. Update variable names and
comments so that the code is clearer to people, as we still need a
temporary legacy WGL context first before we can use
wglCreateContextAttribsARB() to create a WGL core (3.2+) context.
https://bugzilla.gnome.org/show_bug.cgi?id=741946
Using version 1.20 with a forward compatible 3.2 core context is incorrect
since OpenGL 3.2 deprecates shader version 1.20 (See section E.2). The latest
fglrx drivers will not compile these shaders.
https://bugzilla.gnome.org/show_bug.cgi?id=744203
Since we dropped the legacy OpenGL compatibility profile, we need to use
recent OpenGL APi and concepts. This also means that the example code
gets a tad more complicated.
https://bugzilla.gnome.org/show_bug.cgi?id=741946
We simply don't want to care about legacy OpenGL.
All supported platforms also have support for OpenGL ≥ 3.2; it would
complicate the internal code; and would force us to use legacy GL
contexts internally if the first context created by the user is a legacy
GL context, and disable creation of core-3.2 contexts after that.
We will need to fix all our code examples to use the Core 3.2 profile.
https://bugzilla.gnome.org/show_bug.cgi?id=741946
Like what is being done in the X11 and Wayland backends, create the
GdkWin32GLContext in 2 steps, where we only create the actual WGL context
in _gdk_win32_gl_context_realize().
https://bugzilla.gnome.org/show_bug.cgi?id=741946
Users of the GdkGLContext API should be allowed to set properties on the
shim GdkGLContext instance prior to realization, so that the
backend-specific implementation can use the value of those properties
when creating the windowing system specific resources.
The main three options are:
• a major/minor version tuple, to request a specific GL version
• a debug bit, to request a "debug context", which provides additional
validation and run time checking
• a forward compatibility bit, to request a context that does not
have deprecated functionality
See also:
- https://www.opengl.org/registry/specs/ARB/glx_create_context.txthttps://bugzilla.gnome.org/show_bug.cgi?id=741946
One of the major requests by OpenGL users has been the ability to
specify settings when creating a GL context, like the version to use
or whether the debug support should be enabled.
We have a couple of requirements in terms of API:
• avoid, if at all possible, the "C arrays of integers with
attribute, value pairs", which are hard to write and hard
to bind in non-C languages.
• allow failing in a recoverable way.
• do not make the GL context creation API a mess of arguments.
Looking at prior art, it seems that a common pattern is to split the
construction phase in two:
• a first phase that creates a GL context wrapper object and
does preliminary checks on the environment.
• a second phase that creates the backend-specific GL object.
We adopted a similar pattern:
• gdk_window_create_gl_context() creates a GdkGLContext
• gdk_gl_context_realize() creates the underlying resources
Calling gdk_gl_context_make_current() also realizes the context, so
simple GL users do not need to care. Advanced users will want to
call gdk_window_create_gl_context(), set up the optional requirements,
and then call gdk_gl_context_realize(). If either of these two steps
fails, it's possible to recover by changing the requirements, or simply
creating a new GdkGLContext instance.
https://bugzilla.gnome.org/show_bug.cgi?id=741946
This guarantees we only create 1 extra style cascade in total for hidpi
and not one per style context.
Style cascades are now nested like this:
GtkSettings root cascade (scale == 1)
|
+-- GtkSettings per scale cascade (for any scale, no custom providers)
|
+-- GtkStyleContext custom cascade (for any scale, custom providers)
This requires a bunch of care when changing cascade-related properties
inside GtkStyleContext, so that it ends up with a properly setup
cascade, but I think I got those cases right.
The only thing we don't do yet is reverting to a GtkSettings cascade
when the last custom provider is removed from a custom cascade.
The default ->upload_texture() works also for Windows since commit 27cf0fa,
as some of the problems described in 742953 also applied for GL core
contexts on Windows as well before 27cf0fa. Clean up the GDK-Win32 code a
little bit as a result.
This property is necessary to ensure widgets automatically update after
the text scale factor is changed desktop-wide.
And if I'm already doing a property like this, I can make it
overridable. So now you can override the dpi per-widget with CSS like
GtkSwitch {
-gtk-dpi: 48;
}
if you want to debug things.
Long-term, we want to get rid of this property and insist on dpi being
96 everywhere and people can change the font size to get larger fonts.
GPUs generally have problems when you create a 35000px wide surface.
Luckily X catches this and sends a BadAlloc. Which GTK immediately
abort()s on.
Testcase included.
https://bugzilla.redhat.com/show_bug.cgi?id=1163579
We should remove the mir and cairo surface before rendering the
transient_for, which will regenerate the cairo surface anyways.
Otherwise, we end up releasing both, when we only really want to get rid
of the mir surface.
Mouse over a parent menu[bar] didn't work while the menu was open.
The fix was to correct the behaviour of pointer crossing events so that
the pointer appears to be only inside one window at a time.
See: http://tronche.com/gui/x/xlib/events/window-entry-exit/normal.html
We need this because it fixes menu activation. The menu activation code
looks at the time between events to determine if mouse clicks happen too
quickly.
This avoids showing the scrollbars if we are positive the child widget
is being manipulated, regardless of the pointer being close to any of these.
On the next motion event after finishing the operation, the scrollbar will
be shown if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=743894
is_visible() wasn't the right check to perform here before unmapping,
and gtk_widget_unmap() already avoids being doubly called by checking
gtk_widget_get_mapped() anyway.
Rename the "install" projects as "gtk-install" as we are planning to have a
grand solution file that incorporates all project files of the GTK+ stack
with their dependencies, to make it easier for people to build GTK+ from
scratch from a stock installation of Visual Studio 2008 and later.
In that case the scrolledwindow still gets events through the captured
handler, and can thus still control visibility, so hiding the indicators
in this case can only lead to flashing.
This will be used to just detect when an edge of the scrollable area is
reached - as opposed to the edge-overshot signal that is emitted when
the user scrolls past the edge.
https://bugzilla.gnome.org/show_bug.cgi?id=742848
If a side of the box is 0px wide, make the corners owned by the adjacent
sides. This avoids spilling over of unwanted colors from the 0-width
side into the corner.
This is the fix that should actually have been part of
7e5ac3a58d but my amazing amending skills
got rid of it when amending the test.
Commit ff256956b2 introduced a frame_clock_events_paused
flag, but only ever set it to TRUE, instead of unsetting it when
events are resumed. This was leading to assertion failures in
_gdk_display_unpause_events().
Arrange things so that gtk-xdg-hinting==-1 and gtk-xfg-antialias==-1
end up as CAIRO_HINT_STYLE_DEFAULT and CAIRO_ANTIALIAS_DEFAULT in the
cairo font options.
This will not change anything on Linux desktops where xsettings will
always provide values different from -1. But on other platforms, we
can benefit from getting the platform-specific defaults in cairo.
Based on the first patch in:
https://bugzilla.gnome.org/show_bug.cgi?id=735316
If we are disconnecting from a frame clock that has paused event
processing and hasn't issued a resume yet make sure we resume the
events or they will stay blocked forever.
https://bugzilla.gnome.org/show_bug.cgi?id=742636
The code here was always a bit buggy: We removed the tab from
the notebook in a ::drag-data-received handler. But with
GTK_DEST_DEFAULT_DROP, that signal is emitted before we inform
the source side that the drag is finished. With its improved drag
handling, GtkNotebook now interprets this as a 'spontaneous'
removal of the tab being dragged, and cancels the drag, leading
to an unwanted cancel animation.
The easiest fix is to just defer the tab removal to an idle.
When a tab is dropped, we have to remove it from the notebook to
insert it elsewhere. This is expected part of the tab dnd operation,
and we need to differentiate it from 'spontaneous' removals which
cause us to cancel the drag operation.
when the dragged tab is being removed during the drag operation,
we need to cancel the drag. To do so, we have to keep around
a reference to the drag context.
This should fix
https://bugzilla.gnome.org/show_bug.cgi?id=732051
Add a gtk_drag_cancel() function that can be used on the
source side to cancel an ongoing drag operation. This can
be useful, e.g. if the data that is being dragged becomes
unavailable.
It is a bit misleading to have one of the places in the sidebar
selected while in search mode, since the search is not relative
to any location. So, unset the sidebar selection when we enter
search mode.
If the search entry doesn't consume the key event, don't
change to search mode. Otherwise, we interfere e.g. with
Ctrl and Shift keys for selection.
https://bugzilla.gnome.org/show_bug.cgi?id=743660
If the grab belongs elsewhere, the window won't claim the sequence right
away. The sequence may still be claimed afterwards when window dragging
starts, but simple clicks won't be consumed this way.
This makes it possible to close popovers when clicking on the title region,
while still permitting touch/button 1 interaction for every other purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=743257
This function is given a barely setup GdkEvent, so the GdkDevice field
is still unset, causing warnings and misbehaviors when the position
is queried for it.
Given that the wintab GTK+ code seems to rely somewhat hard on the wintab
device managing the pointer cursor, query the pointer position from the
pointer itself.
https://bugzilla.gnome.org/show_bug.cgi?id=743330
The window used NULL as a parent window, which defaults internally to
using the root window of the default screen. But at the time wintab is
initialized, there is no default display/screen yet.
Fix this by retrieving this information from the given GdkDeviceManager,
so we don't have to wait for the display to be in place before
initialization.
https://bugzilla.gnome.org/show_bug.cgi?id=743330
In some layouts this inconsistency results in crashes in
gdk_gl_texture_from_surface() since it uses gdk_gl_context_get_window() but
the returned window is not the same as the one that is being painted so
"window->current_paint.surface" is NULL. I saw this problem when packing a
GdkGLArea into a GtkPaned.
https://bugzilla.gnome.org/show_bug.cgi?id=743146
- Specifically request GL version when creating context. Just specifying core
profile bit results in the requested version defaulting to 1.0 which causes
the core profile bit to be ignored and an arbitrary compatability context to be
returned.
- Fix GL painting by removing GL calls that have been depricated by the 3.2 core
profile.
- Additionally remove glInvalidateFramebuffer() call, it is not supported by 3.2
core.
https://bugzilla.gnome.org/show_bug.cgi?id=742953
Add helper for getting the main clipboard. This makes
the API usable for bindings (as GdkAtoms aren't usable through
gobject-introspection), and easier to use in C.
https://bugzilla.gnome.org/show_bug.cgi?id=712752
The property is useless to set (it only allows 'initial', 'inherit' and
'unset' as values), but it is used to track changes to the icon theme.
And as such, it can ensure that widgets can track when they need to
reload icons.
https://bugzilla.gnome.org/show_bug.cgi?id=743341
Gtk_container_cell_widget_set should chain up to its parent's set
function, not its parent's unset function. This was resulting in
accessibles being erroneously marked defunct after being created.
The ICCCM says:
If the specified property is None, the requestor is an obsolete client.
Owners are encouraged to support these clients by using the specified
target atom as the property name to be used for the reply.
Lets do that, instead of crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=740613
The previous fix for this issue in 732af31424 was incomplete.
The GtkSelectionData does not own the model set with
gtk_tree_set_row_drag_data so change the out param to "transfer none".
This fixes a crash after multiple DnD actions due to the bindings
stealing a reference each time this function is called.
This also adds nullable and optional annotations for tree_model and path while at it.
https://bugzilla.gnome.org/show_bug.cgi?id=743193
Add ::next-match, ::previous-match and ::stop-search keybinding
signals that are bound to Ctrl-g, Ctrl-Shift-g and Escape. Also
add a gtk_search_entry_handle_event() function to handle key events.
If a side of the box is 0px wide, make the corners owned by the adjacent
sides. This avoids spilling over of unwanted colors from the 0-width
side into the corner.
New test for this case is included.
Previously, we would not include any child widget on the first
allocation, which happens right after realize(), but before map(). No
widget is drawable at that point.
The rotation code in the draw_arrow function was assuming that the arrow
would be drawn pointing upwards but it was pointing to the right
resulting in the rotated arrows pointing in the wrong direction.
The recent refactoring caused a pi/2 rotation to be lost. Rather than
adding that back somehwere (to lose it again in the future), we just
draw the arrow pointing upwards as it is expected to do with a 0 angle.
Yes, I like playing around. To enjoy, add this CSS to your application
of choice (preferrably glade or something with lots of images):
GtkImage { animation: spin 2s linear infinite; }
You can thank me later.
The spinner is a regular builtin image now. There is no need to go
through the shadows code manually anymore as regular items do get
shadows automatically.
This also allows simplifying the actual spinner drawing code so that it
actually works.
The order in which properties are defined depends on the order in which
they are computed. And that means that properties can only depend on
other properties that are defined before them.
The next patches will need this reordering.
Instead of supporting every angle, just support top, right, bottom and
left and round the angle to one of those directions.
Adwaita overrides arrows anyway and doesn't even look at the angle, so
this should not be a problem.
Also, make it have a generic entry point with
gtk_css_image_builtin_draw().
The only feature lost so is the drawing of shadows for spinners, but
that will come back later.
The file chooser code now calls into the path bar in init,
starting an async operation. This unveiled that the path bar
code was not safe against being disposed early, by causing
a crahsh of the objects-finalize test.
Fix this by making the callback check for CANCELLED.
When removing all rows, trying to add rows would not work
and throw criticals. This is fallout from a recent change
to insert rows at the right position. Fix this by handling
the 'empty model' case separately.
https://bugzilla.gnome.org/show_bug.cgi?id=743157
This was left unmodified when GtkScrolledWindow was made a windowed widget.
Displacing here by the widget allocation is not necessary anymore, since
we are invalidating the window set at these coordinates.
This patch is a simplification of a previous one by Timm Bäder.
https://bugzilla.gnome.org/show_bug.cgi?id=742243
GtkImageMenuItem always packs a GtkImage when it is synced with a
related action. This is unnecessary when the action doesn't have an icon
set and results in excess padding when a GtkImageMenuItem is put in a
menu bar (GtkUIManager does this).
Fix this by not creating the GtkImage for icon-less actions.
https://bugzilla.gnome.org/show_bug.cgi?id=742181
Just add a 3rd stop in the place where the gradients for the other
states have a 3rd stop. When running transitions between states, this
avoids cross-fades and instead uses the much faster gradient
transitioning code.
Instead of asserting, just print a g_warning() and try to work around
the problem.
I hope that g_warning() isn't too spammy for people that are hit with
it.
Also clarify the docs that not restore()ing after a save() is a bad
idea.
https://bugzilla.gnome.org/show_bug.cgi?id=743101
When creating the query path, explicitly specify if it's for a root node
or for a child. Relying on gtk_style_context_is_saved() is unreliable
(for example when updating the cache).
The last round of filechooser redesign work had left
search somewhat dysfunctional. This commit fixes things
up enough that search is once again a working feature
of the file chooser.
There are some cases where we can end up showing the path
bar without ever setting a file on it. One example is:
1) Open file chooser
2) Hit ~
3) Hit Ctrl-L
While this is a bit of a workaround, at least it makes sure
that we never end up with an empty space where the path bar
is supposed to be.
It seems that posix_fallocate gives an ENODEV error when
called on an fd opened with shm_open on freebsd. Fix up
the error check to only trigger if we get ENOSPC.
https://bugzilla.gnome.org/show_bug.cgi?id=742980
This gets rid of a bunch of awkward transitions. It's not a perfect
solution to the problem of "should we transition from this state" but it
gets rid of the ugliest offenders.
If this is done on dispose(), the widget may be destroyed (and its
controllers list NULLified) within _gtk_widget_run_controllers(),
causing warnings/crashes when it just tried to hop on the next
controllers.
Freeing the controllers here should be a safety net for implementations,
so it also makes sense to do this late. The widgets that choose to
free their controllers on dispose can still do so, and get
_gtk_widget_remove_controller() called for these as an indirect result.
g_utf8_get_char_validated() may return -1 or -2
return type is gunichar(guint32)
Therefore such checks like 'gunichar < 0' or 'gunichar > 0'
are always 'false' or 'true'(except when gunichar == 0).
Signed-off-by: Maks Naumov <maksqwe1@ukr.net>
https://bugzilla.gnome.org/show_bug.cgi?id=742774
If a gtk_style_context_invalidate() is called on a widget's style
context (which nobody should ever do, sheesh!) and we're animating, stop
the animations.
Fixes crashers in Nautilus.
When we get a leave event, we need to remove the over bit,
since we may not get motion events that tell us when we lose
proximity, but we don't have to fade out right away - that
will happen on its on due to inactivity a bit later. Having
the indicator stay visible for a bit feels more relaxed.
If we use GDK_GL_PROFILE_3_2_CORE we are asking for a core profile
according to the GLX_ARB_create_context_profile extension. For that,
we pass the GLX_CONTEXT_CORE_PROFILE_BIT_ARB value for the
GLX_CONTEXT_PROFILE_MASK_ARB attribute.
The specification for the extension says that:
If the requested OpenGL version is less than 3.2,
GLX_CONTEXT_PROFILE_MASK_ARB is ignored and the functionality
of the context is determined solely by the requested version.
Since we're asking for a core profile, we assume a GL version greater
than or equal to 3.2; thus, we don't need to specify the
GLX_CONTEXT_MAJOR_VERSION_ARB or the GLX_CONTEXT_MINOR_VERSION_ARB
attributes, and instead just rely on whatever version GLX gives us.
This seems to work around a strange issue in Mesa; if we ask for a core
profile and any version > 3.0, we get broken rendering on any shared
context we create.
Since gsize doesn't work as a typename in a ui file,
we have to be careful not to pass pointers to wrongly
sized variables when getting the guint64 values out
of the model.
https://bugzilla.gnome.org/show_bug.cgi?id=742664
We still use symbolic icons for Copy, Cut, and Delete operations inside
toolbars and some menus, so it's worth pointing to the symbolic icon
names in the deprecation notices.
https://bugzilla.gnome.org/show_bug.cgi?id=741969
We need to clear the cache manually on full revalidates because
_gtk_css_change_for_child() will clear the full revalidation flags.
And then gtk_style_context_update_cache() will not do the right thing
(which is to clear itself).
Because we can switch from animating to non-animating pretty much
anywhere, do the check for animations unconditionally instead of trying
to cram it into the correct if path (and failing).
We now cache the results of lookups on the parent GtkCssStyle. This
allows sharing styles between widgets (recursively). However, this
only works if the styles can't potentially depend on siblings -
neither directly via sibling selectors or via position pseudo-classes
like :first-child.
Unfortunately, Adwaita currently uses first-child a lot, and in
particular for labels, which are the most common widgets.
The big benefits of this change are both less CPU - due to not needing
to compute styles again - and less memory usage - due to sharing of
the styles between widgets. Here's some nonscientific numbers I
collected while pondering the usefulness of this patch:
glade glade widget
demo demo factory
runtime styles styles
Adwaita before 19.1s 5800 1150
Adwaita now 18.9s 3800 970
Adwaita hacked now 14.5s 3100 910
simple before 11.3s 5800 1150
simple now 10.8s 1300 590
Adwaita: Adwaita as provided by GTK
Adwaita hacked: Adwaita with the first/last-child for GtkLabel removed
simple: A 250 lines simple GTK theme I use for testing
before: This patch not applied
now: this patch applied
glade demo runtime: Starting glade opening a large file and closing it
glade demo styles: GtkCssStaticStyle objects after opening glade with
the large file as per inspector
widget factory styles: GtkCssStaticStyle objects after startup as per
inspector
Previously we looked at the save/restore state when determining the
parent. This is wrong in the case where we're updating the cache though.
So we now save the parent in the style info.
After the parent changes in commit
3a337156d1 we need to refresh the cached
styles after the current style. After all, they now depend on the base
style.
After 3a337156d1 style lookups still used
the parent context's style as the parent style, even though after a
gtk_style_context_save() the root style of the style context is the
proper parent.
Testcase attached.
Instead of keeping an animated style everywhere, we replace it with the
static style when nothing gets animated.
Apart from making the code cleaner, this gets rid of a bunch of animated
style values that do nothing but wrap a static style.
The only style that is animated is the style of the unsaved primary
node. So there's no need to create animated style objects for the other
ones.
There is a bunch of ugliness in the code currently. Further commits are
expected to fix them.
For now, this is only an implementation detail of the animated style.
The idea is to use GtkCssStaticStyle as the result of CSS queries and
then put a GtkCssAnimatedStyle on top that manages the animations. The
neat thing about this is that you can cache the static values.
GtkCssStyle is the base class to be used for all types of styles that do
exist.
GtkCssAnimatedStyle is the only implementation so far, that is exactly a
copy/paste of the old GtkCssStyle code.
I removed it in 14f5ce7108 because I
thought it was unnecessary, but it wasn't. When we build a tree like
this:
.matches ─┬─ .doesntmatch
└─ .alsodoesntmatch
We would get the changes for the .matches part returned. This is however
only right if that node of the tree contains results. If results only
exist with the child nodes (all of which don't match), then this part
should not match either.
GtkCalendar can have an invalid date — mostly at initialization. This
means that GDateTime construction may fail. We need to handle that case
gracefully, like the old code did.
This fixes the `notify` test suite, which started failing with:
/Notification/GtkCalendar:
GLib-CRITICAL **: g_date_time_get_day_of_week: assertion 'datetime != NULL' failed
inside the Continuous builder.
Sending backingScaleFactor to a NULL NSWindow will silently give the
value 0 for the scale factor, causing insidious divide-by-zero bugs down
the line. This checks if the NSWindow is NULL first, as seems to happen
throughout the rest of the file.
Note that I don't have a hi-DPI OS X machine to test this on, though.
https://bugzilla.gnome.org/show_bug.cgi?id=738338
This is so we can detect crossing events on the scrolledwindow widget,
which can be useful for toggling certain behaviors or not depending on
whether the mouse is on the widget.
If the first of the month was falling on a Sunday, we would not
render any days of the previous month, and instead show two weeks
of the next month at the bottom. Improve this by showing one week
of each.
https://bugzilla.gnome.org/show_bug.cgi?id=301835
Changing font size does not cause widgets to update their size
properly anymore, since we forgot an invalidation flag. The
problem can be observed e.g. by running gtk3-demo and calling
gsettings set org.gnome.desktop.interface font-name "Cantarell 22"
On the wayland backend, set up GDK_WINDOW_SUBSURFACE windows
for popovers. In the popover code, the popover-relative-to-parent
calculation had to be tweaked, and it's been made to always prefer
the given popover position, since there's no sizing limitations.
https://bugzilla.gnome.org/show_bug.cgi?id=738891
We were asserting priv->filename != NULL in various places,
which leads to apps refusing to work when HOME is set to a
nonexisting or nonwritable value. Since it isn't hard, just
make GtkRecentManager survive without a filename. We won't
save or read any recently used files in this state, but
thats ok.
https://bugzilla.gnome.org/show_bug.cgi?id=739038
Provide a mechanism for hiding the "Quit", "About" and "Preferences"
menu items from the normal places in a traditional menubar layout (in
the File and Edit menus) when the menu is being rendered in the Mac OS
menubar.
These items can already be found in the application menu.
With this feature, applications can now define a single menu to use in
all 'traditional' scenarios.
Use this new attribute in Bloatpad.
https://bugzilla.gnome.org/show_bug.cgi?id=741610
In addition to the fixed-size mode that is used by the text view,
add a mode in which the magnifier requests enough size to render
the entire inspected widget at the current magnification. In this
mode, the magnifier will update its size when the size of the
inspected widget changes. Also, make the magnifier redraw on its
own whenever the inspected widget draws.
There is no good reason to assign the value directly.
Also, this fixes d23f3254b7
where widgets that chained up instead of calling
gtk_widget_set_allocation() would not draw becaues of empty clip.
(1) Get rid of supports_clip flag. All widgets (implicitly) support
clip.
(2) Don't reset the clip to { 0, 0, 0, 0 } before the "size-allocate"
signal.
(3) Make gtk_widget_set_allocation() set the clip (to the allocation).
This ensures that eveyr widget has a clip set.
Note: It overrides previous calls to gtk_widget_set_clip(), while in
3.14 this didn't happen.
(4) As the clip is set by gtk_widget_set_allocation() now, don't set
it after the "size-allocate" signal anymore.
This fixes calls to gtk_widget_queue_draw() from inside the
size_allocate vfunc.
We've observed hangs of mutter when it initializes GTK+, which
are caused by initializing GL, which in turn makes xwayland
call back into mutter. With this change, mutter should just
disable GL support in GDK, and things will work.
Override the gtk-shell-shows-app-menu and gtk-shell-shows-menubar
settings to FALSE, if we can detect that we are not on the same
session bus as the xsettings provider that we got these settings
from.
We determine this by comparing the bus ID of 'our' session
bus with the one reported in the Gtk/SessionBusId xsetting.
If they are different, then it very likely that we are in an ssh
situation where we see the forwarded X display, but not the
session bus. The D-Bus based menu exporting will not work
in this situation.
https://bugzilla.gnome.org/show_bug.cgi?id=671802
The magnifier is now set enough height to show the line being currently
manipulated, which makes it just big enough to show the layout height at
that size and magnification.
- It is not possible anymore to trigger text DnD through touch, pressing
and dragging from within the selection will instead extend it. Text
shrinking is still available through the handles
- The selection mode for touch is per-word, char-level manipulation is
still available through the handles.
- Tapping within the selection will bring in text handles, and toggle
text selection popover.
This mode could also shrink the selection, plus the starting point would
seem somewhat arbitrary (actually dependent on the dragging direction of
the last selection).
Made this mode more consistent by only allowing it to extend the selection,
only in one direction for each operation, and so it keeps the current
selection as a minimum.
Instead of passing a GdkEvent and let the function figure out whether the
selection should be extended, let that to the caller and just pass a
boolean here.
Using the parent widget context is a leftover of the pre-popover
implementation, which used GdkWindows directly. This will make the context
reflect widget state, at the expense of changing the selector paths
that used to match the handles.
Checking the return value was valid for most gestures, but
GtkGestureLongPress, where the first press triggers internally an action,
but does nothing for the sequence to be claimed/denied, FALSE was eventually
returned, and the button/sequence functions would be incorrect when
::pressed is emitted.
So check that the sequence is being handled by the gesture, this is more
desirable than the return value as it's independent of sequence state,
and still will be FALSE for the cases we want to catch here.
When a RTL paragraph is not set to wrap, the right margin is not respected
because of the margins counted twice so we replace
display->width by PIXEL_BOUND (extents.width), the same quantity
without the margins.
https://bugzilla.gnome.org/show_bug.cgi?id=741702
cat $(top_srcdir)/build/win32/vs10/$(MSVC_SLN).sln | sed 's/11\.00/$(MSVC_FORMAT_VER)\.00/g' | sed 's/2010/$(MSVC_VER_LONG)/g' > $(top_builddir)/build/win32/vs$(MSVC_VER)/$(MSVC_SLN).sln
%.txt:
sed 's/vs10/vs$(MSVC_VER)/g' < $(top_srcdir)/build/win32/vs10/$@ > $(top_builddir)/build/win32/vs$(MSVC_VER)/$@.tmp
sed 's/VS10/VS$(MSVC_VER)/g' < $(top_builddir)/build/win32/vs$(MSVC_VER)/$@.tmp > $(top_builddir)/build/win32/vs$(MSVC_VER)/$@
cat $(top_srcdir)/build/win32/vs10/README.txt | sed 's/vs10/vs$(MSVC_VER)/g' | sed 's/VS10/VS$(MSVC_VER)/g' > $(top_builddir)/build/win32/vs$(MSVC_VER)/README.txt
create_vcxproj:
for F in `(cd $(top_builddir)/build/win32/vs10 && ls *.vcxproj)`; do \
case $$F in \
*) cat $(top_builddir)/build/win32/vs10/$$F | sed 's/v100/v$(MSVC_VER)0/g' > $(top_builddir)/build/win32/vs$(MSVC_VER)/$$F \
;; \
esac; \
done
create_props:
for F in `(cd $(top_builddir)/build/win32/vs10 && ls *.props)`; do \
case $$F in \
*) cat $(top_builddir)/build/win32/vs10/$$F | sed 's/<VSVer>10<\/VSVer>/<VSVer>$(MSVC_VER)<\/VSVer>/g' > $(top_builddir)/build/win32/vs$(MSVC_VER)/$$F \
# YourProject_HEADERS_EXCLUDES = ... # <list of headers to exclude from installation, separated by '|', wildcards allowed; use random unsed value if none>
#
# dist-hook: \ # (or add to it if it is already there, note the vs9 items will also call the vs10 items in the process)
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.
