lineup-parameters: remove unused variable (fixed upstream)
bookmark: cast away const modifier in nautilus_bookmark_compare_with()
when using GLib macros
file-operations: used correct enum in a function call
https://bugzilla.gnome.org/show_bug.cgi?id=772586
The current style of nautilus is rather poor and mixes at least 3
different code styles.
Specific issues that affect the most common contributors to Nautilus
performance are:
- tabs for multiline alignment.
- mix of tabs and spaces.
- errors on no braced one liners conditionals.
- errors on non braced case statements with variable declarations.
So I would say requirements for the style is to address the previous
issues and also be a well known style. I don't want new contributors
to see a new style completely different from C books authors.
So far, I found Allman (aka BSD) style which seems the choice of most C
books authors as far as I can see on internet, and it address the
previous mentioned issues.
Since uncrustify doesn't support the aligment of parameters we do for
multiple stars "**", we also added a script made by Sebastian Wilmet
to align those.
As a matter of practicity I'm going to convert all Nautilus style to
this one, and if the next person who contributes most on Nautilus has
a different choice, please feel free to change it to whatever makes your
performance and your contributors performance the best.
https://bugzilla.gnome.org/show_bug.cgi?id=770564
The compression operation allows multiple formats to be selected. It would be
good to store the last choice of the user in order to select it for future
operations.
https://bugzilla.gnome.org/show_bug.cgi?id=770199
Instead of using a themed icon.
This is necessary for flatpak Nautilus properly.
Patch made mostly by Mathieu Bridon and help of Patrick Griffis.
Thanks a lot!
gettext has been continuously improving, up to a point where intltool
can be deprecated in favor of it. This commit ports the project files to
use upstream gettext.
https://bugzilla.gnome.org/show_bug.cgi?id=769362
Sometimes we want to override the show-desktop-icons gsettings, as we
were doing before splitting the desktop.
Wrongly I assumed that since it's a different binary, once can simply
run it or not, but of course that was an oversimplification, and forgot
all what I needed to do in order to support all the cases for the
desktop handling.
This patch adds the missing command line options we had, --force-desktop
and --no-desktop, and also adds the --force-desktop to the classic
desktop file, since we needed to enable the classic mode.
https://bugzilla.gnome.org/show_bug.cgi?id=765159
We wanted to do this for long time. This will allow to handle the
desktop process in a different binary.
The ultimate goal is to make the desktop code completely split from
nautilus code.
This is the first and minimal step towards that goal.
In this patch we create a desktop application separated from nautilus
application, and remove the desktop handling in nautilus application.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
In icon view, add a smaller zoom level to be able for dense views,
and increase the default padding to allow the labels enough space.
Now levels are 48px, 64px, 96px and 128px for icon view, instead of
only 64px, 96px and 128px, but with the increased padding the 64px and
48px are useful.
List view also gains a bigger level, and they become 16px, 32px, 48px,
64px.
Also, adjust the label max width to be larger, but inside the icon
itself. This fixes the label not taking advantage of all the width the
icon provides, and also a few cases where icons were misaligned.
So we can select what type of view do we want for search independently
of what we normally use.
This is needed since we default to switch to list view for search, but
we would like to allow users to select a different view. However,
instead of adding a preference in the preference dialog, we can do it
more straightforward and change the setting when we are in search.
On the way, rework all the enums and views id for a saner code...
We weren't syncing the last used/ last modified setting in the search
popover when changed location, which means the query didn't get the
last used user choice.
We don't want however to listen to a gsetting key and change every
ongoing search, so instead what we do is get the setting for the
initial creation of a search, and then every user change will set
the gsetting value, but will only affect the next created searches, not
the ongoing ones.
Remote locations by default don't handle recursive search, since
it has high costs associated. We can't, however, neglect the ability
to search recursively on those folders, nor share the same setting
with common folders too.
To fix that, add a new setting called "enable-remote-recursive-search"
which will be used by the next commits to properly implement recursive
search for remote locations.
The menu item for this feature was removed in previous versions of nautilus.
A context menu item for creating links from copied files was added, but some
users prefered to create links from selected files.
Since this is demanded, implement the menu action for it and use the gsetting
added in the previous commits.
https://bugzilla.gnome.org/show_bug.cgi?id=745575
The menu item for creating links was removed in previous versions of nautilus
since it exposes a concept of the file system that is not really clear.
However, we don't have a working solution yet for the use cases that creating
links is a workaround, so we didn't remove the functionality altogether.
We were allowing link creation with a shortcut and with the middle button while
performing a drag and drop operation. However, some users would need to use a
context menu action instead of a drag and drop operation, which usually is less
convenient and prone to errors.
Since this is demanded, implement the menu action for it and add a gsetting
preference to show it in the context menu for those users who like to have it
there.
Also the new implementation uses the code that is already used for other
operations, improving the implementation compared to the previous one.
In an upcoming patch we add the UI for the preference dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=745575
So Gnome Shell is aware of it and can activate it.
Until now Gnome Shell was guessing it was able to open a new
window given the app.new-window action. However, what Gnome Shell
does in this case is just call activate of the application, which
is not the "new-window" action for nautilus, and instead only presents
the current window.
One can argue that Gnome Shell should not try to guess the available
actions to, after that, instead of using them, just activate the
application.
https://bugzilla.gnome.org/show_bug.cgi?id=756370
