With that in place, we would probably be better off with a simple back button (no label) and removing the Name [            ] entry, allowing the name to be changed directly in the toolbar title (granted the 'properties') would be visually separate.

I'll mock this up.

Created attachment 234177 [details] [review]
Add header to properties view

This just adds the title and changes the back button. Can't edit the title in the UI yet, thats a lot more work.

Review of attachment 234177 [details] [review]:

Looks good overall

::: src/properties.vala
@@ +16,3 @@
+    public string title {
+        set {
+            toolbar.set_labels (_("%s - Properties").printf (App.app.current_item.name), null);

A translator comment to indicate %s is a box name would be nice.

@@ +317,3 @@
             populate ();
+            toolbar_label_bind = null;
+            toolbar_label_bind = App.app.current_item.bind_property ("name", this, "title", BindingFlags.SYNC_CREATE);

Do we need both here to trigger some side-effect?

Review of attachment 234177 [details] [review]:

::: src/properties.vala
@@ +16,3 @@
+    public string title {
+        set {
+            toolbar.set_labels (_("%s - Properties").printf (App.app.current_item.name), null);

I'll add one

@@ +317,3 @@
             populate ();
+            toolbar_label_bind = null;
+            toolbar_label_bind = App.app.current_item.bind_property ("name", this, "title", BindingFlags.SYNC_CREATE);

No, thats just a leftover for the old if case.

Attachment 234177 [details] pushed as 356985a - Add header to properties view

Moved the edit-in-title part to bug 692383