CamiTK Community Edition issueshttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues2018-07-09T15:39:29+02:00https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/67Protocol file associated with the action state machine2018-07-09T15:39:29+02:00Emmanuel PromayonProtocol file associated with the action state machine## About you
CamiTK team member.
## Product
action state machine
## Overview
This is issue was created by splitting issue #57 originally submitted on bugzilla by Antoine Tacheau @tacheaua, 2017-09-11.
This issue is abo...## About you
CamiTK team member.
## Product
action state machine
## Overview
This is issue was created by splitting issue #57 originally submitted on bugzilla by Antoine Tacheau @tacheaua, 2017-09-11.
This issue is about providing an associated protocol file to enable double-click to start the action state machine from a desktop without using the command line.
> Currently, we need to open a terminal and type this kind of command to start asm:
>
> camitk-actionstatemachine -f <ProtocolFile> -o <LogFolder>
>
> Since Action State Machine can be used by 'basic user' to run new protocol, it would be easier if a launcher or an interface were available.
>
> ~~For instance:#~~
> ~~- a gui interface in order to select which protocol should be started~~
> ~~or~~
> a specific protocol file (only changing extension by .asm, .prot, .protocolASM ...) to be associated to asm executable. Thus, users only have to double click to start application
>
> -- Antoine Tacheau
## Hints
The best would probably be to :
- add another option to the command line `--protocol-file` (or something like that)
- parse the corresponding `.prot` file (or `.casm` of, as `.asm` extension is [already used a lot, especially for assembler](https://fileinfo.com/extension/asm) and the other suggestion is very looong!)
- a `.prot` can be a very simple file with
- first line: the filepath to the `.scxml`
- second line: filepath to the output directory
- add another page to the Qt Wizard describe above to ask the user if she/he wants to save a corresponding `.prot` for later reuse
- make sure that at file can be associated to the application (on windows reproduce what is done in camitk-imp: at first launch, ask the user if s⋅he wants `.prot` to be associated directly to the application).
- write a wiki documentation to show how to associate `.prot` files to the action state state machine for Windows, KDE and MacOS X
https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/54Improved ActionWidget2024-03-25T18:04:17+01:00Emmanuel PromayonImproved ActionWidget| | |
|--|--|
| **As a** | CEP developer |
| **I would like to** | change just the parameters tab of the action widget (and have more space for my action widget) |
| **So that** | I can deliver the same user experience (doc and informati...| | |
|--|--|
| **As a** | CEP developer |
| **I would like to** | change just the parameters tab of the action widget (and have more space for my action widget) |
| **So that** | I can deliver the same user experience (doc and information about selected target) without reimplementing everything |
## Description / Overview
This story is about improving the `ActionWidget` API/usage:
- It should be possible to get/set only the `QFrame` parameters section of default `ActionWidget` (and hence modifying just the "Parameters" part of the widget, see below)
![Screenshot_20180612_143335](/uploads/a1d13000f8029b6b73afde7bd9a97818/Screenshot_20180612_143335.png)
- It should be possible to easily access the frame itself in order to restrict the space used in the GUI (for instance in the action state machine, as in the screenshot below, should we use all this space for description and targets that nobody really look at) ?
![Screenshot_20180612_143650](/uploads/98f907763249155e8ae9f1b4314b8aea/Screenshot_20180612_143650.png)
- The `Description` / `Targets` / `Parameters` section should take less space (use stacked widget like in the mockup below? Tab widget?)
![Screenshot_20180612_160056](/uploads/d513f0839e4f0acb48fc44db33e97027/Screenshot_20180612_160056.png)
![Screenshot_20180612_160109](/uploads/919244814c8295d69b31f7066f52253c/Screenshot_20180612_160109.png)
## Hints
- Add `set/getFrame()` to `ActionWidget`
- modify action state machine to use the `getFrame()` not the full default widget
- rewrite default widget to take less space
## Acceptance test
- [ ] a tutorial showing a demo
- [ ] asm for reconstruction improve the space for parameter interaction
- [ ] Action API doc updated to show this usagehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/36Interface Data2018-06-13T10:41:45+02:00Emmanuel PromayonInterface Data| | |
|--|--|
| **As a** | CEP developer |
| **I would like to** | add easily manipulate array of data (values, signals, vectors...) to any type of component (not MeshComponent nor ImageComponent) |
| **So that** | I can visualize/inter...| | |
|--|--|
| **As a** | CEP developer |
| **I would like to** | add easily manipulate array of data (values, signals, vectors...) to any type of component (not MeshComponent nor ImageComponent) |
| **So that** | I can visualize/interact data as colors on a mesh, as graph/curve |
| **Epic/Topics** | Interface Data |
## Description / Overview
The epic is called "Interface Data" or how to include 1D temporal signal in CamiTK.
This is a new facet for `Component` that enables storage, manipulation, visualization and interaction with/of array of data. The idea is to offer data abstraction and minimal default behaviour for signal and temporal values.
In the design stage, first check:
- Check the Pulse project to check how they store the signals
- Check the work done by Nico (see `incubator-local/respirm` CEP) in order to handle 1D signal and their representation using a dedicated viewer based on vtkChart library (and some action to process them). In particular check the viewer and the defined actions.
- Check open-source application that help manipulate data and display charts to deduce best practices
- Check for standard in signal processing data format and processing library (if any)
One idea would be to be able to use a python interface/shell/script in order to process the signal directly from a console...
## Hints
As for any creation of interface in CamiTK, this can be done following these steps:
- Create a new interface that add the management of a list of `vtkDataArray` in `Component`
- Create the corresponding helper class
- Create the corresponding viewer (using vtkChart and the possibility to add data as if it was a live physiological signal) and integrate it to camitk-imp
- Create another viewer to display data in a table/spreadsheet
- Take into account the fact that `MeshComponent` can project the data as colors
- move addPointData/addCellData in `InterfaceGeometry` or to the new `InterfaceData` interface (may be use an enum for `FREE`, `ATTACHED_TO_CELLS`, `ATTACHED_TO_POINTS` etc...
## Acceptance tests
- [ ] a new tutorial component that shows how to add/remove/show these data in the new viewer
- [ ] a new tutorial MeshComponent that shows how data can be displayed directly _on_ the mesh surface
- [ ] a new tutorial that shows generates random value based on a sinus function to show how update/acquisition can be done
## Track
/label ~"Track Technology Integration"https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/30Easy action GUI/widget for specific properties2018-06-13T10:43:51+02:00Emmanuel PromayonEasy action GUI/widget for specific properties| | |
|--|--|
| **As a** | CEP developer |
| **I would like to** | easily add/easily manage specific high-level properties/parameters to my action |
| **So that** | my action source code is only focusing on the processing |
## Descript...| | |
|--|--|
| **As a** | CEP developer |
| **I would like to** | easily add/easily manage specific high-level properties/parameters to my action |
| **So that** | my action source code is only focusing on the processing |
## Description / Overview
This story is about having an easy way to declare and manage specific high level properties in actions.
In an `Action` derived class it should be easy to add properties (and automatically create their GUI) for the following:
- `QStringList` → dropdown list
- list of instanciated/available components (with possible restriction to components of a given type) → GUI = dropdown list
- list of `MedicalImageViewer` viewers → GUI = dropdown list
- button (name + icon + tristate or not + double state or not + slot to call) → GUI = `QPushButton` automatically added to the default `ActionWidget` that calls the slot.
Therefore it should be possible to directly write something like:
```cpp
// MyAction constructor
MyAction::MyAction(..) : .. {
...
QStringList myList;
myList << "A" << "B" << "C";
addParameters(new Property(tr("List of strings"), myList, ...);
Property *listOfComp = new Property(tr("Image 1", Property::LIST_OF_COMPONENT, ...);
listOfComp->setAttribute("componentName", "ImageComponent");
addParameters(listOfComp);
addParameters(new Property(tr("Viewer to show"), Property::LIST_OF_MEDICAL_VIEWERS, ...);
Property *pushMeProp = new Property(tr("Push Me"), SLOT(pushMeSlot()), ...);
pushMeProp->setAttribute("checkable",true);
pushMeProp->setAttribute("icon",QIcon(":/images/myIcon.png"));
addParameters(pushMeProp);
...
}
```
## Acceptance test
- [ ] there is a tutorial showing how to use these highlevel
- [ ] the Action and Property API documentation is updated
- [ ] the wizard allow for the creation of such properties
- [ ] the CEP generator is aware of these properties and there are new tests in the `cepgenerator/testing/cepgernerator-test.sh`
- [ ] any action in CamiTK CE that manages this type of high-level properties otherwise should use the new way