along with a new 'type-format' setting that allows
to choose the output format for the "Type" column.
The options implemented for this setting are:
'mime' : Output from g_content_type_get_mime_type().
'description' : Output from g_content_type_get_description().
'category' : It uses the corresponding generic icon
of the mime type to group by categories (aka basic types).
This produces a more compact output than previous options,
and allows for type families to be grouped together, so eg.
after sorting by "Type" column, jpeg and png images will
be placed together, or the various types of archiver files
will also be grouped together.
This format was copied from and currently used by Nautilus
list view, so we also improve consistency with Nautilus.
Bugzilla entry for Nautilus implementation is:
https://bugzilla.gnome.org/show_bug.cgi?id=683722
The list of type families or categories can be checked on:
https://developer.gnome.org/icon-naming-spec/#mimetypes
This 'category' format is set as default.
Issue #362
Page ranges entry can now be focused directly, and will automatically
select the page ranges button when doing so.
This avoids the sometimes counter-intuitive previous behavior where the
entry was automatically focused when toggling the radio button, but the
user may still find themselves clicking uselessly in the text entry
because they scheduled it in their mental model.
Instead, use a new title style class to let
themes influence title formatting. Note that
the theme style will be overridden if the
application uses markup for presentation,
such as <b> or <i>.
There are two ways GTK can add a headerbar to a dialog:
- the dialog is constructed with the :use-header-bar property
- all windows should use client-side decorations
In the first case, the headerbar is added by GtkDialog with no
dedicated style class, and in the latter by GtkWindow with the
"default-decoration" style.
As a result, dialogs with plain titlebars can end up with clearly
distinct and inconsistent styles.
To address this, allow headerbars to track whether they should use
the "default-decoration" style and enable it for dialogs.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/836
The skip-taskbar, skip-pager and urgency hints were
only ever implemented for X11, and are not very useful
with modern desktops. Relegate the functionality to
x11 backend api, and drop the GtkWindow api.
The position child property is problematic, since it
requires us to emit notification for all children when
inserting a child early in the list of children.
Remove the property from all ui files.
We display a list of supported protocols in the server_addresses_popover.
However, this curated list contains protocols which may or may not be
available, depending on the respective gvfs backend being installed.
So, populate the list only with protocols which are available.
https://gitlab.gnome.org/GNOME/gtk/issues/1476
Since the original implementation was likely based on GTK+ 3, the change
in default visibility might have not been considered, which results in
all rows suddenly sporting a visible spinner when opening a fresh file
chooser.
Use an event controller on GtkFontChooserDialog, a nice side effect
is that we can use gtk_event_controller_key_forward() and
gtk_search_entry_set_key_capture_widget() instead of passing events
around for dialog search.
This is meant as an input to the font chooser.
We don't want the user to select a language, but
rather have fonts presented as they would work for
the current language. Therefore, do away with the
lang/script combo on the tweak page.
Avoid the ugly priv->tool_box==NULL check in ::add (and ::remove) by
just not using template xml for this small class. Also, make sure the
GtkBin child is properly set and implement remove to also properly
remove it. Remove the manual widget margins and add some CSS for it.
Also switch to simply using a GtkCenterBox.
This replaces the use of ::button-press-event. There's two
issues with this commit:
1) We don't have a good way to do the equivalent of
gdk_event_triggers_context_menu with gestures
2) We have to defer to and idle to avoid ordering
issues with the treeviews own gestures
Add a button the dialog's header bar that lets us
switch to a second page where we can customize
the selected font.
Make the font chooser widget export an action that the
dialog can use for the button. This has some advantages:
- we can export not just the toggle state, but also enabled
- we can reuse the same enabled state to make the select
button insensitive when no font is selected
To determine whether a font is selected, listen to changes
of the list selection. And ensure that the font chooser is
in an initial state when mapped, even if we close the dialog
from the tweak page.
Scrolling a path bar is of marginal usefulness - you need to
find a really deep place in your filesystem hierarchy in order
to scroll one or two places at best. And the code we had for
this was not working. And it was using legacy event handlers.
Instead of fixing it, remove it.
Add integration of the libcloudproviders DBus API to the
GtkPlacesSidebar by showing name and sync status of the cloud providers.
The exported menu is rendered as a GtkPopover.
The sidebar will be updated if the list of cloudproviders changes e.g.
by adding or removing an account. If any cloud provider changes detailed
information like sync status only the individual sidebar row gets
updated.
Co-authored-by: Carlos Soriano <csoriano@gnome.org>
Co-authored-by: Daniel Boles <dboles@src.gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=786123
Showing all the different errors and warnings when renaming and creating
files/folders without potentially resizing popovers on every keystroke
requires us to know the size of the error messages beforehand, so pack
all of the possible error messages and warnings in labels and those into
a stack. This way we can also neatly crossfade transition between them.
https://bugzilla.gnome.org/show_bug.cgi?id=775636
Translating it seems pointless if we can use a non-translatable example
such as gnome.org instead of foo.example.com.
This will help to make changes in here without breaking string freeze.
https://bugzilla.gnome.org/show_bug.cgi?id=781622
Now that priv->area is guaranteed to be constructed by us, and not
passed in by a user, we can move it to the .ui file and stop manually
managing its lifetime altogether. And once the area is there, we can
move the menu there too (and stop pointlessly destroying/rebuilding it).
This is a free-form tab that can contain information about the
system environment. To see it, set GtkAboutDialog::system-information
to a non-NULL value.
https://bugzilla.gnome.org/show_bug.cgi?id=776604
...by putting it in a stack. The busy_spinner and eject_button are
mutually exclusive, but only the latter was coded to ensure that its
visibility did not cause the rest of the row to reflow. By putting both
widgets in a stack and setting child_visible on that, the row allocates
enough space to show one - or none - at once, avoiding any misalignment.
https://bugzilla.gnome.org/show_bug.cgi?id=772345https://bugzilla.gnome.org/show_bug.cgi?id=772348
This reverts commit 6af5033386.
Scrolled window behavior of propagating child natural sizes
has now been made optional, so there is no need to work around
this by setting a hard coded maximum content height anymore.
GtkPlacesView currently provides no example of
server addresses, which may confuse users.
To fix that, add a helper popover with some
guidance on server addresses.
https://bugzilla.gnome.org/show_bug.cgi?id=756570
We used to always make the labels in message dialogs selectable,
which is a bit problematic wrt. to keynav - the label can
unexpectedly 'turn blue', which irritates some people.
With the new gtk-keynav-use-caret setting, we can now only
make the labels selectable when it is required for accessibilty
reasons.
We weren't using the open flags on the other locations signal, which
makes impossible for applications like nautilus to act in the same
way that for any other location where the user can choose between
opening in the current view, in a new window or in a new tab.
Add a new signal with an open flags parameter and deprecate
the other-location signal.
https://bugzilla.gnome.org/show_bug.cgi?id=754743
The previous way of manually juggling the visibility of the
labels doesn't work anymore, now that gadgets of invisible
widgets don't allocate space anymore.
It's not a hugely complicated file, but it's easier to deal with some of
the details of tooltip windows styling if we have a UI file to edit,
instead of source code.
Use combobox as the element name for the main CSS nodes of
GtkComboBox and GtkComboBoxText. Add the .combo style class
to the button and entry. in a GtkComboBox or GtkComboBoxText.
Unfortunately, GtkFileChooserButton is different from the other
pickers in that it is not a button, but rather has a button.
We ignore the difference for styling purposes, and just add
a .file style class to the button.
The current situation is somewhat sad, with the path
label totally misaligned throughout the rows.
This is fixed by using a size group for the path labels,
so they all have the same allocated size (with the max
of 15 chars). Also, instead of hiding the eject button,
set it child-invisible, so it is hidden and yet it's size
is allocated by GtkBox.
https://bugzilla.gnome.org/show_bug.cgi?id=757303
Disclosure triangles are usually used pointing down, however
in this case the popover spawns in the upper direction, which
makes it odd looking.
Instead of pointing always down or up, point down when not toggled and
animate a rotation when toggled.
https://bugzilla.gnome.org/show_bug.cgi?id=756568
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.