Created attachment 330081 [details] [review]
view: fix documentation

The documentation for NautilusView::view-widget was
still copy-pasted from another property.

Correct it by adding the correct description.

Created attachment 330082 [details] [review]
view: add NautilusView::selection property

Currently we don't have any way to track selection
changes, although NautilusView exposes selection. This
is an inconsistency in code, and should be avoided.

Fix that by adding a NautilusView::selection property
and deprecating the NautilusFilesView::selection-changed
signal.

Created attachment 330083 [details] [review]
files-view: add ::stop-loading action

This action will be consumed by the actionbar, to simplify
the development of the stop button.

Created attachment 330084 [details] [review]
action-bar: implement NautilusActionBar

The new NautilusActionBar class handles everything
needed to be an usable actionbar as envisioned by
the available mockups.

Created attachment 330085 [details] [review]
view: add ::get_action_bar() vfunc

This will be used in the next patch so we can
access the actionbar of the view.

Created attachment 330086 [details] [review]
window-slot: show actionbar

When we change the view, add the view's actionbar
to the bottom of the window slot.

Created attachment 330087 [details] [review]
files-view: remove the floating bar

The floating bar was a bad choice since it's inception. Not
only it hovers content, it's behavior is inconsistent and the
usability of it is very poor.

After the introduction of the actionbar, most of the data that
we displayed through the floating bar was moved to the actionbar,
making the floating bar obsolete.

This commit follows up and completely removes the floating bar.

Created attachment 330088 [details] [review]
actionbar: remove Bookmars and Properties buttons

They look ambiguous, and it's not clear they're related
to the actual folder.

Created attachment 330089 [details] [review]
actionbar: remove the folder name when no selection

After receiving some input from the design team, we
decided that this label was unecessary and distracting.

Thus, removing it would fix this issue.

Review of attachment 330081 [details] [review]:

LGTM although I think this is going to be obsoleted by Neil's work at https://bugzilla.gnome.org/show_bug.cgi?id=764632

Review of attachment 330082 [details] [review]:

much better

Review of attachment 330083 [details] [review]:

ok

Review of attachment 330084 [details] [review]:

Trying this patch I can see few issues:
1- There is a allocation loop, making the buttons jump for 4 times (there is a loop detection until the 4th time in gtk+). I propose to follow something similar as what I'm doing in the GtkPathBar to avoid these allocation loops. That means using a scrolled window and update visibility on an idle (you can use revealers for greater animations and not need to worry about the idle since revealer animation is done in an idle).
2- The bar takes more height than necessary in some situations.
3- The sensitivity of the buttons only changed when the selection is done, not while is being performed. However the stack state changes already. This look inconsistent to me. I would go with one or the other. Note that this is specially noticeable when going from something selected to nothing selected.

And some code review:

::: src/nautilus-action-bar.c
@@ +5,3 @@
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or

Version 2 of GPL.
Speaking of that, actually I need your agreement to change the files already in Nautilus that you created on the past to change them to GPL 2, if you agree, can you agree here in public so I can point to some place in the commit?
Thanks!

@@ +35,3 @@
+  MODE_FILES_ONLY,
+  MODE_FOLDERS_ONLY,
+  MODE_MIXED

mixed sounds strange. How about MODE_FOLDERS_AND_FILES?

@@ +166,3 @@
+
+          if (nautilus_file_get_directory_item_count (file, &file_item_count, NULL))
+            folder_item_count += file_item_count;

I think Allan said this "number of items inside the folder" was useless, and I kinda agree.

@@ +262,3 @@
+  else
+    {
+      /* This is marked for translation in case a localizer

prepend "Translators:"

@@ +380,3 @@
+
+static gboolean
+real_update_status (gpointer data)

this is not how we use the real_* pattern, which is usually used for vfuncs. this one could be called simply update_status, and the other once schedule_update_status.

@@ +440,3 @@
+
+static void
+location_changed_cb (NautilusActionBar *self)

do you mind using on_location_changed?
I'm trying to keep the same pattern for callbacks

@@ +459,3 @@
+
+static void
+clear_selection_cb (NautilusActionBar *self)

dito

@@ +611,3 @@
+      static_button_width = button_width;
+
+      gtk_widget_set_size_request (self->default_app_button, button_width, -1);

This is not allowed inside size_allocation... as we enter in a loop (which is what I'm seeing)

@@ +622,3 @@
+  /* Hide the separator if needed */
+  if (self->mode == MODE_NO_SELECTION)
+    gtk_widget_set_visible (self->no_selection_separator, visible_items > 3);

ditto

::: src/resources/css/Adwaita.css
@@ +178,3 @@
 .searchbar-container { margin-top: -1px; }
+
+actionbar { border-top: 1px solid @borders; }

shouldn't the background be as the headerbar or the action bar in the other locations?

::: src/resources/ui/nautilus-action-bar.ui
@@ +338,3 @@
+            </child>
+            <child>
+              <object class="GtkBox">

This is making the action bar growing in height more than necessary in my case I think.

Review of attachment 330085 [details] [review]:

Review of attachment 330086 [details] [review]:

Review of attachment 330087 [details] [review]:

I would prefer to not say "it was a bad choice since it's inception" in the history of Nautilus. It was the work of someone after all :)

Review of attachment 330088 [details] [review]:

this should be squashed I guess

Review of attachment 330089 [details] [review]:

squashed as well no?

thanks for the work Georges!

ping - any merging of patches planned here?

(In reply to André Klapper from comment #20)
> ping - any merging of patches planned here?

No, we are blocking on design

*** Bug 681802 has been marked as a duplicate of this bug. ***

Superseded by https://gitlab.gnome.org/GNOME/nautilus/issues/322