That way, the GTK engine doesn't think that the general .button CSS
might potentially apply to it.
And because combobox button is overly complex and stupid, it cannot be
cached.
So buttons thought they cannot ever cache anything because they might
suddenly end up inside a combobox without noticing and then they'd need
to round their corners differently. Of course they're just regular
"Remove" buttons like all the other 100s of "Remove" buttons in
gnome-software. But hey, better not cache anything for them and
recompute their CSS every time the :hover state changes on one of the
rows.
We can actually share :first-child/:last-child related things now,
because we special case them. So the only positions we cannot cache are
nth-child/nth-last-child.
This should take care of a lot of Adwaita's styling.
This way, we can live without row references.
A side effect is that opening the inspector on the gtk-demo list box
example now only takes 0.5s instead of the previous 3 minutes.
Instead of queueing a new idle handler every time we call
gtk_window_update_debugging(), only queue one if none is queued that.
Saves a lot of work, in particular when templates create context menus
for every row in a large listbox as in the gtk-demo listbox example.
Do not use .button anymore.
This is for 2 reasons:
1. The styling is seperate in our themes, so it doesn't make sense to
share the style class.
2. Due to the shared styling of .buton, listbox rows inherit all the
special case styles that exist for buttons - such as linked buttons,
header buttons, entry buttons, spinbutton buttons, etc. This means
that the code has to check all these special cases all the time and
for listbox rows, this is very slow.
Defer a11y initialization until we have a display. A11y initialization
causes widget classes to be initalized, which in turn needs some
backend-specific information about modifier masks that can't be
obtained before we have a display.
https://bugzilla.gnome.org/show_bug.cgi?id=736125
If we manually enter an unaccessible path in the entry, e.g
"/root/foo.txt", we should receive an error saying that the
folder is not accessible instead of showing the replace
confirmation dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=753969
Previously we were assuming that only list box rows could occur
as focus children of a list box, and would crash if that wasn't
the case. This commit handles this case, and integrates focusable
headers into directional keynav and the focus chain.
The typical case of using separators as headers is not affected
by this change.
https://bugzilla.gnome.org/show_bug.cgi?id=753694
State that the overlays are placed wrt to the GtkOverlay, not
with respect to the main widget. This makes a difference for
small main widgets which are not configured to fill the entire
GtkOverlay.
When an operation is cancelled it's never safe to access
the object itself or the private struct, since it could be
called (and probably is) during finalize.
In case the operation is cancelled, just bail out to fix
the crashes.
Add a spinner when networks are being fetched and make
the network section permanent and show a placeholder with
a message that no networks were found in case there are no
networks. In this way users from previous versions won't be
confused with the fact that no networks are shown.
https://bugzilla.gnome.org/show_bug.cgi?id=753786
Previously we had a network item in the sidebar, which now
is replaced by the network section on other-locations view.
However we were not exposing the networks in network:///.
Fetch them and add them in the network section of other-locations
view.
https://bugzilla.gnome.org/show_bug.cgi?id=753786
Code exists in the wild that calls this function after the widget has
been destroyed (and the pixel cache released). Simply check that the
pixel cache exists to preserve the existing state.
When you move line by line, only padding is
automaticly shown and you need to use Page key to show margin.
This commit also fix cursor going out of the screen bug.
In order to play along with child widgets that use scroll events for anything
else than scrolling, it will be better to do this in the bubble phase, so
the child widget has an opportunity to GDK_EVENT_STOP the event before we
trigger kinetic scrolling.
This of course won't work for widgets that choose to reimplement scroll event
handling themselves, they should be smart at resorting to GtkScrolledWindow's
scroll event handling.
This fixes kinetic scrolling kicking in too pervasively on widgets that eg.
implement zoom on scroll events.
https://bugzilla.gnome.org/show_bug.cgi?id=753495
By assigning an URI to Other Locations item, we
can programaticaly select it. Fixes a bug in Nautilus,
where the Other Locations item is unselected imediately
after being clicked.
GtkPrintOperation was emitting paginate only if a signal was
connected, this meant that subclassing and overriding the
paginate vfunc lead to the unexpected result that paginate did
not run.
Instead we always emit the signal and use a custom accumulator:
if there is a signal we just run that and avoid the default
handler, otherwise we run the default handler which can be the
one by the subclass or the default handler that just skips
pagination.
Patch by Yevgen Muntyan, fixes#345345
We were not allowing to cancel the operation at all, and at
most the operation was cancelled only when clicked connect again.
Also due to gvfs bug 753735 we actually weren't cancelling
at all, and therefore creating multiple dialogs.
We don't want to leak references if the widget created to represent the
item in the model does not have a floating reference — which is usually
what happens in bindings, as they automatically sink references when
creating new instances.
See commit 6e03e7e8 for the similar change in GtkListBox.
These will be mutually exclusive with touch events, so it won't
be possible to trigger gestures through mixed input and whatnot.
The accounting of touchpad events is slightly different, there
will be a single internal PointData struct, stored in the hashtable
with the NULL event sequence/key (same than pointer events in
this regard), just that the events stored will be GdkEventTouchpad*,
so will hold information about all fingers at once.
But this difference is just internal, the GtkGesture API doesn't
make explicit assumptions about the number of points (the closest
to a per-point query API is gtk_gesture_get_sequences()). All
signals emitted just contain the last changed GdkEventSequence,
and API takes GdkEventSequences, so everything is consistent with
sequence=NULL for touchpad events.
Along the code, we're basically asking for 1) the total count of
touchpoints, and 2) the number of active touchpoints (not denied
nor ended).
Wrap both usecases into a _gtk_gesture_get_n_physical_touchpoints(),
and replace all occurrences.
The gestures that don't want touchpad gesture events are majority,
even those that want such events will only listen to subsets (eg.
pinch, swipe,...).
So it makes sense to ignore touchpad events by default, and let
subclasses opt those in.
This will be used right before handle_event() in order to filter
out events, useful to make the previous "no touchpad events" behavior
the default, and have gesture subclasses include manually the touchpad
events they handle.
For all other events, we run the bubble phase deep in the specific
::motion/button-press/release/touch handlers.
For touchpad events, it doesn't make sense to use GtkWidgetClass
slots if the intended way to deal with these are gestures, so we
run the bubble phase directly from gtk_widget_event_internal().
Do not call _gtk_icon_helper_clear explicitely when the properties
are set, since the corresponding _gtk_icon_helper_set_* method
already calls clear internally.
While at it rename the reset function to make it clear that it
is calling notify for the previous image type and avoid the
notification if the image type is not changing.
We have a testcolorchooser test, with a --edit option. It was
supposed to make the color chooser come up in edit mode, but
it didn't work ever since we dropped the ::response handler.
Fix it by resetting show-editor on unmap, instead of on map.
This way, users can set show-editor before showing the dialog,
and it will take effect.
Since we're dealing with networks, terms like "Eject" or
the eject button are misleading, since we're not actually
ejecting but disconnecting.
Fix that by showing the appropriate icon and tooltip.
We are not showing the URL of network locations
anymore, since they are distracting and not
necessary.
The code, however, forgot to cleanup the URL,
so we are still showing the URL for network
locations.
Fix that by properly cleanup the URL for network
locations.
The .button:link .label selector matches any label "inside" a
link button. And a label inside the context menu counts as inside
for this purpose. This causes the text-decoration property to
leak into the context menu, even though the property is not
inherited. Avoid this by tightening the selector to
.button:link > .label.
https://bugzilla.gnome.org/show_bug.cgi?id=753451
When we connect to a server, the default and expected
behavior is going to the default location, which usually
is the home directory or a writable directory.
GtkPlacesSidebar behaves properly, while GtkPlacesView
doesn't.
Fix that by jumping to the default locations instead of
the root location.
Don't use gtk_widget_show_all() on row widgets because that would
unconditionally show all of its children. This might be unwanted in case
the row implementation wants to keep some of its children hidden.
This commit changes it to use show() instead of show_all() and relies on
the row widget to control the visibility of its children itself as
appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=753392
GtkFileSystem has a complicated way to handle cancellables.
You keep the cancellable pointer that is returned by
_gtk_file_system_get_info and similar methods so that you can
cancel the operation, but you do not own a reference to it.
The only place where it is ok to unref a cancellable is in
your callback, which gets handed a cancellable that you need
to unref at the end. You are expected to compare it to the
pointer you stashed away to find out if the operation has
already been superseded by a newer call, in which case you
disregard the results.
GtkFileChooserButton was following these rules for most of
the cancellables it keeps around, but it was sometimes unreffing
the cancellables that are stored in the model, which could lead
to refcount confusion and crashes. This commit makes it follow
the rules for that case too, which fixes the crash in the bug
below, and does not show up any leaks in valgrind under light
testing.
https://bugzilla.gnome.org/show_bug.cgi?id=737804
The recent change to the enum declaration for GtkCssChange actually
relied on compiler-dependent behavior, which also breaks the build on
some non-GCC compilers, such as Visual Studio. As noted in the
G_STATIC_ASSERT line just beneath this declaration, we need to change
this enum declaration to #define's, in order to fix the build in such
situations.
https://bugzilla.gnome.org/show_bug.cgi?id=752814
It works just as well here as it does in the file chooser, and
this lets us unify the right-click and long-press behavior a bit.
We used to switch directly to the editor on long-press, now we
can show the popover, just as we do on right-click.
This is implicitly done for us in the case of grabs on windows from other
groups, but we must perform this check explicitly for grabs with
owner_events=True on windows from the same group, in that case the window
would handle the events as if there was no grab.
https://bugzilla.gnome.org/show_bug.cgi?id=752327
We only load thumbnails when we find that the row is in the visible
range of the treeview. It seems that animated scrolling makes it so
that the bottommost row stays out of the visible range until it is
too late. To work around this, extend the range by one row in each
direction.
http://bugzilla.gnome.org/show_bug.cgi?id=753142
Properties like transition-property might change when hovering over
something, even if the property itself does not change. These properties
don't affect drawing, so don't queue redraws for them.
Since a lot of Adwaita sets transition: all, it's easy to end up in a
state where we're making dummy transitions for all of the icons, most of
which we'll never be showing.
Interpret a unmodified primary click on the selection like a double
click. This makes it possible to activate a file or open a folder
without using double-click.
The visibility toggling happening on ::click() relied implicitly
on the popover animation, but breaks on disabled animations. The
recursion happening within gtk_toggle_button_set_active() (which
triggers ::clicked when changing state) makes this vfunc to run
again, inverting the visibility of the popover in result.
Fix this by explicitly checking about recursion, we want the
button to be toggled to the right state, but we don't want the
callback running again.
https://bugzilla.gnome.org/show_bug.cgi?id=752577
Instead of putting it inside the button manually, put it there properly
by adding a box containing the cell view and the arrow.
Do the same thing in list mode, instead of creating an event box that
tries to behave as a button.
This is unnecessary - all the recent files are in the model already.
It also leads to duplicates, since our duplicate filtering is based
on g_file_equal, which does not consider recent:///blabla with
target-uri=/my/example to be the same as file:///my/example.
The "Computer" row from places view is an abstract volume
that represents the root of the current partition. As such,
it cannot be mounted or unmounted.
Remove the related item on context menu for Computer row.
We were previously mixing the model used when filtering with an iter that
has been resolved to the backing model.
This results in both an invalid row index as well as an invalid
iter->stamp.
Since we started adding a persistent Computer item,
all the code related to the view modes became obsolete,
since the view is never empty anymore. So, drop this
dead code and use the plain stack to manage the empty
search results view.
Also, this patch fixed a very annoying keyboard navigation
issue where we couldn't go from the On This Computer to Networks
lists, because they were two separate widgets. Merge the two
lists into a single one, and update headers accordingly.
The places sidebar rows' labels were missing a proper
xalign, which caused the labels to keep shaking while
the sidebar was resized.
Fix that by setting the label's xalign to 0.
The GFile containing the Computer item was not
properly dereferenced, so plug that leak by both
dereferencing it and adding some reference management
on GtkPlacesViewRow.
GtkPlacesView widget manages persistent locations,
factoring out GtkPlacesSidebar functionality.
It, however, does not completely shows all sidebar
locations, since Computer is still missing.
Add a Computer item, adjusting some internal behavior
to make that possible.
The doc for gtk_places_view_get_search_query was being
set twice, while gtk_places_view_set_search_query was
never set.
Fix that by correcting the wrong getter documentation.
Use the same explanation of why GtkPlacesSidebar::show-connect-server
was deprecated and its replacements on getter and setter.
Also, fix a mistakenly deprecated function.
GtkCssProvider was using the wrong unref function for GtkCssKeyframe
objects. Funnily, this didn't crash at all, the refcount was at the
same place in the struct - it just didn't free all the memory, causing
valgrind to complain.
Instead of storing the dnd icon as a pixbuf store it
as a cairo surface and transfer the device scale
when converting it to a NSImage. In the pixbuf/stock/named
setters convert to a surface instead (no hidpi support yet)
Previous commits removed from places sidebar the code related
to displaying the Computer item, which should be shown when
the sidebar is not displaying the Other Locations item.
Add back the item when the sidebar is not in Other Locations'
mode.
Make GtkSearchHit carry a GFile instead of an uri. Most of the
search engines already have the object around, and converting
to an uri and back is unnecessary extra work.
Add a helper function that says whether a location should be
considered remote. To determine this, we look at the filesystem
type reported by gvfs, and say 'remote' for sftp, webdav, ftp,
nfs and cifs.
It is a bit pointless to have the file chooser get a uri from an
existing GFile to put in the query, only to have some of the search
engines reconstruct a GFile from it.
It was a special case and it's not used by themes anymore.
Plus, in the CSS world, if a theme wants a separator, it can just
style the button's border to create one.
Without properly cleaning up GtkMenu private attach state
(GtkMenuAttachData) when the attached widget is freed, we would end up
with an invalid pointer to a freed widget. Trying to detach from that
widget would cause a segmentation fault.
https://bugzilla.gnome.org/show_bug.cgi?id=752761
Rewrite gtk_places_sidebar_set_show_enter_location docs, add
references to the relevant signals, remove mentions of
GtkPlacesView from the docs, since it is not public at this point.
https://bugzilla.gnome.org/show_bug.cgi?id=752633
When the dialog is as narrow as possible, we still want some
space between the entry and the search button, so use margins
around the entry and label instead of box spacing.
This ensures that windows appear in the inspectors tree when
they are created, and it prevents GTK_DEBUG=interactive from
coming up with an empty object tree.
https://bugzilla.gnome.org/show_bug.cgi?id=752664
The previous fix was falling into the crack between
realized and mapped - we would apply the state when a window
is just realized, then unset the _initially flag, and then
when the window gets mapped, we'd undo the state. To fix
this, go back to the way things were when these flags were
first introduced.
https://bugzilla.gnome.org/show_bug.cgi?id=752765
When using the location popup to complete to a directory name
(with a trailing /), we should not punish the user by making the
Open button insensitive and preventing the Enter key from doing
the expected thing (switching to that directory).
https://bugzilla.gnome.org/show_bug.cgi?id=752708
Make sure entering the three special strings ".", ".." or "~" in
the location entry works as expected. They already worked correctly
if you append a '/' to force them to be recognized as the 'folder'
part, but that should not be necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=752707
Go back to use these variables only for pre-mapped state changes.
Their use got muddied over the years, and it was hard to keep track
of what is acutal state, and what just a queued request.
The save_widgets_create function was not safe against
being called multiple times in save mode, calling
gtk_file_chooser_set_create_folders was a way to trigger
this crash.
Previously, we would pango_font_describe() every time the code ran and
we wouldn't ever hit the optimized quick exit.
The code now is a lot more complex because the
compute-actual-value-when-required-the-first-time approach is not
supported out of the box in GtkTreeModel (or GValue).
When the search is cancelled, we may end up with a tracker
dbus reply coming in after the GtkSearchEngine object is
already gone, and bad things happen. Prevent this by
using g_signal_connect_object instead of g_signal_connect.
We generally have const getters for strings, and the two users
of this API were promptly leaking the (unexpected) copy they
got from gtk_query_get_location and gtk_query_get_text.
I forgot to clean up the long press gesture, and in additon, creating
the rename popover from the ui template was causing the tree view
to not be disposed when the file chooser goes away. Work around this
by manually unsetting the relative-to widget of the popover in dispose.
We are trying to scroll the header in view together with the
focus row. The way this is implemented works fine when scrolling
up, but falls short when scrolling down. Fix this by making sure
that both the row and the header bar visible.
We automatically pick up an adjustment from our parent
scrollable, but we failed to update it when it changes.
This is happening in the places sidebar, and it was causing
the focus-tracking to fail there, letting the focus move
out of view. With this change, the focus remains visible.
Remove the code in the sidebar keypress handler that imperfectly
reproduces what GtkListBox already does: moving selection and
focus in response to arrow keys.
1. This confuses the code as it's using the old type hint with the new
type hint on GDK window creation
2. It only existed as a workaround for old code that directly accessed
window->type_hint which hasn't been possible since 3.0.
I believe that first_column can only ever be NULL here if
last_column is NULL too, in which case we'd exited already.
But coverity doesn't see that, so add an explicit exit.
We don't care about the error here, but we were relying on
g_resources_get_info to zero the size even in case of error.
No need to do that, we can just check the return value. Plus,
it makes coverity happy.
The way this code is written, we know that there is an item in
the hash table and the iter_next call will give it to us, so
no need to check the return value. Annotate the call to tell
coverity.
Previously, the (1<<31) value evaluated to the 64bit value
0xFFFFFFFF80000000
instead of
0x0000000080000000
Avoid this by explicitly casting the value to unsigned long long.
Also cast all values to unsigned long long to achieve consistency
and hopefully in the future get new values added the same way.
We "fix" this signal the same way we did for GtkEntry and
GtkTextView: slightly change the signature so that the passed
widget may be a container other than a GtkMenu, and add a
property to explicitly opt in to receiving the signal in
this case.
With the name entry being in the header bar now, we no longer
get bindings working by just letting the key event bubble up,
we have to explicitly apply them on key events that the save
entry is not handling.
They were updated in style-changed, causing the label to get set to
(None), then to the actual file name again a frame later, both of the
updates cause the GtkFileChooserButton to resize, possibly to the
minimal width, causing the layout to jump. Fix this by only updating
icon/label in style-updated when the icon theme actually changed, which
is the only case we care about here.
https://bugzilla.gnome.org/show_bug.cgi?id=752509
"Yo, we heard you like traversing NULL-terminated arrays to operate on
them, so we called g_strv_length() as the for condition, so you can
iterate the array while iterating the array."
Instead of making famed rapper and television producer Xzibit proud, we
should avoid calling g_strv_length() on an array while looping on the
array, to avoid quadratic complexity.
We do this in various places that deal with arrays of strings that we
cannot really guess are short enough not to matter — e.g. the list of
CSS selectors in the inspector, or the required authentication
information for printing.
Previous commits changes the behavior of GtkPlacesSidebar, as it stops
handling persistent devices and only manages mounted networks, XDG
directories and bookmarks.
By radically breaking the previous behavior, we may have trouble
since we provide no alternatives to that besides the private widget
GtkPlacesView.
Fix that by showing the persistent devices when not showing Other
Locations item.
Commit 7db399d975 introduces
the Other Locations item, as well as some behavioral changes
to GtkPlacesSidebar. It, howevers, wrongly changes the section
of code that handles the Connect to Server item, with various
side effects depending on the environment setup.
Fix that by adding the Connect to Server at the right section
of code.
gtk_css_node_set_after/before() are now called
gtk_css_node_insert_after/before().
This brings them in line with other similar APIs (ie GtkListStore). And
it allows easier usage of the API (see changes to gtkbox.c).
Previous patch modified places sidebar widget to stop handling
fixed devices by adding an "Other Locations..." item. Up to now,
however, these changes are isolated from each other since the
bundled file manager widgets ignore the sidebar requests for
external management of fixed devices and networks.
To fix that, make the file chooser widget be aware of the
GtkPlacesSidebar::show-other-locations signal and, when requested,
show places view to manage the fixed devices and networks.
https://bugzilla.gnome.org/show_bug.cgi?id=752034
Places sidebar is a widget that enabled the user to select
XDG directories, bookmarks and mounted network locations,
as well as manages permanent and removable devices.
The new design that aims to look less clutered makes the
sidebar display only removable devices, as well as mounted
networks, bookmarks and XDG directories, and delegates the
management of permanent devices such as hard drive partitions
to GtkPlacesView, a newly introduced widget for this specific
purpose.
To delegate it, add an "Other Locations..." item to notify
when the permanent devices manager is required. Besides that,
don't show these fixes devices on the sidebar itself, as they
are not supposed to be handled by the sidebar anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=752034
Places sidebar shows XDG directories, mounted and unmounted devices,
connected networks, bookmarks and actions like 'Connect to server'
and 'Insert location', which causes the sidebar to grow very quickly
and look cluttered. Because of that, new mockups for the sidebar try
to simplify it.
To make the sidebar simpler, the new mockups propose that it should
only handle connected networks and removable devices such as flash
drives and USB devices, and delegates other devices for external
widgets through the 'Other Locations' item.
To handle fixed devices and manage network connections, add a new
widget named GtkPlacesView, based on Nautilus mockups to keep
consistency between GNOME file management tools - in this case,
between Nautilus and the bundled Gtk's file chooser.
https://bugzilla.gnome.org/show_bug.cgi?id=752034
With the previous approach, we could only show the spinner
before we had any results. With the new approach, we can just
leave the timeout in place and always show the spinner until
the search is done.
We were showing things like "Searching in (null)" if the current
folder is not in the sidebar. Avoid that by falling back to using
current_folder.
Pointed out by Carlos Soriano.
Avoid using a stale timestamp (from the last user interaction with the
application) when a message arrives from D-Bus requesting that a new
window be created.
In this case the most-correct thing that we can do is to use no
timestamp at all.
We modify gdk_x11_display_set_startup_notification_id() to allow a NULL
value to mean "reset everything" and then call this function
unconditionally on receipt of D-Bus activation requests. The result
will be that a missing desktop-startup-id in the platform-data struct
will reset the timestamp.
Under their default configuration metacity and mutter will both map
windows presented with no timestamp in the foreground. This could
result in false-positive, but there is very little we can do about that
without the original timestamp from the user event.
https://bugzilla.gnome.org/show_bug.cgi?id=752000
