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
GtkIconTheme doesn't scale icons beyond the size specified in the theme
anymore. This can result in arbitrarily large menu items when a theme
only provides large icons.
Force icons to always be 16x16 to ensure that menu items always have the
same height.
https://bugzilla.gnome.org/show_bug.cgi?id=741259
Since the support for GL support in the GDK Windows backend has landed in
master, we need to build it in the Visual Studio builds. Update the
projects for that and "install" the public header that was added.
This adds support for OpenGL to the GDK Windows backend using the WGL API
calls, which enables programs that uses the GTK+ GLArea widgets to work on
Windows as well.
This also adds a simple utility function to query for the version of OpenGL
that is supported by the Windows system, like the one provided by the X11
backend.
Many thanks to Alex (and Emmanuele, who started the OpenGL integration in
GTK+) who offered advice and help along the way, as well as the X11 and
Wayland backend for this work to refer to and to model upon.
https://bugzilla.gnome.org/show_bug.cgi?id=740795
As the alignments, strides and image formats may be different across
platforms, make the texture upload a vfunc to allow backends to override
the GL commands for uploading textures for the software implementation for
gdk_gl_texture_from_surface(), if necessary.
Suggested by Alex to avoid copying non-trivial portions of code which would
then add maintainenace burden.
https://bugzilla.gnome.org/show_bug.cgi?id=740795
This drops the maybe_allocate_buffers that re-allocates buffers
at any point. Instead we just set have_buffers to FALSE and have
the buffers re-created when needed.
This also makes the buffer creation code imdeponent and makes it
clean up no longer needed buffers in order to handle being called
multiple times due to the above.
We also ensure we re-allocate the buffers when we're resizing
and the buffers are already created.
We can't combine multiple draws into one for the software fallback,
because each quad has a different texture. And we generally don't
want to make a larger single texture because then we would have
to upload more data.
On creation, we call action_removed() in case the action was missing
from the start. Because we just created the action, 'can_activate' will
always be FALSE here and this function will therefore always do nothing.
We do want the visibility state to be updated though, for the case where
the action is missing but the item should still be visible from the
start.
Update the visibility directly instead of trying to call
action_removed().
https://bugzilla.gnome.org/show_bug.cgi?id=735122
We were only properly setting the "is-visible" flag to TRUE for menu
items with associated actions and not (for example) on submenus.
This was fine because the code for building GtkMenus from models
(correctly) assumed that submenus should always be visible and never
checked the property.
This is not true for the Mac OS code, which actually checked the
property and found it to be false for submenus.
Initialise the property to TRUE so that we get the correct value
reported for items that don't have actions.
https://bugzilla.gnome.org/show_bug.cgi?id=735122
All popover sides have extra margins to possibly hold the tail, this is
accounted for in gtk_popover_get_rect_coords(), and should be accounted
for too in the tail position calculation.
This fixes the gtk_render_frame_gap() warnings seen when a popover is
pushed far too close to window sides.
After b49c7c3421 we were no longer doing a
full revalidate after GTK_CSS_CHANGE_SOURCE changes.
This fixes spurious failures of widgets not properly updating when
changing the theme.
These functions, while added for use by the GTK inspector, are generally
useful to applications that need to resolve what action groups are
available to a particular GtkWidget.
https://bugzilla.gnome.org/show_bug.cgi?id=741386
Without this, the focus will not be inside the top_stack when
we switch to the statistics page and it shows the excuse. This
in turn will make the next page not take focus as expected when
switching away from the statistics page again.
Add notebook-like focus handling: Keep track of the last focused
descendent of each page, and focus it again when switching back
to the page. If there is no last focused child, we move the focus
into the page as if the user had hit Tab.
When using a completion with some custom cells in the cell layout,
if would often size wrong when first presented on screen.
The entry completion is the only place in the entire gtk code base
that calls gtk_tree_view_column_cell_get_size outside of gtktreeview
itself. It calls into the function before the tree view has done some
important validation on its cell state, the net result of which is
only the first element in the gtkcellareabox the entry completion uses
well actually have its size respected.
We now call gtk_widget_get_preferred_size on the tree view before
calling into the individual cell size routines, to guarantee that the
tree view has run its validate_rows routine and cell state is valid.
https://bugzilla.gnome.org/show_bug.cgi?id=741130
Use the new scrollable API for getting non-scrollable borders
and draw over/undershoot at the right place. In practice, this
means that they now appear below treeview headers.
Add a vfunc to return a non-scrollable border around scrollables.
This would be nicer as a property, but we can't add properties
to an interface without breaking 3rd party implementations, so
make this an optional vfunc, and handle it not being set.
The new region selector tracks more than just one soimple selector, so
it requires some more advanced specificity tracking.
Technically, this is still not correct, because it will report the same
specificity for
tab:sorted
and
tab:sorted:sorted
(and the second selector will be printed as the first) but this is
regions, so meh.
This is just a way to handle regions more conveniently. What this does
is to change the descendant matcher into a maybe-descendant matcher
whenever the current object we're parsing might be a region. Because "*"
might also refer to a region and not just a new element.
See testsuite/reftests/css-match-region-matches-star.ui for a testcase.
When parsing a selector like
tab:active
We used to create 2 selector objects, one for the region, and one for
the pseudoclass. Now, for convenience, we special-case region
pseudoclass parsing so that the active flag is added to the region
selector.
A side effect is that ":nth-child(1)" no longer works for regions.
Hopefully people didn't use this but used the saner ":first-child"
instead.
We used to switch to the objects tab when an object is
picked, but now may have two places with picker buttons:
the objects tab and the interactive tab.
So, just don't do that anymore.
Currently we only take into account the window GActionGroup for
activating the accels.
However, the application could have some custom GActionGroup in the
chain of focused widgets that could want to activate some action if
some accel is activated while that widget is focused.
To allow applications to set accels on widgets that use custom
GActionGroups, simply use the muxer of the focused widget, which
already contains the actions of the parents.
https://bugzilla.gnome.org/show_bug.cgi?id=740682
Add links from gtk_icon_theme_list_contexts() to
gtk_icon_theme_list_icons(), and from there to the Icon Theme
Specification and the Icon Naming Specification.
https://bugzilla.gnome.org/show_bug.cgi?id=461249
Adding rows to the bottom of the list is confusing as you cannot see
them if the window is small so it is not apparent that anything has
happened. Fix this by adding the new row immediately below the current
row and set the cursor on the new row so it is ready to be edited.
https://bugzilla.gnome.org/show_bug.cgi?id=721939
Most of the core GNOME applications (eg., gnome-control-center,
gnome-documents, and nautilus) start searching as soon as the text
changes, and don't wait for the user to hit ENTER. It would be nice to
follow the same pattern.
https://bugzilla.gnome.org/show_bug.cgi?id=739977
Since widgets subelements are now both widget childs and widget
classes, say .spinbutton.button and .spinbutton .button,
the linking logic needs to be adapted to be stricter with
child selectors. This fixes vertically linked spinbuttons.
Since widgets subelements are now both widget childs and widget
classes, say .spinbutton.button and .spinbutton .button, the linking
logic needs to be adapted to be stricter with child selectors.
This fixes vertically linked spinbuttons.
If the previous focus widget is unmapped (eg. hidden, scheduled for
destruction, etc), make the popover forget about it and grant focus
back to the window itself.
The shadow rendering code had code to exit early if we determine
that the shadow is entirely clipped away. Unfortunately, the check
based on cairo clip extents fails for any clip regions that are
more complicated than axis-aligned rectangles, and we are using
a hollow rounded rectangle here. So, instead, do the check manually,
using the just-introduced API in GtkRoundedBox.
This adds two functions for checking whether an axis-aligned
rectangle is completely outside or inside of a rounded box.
These are not trying to be exact, but fast.
As the print preview command is moved into the sources, don't define it in
the preprocessor definitions. However, define the
GTK_PRINT_BACKEND_ENABLE_UNSUPPORTED in the preprocessor definitions, to
make the build in-line with the autotools builds.
We were concatenating "file://" to the result of g_get_user_special_dir() to build
a URI, but this is not enough on Windows. Use g_filename_to_uri() instead.
See https://bugzilla.gnome.org/show_bug.cgi?id=739453
Previously, the inspector would not change the hilight while the
previous hilight was still flashing.
This is inconvenient while arrowing through the object selection
treeview though where you want the currently selected row to hilight
when arrowing quickly.
The GTK_FILE_SYSTEM_ENABLE_UNSUPPORTED define is not used anymore,
and we don't install a gtk.css file for Raleigh, so no need to
uninstall one either.
gtk-update-icon-cache is no longer used at build time, so a lot
of the complicated machinery we have around that (conditional
build, cross build, etc) are no longer required.
The files for build of GtkInspector have been intergrated into the build of
the main GTK+ DLL, and the Visual Studio project templates for those have
been removed as well. Make that removal complete by removing from the
solution files references to it and make the 'gtk' project not to depend on
the gtk-inspector project.
1) Use font-size instead of color
This makes it easier to compare reference and test because the values
don't change.
2) Actually sort the reference properly
This unbreaks the test.
This subdirectory gets in the way when integrating the inspector
build more fully with GTK+, and does not really add anything.
Just move everything one level up.
I checked Cairo source code (actually pixman, as Cairo just passes
through) to make sure that the behavior stays identical: negative values
cause an error message from pixman, zero is allowed. Both return an
empty region which gtk_widget_queue_draw_region() would then proceed to
ignore.
The calls to cairo_translate in
_gtk_print_context_rotate_according_to_orientation,
_gtk_print_context_reverse_according_to_orientation and
_gtk_print_context_translate_into_margin assume an unscaled context.
These functions should therefore be called before scaling the context,
otherwise the origin does not always end up in the top left corner.
https://bugzilla.gnome.org/show_bug.cgi?id=740742
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
gtk_window_propagate_key_event() will run unstopped from the focus widget up to the
popover if GDK_EVENT_PROPAGATE was returned along the chain, resulting in infinite
recursion. This could be just triggered by pressing some modifier key on an entry...
If a file system event arrives while GtkFileChooserWidget is asking the
user to edit the name of a newly created folder, the file system model
will drop the row with the editable cell, and the user will have to
start from scratch.
This makes creating new directories impossible inside a directory with a
file currently being downloaded, for instance, and it's really unhelpful
to the user because the editable row simply disappears.
We already have a mechanism in place to freeze the file system model, so
we can reuse it between the add_editable() and the remove_editable()
calls.
https://bugzilla.gnome.org/show_bug.cgi?id=729927
We directly get the length of the secret from the g_variant
and use it in a following g_strndup which ensures that the
resulting string is terminated.
This fixes reading secrets which were stored by system-config-printer.
https://bugzilla.gnome.org/show_bug.cgi?id=740612
This is a bit bizarre, but the cell renderer can apply different
flags from the actual style context, and we should use those instead
of the widget flags.
:not() works for names, ids, classes and pseudoclasses based on states.
It does not yet work for positional pseudoclasses (like :last-child or
:even) as there is region madness going on with those.
The adjustment value being equal is checked by
gtk_adjustment_set_value() and the necessity of calc_layout() is handled
by the value_changed signal handler.
This is the expected behavior while the popover keeps the grab, leaving
this up to the toplevel implementation gives place to key handlers
connected there to handle the event otherwise, and maybe redirect key
events somewhere else.
NULL-plus-something could be seen by the compiler to attempt to do
arithmetic with void *, which is a GCCism. Instead, do the math normally
and cast the results as a void *.
https://bugzilla.gnome.org/show_bug.cgi?id=740605
Use xdg_surface_set_window_geometry() to tell the compositor about the
shadow widths, this makes some gnome-shell/mutter features (edge resistance,
frames around windows in the overview, side maximization, ...) work alright
with GTK+.
In order to add this, some other places in gdkwindow-wayland had to gain
some knowledge about margins:
- xdg_surface_configure() now syncs the shadow after applying the state,
and gdk_wayland_window_set_shadow_width() possibly reconfigures the
window in order to preserve window geometry. This is necessary to keep
shadows in sync with state/geometry changes, as this does not happen
all at once.
- xdg_popups relative to an xdg_surface are shown relative to buffer
coordinates, so the left/top margins must be added there.
https://bugzilla.gnome.org/show_bug.cgi?id=736742
This requires us to use GL_TRIANGLES and six verts per quad instead
of four, which makes me think it might not be worth it on
well-optimized GL drivers. However, from talking to some driver
developers about it, the GL_TRIANGLES should be faster, since this
means that there's one giant contiguous buffer instead of many small
buffers.
If we were really rendering a lot of quads, I'd use an element buffer
and GL_PRIMITIVE_RESTART, but we're really not ever rendering that
many quads, and the setup cost for that would just be too annoying.
It's unused. At the same time, rename "begin_paint_region" to
"begin_paint". This will help us clean up how GDK painting works
in the future to allow more creative use of double-buffering.
...for Broadway builds, as it was producing a wrongly-named check file for
that configuration, so that a clean would not be correctly performed and
subsequently affected rebuilds.
This is needed in the edge case where the X11 backend rounded the actual
size, and the GL flipping really needs the correct window height to
do proper Y coordinate flipping.
https://bugzilla.gnome.org/show_bug.cgi?id=739750
This is required for the X backend GL integration. If the
window has a height that is not a multiple of the window scale
we can't properly do the y coordinate flipping that GL needs.
Other backends can ignore this and use the default implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=739750
Rather than just rounding down the position *and* the size separately
we correctly calculate a rectangle in scaled window coords that fully
covers the real window size. This really only makes a difference
when the window size/position isn't a multiple of the window scale.
https://bugzilla.gnome.org/show_bug.cgi?id=739750
Keep track of the exact size of X windows in underlying pixels; we
generally use the scaled size instead, but to properly handle the GL
viewport for windows that aren't a multiple of window_scale,
we need to know the real size.
https://bugzilla.gnome.org/show_bug.cgi?id=739750
Although we specify a resize increment to try and get a size that is
a multiple of the window scale, maximization typically wins
over the resize increment, so the window might be odd sized.
Round *up* in this case, rather than down, since it's better to
truncate a line or two at the bottom and right of the window rather
than have a line or two that we don't know what to do with.
https://bugzilla.gnome.org/show_bug.cgi?id=739750
The intention was that ::iconic indicates which representation is
preferred (text or icon). We fall back to the other representation
if one is missing.
If the widget is an action widget, it's been previously added with
gtk_dialog_add_action_widget, which calls add_response_data on it, which
in turn connects to the clicked/activate signal of that widget, so we
don't need to connect to that signal a second time in
gtk_buildable_custom_finished.
When overshooting through touchpad kinetic scrolling, the scrollbar remains
mostly static as it already hit a boundary. However, the fade in/out checks
are constantly run during scroll events, causing needless redraws in this
specific case.
The scrollbars are still internal children of the GtkScrolledWindow
and handled in ::forall(), no need to propagate draw here again
after chaining up in ::draw().
During size request, all sides' margins are ensured to be as big
as TAIL_HEIGHT, just to avoid possible relocation loops if the
popover doesn't fit in its original position. This must be
accounted for in size_allocate() as well.
Look for themes in $prefix/themes/$name/gtk-$version/ (for
version = 3.16, 3.14, ...), before using the old location
$prefix/themes/$name/gtk-3.0/. This gives theme authors a
way to support multiple versions of GTK+ 3 with separate
css files.
We really want margins around the scrollable content, not around
the viewport. Make it so by using textview-specific properties.
This is unfortunately a little complicated for top/bottom.
Css margin now works on the slider as they do on the trough.
The margin is not considered in the space allocation as it is for
the trough, so the slider width will be the set slider-width -
margins. Spefifying margins on the main widget in the css will
clearly affect both the trough and the slider, so theme changes are
needed.
The current way of exposing GDK API that should be considered internal
to GTK+ is to append a 'libgtk_only' suffix to the function name; this
is not really safe.
GLib has been using a slightly different approach: a private table of
function pointers, and a macro that allows accessing the desired symbol
inside that vtable.
We can copy the approach, and deprecate the 'libgtk_only' symbols in
lieu of outright removal.
https://bugzilla.gnome.org/show_bug.cgi?id=739781
Instead of possibly calling wl_surface_commit() out of
GdkFrameClock::after-paint, tick the transient parent clock so ::after-paint
can be eventually run.
This ensures that the subsurface coordinates (considered part of the state
of the parent) aren't committed untimely, and guaranteed to be orderly with
the wl_subsurface-relative state.
This is a gtk-side fix for https://bugzilla.gnome.org/show_bug.cgi?id=738887
cairo_region_copy(NULL) will effectively return an empty region, as this
function is always meant to return valid memory. This however inverts the
meaning of the NULL region and results in entirely non-clickable windows.
This event might not have an action yet, but certainly accounts, and
should be triggering recognition.
This fixes a crash when attempting to drag CSD windows through touch. As
since cfaec2d2f5, gtk_gesture_single_get_current_sequence() would
rightfully return NULL if the gesture didn't enter recognition, making
event lookup fail.
We need to export the symbols so they can be used in the
inspector, but we don't really want to make this supported
public API, so keep them out of installed headers.
Store the cursor name on the cursor (rather than always using its type).
Use this when setting a cursor on a surface.
The mir server will fallback to using standard cursors from the cursor
theme if the name used is not one of those defined by mir, which is more
or less what we want to happen here in case of creating a cursor by
name.
If buffer age is undefined and the updated area is not the whole
window then we use bit-blits instead of swap-buffers to end the
frame.
This allows us to not repaint the entire window unnecessarily if
buffer_age is not supported, like e.g. with DRI2.
This moves the GDK_ALWAYS_USE_GL env var to GDK_GL=always.
It also changes GDK_DEBUG=nogl to GDK_GL=disable, as GDK_DEBUG
is really only about debug loggin.
It also adds some completely new flags:
software-draw-gl:
Always use software fallback for drawing gl content to a cairo_t.
This disables the fastpaths that exist for drawing directly to
a window and instead reads back the pixels into a cairo image
surface.
software-draw-surface:
Always use software fallback for drawing cairo surfaces onto a
gl-using window. This disables e.g. texture-from-pixmap on X11.
software-draw:
Enables both the above.
The Mir backend was checking for button mask changes to generate the appropriate
GDK event. When Mir generates a touch event it has no button mask. In this case
we'll just generate a primary button event.
This was unnecessarily creating a framebuffer in the texture case,
and it was not properly setting up a framebuffer with the texture
as source in the software fallback w/ texture source case.
Commit afd9709aff made us keep impl window
cairo surfaces around across changes of window scale. But the
window scale setter forgot to update the size and scale of the
surface. The effect of this was that toggling the window scale
from 1 to 2 in the inspector was not causing the window to draw
at twice the size, although the X window was made twice as big,
and input was scaled too. Fix this by updating the surface when
the window scale changes.
We need to use this in the code path where we make the context
non-current during destroy, because at that point the window
could be destroyed and gdk_window_get_display() would return
NULL.
The child property setting must be prepared to deal with any
child property for any child, even if it doesn't make sense,
like the pack-type for the custom title. This is happening
in glade when undoing a change in the custom-title property.
When a GtkRadioButton has no focus, it will accept it when there is no
other active button in its group.
If the active button in the group is hidden, for example because the UI
desires not to have a default option pre-selected, currently the focus
will not be accepted, which is not desired behavior.
This commit changes the code to only consider visible buttons in the
group when checking whether another button is active.
https://bugzilla.gnome.org/show_bug.cgi?id=739474
Stop using activate-on-single click for the property list -
it is a little annoying to have the popover come up when you
just click in the list to get the focus there.
This restructures the way buffers are allocated and bound in a way
that is more flexible.
Buffer operation happens in three phases:
create_buffer() - Creates the gl objects
allocate_buffers() - Allocates space for the buffers at a given size
attach_buffers() - Attaches the buffers to the framebuffer and makes
the framebuffer the default drawing target
And destroy via
delete_buffers()
We call all these the first draw, and after that we allocate buffers
each time the widget changes size until the buffers are deleted.
We delete the buffers at unrealize.
However, anyone that wants to manually control buffer allocation strategies
can manually call allocate/delete_buffers().
There are also some other changes:
* Support for stencil buffers.
* A manual render mode where ::draw doesn't render unless you manually
invalidated the previous rendering.
This moves the code related to the frame sync code into
the is_attached check, which means we don't have to ever
run this when making non-window-paint contexts current.
This is a minior speed thing, but the main advantage
is that it makes making a non-paint context current
threadsafe.
This is not really needed. The gl context is totally tied to the
window it is created from by virtue of sharing the context with the
paint context of that window and that context always has the visual
of the window (which we already can get).
Also, all user visible contexts are essentially offscreen contexts, so
a visual doesn't make sense for them. They only use FBOs which have
whatever format that the users sets up.
We had some code that tried to reuse the context over realize, but
that doesn't work as we need to share with the possibly new
paint context of the re-realized window.
To properly support multithreaded use we use a global GPrivate
to track the current context. Since we also don't need to track
the current context on the display we move gdk_display_destroy_gl_context
to GdkGLContext::discard.
Removed bright translucent outer border for "top level" osd widgets,
insensitive osd entry styled, more meaningfull color variables and
some code rationalization.
We used to have a weak ref to the cairo surface and it was keep
alive by the references in the normal windows, but that reference
was removed by d48adf9cee, causing
us to constantly create and destroy the surface.
https://bugzilla.gnome.org/show_bug.cgi?id=738648
We want to create windows with the default visuals such that we then
have the right visual for GLX when we want to create the paint GL
context for the window.
For instance, (in bug 738670) the default rgba visual we picked for the
NVidia driver had an alpha size of 0 which gave us a BadMatch when later
trying to initialize a gl context on it with a alpha FBConfig.
Instead of just picking what the Xserver likes for the default, and just
picking the first rgba visual we now actually call into GLX to pick
an appropriate visual.
Add a menu-name property and use it in a default implementation
of ::clicked to switch menus if we are inside a stack. This means
GtkModelButton is no longer entirely generic, but rather expects
to be used inside a GtkPopoverMenu. It still works in other contexts
too, of course.
Rename the "toggled" property to "active", since that is what
GtkActionHelper expects to update for check and radio actions.
Also make the property readable, since GtkActionHelper wants
to read it.
The visuals are typically sorted by some sort of "most useful first"
order. And picking the last one is likely to give us the weirdest
matching glx visual.
Under wayland, the compositor doesn't have a 'overall window alpha'
knob, we just need to add the alpha to the buffers we send.
Client-side alpha, if you want to call it that.
Implement this by reusing the existing alpha support for non-toplevel
widgets. As a side-effect of the implementation, windows with RGBA
visual under X will now also use per-pixel alpha, instead of
overall alpha.
The differences between the mutter and GTK+ code are subtle, but it
turns out that _gtk_cairo_blur_compute_pixels actually returns the
shadow *spread*. Since we use a triple box blur, the constant was
multiplied by 1.5 to approximate three chained box blurs. Split this
out and use the correct value for the lobe width.
We weren't passing in the right "d" value, which was causing the blur to
behave incorrectly, especially in the case of 1px blurs, which would
cause no blurs at all.
The blur should now match the web.
We don't want separators in both side of an iconic section
and use a 10px margin to separate two iconic sections.
Separators are also updated in case of dynamic insertion
( often used with menu items for plugins )
https://bugzilla.gnome.org/show_bug.cgi?id=738650
We want to be able to style the empty blocks independently of all the
offset styles, so remove the current style class when painting an empty
block.
https://bugzilla.gnome.org/show_bug.cgi?id=707695
It is not possible to successfully build GTK+ on OS X 10.6 and below
since NSFullScreenWindowMask is only available starting with 10.7. Add
ifdef guards around setStyleMask: in order to allow it to build on
earlier OS X releases.
https://bugzilla.gnome.org/show_bug.cgi?id=737561
Commit 30a1c4ab fixed several memleaks including one in
gtk_font_chooser_widget_find_font.
However, the fix causes one extra call to gtk_tree_model_iter_next()
after finding the font we look for (ie pango_font_description_equal
returns TRUE): the 'increment' part of the for loop
(gtk_tree_model_iter_next) is run before the 'exit condition' of the for
loop is evaluated.
This commit reverts this part of commit 30a1c4ab and adds an extra
call to pango_font_description_free in order to fix the leak.
https://bugzilla.gnome.org/show_bug.cgi?id=739111
When using GtkFontChooserButton, the same GtkFontChooserWidget can be
hidden and shown multiple times. When doing that, the font that was
chosen the previous time should be the selected one in the
GtkFontChooserWidget, however this does not work as expected and a
somehow 'random' font gets selected (or none) instead.
Every time the font chooser widget is shown, its style will be updated,
causing gtk_font_chooser_widget_style_updated and then
gtk_font_chooser_widget_load_fonts to be called.
gtk_font_chooser_widget_load_fonts starts by clearing the GtkListStore
listing the available fonts, repopulates it, and then makes sure the
current font is selected.
However, this does not work as expected, as during the call to
gtk_list_store_clear, the cursor_changed_cb will be invoked multiple
times when the GtkTreeView cursor gets moved when the line where the
cursor currently is gets removed. This will cause the 'current font'
state (priv->font_desc) to be unexpectedly modified, and when
gtk_font_chooser_widget_load_fonts tries to reposition the cursor to the
'current font', we won't get the expect result.
This commit avoids that by making sure cursor_changed_cb does not get
called when we call gtk_list_store_clear in
gtk_font_chooser_widget_load_fonts.
https://bugzilla.gnome.org/show_bug.cgi?id=739111
Commits 314b6abbe8 and eb9223c008 were ignoring
the fact that the code where found is set to 1 was modifying
col - which was an ok thing to do when that part of the code
was still breaking out of the loop, but it is no longer doing
that (since 2003 !). Fix things up by storing the final col
value in a separate variable and using that after the loop.
https://bugzilla.gnome.org/show_bug.cgi?id=738886
2014-10-26 21:48:59 -04:00
1638 changed files with 273543 additions and 196797 deletions
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
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
cat $< | sed 's/vs10/vs$(MSVC_VER)/g' | sed 's/VS10/VS$(MSVC_VER)/g' > $(top_builddir)/build/win32/vs$(MSVC_VER)/$@
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 \
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.
Benjamin Otte
Carlos Garnacho
Alexander Larsson
Lapo Calamandrei
Matthias Clasen
cedlemo
Balázs Úr
Christoph Reiter
William Hua
Marek Kasik
Emmanuele Bassi
Paolo Borelli
Caolán McNamara
Christian Kirbach
Piotr Drąg
Chun-wei Fan
Timm Bäder
Jakub Steiner
Ting-Wei Lan
Cosimo Cecchi
Jonas Ådahl
Christian Hergert
Yosef Or Boczko
Carlos Soriano
Daniel Mustieles
Dimitris Spingos
Jordi Mas
Cosimo Cecchi
Rui Matos
Alberts Muktupāvels
Victor Ibragimov
Rico Tzschichholz
John Ralls
Cédric Valmary
Krzesimir Nowak
Dave Airlie
Руслан Ижбулатов
Dušan Kazik
Marek Černocký
Pietro Gagliardi
Kjell Ahlstedt
Kjartan Maraas
Marco Trevisan (Treviño)
Lars Uebernickel
Philip Chimento
Balázs Meskó
Gábor Kelemen
Alexandre Franke
Lionel Landwerlin
Sjoerd Simons
Garrett Regier
Petr Kovar
Debarshi Ray
Yuri Myasoedov
Simon McVittie
Fabiano Fidêncio
Jose Rostagno
Daiki Ueno
Kai Willadsen
Sveinn í Felli
Rafael Ferreira
Daniel Korostil
Michael Catanzaro
Federico Mena Quintero
Sebastian Keller
Matej Urbančič
Daniel van Vugt
Ask Hjorth Larsen
Evangelos Foutras
Khaled Hosny
Anders Jonsson
William Hua
Joanmarie Diggs
Denis Arnaud
Olivier Fourdan
Stas Solovey
Antoine Jacoutot
Ryan Lortie
Hans de Goede
Will Thompson
Marcus Karlsson
Ignacio Casal Quinteiro
Changwoo Ryu
Niels Nesse
Inaki Larranaga Murgoitio
Tom Tryfonidis
Milo Casagrande
Tom Hughes
Emmanuele Bassi
Muhammet Kara
hanniedu
Vadim Rutkovsky
Милош Поповић
Bastien Nocera
Zahari Yurukov
Trần Ngọc Quân
Josef Andersson
Nelson Benítez León
Samir Ribic
A S Alam
Philip Withnall
Andre Heinecke
Bastian Ilsø
Aurimas Černius
Baurzhan Muftakhidinov
Frédéric Péters
Eric Le Bihan
Claude Paroz
Georges Basile Stavracas Neto
Fran Dieguez
Stefan Sauer
Murray Cumming
Peter Bloomfield
Friedel Wolff
Olivier Fourdan
Rafal Luzynski
Efstathios Iosifidis
Daniel Drake
Chao-Hsiung Liao
Thibault Saunier
Arnav Singh
Jasper St. Pierre
Pier Luigi Fiorini
Armin K
Víctor Manuel Jáquez Leal
Felix Riemann
Matias De lellis
Christian Persch
Jonas Danielsson
Mike Gorse
Maks Naumov
Iain Lane
Nelson Benitez Leon
David King
David King
Bruce Cowan
Sebastien Lafargue
Patrick Welche
Florian Müllner
Erick Pérez Castellanos
Sébastien Wilmet
Michael Natterer
Matt Watson
Carlos Soriano
Phillip Wood
Ankita Patil
Trinh Anh Ngoc
Leo Wolf
Ray Strode
Owen W. Taylor
Robert Ancell
Javier Jardón
Christophe Fergeau
