| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
g_object_get() returns a ref to the property object. We must unref it.
|
| |
|
|
|
| |
There are some style issue since the last run. Let's run it again
before enabling style-check CI job.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Uncrustify makes the following change, which is unwanted:
gtk_widget_set_sensitive (self->view_button, new_sections->extended_section != NULL ||
- new_sections->zoom_section != NULL ||
- new_sections->supports_undo_redo);
+ new_sections->zoom_section != NULL ||
+ new_sections->supports_undo_redo);
Let's add parentheses to prevent this unwanted change.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently, the tooltip says 'Toggle view', which isn't clear.
Usability testers had difficulty finding out how to change between
list and grid view.
Change tooltip to say 'Show list' or 'Show grid', depending on which
view it can change to.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/issues/893
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We hide the pathbar background when the window so small that the
pathbar is no longer centered. This was introduced to make the
pathbar flat.
However, now that the pathbar is buttonized again, it doesn't make it
flat, so there is no point. The transformation is only a distraction.
Furthermore, it is prone to styling glitches.
So, give up on the transformation and always have a pathbar background,
effectively reverting commit 080400bd243ab86d82954eaff0c866c3ac97f3f2
Fixes: https://gitlab.gnome.org/GNOME/nautilus/issues/907
|
| |
|
|
|
|
|
|
|
|
|
| |
Sometimes the search button and search entry state can get out of
sync. This will lead to the need of pressing the search button
twice to display the search entry again.
This patch solves this behavior by binding the "searching"
property between toolbar and window-slot.
Fixes https://gitlab.gnome.org/GNOME/nautilus/issues/570
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 0009d0e771f1a7cb9adf12e78d66aefcccc766b6
That commit gave the pathbar a bounding frame under HighContrast.
However, this 1px border is not consistent with button borders, and
it lacks padding. The result is uglier than before the change.
Furthermore, it may be the case that setting GTK_STYLE_CLASS_BACKGROUND
and GTK_STYLE_CLASS_FRAME in a GtkBox is either meaningless or leads to
unexpected styling.
This change is neutral for Adwaita, so let's revert it.
Fixes https://gitlab.gnome.org/GNOME/nautilus/issues/674
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
On wider windows, we show a border around the pathbar and fill it
with background color using custom CSS specific for Adwaita.
This means the pathbar is unbounded in HighContrast mode or 3rd party
custom themes, giving the headerbar an uncentered, unbalanced layout.
Fix that using the "frame" and "background" style class which are
exposed by Gtk+ for this purpose.
Closes: https://gitlab.gnome.org/GNOME/nautilus/issues/661
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The border is necessary for the centered look in wide windows.
However, in small windows, it's only visual noise.
So, show borders only when the window is wide enough for the pathbar
container to grow to the maximum width. Also, remove the margin after
the search button, which looks weird now.
Related to https://gitlab.gnome.org/GNOME/nautilus/issues/548
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Calling _set_window_slot() in the window slot weak ref notification
callback isn’t a good idea, given that most of the stuff being cleaned
up there is done automagically, and results in runtime warnings or
potentially a segfault when removing a property binding.
This commit split nautilus_toolbar_set_window_slot(), so that property
bindings aren’t removed if called from the weak reference notification
function. Additionally, the same notification functions nulls out the
icon property binding, fixing the same thing happening in dispose().
Fixes https://gitlab.gnome.org/GNOME/nautilus/issues/441
|
| |
|
|
| |
The view widget binding is no longer created.
|
| |
|
|
|
|
| |
So it doesn't get as wide on bigger screens.
Related: https://gitlab.gnome.org/GNOME/nautilus/issues/548
|
| |
|
|
|
|
|
|
|
|
|
|
| |
One of the benefits of the new menu on the path bar buttons is that we
show the background menu.
This was the intended design since the start, but we didn't come to
finalize it earlier on.
Now with the 3.30 approaching, this work implements that.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/405
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This commit removes redundant header inclusions and tries to optimize
headers by using forward declarations of types in headers. Such
optimization should generally make builds speedier in that changes in
certain headers will not cause unrelated sources to be rebuilt.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generally actions in Nautilus were accessed through context menus or
keyboard shorcuts. However, those are not very discoverable and are
not touch friendly.
Even more, in list view it was not possible to access background actions
since there is always a selection, making Nautilus UX quite poor in that
case.
Also some actions were placed in the app menu, which didn't was not as
clear for some people given that we have most of actions in the toolbar.
In all, we came with a new design that solves the main goals of
discoverability, touch friendly and accessibility for background actions
and app actions, and now are placed in the toolbar together with an
overhaul of the looks of Nautilus path bar and search.
There is still work to do, specifically finding a design that works for
the selection actions and also to replace the current information
floating bar. The later might be just a different goal. However this
goes in the right direction.
See https://gitlab.gnome.org/GNOME/nautilus/issues/322
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The current way poses problems when dragging the window on one of the
navigation buttons, i.e. the long-press menu gets shown while dragging
the window around. Also, those signals are gone in gtk4.
|
| |
|
|
|
|
|
|
| |
Due to the absence of an obvious way to close location entry
a close button is added to the location entry container which
can be used to close it.
Fixes : https://gitlab.gnome.org/GNOME/nautilus/issues/63
|
| |
|
|
|
|
|
| |
This solves the issue of the location entry remaining in the toolbar
if the user inadvertently (or not) tab-focuses a different widget.
https://bugzilla.gnome.org/show_bug.cgi?id=92509
|
| |
|
|
|
|
|
|
|
|
| |
When undo_active/redo_active is FALSE, undo_label/redo_label
was getting overwritten irrespective of whether they were
NULL or not.
Let the label values be freed incase they are updated.
https://bugzilla.gnome.org/show_bug.cgi?id=782083
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have been going back and forth of a solution to make the operations
button noticeable enough once it appears.
First we implemented a highlight inside the button. But that wasn't
enough, so we had to show the operations popover at the start.
That is not really good because it appears in every window, and the user
has to explicitly close it, which is annoying.
This patch implements another animation highlight, which is more
visually bold to try to catch the attention, in order to not need to
show the operations popover.
https://bugzilla.gnome.org/show_bug.cgi?id=753728
|
| |
|
|
|
|
|
|
| |
When the user toggled the Show Hidden Files option on the toolbar menu,
previously the menu disappeared - which isn't the correct behaviour. This
commit changes it so that the menu doesn't disappear.
https://bugzilla.gnome.org/show_bug.cgi?id=766952
|
| |
|
|
|
| |
Some issues were fixed, and now we can rerun Uncrustify to format
correctly more part of the code.
|
| |
|
|
|
|
|
| |
gtk_menu_popup() was deprecated in GTK+ 3.22. By replacing the call with
one of the recommended ones, some code has also become redundant.
https://bugzilla.gnome.org/show_bug.cgi?id=773349
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we are using the old GObject class declarations, which have two
problems.
One problem is that we cannot use smart pointers like g_autoptr. The other
problem is the boilerplate code generated that makes the code less readable,
so harder to understand.
To fix this use G_DECLARE* type.
https://bugzilla.gnome.org/show_bug.cgi?id=771840
|
| |
|
|
|
|
|
|
| |
And make the style of Nautilus the same for all files.
Hopefully we can fix all the style issues we can find in the next days,
so expect a little of movement on this.
https://bugzilla.gnome.org/show_bug.cgi?id=770564
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the toolbar menu reorganisation work, the code to create and
manage the undo/redo items on the menu ended up in files-view.c. This
isn't the correct place as they don't have much to do with the files
view. Some refactoring was needed before the code for these items could
be moved back into the toolbar, which has now been done in a previous
commit.
This commit moves the undo/redo creation and management code into the
toolbar.
https://bugzilla.gnome.org/show_bug.cgi?id=764632
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we have this menu structure:
------------------------------
1. New Folder/New Tab/Bookmark
------------------------------
2. Zoom controls
------------------------------
3. Undo/Redo
------------------------------
4. Sort options
------------------------------
5. Other view related controls
------------------------------
The view creates 2-5, contained in a single GtkWidget - which is then
passed to the toolbar via the enclosing window slot. The problem is that
3 shouldn't be created or managed by the view as the controls in that
section of the menu are not related to the view. We'd like to move this
responsibility back to the toolbar, but that would mean the view must
pass multiple menu sections back to the toolbar (as 3 is in the middle
of the other view controls).
This change allows the view to pass multiple sections back to the
toolbar, using the new NautilusToolbarMenuSections structure. The files
view now passes 2 as a separate section to 3-5 (3 will be moved out of
the view in a future commit).
https://bugzilla.gnome.org/show_bug.cgi?id=764632
|
| |
|
|
|
|
|
|
| |
The popover ui definition was in the toolbars definition file which was
getting pretty big. Have moved the popover definition into its own file,
to separate things out a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=764632
|
| |
|
|
|
|
|
|
|
|
|
| |
The files view creates and owns these buttons currently, meaning they
aren't shown on the menu when the Other Locations view is active.
This change moves the menu items from the view's toolbar menu ui file
and into the ui file for the shared popover, so that the buttons are
also shown for Other Locations.
https://bugzilla.gnome.org/show_bug.cgi?id=764632
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior changes to merge the view and action menus essentially moved the
action menu items into the view menu. This was the path of least
resistance; the view has a lot of hooks on items in the view menu,
whereas the there are very few hooks on items in the action menu,
meaning the latter could be moved more easily.
However, previously the view menu was disabled for Other Locations and
the action menu wasn't. So the side effect of the changes is the
remaining menu is now disabled completely on Other Locations. There are
a couple of items that could be shown for Other Locations (e.g. New
Tab), so we still want to show a menu, but this involves some
refactoring so has been deferred until now.
This commit is the first part of the refactoring; the files view owns
the menu popover, meaning that the Other Locations view doesn't have
access to it. This commit moves the ownership of the menu popover to the
toolbar. Future commits will move the common items into the popover so
all views will show them.
https://bugzilla.gnome.org/show_bug.cgi?id=764632
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Usability tests conducted by Gina Dobrescu have highlighted a number of
issues with the toolbar menus. Users can't switch between list and grid
mode with a single click, and they have struggled to find the switch
between list and grid mode.
Allan Day has come up with a design to address these problems. The view
and action menus have been combined into a single menu, and we have
added a new button to the toolbar which toggles the view mode between
list and grid mode.
https://bugzilla.gnome.org/show_bug.cgi?id=764632
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is in preparation for merging the view menu into the action menu.
The action menu is currently a GMenu, which doesn't support the controls
we have on the view menu, e.g. the zoom slider and the button rows.
Converting to a GtkPopoverMenu will allow us to merge the menus.
This is part of the toolbar menu redesign to improve the usability of
the menus.
https://bugzilla.gnome.org/show_bug.cgi?id=764632
|
| |
|
|
|
|
|
| |
So that the menu doesn't show at random places under Wayland which
expects all subsurfaces to have a parent surface.
https://bugzilla.gnome.org/show_bug.cgi?id=767446
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
And fix make distcheck.
Although libnautilus-private seem self contained, it was actually
depending on the files on src/ for dnd.
Not only that, but files in libnautilus-private also were depending on
dnd files, which you can guess it's wrong.
Before the desktop split, this was working because the files were
distributed, but now was a problem since we reestructured the code, and
now nautilus being a library make distcheck stop working.
First solution was try to fix this inter dependency of files, but at
some point I realized that there was no real point on splitting some of
those files, because for example, is perfectly fine for dnd to need to
access the window functions, and it's perfectly fine for the widgets
in the private library to need to access to all dnd functions.
So seems to me the private library of nautilus is somehow an artificial
split, which provides more problems than solutions.
We needed libnautilus-private to have a private library that we could
isolate from extensions, but I don't think it worth given the problems
it provides, and also, this not so good logical split.
Right now, since with the desktop split we created a libnautilus to be
used by the desktop part of nautilus, extensions have access to all
the API of nautilus. We will think in future how this can be handled if
we want.
So for now, merge the libnautilus-private into src, and let's rethink
a better logic to split the code and the private parts of nautilus than
what we had.
Thanks a lot to Rafael Fonseca for helping in get this done.
https://bugzilla.gnome.org/show_bug.cgi?id=765543
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, the operations button doesn't get removed from every
Nautilus window. And if clicked, an empty popover will appear. One case
is when the user starts a long operation, and then closes the popovers
in all windows once the operations have completed (and before the
buttons are due to be removed).
All windows get notified that the operations have finished. But if
there's a popover open in any window at that point, the windows don't
schedule removal of the button - as the logic is to keep the buttons
visible while there are popovers open. When the user then closes the
popover in the last window, that window knows there are no popovers in
the other windows, so it removes the button from it's toolbar. But
there's nothing to notify the other windows to remove their buttons.
The fix is to implement a more robust solution; instead of the windows
checking the other windows for popovers (windows shouldn't know about
the other windows anyway), the progress info manager maintains a list of
viewers. When an popover is open or closed, the window tells the manager
to update it's list of viewers. When there are no entries in the list,
the info manager notifies all listeners (the windows), so they all know
when to schedule removal of their buttons.
https://bugzilla.gnome.org/show_bug.cgi?id=765019
|
| |
|
|
|
|
| |
It checks the parents visibility as well.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to avoid showing the operations popover in the desktop, or
basically in any window that has the disable-chrome property set.
We can check inside the toolbar if the toolbar itself is hidden in order
to know whether it makes sense to show the operations popover.
In this way we don't relay in special casing subclasses of the window.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Vim and emacs modelines are used to specify some of the code style in the code.
However, this is misleading and poorly supported since nautilus had a mix of
code style for some time.
Also, the mode lines doesn't specify the whole code style, so we will need to
use a different tool as well to specify the whole code style.
For that, we can just use a different tool for everything.
So remove the mode lines, and in a short future we will reestyle the nautilus
code to have a single code style, and use a tool like editorconfig to specify
the whole code style.
|
| |
|
|
|
|
|
| |
Move focus in and out from it when opening and make the info widget
to be able to focus.
https://bugzilla.gnome.org/show_bug.cgi?id=762136
|
| |
|
|
|
|
|
|
|
| |
We needed a check there to not show it if the window is the desktop one.
Also this fixes the operations button not being hidden again due to
the desktop window popover being shown.
https://bugzilla.gnome.org/show_bug.cgi?id=761551
|
| | |
|
| | |
|
