Request for review: Split View

Hi folks,

as discussed back in February (Subject "Split/dual pane view again
(but this time with code)" [1]), I've been working on a
split view branch for Nautilus. Since then, I've been cleaning up the
patchset, and modified it according to the discussion that was taking
place in linked thread.

The code is on git://
in the "split-view" branch.

I've been using the code for months now, without problems. I also got
some feedback from testers, thanks to an Ubuntu PPA and Arch Linux
packages, which were very positive. Not being aware of serious remaining
issues, I thought it's time to actually request a review.

This is my first request-for-review with non-trivial patches to a
GNOME project, so please let me know if I am missing something or
should be more elaborate on a specific topic.


There's been much discussion going on on how split view filebrowsing
is useful, so I'll make this short. File operations like "copy" or
"move" have a source and a target location, which can be represented
by file managers as two adjacent panes. The main difference to just
having two windows side-by-side is the introduction of a "default
target" for those operations, which makes (especially keyboard-)
navigation much faster and easier. Personally, I find this especially
true when dealing with remote locations via GVFS. It's also useful for
enabling the user to create Nautilus scripts that work on two
locations, such as a file- or directory diff.

User-visible changes

Spatial mode:
None intended

Navigation mode:
New menu items:
View -> Extra Pane
Edit -> Copy to -> Copy to other pane
Edit -> Move to -> Move to other pane
Go -> Switch to other pane
Go -> Go to same location as other pane

Environment variables for Nautilus scripts:
(which do the same as their equivalents without NEXT_PANE, but for the
inactive pane)

Architectural changes:

In the current state of git master, every window can hold one or
multiple slots, and one of these slots is "active" at a given time.

The branch introduces the concept of a "pane" as a new layer between slots and
windows. Every window can hold one or multiple panes, and one of these
panes is active at a given time.

Every pane, on the other hand, contains one or multiple slots, of
which a single slot is active for each pane at a given time.
Consequently, in order to access the currently active slot in a
window, a programmer would now access window->details->active_pane->active_slot
instead of window->details->active_slot.

The pane implementation resides in the pane classes
NautilusWindowPane and the derived NautilusNavigationWindowPane.

Much logic that used to be specific for a window (e.g. the location and other
bars) is now specific to a pane.

The first commits in the split-view branch (roughly until
4ca8c17639af22f5cf40821c1a6504377e560ac0) reflect this re-factoring,
and don't introduce new functionality.

Relying on this foundation, the remaining parts are rather straight

Bugs / Limitations / Annoyances

I am currently only aware of a single small annoyance: When in split
view mode, and a pane opens an additional tab, the pane gets resized
to be larger than before. Obviously, there's something fishy going on
during size allocation negotionations between the GtkPaned and
GtkNotebook. I have not yet been able to track that down yet.

It would be great if one of the core devs could have a look and comment.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]