app-window: Add 'current-item' prop

Prepares its move from App to AppWindow because each window may have a
different current item. Also makes App's current_item attribute a
property to bind them during the move.

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
app-window: Move show_properties() from App

show_properties () only uses things that are part of AppWindow ('view',
'current-item') or will be moved to it in next patches ('selection-mode',
'ui-state') and so it should be moved to AppWindow.

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
app-window: Move connect_to() from App

Allows to connect the current item to its window, so it should be part of
AppWindow as 'current-item' is moving from App to it.

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
app-window: Move select_item() from App

As the 'current-item' property is moving from App to AppWindow,
select_item () should follow it.

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
app-window: Disconnect machine on collection page

Moves the cancellation of the current machine's conection when the UI is
in collection state from App to AppWindow. As the 'current-item' property
is moving from App to AppWindow and as the UI state will too, the
cancellation should move. Also moves the setting of the current item's
state from App to AppWindow.

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
app: Remove 'current-item' prop

Removes the 'current-item' property from App. Also makes the
'current-item' property of AppWindow an attribute as it was only needed
to bind current items during the move. It finishes its move from App to
AppWindow.

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
app-window: Add 'selection-mode' prop

Prepares its move from App to AppWindow because each window may been in
selection mode independently from the others.

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
collection-view: Setup UI once window is constructed

This is part of the move of the 'selection-mode' property from App to
AppWindow. This adds setup_ui() to the CollectionView class to ensure that
the connection to the notification of 'selection-mode' is done once the
window is constructed.

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
selectionbar: Setup UI once window is constructed

This is part of the move of the 'selection-mode' property from App to
AppWindow. This adds setup_ui() to the Selectionbar class to ensure that
the connection to the notification of 'selection-mode' is done once the
window is constructed.

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
Use AppWindow's 'selection-mode' prop instead of App's

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
collection-toolbar: Move 'ui-state' connection to setup_ui()

This moves the connection to the App's 'ui-state' notifications from the
constuctor to setup_ui (). UIState will no more be implemented by App but
rather by AppWindow, so we must ensure that the window is constructed when
trying to connect to 'ui-state' notifications.

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
app: No more implements UIState

UI state is now managed by AppWindow as each window can have a different
UI state from the others.

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
topbar: Drop use of AppWindow singleton

Instead of using the AppWindow singleton, Topbar now has its own reference
to AppWindow that it receives through a parameter to setup_ui().

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
collection-toolbar: Drop use of AppWindow singleton

Instead of using the AppWindow singleton, CollectionToolbar now has its
own reference to AppWindow that it receives through a parameter to
setup_ui().

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
selection-toolbar: Drop use of AppWindow singleton

Instead of using the AppWindow singleton, SelectionToolbar now has its
own reference to AppWindow that it receives through a parameter to
setup_ui().

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
wizard: Drop use of AppWindow singleton

Instead of using the AppWindow singleton, Wizard now has its own
reference to AppWindow that it receives through a parameter to setup_ui().

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
display-page: Drop use of AppWindow singleton

Instead of using the AppWindow singleton, DisplayPage now has its own
reference to AppWindow that it receives through a parameter to setup_ui().

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
display-toolbar: Drop use of AppWindow singleton

Instead of using the AppWindow singleton, DisplayToolbar now has its own
reference to AppWindow that it receives through a parameter to setup_ui().

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
collection-view: Drop use of AppWindow singleton

Instead of using the AppWindow singleton, CollectionView now has its own
reference to AppWindow that it receives through a parameter to setup_ui().

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098
selectionbar: Drop use of AppWindow singleton

Instead of using the AppWindow singleton, Selectionbar now has its own
reference to AppWindow that it receives through a parameter to setup_ui().

This is needed to drop the use of AppWindow singleton and therefore to
make multiple windows possible.

https://bugzilla.gnome.org/show_bug.cgi?id=732098