| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
In dropping the support for creating website links from Firefox drops,
commit 0e0f5b9 also removed the ability to handle _NETSCAPE_URLs at all.
Re-add the necessary bits for drag'n'drop downloads to work as they did
in GNOME 3.28.
Closes: #687
|
| |
|
|
|
|
|
|
|
|
| |
This might made sense with the desktop...althought not sure how used
was it.
For Nautilus as an app this probably doesn't make much sense, and
probably it was not very used...
Remove it so we are a step closer to remove nautilus-link handling.
|
| |
|
|
|
|
|
|
|
|
| |
We need to move away from using eel and port most functionalities
inside nautilus.
Replaced the usage of eel_show_warning_dialog() with the show_dialog()
alternative.
https://gitlab.gnome.org/GNOME/nautilus/issues/331
|
| |
|
| |
This reverts commit 1f4bd55d1b9d5f701f2df8d1be7466df85a8669a
|
| |
|
|
|
|
|
|
|
|
| |
We need to move away from using eel and port most functionalities
inside nautilus.
Replaced the usage of eel_show_warning_dialog() with the show_dialog()
alternative.
https://gitlab.gnome.org/GNOME/nautilus/issues/331
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were setting the icon position metadata for any operation in any file
due to legacy code where nautilus was able to have a
freedom-of-placement canvas in the regular windows.
However that changed and we can only have freedom-of-placement in the
desktop window.
Setting the metadata is a extremely expensive operation, and was causing
issues, outlined in https://bugzilla.gnome.org/show_bug.cgi?id=757747,
summarizing copy and move operations where really slow when using drag
and drop, operations when we need to store the icon position when using
a freedom-of-placement canvas view.
This patch tries to only set the metadata when necessary, which is when
using the desktop window. However the code is pretty integrated with the
rest of Nautilus, so the patch was able to isolate the part when the
metadata is set and only provide metadata when the target is the desktop.
However, for unsetting the metadata the patch need to check if it's
the desktop inside the file-operations, which is less than ideal.
https://bugzilla.gnome.org/show_bug.cgi?id=775910
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were using a custom clipboard monitor, due to some old behaviour
in 2004 where not all X servers supported XFIXES, which allows to
monitor global clipboard changes between processes, which are needed in
Nautilus for copy, paste and link operations, and their availability
check.
Since Nautilus was a single process, it was working for most of the
time.
However recently we split the desktop in a different process, so we
were not able to correctly set the GDK action for clipboard, since
we were relying on sharing the same clipboard in the same process.
In order to fix this, this patch reworks the clipboard handling to a
more modern way, using the owner-changed signal present in XFIXES.
This fixes the clipboard changing between the desktop and Nautilus
and interproccess clipboard handling, fixes small corner cases, and
in the way this patch makes the code design and ownership of clipboard
more clearer.
https://bugzilla.gnome.org/show_bug.cgi?id=771046
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Even if the build is fixed in the previous commit, we were
explicitely including the libnautilus-private path. So add
it to keep consistency.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In previous commits we removed opening automatically a folder
when performing a dnd operation and hovering it, since it
is rather difficult to control. Increasing the timeout doesn't
fix the problem, since we can't know how much a person needs to
control its mouse or see the files in the current folder.
Basically it performs an action even if the user is still, which
is a problem.
But seems some users were used to it, so instead of removing it
altogether add a gsetting key to allow its use.
The key will be set as false by default to avoid making the experience
difficult out of the box.
https://bugzilla.gnome.org/show_bug.cgi?id=754454
|
| |
|
|
|
|
| |
This reverts commit ec2b9674b0025bcd8cd30246135962d5a77d9685.
https://bugzilla.gnome.org/show_bug.cgi?id=754454
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were opening the hovered folder after a timeout when performing a
drag and drop operation.
However, this causes that the user could lose track of were the user was
and fail the dnd operation, or even worse, drop in a unknow location and
makes the whole operation rather anoying.
Also looks like could be a problem for disabled people.
So instead just don't open locations on hover for the main view.
Pathbar remains opening with the timer on hover, since the pathbar
itself doesn't change and therefore the user don't lose the track.
https://bugzilla.gnome.org/show_bug.cgi?id=727790
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is another step towards the isolation of the management
of the direcotories, views, slots and windows.
The current situation had a few issues:
- the comunication of changes in the model was done in a
bidirectional way. So for example, sometimes the view updates
directly the slot, sometimes directly the window, and sometimes
the window was listening to changes on the model and updating the slot,
view, or model itself. Problem with this is, encapsulation is wrong,
the code paths are confusing, and the public API exposed is big.
- public API is big, so even if sometimes if convenient to not do the
same thing twice, having public API that is actually covered by the GLib
or Gtk API doesn't worth it, if the complexity of the API grows too much.
In Nautilus case, specifically on the slot, we were allowing all kind of
convenient API, but it was behaving differently depending on small connotations.
- management was not encapsulated. So the window was modifyng the model, or
doing actions that belongs to the slot or the view. The same thing for the slot
and the view, and similarly for the application and the window. For example,
we were handling the flag for creating new windows on a specific window,
instead of relying on the application management. Similar cases for the slot
and the view.
- there were multiple code paths for opening a location. This is one of the
biggest changes on the patch. We were exposing API to open a location in every
component, and we were using that API from other components above or below the
hierarchy randomly. So for example the view was using the opening location
API from the slot, the window, and the application; but with the same pourpose,
opening a location in the active window.
- API was not explicit. For example sometimes we wanted to open
a location in the current active window, but somtimes it was implicit and
sometimes not, and to be safe we were making it explicit on the caller.
- we were using mutiple code paths with the same intention. This is related
to the previous one, the intention in every caller was not clear.
This patch tries to improve the situation, also thinking on the future
rework of the views and separation of the desktop handling.
The patch applies the following rules:
- If the API is provided somehow by nautilus-file or Glib or Gtk, don't
add new API. Custom API is fine if it is used inside the component itself,
since the added complexity for tracking code paths is not that important.
- Use one way communication, from the top level to the innermost component.
In case that the component needs top level features, ask the most top level.
A specific example, the view provides opening a new window with a selection.
Although encapsulation is good, there is not a good way to avoid the dance
from the model to the view to the slot to the window to the application.
So instead of that, allow a quick shorcut only communicating to the top most
level. In this way, the code path is always the same (therefore much easier to
debug or to change code) and encapsulation is preserved.
- don't break encapsulation. Only allow management of the component to the component
itself or its parent. So for example, the slot is the one that manages errors on what
happens in the slot itself.
Exception to this is the application, that needs access to all the hierarchy for
specific situations. For example for updating the dbus locations or to discern
between a desktop window or a common window.
- if two way communication is needed, listen changes through properties.
We have been moving to properties lately, since it clearer and cleaner and
allow a few features that are useful like listening to its changes withouth
explicit API for it. This allows to bind properties in a clean way throuh the
hierarchy and not breaking the encapsulation.
In this patch most of the ground work is done, and some things are remaining
like moving all the loading of the location to the view instead of the slot.
Even if it is convenient to have some management on the slot to share between
the views, some views don't use models at all, or they are not common
files, like the other-locations, and this breaks the situation. At some point
what we want for the files-view is having a common model API, that can be on top
of nautilus-file or in nautilus-file itself.
With this patch, a serie of improvements can be done now, and they will
come in future patches.
|
|
|
NautilusView is the proposed name for the new
interface that will cover NautilusFilesView and
NautilusPlacesView.
The current NautilusView name, however, will crash
with the proposed interface name.
Fix that by changing the class name to NautilusFilesView.
As an easter egg, makes it match the current Nautilus
code style.
|
