| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were using a custom signal that reports the previous
location and the new one, given that was needed by files-view
for its bookmarks in the file chooser.
Previous patch removed that, so now the only client is the application
which updates the dbus locations available to FileManager dbus.
We want to have some consistency between the handling of the
views/slots/windows, and we are moving forward to use properties
instead of signals since makes it clearer and cleaner, and allow
bindings and other nice things.
For that, match what the view does and expose a location property
on the slot.
In future, if the window has some client that listen to the current
viewed location, a property binding to the active slot would do.
In this case, we can't bind the property to the one of the view, since
there is still some management done on the slot, but this will change
soon when we move the remaining location management to the view itself.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
That was used when the action "Move to..." or "Copy to..."
since it was using gtkfilechooser to choose the destination.
We were adding a sidebar shortcut folder for every slot that was
opened, that means that if we had a few tabs, the sidebar started
to look crowed. Also the sidebar is no longer consistent, since
it's diffenrent thant the state of the sidebar in the main Nautilus
window.
Designers agree that is better to make the sidebar less crowed and
don't make it incosistent, since the value of adding a shorcut for
opened locations doesn't balance the inconsistency and crowdness of
the sidebar.
|
| |
|
|
|
|
|
| |
With the latest patches where we separated the management
of each component to its own class, this is no longer necesary,
since the only component that takes care about the view loading
is the slot.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
doesn't provide the right size
The icons displayed were too large
https://bugzilla.gnome.org/show_bug.cgi?id=749969
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This feature was broken since commit 3eeda743a42fe10f0e31743c3fb2ba8907fc8883
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=738673
|
| | |
|
| | |
|
| |
|
|
| |
last action that belongs to the slot instead of the window.
|
| |
|
|
| |
Ooops, tabs....
|
| |
|
|
|
|
|
|
| |
Previously GTK+ picked some default width for these labels.
https://bugzilla.gnome.org/show_bug.cgi?id=739736
https://bugzilla.gnome.org/show_bug.cgi?id=751355
|
| |
|
|
|
|
|
| |
Some of the labels in the preferences tends to have very long
labels. Limit their width to 65 characters and allow them to break.
https://bugzilla.gnome.org/show_bug.cgi?id=739736
|
| | |
|
| |
|
|
|
|
|
|
| |
Delefate the view management to the slot.
Also on the way, remove duplicates of views ID.
This patch is another step forward to full isolation of
window/slot/view
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Just match gtkplacesview from master which has some fixes
for cancellables operations accesing the private struct when
cancelled, and therefore making it crash.
https://bugzilla.gnome.org/show_bug.cgi?id=753939
|
| | |
|
| | |
|
| |
|
|
| |
It's not necessary at all to track them.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Nautilus shows a visual feedback for when the current folder is
empty. This, however, is undesired for the desktop, since we don't
want to clutter the desktop area.
Fix that by not displaying the empty state for desktop view only.
https://bugzilla.gnome.org/show_bug.cgi?id=753752
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
nautilus-connect-server is a legacy application from
GNOME 2 era, where we had no consistent way to manage
servers.
With the introduction of NautilusPlacesView, this code
becomes obsolete, as the network management logic is
moved to the places view.
Remove the legacy code.
https://bugzilla.gnome.org/show_bug.cgi?id=753871
|
| |
|
|
|
|
| |
And add a comment to track this...
https://bugzilla.gnome.org/show_bug.cgi?id=753871
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
we were asking for the file type blocking the UI. Use
nautilus file instead which catch the values.
https://bugzilla.gnome.org/show_bug.cgi?id=753871
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nautilus is in the proccess of receiving a places view,
based on GtkFileChooser's one.
To be able to handle that, an abstraction layer is needed
between NautilusFilesView and NautilusWindowSlot, so we factor
out the common data between views.
Add the NautilusView interface, and make NautilusFilesView a
NautilusView implementation. Because of the new way we handle
search on the view side, the search logic is rewritten to match
the new expected behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=753871
|
| |
|
|
|
|
|
|
|
| |
The last action assigned was 'sort', and then we immediately
try to change the 'keep-aligned' state, causing a bunch of
criticals when using the Desktop Icons.
Fix that by correctly ordering the actions and avoiding set
the state of the wrong action.
|
| |
|
|
|
|
|
|
|
|
|
| |
We were looping with a timeout to make sure we don't miss
any operation that it's time remaning was not well calculated.
But we were not stoping this loop when all the operations were
took into account. So remove the timeout if all the operations
are being show, cancelled, or finished.
https://bugzilla.gnome.org/show_bug.cgi?id=753728
|
| |
|
|
|
|
|
|
|
| |
Users weren't noticing that the button appeared, and tried
to perform the same operation again.
Try to catch their attention on the button with an animation
on it when the button appears.
https://bugzilla.gnome.org/show_bug.cgi?id=753728
|
| |
|
|
|
|
|
|
| |
We were updating the operations button style always that
update_operations was called. Thing is that is not necesary,
and can cause some anoyances in patchs that are to come.
https://bugzilla.gnome.org/show_bug.cgi?id=753728
|
| |
|
|
|
|
|
|
| |
And instead increase the timeout to hide the button to allow
not flash but don't take too much in provide feedback that
and operation is being done
https://bugzilla.gnome.org/show_bug.cgi?id=753728
|
| |
|
|
|
|
|
| |
Instead of using blue, use a white higligth with the same colors
as the current button class of adwaita.
https://bugzilla.gnome.org/show_bug.cgi?id=753728
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
We have to use the relative coordinates wrt the view, not the ones
of the item inside the scrolled widnow itself.
|
