| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Drag and dropping on a search or starred location tab gives an error dialog
that says "Error while copying to /".
In order to be able to drop the selection on a target it is also necessary
to check whether it is editable, property which is set False for the Star
and Search directories.
https://gitlab.gnome.org/GNOME/nautilus/issues/168
|
| |
|
|
| |
Mis hojos!
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
So we can debug ref counting issues more comfortably.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the dnd on the sidebar is only triggered when hovering
above the sidebar itself. However we would like to give some
feedback all along on the dnd operation.
For that GtkPlacesSidebar has set_drop_targets_visible public API,
which was implemented a few months ago and the GtkFileChooser is
already using.
I just forgot to implement the support for it on Nautilus... even if
the original work was done for Nautilus, since users will probably
use dnd more on nautilus than on the file chooser.
I'm not entirely happy with the implementation, since it uses custom
functions to access the drag data, given that we need them at drag-begin
time and in random places on the code, since nautilus is doing all the dnd
work manually and on different places.
The final result is that drag and drop is still managed mostly on its own
widgets, in this case list-view and canvas-view, and nautilus-dnd manages
a central accessor for dnd in nautilus, in this case requesting depending
on the widget that is the owner of the data, its data through the custom
functions of that particula widget. All other ways I tried to do it entirely
with only gtk_drag_* or gdk_drag_* functions were in vanish if no a complete
refactoring is done, and probably it doesn't worth the effort. Also I
actually separated the list view dnd code as well, so now at least the
pattern to handling dnd on nautilus is more or less consistent.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GtkFileChooser received a Other Locations view that lists
persistent devices, as well as networks and the root location
for the computer's hard drive.
Since Nautilus is a file management tool too, it should keep
consistency between Gtk+ file chooser, something that doesn't
happen since it doesn't display Other Locations.
To fix that, add NautilusPlacesView, a NautilusView implementation
that displays the GtkPlacesView widget. In order to implement that,
update window-slot to correctly display the places-view whenever
Other Locations is clicked.
https://bugzilla.gnome.org/show_bug.cgi?id=753871
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Make pathbar also change locations when hovered by
XDS dnd targets (eg. dragging a file from file-roller).
Fixes bug 705609
Signed-off-by: Nelson Benítez León <nbenitezl+gnome@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
Make pathbar also change locations when hovered by
text dnd targets.
Fixes bug 705549
Signed-off-by: Nelson Benítez León <nbenitezl+gnome@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
Don't call nautilus_window_slot_open_location if the location
has already been loaded, as it causes an unwanted refresh.
Fixes bug 705492
Signed-off-by: Nelson Benítez León <nbenitezl+gnome@gmail.com>
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=692097
|
| |
|
|
|
|
| |
Since we handle envets manually.
https://bugzilla.gnome.org/show_bug.cgi?id=635485
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=329515
|
| |
|
|
|
| |
The NautilusFile tracks changes in the file name, so it solves the bug
reported in https://bugzilla.gnome.org/show_bug.cgi?id=581748
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=643968
|
| |
|
|
| |
And use new method names in other classes
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the past, nautilus was designed keeping in mind the concept that it
might not just be a file browser, but a sort of platform to embed
various kind of views in it.
- libnautilus-private: general lowlevel items, such as the icon
container, NautilusFile, I/O and so on
- src: general widgets and UI items
- src/file-manager: file manager views, agnostic of what's in src/,
for the sake of being pluggable enough
This is really not applicable anymore, as nautilus won't go in any
direction other than being a file manager; at the same time, this
complicates code and architecture quite a lot.
In this commit, as a first step towards a more clean codebase, we remove
the NautilusWindowInfo and NautilusWindowSlotInfo interfaces, using
NautilusWindow and NautilusWindowSlot directly.
Note that there should be no actual code changes, only moving of pieces
around.
|
| |
|
