We are using the current gtk event position to check if
the user clicked in the eject button of a row.
However, we are calling this in row-activated signal, which
can happens when the gtk+ mainloop already removed the "current"
event, and therefore we were trying to access a null event position
which crashes the sidebar.
To fix it check if we have as current event, and if not,
we will not check for the position. But it's better than crashing,
and shouldn't happen too much.
https://bugzilla.gnome.org/show_bug.cgi?id=754995
We automatically pick up an adjustment from our parent
scrollable, but we failed to update it when it changes.
This is happening in the places sidebar, and it was causing
the focus-tracking to fail there, letting the focus move
out of view. With this change, the focus remains visible.
The menu tracker does a better job of this than we can, so move over to
using it instead.
This fixes issues with './testgmenu --import' not properly displaying
the language submenu.
https://bugzilla.gnome.org/show_bug.cgi?id=752016
I believe that first_column can only ever be NULL here if
last_column is NULL too, in which case we'd exited already.
But coverity doesn't see that, so add an explicit exit.
We don't care about the error here, but we were relying on
g_resources_get_info to zero the size even in case of error.
No need to do that, we can just check the return value. Plus,
it makes coverity happy.
The way this code is written, we know that there is an item in
the hash table and the iter_next call will give it to us, so
no need to check the return value. Annotate the call to tell
coverity.
When using frame times from _NET_WM_FRAME_DRAWN and _NET_WM_FRAME_TIMINGS, we
were treating them as local monotonic times, but they are actually extended-precision
versions of the server time, and need to be translated to monotonic times in the
case where the X server and client aren't running on the same system.
This fixes rendering stalls when using X over a remote ssh connection.
https://bugzilla.gnome.org/show_bug.cgi?id=741800
We used to "invalidate" scroll valuators, so the next scroll event could
be used as the base for the next scroll deltas. This has the inconvenience
that it invariably consumes the first event received after enter and,
due to interactions with WM overeager passive button grabs, there's a
possibility we don't scroll at all if we receive interleaved "smooth
scroll" XI_Motion events and XI_Enter events (Normally triggered by regular
scroll wheels in mice).
In order to fix this, and at the expense of some sync-call overhead on
XI_Enter events (one XIQueryDevice call per slave device), query the
current scroll valuator state for all the slaves of the entered pointer,
so we do know beforehand the right base values. If new devices are plugged
while the pointer is on top of the client, the initialized scroll values
will match the valuators'.
https://bugzilla.gnome.org/show_bug.cgi?id=750994https://bugzilla.gnome.org/show_bug.cgi?id=750870
gdk_x11_device_xi2_window_at_position() may attempt to push/pop
a few error trap pairs while traversing the window tree. Move it
outside the server grab, and around the multiple XIQueryPointer
calls we may do here.
https://bugzilla.gnome.org/show_bug.cgi?id=751739
The WM isn't aware of O-R (popup) or offscreen windows. If somebody
maps an offscreen or a popup GTK+ window before the main window, we'll
complete the sequence before a "real" window is mapped. Make sure to
ignore these for startup notifies.
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
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
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
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
As an actionable (inherited from GtkButton), a GtkMenuButton
should not set its own sensitivity when it has an action-name
set, but just follow the enabled state of the associated
action.
https://bugzilla.gnome.org/show_bug.cgi?id=738083
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
"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.
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.
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
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
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
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.
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
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
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
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.
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.
gtk_drag_cancel() will become public API in 3.16; we keep it
private here so we can use it from GtkNotebook.
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.
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 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
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
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
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
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 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
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
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
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
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
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.
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
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.
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.
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
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
...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.
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.
It seems in cairo 1.14 we need this after having painted an image surface
to a X11 window surface (i.e. with GDK_RENDERING=image).
(cherry picked from commit 90555e06be)
When a new screen is set on a window, we unrealize it, to
recreate all the resources. But we don't reset the client_decorated
flag, so realize() doesn't call create_decoration() - which makes
sense, since the decoration already exists. But the side-effect
of create_decoration() is to select the rgba visual, and visuals
are per-screen.
Fix this by looking for the rgba visual in set_screen(), and
replacing it with the rgba visual for the new screen, if necessary.
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.
(cherry picked from commit 113e1d1dc0)
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
(cherry picked from commit afd9709aff)
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
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
"Install" gdkbroadwaydisplay.h, as it is a public header of GDK Broadway,
also fix the MSVC 2010+ gtk-copy-gdk-broadway.props property sheet as a
'>' is missing. Sorry for not noting these issues earlier, as MSVC
Broadway builds were recently restored. My bad :|
The current implementation of this script generate headers with \x-escaped
strings that can become too long (> 65535 characters) for Visual Studio
to consume, hence the build of broadwayd would break on Visual Studio.
This changes the script to instead format the string as an array of hex
characters, not unlike what GResource does, so that builds can continue as
normal on Visual Studio builds as well.
https://bugzilla.gnome.org/show_bug.cgi?id=739001
There is now a broadway-buffer.c source that needs to be built for this, so
add it into the projects. Since crypt() is no longer used, don't include
crypt.c in the builds, and so clean up the projects a bit.
wayland doesn't strictly follow the XDG_RUNTIME_DIR spec by falling back
to another directory in case the runtime dir is not properly set.
When this variable is unset, wayland will log an error to us, which we
treat as fatal, aborting the entire program.
Skip ourselves all the trouble and don't try to bring up the wayland
backend when we know it will fail in this way.
https://bugzilla.gnome.org/show_bug.cgi?id=738873
When gtk_window_set_titlebar (win, NULL) is called, we were taking
an early exit and forgot to re-map the window. This does not normally
happen in practice, but glade is about to get a 'csd' switch which
lets one toggle back and forth between titlebar and no titlebar.
When the searchbar is hidden, a 1-pixel-high piece of it is
still peeking out, because visible widgets are always allocated
at least 1x1. Work around this by setting child-visible to FALSE
in this situation.
https://bugzilla.gnome.org/show_bug.cgi?id=724096
When a drive is ejected or a volume unmounted the current directory
doesn't change most of the times being empty or being a directory that
user shouldn't take care about, like /run/media
Seems more useful to change to $HOME directory in that case so the user
can see something useful and familiar just after unmounting.
https://bugzilla.gnome.org/show_bug.cgi?id=737983
Currently we change the current location if we click the eject button of
a mount.
Check whether the user actually clicked the eject button and don't
change location in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=737983
Currently writing wl_data_offer data into the fd is 1) synchronous, which
is noticeable when transferring large amounts of data, and 2) buggy, write()
error checking is done on the accumulator, breaking both the written data
accounting and error checking itself.
Fix both by making writes asynchonous through GOutputStream, the operation
is spun off and either finished, or cancelled if new data is stored in the
selection while the transfer is active.
auth_info should be a NULL-terminated array as it is used in
e.g. g_strdupv invocations iterating over its elements until
a NULL element is encountered.
https://bugzilla.gnome.org/show_bug.cgi?id=737777
These turned out to break existing ui files, concretely
GWeatherLocationEntry was no longer guessed correctly.
Update the testcases to reflect this, and add a testcase
for GWeather.
The documentation explicitly states that 0 is an allowed value for using
the same scale as the window. This 0 value is also explicitly checked
down in the call chain and handled.
We get multiple notifications from the bookmark manager when
something changes. Every time, we reconstruct the sidebar contents
completely, by clearing the store. The bookmarks are added with
async calls though, and the code was forgetting to cancel outstanding
async requests, leading to multiple instances of the same bookmark
getting added. Use the cancellable we already have to prevent that.
This could be made much more efficient by not recreating the entire
sidebar quite so often (3-5 times for a single bookmark rename).
https://bugzilla.gnome.org/show_bug.cgi?id=737679
I've noticed a missing image show up in my print dialog, where
the printer reported "printer-paused" as icon. Rearrange things
so we always fall back to "printer" for printer icons.
With buttons at the bottom, things were not looking good here:
no spacing, and a gray background. Add spacing, and put the buttons
on the white background.
It turns out that GtkBuilder will sometimes set a property
twice. Normally, this is harmless, but for GtkRadioButton:group,
it triggered a critical. Remove that.
When allocated more than the requested height, GtkCalendar
was 'falling apart'. Not only was the main part rendered
at the far end of the allocation, clicking on days was
broken in this scenario.
Fix this by always placing the main part directly under
the header and day names.
https://bugzilla.gnome.org/show_bug.cgi?id=737670
The warning may have had some value at some point, but if
people uninstall large icons just to make the warning go
away, it does more harm than good. So just remove it.
Context menus inherit their style from the widget they are attached
to. This can have unexpected effects in particular for font, as can
be seen in gedit or gnome-calculator. Prevent this by resetting
the font of context-menus to the initial value.
Tell people that they need to download and install the Adwaita icon theme,
by following the instructions given on
https://live.gnome.org/GTK%2B/Win32/MSVCCompilationOfGTKStack.
Also tell people they can either use IJG JPEG or libjpeg-turbo for non-GDI+
builds of GDK-Pixbuf.
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.
Mingye Wang
Ignacio Casal Quinteiro
Pedro Albuquerque
Felipe Braga
Arash Mousavi
Carlos Soriano
Anders Jonsson
Andika Triwidada
Matthias Clasen
Ryan Lortie
Carlos Garnacho
Marek Černocký
Balázs Úr
Owen W. Taylor
Aurimas Černius
Matej Urbančič
Piotr Drąg
Jasper St. Pierre
Emmanuele Bassi
Krzesimir Nowak
Alexander Larsson
cedlemo
Caolán McNamara
Cosimo Cecchi
Cosimo Cecchi
Benjamin Otte
John Ralls
Cédric Valmary
Jakub Steiner
Marek Kasik
Руслан Ижбулатов
Sveinn í Felli
Christian Hergert
Michael Catanzaro
Federico Mena Quintero
Christian Kirbach
Lars Uebernickel
Georges Basile Stavracas Neto
Will Thompson
Joanmarie Diggs
Marcus Karlsson
Tom Hughes
Emmanuele Bassi
hanniedu
Necdet Yücel
Vadim Rutkovsky
Samir Ribic
Andre Heinecke
Chun-wei Fan
Мирослав Николић
Debarshi Ray
Peter Bloomfield
Rico Tzschichholz
Paolo Borelli
Thibault Saunier
Arnav Singh
Pier Luigi Fiorini
Matias De lellis
Garrett Regier
Christian Persch
Mike Gorse
Maks Naumov
Nelson Benítez León
Iain Lane
David King
David King
Sebastien Lafargue
Patrick Welche
Timm Bäder
Matt Watson
Bruce Cowan
Shankar Prasad
Ting-Wei Lan
Lapo Calamandrei
Kjell Ahlstedt
Phillip Wood
Yosef Or Boczko
Leo Wolf
Efstathios Iosifidis
Alberts Muktupāvels
Bernd Homuth
Christophe Fergeau
Gábor Kelemen
Brion Vibber
Rafael Ferreira
Kjartan Maraas
Daniel Mustieles
Dušan Kazik
Thomas Lange
Baurzhan Muftakhidinov
Carlos Soriano
Milo Casagrande
Dariusz Gadomski
Nilamdyuti Goswami
Vasiliy Nuzha
Changwoo Ryu
Kalev Lember
Stas Solovey
Alexandre Franke