Suggestions for the modification history about rafcon

[franzlst]

I would like to discuss some of this a bit may also on Monday.

• Note 1 --- my opinion is implemented --- may there are others
• Note 2 --- Nr OK --- |
• Note 2 --- Method and Action is the same and the method_name is underscored --- |
• Note 2 --- Parameter OK -> if we talk about a methods we also should add the arguments :)
• Note 2 --- Affected OK --- but at the end -> as long as it is basically the actual third column 'instance' and it would be a weight column --- my opinion is 'method' is the most important column
• Note 3.1 and 3.3 --- on command sir :D
• Note 3.2 --- found even one more 👯
• Note 4 --- May I missunderstood you but this is what it is doing ---
• Note 5 --- thought that was already fixed :)

Originally created by @Rbelder at 2016-02-17 16:18:31+00:00 (moved from RMC internal repository)

[franzlst]

About the history order:
I think both ways are fine, but it should be consistent. I was very irritated, because the order is reversed in subbranches:

• 5
• 4 (=> descending)
• 1
  • 2
  • 3 (=> ascending)
• 0

About columns

• I would prefer Action rather than Method, as method is more a computer science term, compared to action referring to a user action
• I don't know whether you got me correct referring to underscores: In the GUI, I would prefer "add state" rather than "add_state", similarly "add input data port" instead of "add_input_data_port", the argument is more or less the same as above
• The left side bar is limited in with, therefore we should try to keep the columns narrow. This could mean showing only the state type when then parameter is a state and the method is add_state (the name is "Untitled" anyways). On the other hand, for "Affected", the name of the state would be more informative. So finding a proper solution here is not trivial.
• I would remove the brackets '[', ']' in the parameters column
• These "issues" are really not a big deal, but I think they improve the usability and looks for the user

Clicking on history items
Hmm, now it is working. I will keep an eye on it and see if I can crash it again 😉

Jump to top
Seems to be fixed now

Thank you for the fast response!

Originally created by @franzlst ([email protected]) at 2016-02-18 07:07:10+00:00 (moved from RMC internal repository)

[franzlst]

About the history order:
I was sure that this will be a point but it is a choice to have always a continues queue of actions in the tree or a break. To reach 3 the actions will be used as follows [(undo, 4), (undo, 1), (redo, 2), (redo, 3)]. So the tree also describe a kind of distance between state-machine edit-states. We could put it on the stack for Monday. 😅

About columns

• the gui is oriented according usage and not according core elements so:
  • Prefer Action rather than Method, as method is more a computer science term, compared to action referring to a user action
  • underscores: In the GUI, we prefer "add state" rather than "add_state", similarly "add input data port" instead of "add_input_data_port"
• the limiting of the column weight needs to be improved and a final solution found
• brackets '[', ']' in the parameters column will be removed it is only a list of strings converted to a string at the moment

Clicking on history items
The not functional clicking feature seems to be caused in your case by undo-bug of element-0 and ending up at element-(-1). As long as the feature is using the trail-pointer-id the -1 id results in no solution for the action-path-serach.

Originally created by @Rbelder at 2016-02-18 09:48:26+00:00 (moved from RMC internal repository)

[franzlst]

Outcome of the discussion of the meeting at 2016-02-22 concerning the modification-history-tree-view was:

• the ordering newest on top is equal to the oldest on top -> as long as execution-history use the same (newest on top) and it is common practice in other application the implementation of element ordering is fine
• the ordering of elements continues to switch if a branch (new tree level) is created by-side the active branch (trail-history) -> it is the same weird as without switching the ordering but depicts the queue of actions between two elements

Originally created by @Rbelder at 2016-02-23 09:39:24+00:00 (moved from RMC internal repository)