beat.editor issueshttps://gitlab.idiap.ch/beat/beat.editor/-/issues2020-03-26T12:44:59Zhttps://gitlab.idiap.ch/beat/beat.editor/-/issues/256Toolchain tests for BlockType class2020-03-26T12:44:59ZFlavio TARSETTIToolchain tests for BlockType classSummary
Tests for possible block type objects are missing for the toolchain editorSummary
Tests for possible block type objects are missing for the toolchain editorFlavio TARSETTIFlavio TARSETTIhttps://gitlab.idiap.ch/beat/beat.editor/-/issues/255Ensure field max length is respected2020-03-25T11:42:34ZSamuel GAISTEnsure field max length is respectedThe short description field has a maximal length on the platform that must checked here.
There editors should implement these constraints.
If possible these constraints should also be encoded in the corresponding schemas and the variou...The short description field has a maximal length on the platform that must checked here.
There editors should implement these constraints.
If possible these constraints should also be encoded in the corresponding schemas and the various editors use that information to enforce them.
See beat/beat.core#95Flavio TARSETTIFlavio TARSETTIhttps://gitlab.idiap.ch/beat/beat.editor/-/issues/254PyPI classifier designation update for GPL v3 licenses2020-03-03T13:45:06ZFlavio TARSETTIPyPI classifier designation update for GPL v3 licensesSummary
PyPI has changed its classifier designation for GPL v3 licences
What is the current bug behavior?
The current bug is shown in this release pipeline:
https://gitlab.idiap.ch/beat/beat.editor/pipelines/37844
and specifically i...Summary
PyPI has changed its classifier designation for GPL v3 licences
What is the current bug behavior?
The current bug is shown in this release pipeline:
https://gitlab.idiap.ch/beat/beat.editor/pipelines/37844
and specifically in the following job
https://gitlab.idiap.ch/beat/beat.editor/-/jobs/191064
where an error is thrown:
```
requests.exceptions.HTTPError: 400 Client Error: Invalid value for classifiers.
Error: 'License :: OSI Approved :: GNU General Public License v3' is not a valid choice
for this field for url: https://upload.pypi.org/legacy/ 515
```
What is the expected correct behavior?
It shouldn't fail on this deployment part on PyPI
Relevant logs and/or screenshots
- https://gitlab.idiap.ch/beat/beat.editor/pipelines/37844
- https://gitlab.idiap.ch/beat/beat.editor/-/jobs/191064
Possible fixes
This faulty line in `setup.py`:
**"License :: OSI Approved :: GNU General Public License v3"**
should become:
**"License :: OSI Approved :: GNU General Public License v3 (GPLv3)"**Flavio TARSETTIFlavio TARSETTIhttps://gitlab.idiap.ch/beat/beat.editor/-/issues/253Known issue to track specific package version2020-03-02T16:54:48ZFlavio TARSETTIKnown issue to track specific package versionSummary
The known issue pointer should target the proper package version in the "about" dialog.
Related to https://gitlab.idiap.ch/beat/beat.editor/issues/252Summary
The known issue pointer should target the proper package version in the "about" dialog.
Related to https://gitlab.idiap.ch/beat/beat.editor/issues/252Flavio TARSETTIFlavio TARSETTIhttps://gitlab.idiap.ch/beat/beat.editor/-/issues/252Pointer to known issues in the editor "about" notice2020-03-02T15:55:43ZFlavio TARSETTIPointer to known issues in the editor "about" noticeSummary
A pointer indicating known issues should be given in the `"about"` notice of the editor applicationSummary
A pointer indicating known issues should be given in the `"about"` notice of the editor applicationFlavio TARSETTIFlavio TARSETTIhttps://gitlab.idiap.ch/beat/beat.editor/-/issues/251Toolchain scene refactoring2020-03-02T13:11:17ZFlavio TARSETTIToolchain scene refactoringSummary
The QGraphicsScene used for toolchains requires a refactoring.
In particular:
- a better naming of the class
- tests should be addedSummary
The QGraphicsScene used for toolchains requires a refactoring.
In particular:
- a better naming of the class
- tests should be addedFlavio TARSETTIFlavio TARSETTIhttps://gitlab.idiap.ch/beat/beat.editor/-/issues/250LICENSE.AGPL file location is wrong in conda recipe2019-11-15T14:07:37ZAndré AnjosLICENSE.AGPL file location is wrong in conda recipeIt should read `LICENSE.AGPL` instead of `../LICENSE.AGPL`.
The same should be propagated to all relevant packages.
See: bob/bob.devtools#44It should read `LICENSE.AGPL` instead of `../LICENSE.AGPL`.
The same should be propagated to all relevant packages.
See: bob/bob.devtools#44Samuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.editor/-/issues/249Nightlies are failing because of this package's tests2019-11-08T09:20:47ZAndré AnjosNightlies are failing because of this package's testsBoth linux builds are stuck and will stay like this until the timeout:
https://gitlab.idiap.ch/beat/beat.nightlies/pipelines/34701
@flavio.tarsetti: could you please check?Both linux builds are stuck and will stay like this until the timeout:
https://gitlab.idiap.ch/beat/beat.nightlies/pipelines/34701
@flavio.tarsetti: could you please check?Flavio 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 GAISThttps://gitlab.idiap.ch/beat/beat.editor/-/issues/247Sphinx errors during nightly builds2019-08-12T07:13:09ZAndré AnjosSphinx errors during nightly buildsThe version of Sphinx was updated to 2.x on the base software stack and, with that, there is a new error on the documentation (actually a warning, but it is in pedantic mode). For this reason, the building of the editor v1 failed, and s...The version of Sphinx was updated to 2.x on the base software stack and, with that, there is a new error on the documentation (actually a warning, but it is in pedantic mode). For this reason, the building of the editor v1 failed, and so did the nightlies.
To get a green nightly, we need to fix this.Flavio TARSETTIFlavio TARSETTIhttps://gitlab.idiap.ch/beat/beat.editor/-/issues/246Correct base types management in AssetModel2020-08-10T08:39:27ZSamuel GAISTCorrect base types management in AssetModelSummary
The DataFormat base types provided through AssetModel shall not be used everywhere a DataFormat is used.
An analysis must be done to determine where exactly it make sense to have them and also if they must be made availble toge...Summary
The DataFormat base types provided through AssetModel shall not be used everywhere a DataFormat is used.
An analysis must be done to determine where exactly it make sense to have them and also if they must be made availble together with the other Dataformats provided by the prefix.
AssetModel shall be purged from these types and a dedicated subclass created if it makes sense to provide them all in one or more places in the code.
Depending also on whether these base types should be the only type used, another model might be created or [QStringListModel](https://doc.qt.io/qt-5/qstringlistmodel.html) used directly in these cases.[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/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/243There is no way to close an asset without opening another one.2020-08-10T15:27:51ZZohreh MOSTAANIThere is no way to close an asset without opening another one.At the moment at all the times there should be one asset opened (except for when the editor starts).
It might be useful to add a button to close an asset without opening a new one. It might also be useful in the future if multiple insta...At the moment at all the times there should be one asset opened (except for when the editor starts).
It might be useful to add a button to close an asset without opening a new one. It might also be useful in the future if multiple instances/windows of editor are open.https://gitlab.idiap.ch/beat/beat.editor/-/issues/242Delete button does not ask for confirmation if you are deleting an asset that...2019-10-04T15:12:53ZZohreh MOSTAANIDelete button does not ask for confirmation if you are deleting an asset that is not being edited at the time.If you are editing an asset and delete the same asset the dialogue box says something like "you are about to delete the asset you are editing currently, are you sure", but if you try to delete another asset while you are still editing an...If you are editing an asset and delete the same asset the dialogue box says something like "you are about to delete the asset you are editing currently, are you sure", but if you try to delete another asset while you are still editing another asset (This is possible because you are able to borrows the files on the left of the editor window), it just deletes the asset without asking any confirmation. This is not good since users can delete some files by accident and there is no way to recover them from the editor at the moment (there is no undo).https://gitlab.idiap.ch/beat/beat.editor/-/issues/241Make the size of the dialogue boxes changable2020-02-26T11:01:22ZZohreh MOSTAANIMake the size of the dialogue boxes changableWhen you are saving an asset the name of the asset being saved is written on the top of the dialogue box in the format <username>/<asset_name>/<version> , which usually is a long string but the size of the dialogue box is very small and ...When you are saving an asset the name of the asset being saved is written on the top of the dialogue box in the format <username>/<asset_name>/<version> , which usually is a long string but the size of the dialogue box is very small and this string is not readable. Also the user cannot change the size of the box as well which means cannot read the name of the asset being saved. This can be problematic as explained in #230 (closed bug).
The dialogue box for deleting an asset is also fixed in size. At the moment there is no name on the top of the dialogue box but it may become necessary in the future.Flavio TARSETTIFlavio TARSETTIhttps://gitlab.idiap.ch/beat/beat.editor/-/issues/240ParameterWidget needs better size handling2019-07-02T08:56:34ZSamuel GAISTParameterWidget needs better size handlingSummary
ParameterWidget has way too much white space when showing "small" editors
Steps to reproduce
Open a plotter and look at the parameters
What is the current bug behavior?
Depending on the type of parameter and it's setup, th...Summary
ParameterWidget has way too much white space when showing "small" editors
Steps to reproduce
Open a plotter and look at the parameters
What is the current bug behavior?
Depending on the type of parameter and it's setup, there's too much vertical
space.
What is the expected correct behavior?
We should have the editor take just the height needed.
Possible fixes
The widget should be resized when the current editor changes[v2] 1 - Edition/Visualization for small editorsSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.editor/-/issues/239Library editor forces a dump of an optional key "uses:{}" for the available l...2020-05-28T10:57:29ZFlavio TARSETTILibrary editor forces a dump of an optional key "uses:{}" for the available libraries when the field is empty#### Summary
The library editor requires fixing. The key "uses" is set mandatory during the dump when it should actually be an optional field
#### Steps to reproduce
The bug is identified here:
https://gitlab.idiap.ch/beat/beat.edito...#### Summary
The library editor requires fixing. The key "uses" is set mandatory during the dump when it should actually be an optional field
#### Steps to reproduce
The bug is identified here:
https://gitlab.idiap.ch/beat/beat.editor/blob/v2/beat/editor/test/test_libraryeditor.py#L40
and explained in detail: https://gitlab.idiap.ch/beat/beat.core/merge_requests/79
#### What is the current bug behavior?
The current behavior forces the library to have a dump "uses" key
#### What is the expected correct behavior?
The schema of the library is explicit about it being an optional field. So if empty we should not get a "uses:{}" at the dump
The test needs to be fixed accordingly
#### Relevant code:
https://gitlab.idiap.ch/beat/beat.editor/blob/v2/beat/editor/test/test_libraryeditor.py#L40[v2] 1 - Edition/Visualization for small editorsSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.editor/-/issues/238disable focus for mouse wheel on the spinboxes2019-06-28T07:58:17ZZohreh MOSTAANIdisable focus for mouse wheel on the spinboxesThe issue is that when you are scrolling on an editor page that includes spinboxes (a big dataformat), the focus of the mouse can easily change to one of the spinboxes. You are scrolling down and suddenly it stops scrolling, by the time ...The issue is that when you are scrolling on an editor page that includes spinboxes (a big dataformat), the focus of the mouse can easily change to one of the spinboxes. You are scrolling down and suddenly it stops scrolling, by the time you realize why it is not scrolling the value of some of the spinboxes have already changed and it is safe to assume that user does not know the previous value!
If this focus functionality is disabled the problem will probably is solved.Samuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.editor/-/issues/237Improve remove/add button visuallization2020-06-19T14:52:24ZZohreh MOSTAANIImprove remove/add button visuallizationIt is not easy to distinguish which add/remove button is for which sub-category when there are many categories in an asset (such as a big confusing dataformat). This problem should be addressed properly. Maybe if we have different shades...It is not easy to distinguish which add/remove button is for which sub-category when there are many categories in an asset (such as a big confusing dataformat). This problem should be addressed properly. Maybe if we have different shades for the editor objects (see #235) This problem is solved automatically but there might be a better way.
Also at the moment the add button in the algorithm object is on the left but in the dataformat objects is on the right. The decision is to move all of them to the right.Samuel GAISTSamuel GAIST