franzlst / issue-mover-test Goto Github PK

Originally created by stei-fn at ([email protected])

This is a suggestion which I put here for discussion.

In my opinion, not only the class name is important for defining its purpose, but also the module/package path in which the class resides. That's why the State class is called State and not RAFCONStatemachineState. There are exceptions to this, especially if the class serves some kind of pattern purpose (StateModel, despite the class is within the model module).

We do not always follow that "rule" and I would like to change this for parts of the execution:

• StateMachineExecutionEngine should be renamed to ExecutionEngine (it is within the statemachine.execution module)
• StateMachineExecutionStatus should be renamed to ExecutionStatus and moved into the statemachine.state_machine.py file.
• StateExecutionState should be renamed to ExecutionStatus (why is the one called ...Stat us and the other ...Stat e?) and moved into the statemachine.states.state.py file

Related to statemachine.enums.py:

• DataPortType should be removed at all, instead the classes itself should be used as types. At the least the enum should be moved into the statemachine.state_elements.data_port.py file
• Same for StateType
• CallType should be moved into the statemachine.execution.execution_history.py file

In case you agree to this and we decide to postpone this for a minor release, I would also suggest to rename the statemachine module to core and mvc to gui.

Originally opened by stei-fn ([email protected])

The user should be able to resize all elements in a multi-selection.

The issue is a duplication of mantis issue https://rmintra01.robotic.dlr.de/mantis/view.php?id=1911.

I would like to have the scoped variables (SV) placed on the bottom (in the middle) of a state by default. There are different reasons why:

• The logical ports or in the upper left, upper edge, or upper right of a state and the input- and output-data-ports are already at the bottom
• In the top there is already the label/field for the state name
• Also having it left orientated is not that nice because the SV is usually used later in the state machine development when most of the space on the left side is used (SV mostly are not used as imports for the first child states)

What do you think? The issue is low priority but it came to my mind.

Originally created by beld-rc (unknown email) at 2017-02-24 16:35:30+00:00

See https://docs.python.org/2/howto/logging.html#configuring-logging

This is the text of the issue.

Originally created by stei-fn at ([email protected])

This is a suggestion which I put here for discussion.

In my opinion, not only the class name is important for defining its purpose, but also the module/package path in which the class resides. That's why the State class is called State and not RAFCONStatemachineState. There are exceptions to this, especially if the class serves some kind of pattern purpose (StateModel, despite the class is within the model module).

We do not always follow that "rule" and I would like to change this for parts of the execution:

• StateMachineExecutionEngine should be renamed to ExecutionEngine (it is within the statemachine.execution module)
• StateMachineExecutionStatus should be renamed to ExecutionStatus and moved into the statemachine.state_machine.py file.
• StateExecutionState should be renamed to ExecutionStatus (why is the one called ...Stat us and the other ...Stat e?) and moved into the statemachine.states.state.py file

Related to statemachine.enums.py:

• DataPortType should be removed at all, instead the classes itself should be used as types. At the least the enum should be moved into the statemachine.state_elements.data_port.py file
• Same for StateType
• CallType should be moved into the statemachine.execution.execution_history.py file

In case you agree to this and we decide to postpone this for a minor release, I would also suggest to rename the statemachine module to core and mvc to gui.

NA

The scoped data value next to the scoped data name eases the usability.

enhancement

NA

At the moment important logs like warnings and errors move away very fast (especially if debug logs are shown) before the user actually can read them.

I would like to have some notification that stays till the user has clicked into the console window.

The feature request is minor and can be used a discussion about the feature, at the moment. So that we find the right sub-tasks for the issue.

Notes and ideas about the feature:

• The check boxes to activate warnings or errors could blink or be highlighted and maybe have a count of warning and error messages that have been logged since the last visit in this window. (this is possible and more or less easy to implement)
• The notification can also occur if the check boxes of errors and warnings are set to False to avoid to miss the error messages while this often mistakenly used settings
• additionally a observation of the scroll bar to count down the warnings and errors can help.

Originally created by beld-rc at

This is the text of the issue.

Originally created by Franz ([email protected]) at 2017-02-06 12:47:46+00:00

The view port of the last edit should be restored if the statemachine is edited another time.

This is a duplicate to issue https://rmintra01.robotic.dlr.de/mantis/view.php?id=1912

This is a suggestion which I put here for discussion.

In my opinion, not only the class name is important for defining its purpose, but also the module/package path in which the class resides. That's why the State class is called State and not RAFCONStatemachineState. There are exceptions to this, especially if the class serves some kind of pattern purpose (StateModel, despite the class is within the model module).

We do not always follow that "rule" and I would like to change this for parts of the execution:

• StateMachineExecutionEngine should be renamed to ExecutionEngine (it is within the statemachine.execution module)
• StateMachineExecutionStatus should be renamed to ExecutionStatus and moved into the statemachine.state_machine.py file.
• StateExecutionState should be renamed to ExecutionStatus (why is the one called ...Stat us and the other ...Stat e?) and moved into the statemachine.states.state.py file

Related to statemachine.enums.py:

• DataPortType should be removed at all, instead the classes itself should be used as types. At the least the enum should be moved into the statemachine.state_elements.data_port.py file
• Same for StateType
• CallType should be moved into the statemachine.execution.execution_history.py file

In case you agree to this and we decide to postpone this for a minor release, I would also suggest to rename the statemachine module to core and mvc to gui.

This is the text of the issue.

Originally created by stei-fn at ([email protected])

The issue combines problem with meta data scaling or update when doing a group states, ungroup state or substitute state action. The sub-tasks concern smaller elements to be fixed to improve usability and maybe also features that are not implemented for opengl.

• scaling and relative position changes of group states and ungroup state actions should work simular to opengl
• suspend drawing meta data for all three actions similar to state type change
• the right usage of the meta_signal of the state model to inform the gaphas viewer about changes made by the model has to be found, too. At the moment, the signal creates problems with the modification history.

Fill free to add some sub-task concerning this three actions. 😄

This is the text of the issue.

Originally created by Franz ([email protected]) at 2017-02-06 12:47:46+00:00

Originally created by stei-fn at ([email protected])

NA

Originally created by stei-fn at ([email protected])

This is a suggestion which I put here for discussion.

In my opinion, not only the class name is important for defining its purpose, but also the module/package path in which the class resides. That's why the State class is called State and not RAFCONStatemachineState. There are exceptions to this, especially if the class serves some kind of pattern purpose (StateModel, despite the class is within the model module).

We do not always follow that "rule" and I would like to change this for parts of the execution:

• StateMachineExecutionEngine should be renamed to ExecutionEngine (it is within the statemachine.execution module)
• StateMachineExecutionStatus should be renamed to ExecutionStatus and moved into the statemachine.state_machine.py file.
• StateExecutionState should be renamed to ExecutionStatus (why is the one called ...Stat us and the other ...Stat e?) and moved into the statemachine.states.state.py file

Related to statemachine.enums.py:

• DataPortType should be removed at all, instead the classes itself should be used as types. At the least the enum should be moved into the statemachine.state_elements.data_port.py file
• Same for StateType
• CallType should be moved into the statemachine.execution.execution_history.py file

In case you agree to this and we decide to postpone this for a minor release, I would also suggest to rename the statemachine module to core and mvc to gui.

Originally opened by stei-fn ([email protected])

I would like to have the scoped variables (SV) placed on the bottom (in the middle) of a state by default. There are different reasons why:

• The logical ports or in the upper left, upper edge, or upper right of a state and the input- and output-data-ports are already at the bottom
• In the top there is already the label/field for the state name
• Also having it left orientated is not that nice because the SV is usually used later in the state machine development when most of the space on the left side is used (SV mostly are not used as imports for the first child states)

What do you think? The issue is low priority but it came to my mind.

Originally created by beld-rc (unknown email) at 2017-02-24 16:35:30+00:00

This is a suggestion which I put here for discussion.

In my opinion, not only the class name is important for defining its purpose, but also the module/package path in which the class resides. That's why the State class is called State and not RAFCONStatemachineState. There are exceptions to this, especially if the class serves some kind of pattern purpose (StateModel, despite the class is within the model module).

We do not always follow that "rule" and I would like to change this for parts of the execution:

• StateMachineExecutionEngine should be renamed to ExecutionEngine (it is within the statemachine.execution module)
• StateMachineExecutionStatus should be renamed to ExecutionStatus and moved into the statemachine.state_machine.py file.
• StateExecutionState should be renamed to ExecutionStatus (why is the one called ...Stat us and the other ...Stat e?) and moved into the statemachine.states.state.py file

Related to statemachine.enums.py:

• DataPortType should be removed at all, instead the classes itself should be used as types. At the least the enum should be moved into the statemachine.state_elements.data_port.py file
• Same for StateType
• CallType should be moved into the statemachine.execution.execution_history.py file

In case you agree to this and we decide to postpone this for a minor release, I would also suggest to rename the statemachine module to core and mvc to gui.

Originally opened by stei-fn ([email protected])

This is the text of the issue.

Originally created by stei-fn ([email protected]) at 2017-02-06 12:47:46+00:00

All handles are currently being drawn the very same way. This should be changed.

• Resize handles of states should be drawn further outside and in the way our designed suggested it
• Port handles should not be placed within the port, hiding its content. Also the optics should be changed (how?)
• Connections handles should also get their unique look (how?)

Originally opened by stei-fn ([email protected])

Right now if a new state is created, it is created at the next position of the virtual grid of the parent state.
This new position can be hehind an existing lager state. So the new state will be completely invisible.

At the moment important logs like warnings and errors move away very fast (especially if debug logs are shown) before the user actually can read them.

I would like to have some notification that stays till the user has clicked into the console window.

The feature request is minor and can be used a discussion about the feature, at the moment. So that we find the right sub-tasks for the issue.

Notes and ideas about the feature:

• The check boxes to activate warnings or errors could blink or be highlighted and maybe have a count of warning and error messages that have been logged since the last visit in this window. (this is possible and more or less easy to implement)
• The notification can also occur if the check boxes of errors and warnings are set to False to avoid to miss the error messages while this often mistakenly used settings
• additionally a observation of the scroll bar to count down the warnings and errors can help.

Originally created by beld-rc (unknown email) at 2017-02-10 12:33:07+00:00

This is the text of the issue.

Originally created by stei-fn at ([email protected])

All handles are currently being drawn the very same way. This should be changed.

• Resize handles of states should be drawn further outside and in the way our designed suggested it
• Port handles should not be placed within the port, hiding its content. Also the optics should be changed (how?)
• Connections handles should also get their unique look (how?)

Originally opened by stei-fn ([email protected])

This is the text of the issue.

Originally created by Franz ([email protected]) at 2017-02-06 12:47:46+00:00

I would like to have the scoped variables (SV) placed on the bottom (in the middle) of a state by default. There are different reasons why:

• The logical ports or in the upper left, upper edge, or upper right of a state and the input- and output-data-ports are already at the bottom
• In the top there is already the label/field for the state name
• Also having it left orientated is not that nice because the SV is usually used later in the state machine development when most of the space on the left side is used (SV mostly are not used as imports for the first child states)

What do you think? The issue is low priority but it came to my mind.

Originally created by beld-rc (unknown email) at 2017-02-24 16:35:30+00:00

This is the text of the issue.

Originally created by stei-fn at ([email protected])

All handles are currently being drawn the very same way. This should be changed.

• Resize handles of states should be drawn further outside and in the way our designed suggested it
• Port handles should not be placed within the port, hiding its content. Also the optics should be changed (how?)
• Connections handles should also get their unique look (how?)

This is a suggestion which I put here for discussion.

In my opinion, not only the class name is important for defining its purpose, but also the module/package path in which the class resides. That's why the State class is called State and not RAFCONStatemachineState. There are exceptions to this, especially if the class serves some kind of pattern purpose (StateModel, despite the class is within the model module).

We do not always follow that "rule" and I would like to change this for parts of the execution:

• StateMachineExecutionEngine should be renamed to ExecutionEngine (it is within the statemachine.execution module)
• StateMachineExecutionStatus should be renamed to ExecutionStatus and moved into the statemachine.state_machine.py file.
• StateExecutionState should be renamed to ExecutionStatus (why is the one called ...Stat us and the other ...Stat e?) and moved into the statemachine.states.state.py file

Related to statemachine.enums.py:

• DataPortType should be removed at all, instead the classes itself should be used as types. At the least the enum should be moved into the statemachine.state_elements.data_port.py file
• Same for StateType
• CallType should be moved into the statemachine.execution.execution_history.py file

In case you agree to this and we decide to postpone this for a minor release, I would also suggest to rename the statemachine module to core and mvc to gui.

This is the text of the issue.

Originally created by stei-fn at ([email protected])

This is a suggestion which I put here for discussion.

In my opinion, not only the class name is important for defining its purpose, but also the module/package path in which the class resides. That's why the State class is called State and not RAFCONStatemachineState. There are exceptions to this, especially if the class serves some kind of pattern purpose (StateModel, despite the class is within the model module).

We do not always follow that "rule" and I would like to change this for parts of the execution:

• StateMachineExecutionEngine should be renamed to ExecutionEngine (it is within the statemachine.execution module)
• StateMachineExecutionStatus should be renamed to ExecutionStatus and moved into the statemachine.state_machine.py file.
• StateExecutionState should be renamed to ExecutionStatus (why is the one called ...Stat us and the other ...Stat e?) and moved into the statemachine.states.state.py file

Related to statemachine.enums.py:

• DataPortType should be removed at all, instead the classes itself should be used as types. At the least the enum should be moved into the statemachine.state_elements.data_port.py file
• Same for StateType
• CallType should be moved into the statemachine.execution.execution_history.py file

In case you agree to this and we decide to postpone this for a minor release, I would also suggest to rename the statemachine module to core and mvc to gui.