beat.editor issueshttps://gitlab.idiap.ch/beat/beat.editor/-/issues2019-06-03T09:36:59Zhttps://gitlab.idiap.ch/beat/beat.editor/-/issues/219AssetModel latest only feature is incomplete2019-06-03T09:36:59ZSamuel GAISTAssetModel latest only feature is incompleteSummary
The "latest only" property implement of AssetModel is currently incomplete and does not work for all asset types.
Steps to reproduce
```
model = AssetModel()
model.prefix_path = "path/to/prefix"
model.asset_type = "AssetType....Summary
The "latest only" property implement of AssetModel is currently incomplete and does not work for all asset types.
Steps to reproduce
```
model = AssetModel()
model.prefix_path = "path/to/prefix"
model.asset_type = "AssetType.DATAFORMAT"
asset_list = model.stringList()
model.setLatestOnlyEnabled(False)
full_asset_list = model.stringList()
assert asset_list != full_asset_list
assert len(asset_list) < len(full_asset_list)
```
What is the current bug behavior?
The same list of assets is returned for types that are neither database nor protocol templates.
What is the expected correct behavior?
The two lists should be different if the prefix contains several versions of these assets
Possible fixes
Implement the same "un-filtering" for all assets where it make sense.
The fix will require beat/beat.core!76[v2] 1 - Edition/Visualization for small editorsSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.editor/-/issues/231The cleanup for the content widget is not done properly.2019-10-04T15:12:53ZZohreh MOSTAANIThe cleanup for the content widget is not done properly.The issue is that if you edit an asset (tested with dataformat), and then open another dataformat without saving the previous one the content of what you have opened past will be shown in the one that has not been saved, instead of it be...The issue is that if you edit an asset (tested with dataformat), and then open another dataformat without saving the previous one the content of what you have opened past will be shown in the one that has not been saved, instead of it being in the previous state.
I realize that you don't even need to make a new dataformat. To reproduce the issue, you just need to have several dataformat from one or more than one user available. Start opening them one after another and look at the change in the content!
The issue comes from how the widgets are being cleaned before a new asset is open. The content from previous asset is not cleaned fully and what you see as the newly open asset is not it's own content but information from the leftovers.Samuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.editor/-/issues/244Improve plotter new creation handling2019-10-04T15:12:49ZSamuel GAISTImprove plotter new creation handlingSummary
Currently when creating a new Plotter, the prototype contains "plot/unknown/1".
This has problematic implications:
- The editor will fail to load it
- Test will fail because the editor can't load that dataformat
Steps to repr...Summary
Currently when creating a new Plotter, the prototype contains "plot/unknown/1".
This has problematic implications:
- The editor will fail to load it
- Test will fail because the editor can't load that dataformat
Steps to reproduce
1) Click on new
2) Select Plotter
3) Try to edit the plotter created
What is the current bug behavior?
An error is raised and it make the application fail
What is the expected correct behavior?
Either:
- Show a dialog asking to select a dataformat to use.
- Select a suitable dataformat from the prefix. Maybe a simple default like for the algorithm prototype.
Possible fixes
One possibility could be to have a method called after the dialog has been closed that can be re-implemented in sub-classes to do whatever is needed for the newly created object.
Another would be to move the dialog logic in its own method so re-implementing _createNewAsset would be easier.
Note that this affects beat/beat.editor!101[v2] 1 - Edition/Visualization for small editorsFlavio TARSETTIFlavio TARSETTIhttps://gitlab.idiap.ch/beat/beat.editor/-/issues/245Improve error handling2019-12-11T09:57:48ZSamuel GAISTImprove error handlingSummary
Currently, there's lot of code triggering a RuntimeError which in turn will make beat.editor stop.
Most of these situations should be gracefully handled. If possible, a fix should be proposed to the user so he can continue work...Summary
Currently, there's lot of code triggering a RuntimeError which in turn will make beat.editor stop.
Most of these situations should be gracefully handled. If possible, a fix should be proposed to the user so he can continue working.
Steps to reproduce
1) Create a new Plotter
2) Load the plotter
This will make beat.editor crash as the new Plotter will be based on the prototype that contains an invalid entry.
This situation is already reported in #244
What is the current bug behavior?
beat.editor will end there
What is the expected correct behavior?
beat.editor should not stop
Possible fixes
The user should get a message about what is going wrong. If possible a fix should be proposed and applied if accepted.
In any case, the editor should continue working.[v2] 1 - Edition/Visualization for small editorsFlavio TARSETTIFlavio TARSETTIhttps://gitlab.idiap.ch/beat/beat.editor/-/issues/248QMenu for push button lifetime issue2019-10-02T12:00:49ZSamuel GAISTQMenu for push button lifetime issueSummary
While doing tests to check whether PySide2 could be used, an issue has been found with the handling of QMenu when used in a helper function to generate a QPushButton, the related QMenu and QActions.
On return of the method, th...Summary
While doing tests to check whether PySide2 could be used, an issue has been found with the handling of QMenu when used in a helper function to generate a QPushButton, the related QMenu and QActions.
On return of the method, the QMenu object is destroyed with PySide2 while not with PyQt5.
This is likely related to the fact that QPushButton::setMenu does not take ownership of the QMenu. So it likely is garbage collected at the end of the method.
Steps to reproduce
```
import sys
from PySide2.QtWidgets import QApplication
from PySide2.QtWidgets import QAction
from PySide2.QtWidgets import QMenu
from PySide2.QtWidgets import QPushButton
def build_button_with_menu():
button = QPushButton("The button")
menu = QMenu("The menu")
button.setMenu(menu)
action = menu.addAction("The action")
return button, action
app = QApplication(sys.argv)
button, action = build_button_with_menu()
action.triggered.connect(app.quit)
sys.exit(app.exec_())
```
What is the current bug behavior?
This will trigger a property error saying that triggered has no connect property.
Checking the action itself will show the correct type but the signal object related methods will be missing.
What is the expected correct behavior?
No error, the connection gets created, the button is shown and when clicking on the action, the application should stop.
Possible fixes
The fix is to give the QMenu a parent, in this case, the button itself, so its lifetime doesn't end with the end of the method.[v2] 1 - Edition/Visualization for small editorsSamuel GAISTSamuel GAIST