diff --git a/src/gui/ctrl/actions.hpp b/src/gui/ctrl/actions.hpp index 621ffe64a..c85f57162 100644 --- a/src/gui/ctrl/actions.hpp +++ b/src/gui/ctrl/actions.hpp @@ -224,6 +224,35 @@ namespace ctrl { + /** + * Updates the state of the menu/toolbar actions + * to reflect the current state of the workspace + * @note the actual functionality was disabled by Joel with changeset 6151415 (from 4.4.2009), + * which introduced a PanelManager. This whole concept was seemingly never finished. + * @todo as of 2017, the relation of panels to top level windows is unclear and likely + * needs to be replaced by a focus + perspective concept (--> see topic "Interaction Control") + */ + void + updateActionState (workspace::WorkspaceWindow& currentWindow) + { + ///////////////////////////////////////////////////////////////////////////////////////TICKET #1076 find out how to handle this properly + ///////////////////////////////////////////////////////////////////////////////////////TICKET #1097 clarify the role and behaviour of Panels + /* unfinished, disabled by Joel with changeset 6151415 (from 4.4.2009) + * + REQUIRE(currentWindow.assetsPanel != NULL); + REQUIRE(currentWindow.timelinePanel != NULL); + REQUIRE(currentWindow.viewerPanel != NULL); + +// is_updating_action_state = true; + assetsPanelAction->set_active (currentWindow.assetsPanel->is_shown()); + timelinePanelAction->set_active(currentWindow.timelinePanel->is_shown()); + viewerPanelAction->set_active (currentWindow.viewerPanel->is_shown()); +// is_updating_action_state = false; + */ + } + + + private: /* ===== Internals ===== */ @@ -267,34 +296,6 @@ namespace ctrl { - /** - * Updates the state of the menu/toolbar actions - * to reflect the current state of the workspace */ - void - updateActionState() - { - ///////////////////////////////////////////////////////////////////////////////////////TICKET #1076 find out how to handle this properly - /* - WorkspaceWindow& currentWindow = getWorkspaceWindow(); - - REQUIRE(currentWindow.assetsPanel != NULL); - REQUIRE(currentWindow.timelinePanel != NULL); - REQUIRE(currentWindow.viewerPanel != NULL); - - is_updating_action_state = true; - assetsPanelAction->set_active (currentWindow.assetsPanel->is_shown()); - timelinePanelAction->set_active(currentWindow.timelinePanel->is_shown()); - viewerPanelAction->set_active (currentWindow.viewerPanel->is_shown()); - is_updating_action_state = false; - */ - } - - - - - - private: - /* ============ View Actions ========== */ @@ -305,6 +306,7 @@ namespace ctrl { //if(!is_updating_action_state) // workspaceWindow.assetsPanel->show( // assetsPanelAction->get_active()); //////global -> InteractionDirector + unimplemented ("view assets"); } void @@ -313,6 +315,7 @@ namespace ctrl { /////////////////////////////////////////////////////////////////////////////////////TODO defunct since GTK-3 transition //if(!is_updating_action_state) // workspaceWindow.timelinePanel->show(timelinePanActionselAction->get_active()); + unimplemented ("view timeline"); } void @@ -321,6 +324,7 @@ namespace ctrl { /////////////////////////////////////////////////////////////////////////////////////TODO defunct since GTK-3 transition //if(!is_updating_action_state) // workspaceWindow.viewerPanel->show(viewerPanelAction->get_active()); //////global -> InteractionDirector + unimplemented ("view viewer"); } diff --git a/src/gui/ctrl/ui-manager.cpp b/src/gui/ctrl/ui-manager.cpp index 05e4e2ec8..318a8bbb9 100644 --- a/src/gui/ctrl/ui-manager.cpp +++ b/src/gui/ctrl/ui-manager.cpp @@ -121,8 +121,8 @@ namespace ctrl { void UiManager::updateWindowFocusRelatedActions() { - UNIMPLEMENTED ("how to handle activation of menu entries depending on window focus"); ////////TICKET #1076 find out how to handle this properly - //////see Actions::updateActionState() + ///////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1076 find out how to handle this properly + actions_->updateActionState (globals_->windowList_.findActiveWindow()); } diff --git a/src/gui/workspace/panel-manager.hpp b/src/gui/workspace/panel-manager.hpp index 6c6d62bf5..465dfbb88 100644 --- a/src/gui/workspace/panel-manager.hpp +++ b/src/gui/workspace/panel-manager.hpp @@ -24,6 +24,9 @@ /** @file panel-manager.hpp ** Management of dockable panels. ** + ** @todo 2017 need to clarify the intended behaviour of panels + ** ///////////////////////////////////////////////////////////////////////////TICKET #1097 clarify the role and behaviour of Panels + ** ** @see actions.hpp */ diff --git a/wiki/renderengine.html b/wiki/renderengine.html index a2e012baa..43107fd1a 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -3420,7 +3420,7 @@ The InstanceHandle is created by the service implementation and will automatical → see [[detailed description here|LayerSeparationInterfaces]] -
+
This overarching topic is where the arrangement of our interface components meets considerations about interaction design.
 The interface programming allows us to react on events and trigger behaviour, and it allows us to arrange building blocks within a layout framework. Beyond that, there needs to be some kind of coherency in the way matters are arranged -- this is the realm of conventions and guidelines. Yet in any more than trivial UI application, there is an intermediate and implicit level of understanding, where things just happen, which can not fully be derived from first principles. It is fine to have a convention to put the "OK" button right -- but how to we get at trimming a clip? How do we how we are to get at trimming a clip? if we work with the mouse? or the keyboard? or with a pen? or with a hardware controller we don't even know yet? We could deal with such on a case-by-case base (as the so called reasonable people do) or we could aim at an abstract intermediary space, with the ability to assimilate the practical situation yet to come.
 
@@ -3464,7 +3464,10 @@ The primary insight is  //that we build upon a spatial metaphor// -- and thus we
 :navigating means to move the SpotLocator, in order to move the spot from work site to work site
 :the spot locator is relocated by loading a new focus path to another [[work site|WorkSite]]
 
-The concept of a //focus goal// has several ramifications: for one it implies that there is something like //"current cotrol system",// which also could be the //currently active control system(s).// Simply because focus, as the realisation of the abstract notion of the spot, is always tied to a control system able to implement it. And when we're able to define generic location coordinates and then //"move there",// with the help of the spotLocator, we draw the conclusion that there must be a focus (implementation) be moving towards that location. Like e.g.  the desired entity gaining the keyboard focus. And the second thing we may conclude is that there is some degree of leeway in the way how such a focus goal is reached. Since the inner logic of control systems can be quite drastically different from each other, we need to leave it to the actual control system //how a focus goal is reached.// To point out an obvious example: it is not a good idea to move the mouse pointer forcibly onto a screen element. Rather, we must use the established mechanisms of switching, scrolling and unfolding to bring the desired target element into the visible area, leaving the last step to the user, which must actively move the mouse onto the target. And we must give good visual clues as to what happened, and what we expect from the user (namely to direct her attention onto the element brought into focus).
+The concept of a //focus goal// has several ramifications: for one it implies that there is something like //"current cotrol system",// which also could be the //currently active control system(s).// Simply because focus, as the realisation of the abstract notion of the spot, is always tied to a control system able to implement it. And when we're able to define generic location coordinates and then //"move there",// with the help of the SpotLocator, we draw the conclusion that there must be a focus (implementation) be moving towards that location. Like e.g.  the desired entity gaining the keyboard focus. And the second thing we may conclude is that there is some degree of leeway in the way how such a focus goal is reached. Since the inner logic of control systems can be quite drastically different from each other, we need to leave it to the actual control system //how a focus goal is reached.// To point out an obvious example: it is not a good idea to move the mouse pointer forcibly onto a screen element. Rather, we must use the established mechanisms of switching, scrolling and unfolding to bring the desired target element into the visible area, leaving the last step to the user, which must actively move the mouse onto the target. And we must give good visual clues as to what happened, and what we expect from the user (namely to direct her attention onto the element brought into focus).
+
+!Building the framework
+To create such a system is an ambitious goal. We can not reach it in a single step, since it entails the formation of a whole intermediary layer, on top of the //usual UI mechanics,// yet below the concrete UI interactions. Especially, we'd need to clarify the meaning of //perspective,// we need to decide on the relation of top level frame, individual view, layout, focus and //current location within the UI.// On a second thought, building such a system implies we'll have to live with an intermediary state of evolution, where parts of the new framework are already in place without interfering with common conventional usage of the interface as-is.
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 2ca1cc061..d4c9c2da8 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -1783,8 +1783,9 @@ - - + + + @@ -1801,17 +1802,17 @@ - + - - - - - + + + + + @@ -1819,8 +1820,11 @@ + + - + + @@ -1829,6 +1833,45 @@ + + + + + + + + +

+ ...wartet noch darauf, +

+

+ daß die alte, obsolete Timeline zurückgebaut ist +

+ + + + + + + + + + + +

+ siehe guifacade.cpp +

+

+ Problem ist: wenn das triggerShutdown kommt, +

+

+ bevor die Notification-Facade geöffnet werden konnte +

+ + + + + @@ -1855,17 +1898,16 @@ - + + + - - - @@ -2367,15 +2409,21 @@ - - - - - - + + + + + + + + + + + - - + + + @@ -2613,13 +2661,17 @@ + + + + - + - + @@ -2642,16 +2694,16 @@ - + - + - + @@ -2673,7 +2725,7 @@ - + @@ -2695,7 +2747,7 @@ - + @@ -2710,13 +2762,13 @@ - + - + @@ -2749,7 +2801,7 @@ - +