CamiTK Community Edition issueshttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues2018-06-13T10:43:51+02:00https://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
https://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/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/59Auto center option in InteractiveViewer2018-06-15T18:17:15+02:00Emmanuel PromayonAuto center option in InteractiveViewer## About you
This is a feature request that summarizes two bugs submitted on the old bugzilla:
- "InteractiveViewer option for specifying whether the scene must be centered when a Component is added" submitted by Hadrien Oliveri on 2015...## About you
This is a feature request that summarizes two bugs submitted on the old bugzilla:
- "InteractiveViewer option for specifying whether the scene must be centered when a Component is added" submitted by Hadrien Oliveri on 2015-07-07
- "Impossible to scroll through a zoomed image without the image automatically de-zooming" submitted by Nikolai on 2015-01-16
## Product:
imp
## Overview:
### Hadrien's submission
> Hello everyone,
> I'm developping a surgery simulator, and I need to add Components during the simulation. By default, the scene is
> recentered by the InteractiveViewer each time a Component is added (which is quite annoying). I modified this locally in
> my sdk and it works well for my ad hoc needs.
>
> I would be great if recentering the scene by default could be specified in the Imp user preferences for example.
>
> Thank you
>
> -- Hadrien Oliveri
### Nikolai's submission
> Imp de-zooms automatically when it's not expected. In this case, the 2D medical viewer panes de-zoom when you try to scroll through the image's volume with the vertical slider.
>
>
> Steps to Reproduce:
> Open Imp. Open any 3D image. Zoom in on any of the 2D viewers using the scroll wheel of your mouse. Move the vertical slider to another image plane. You will see the viewer de-zoom automatically.
>
>
> The viewer should stay zoomed while scrolling with the sliders.
>
> -- Nikolai
## Interpretation & Possible fixes
Both problems can be solved by implementing a special "Auto Center" option for the `InteractiveViewer`s.
Auto center
- [ ] When a new component is loaded (default is yes)
- [ ] When a slice is changed (default is yes)
As well as a "Center" Icon on the toolbar or the slice viewer side bar.
Depends on #17 https://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/72use setProperty with QString instead of char*2020-05-18T14:55:02+02:00Matthias Tummersuse setProperty with QString instead of char*| | |
|--|--|
| **As a** | CEP developer |
| **I would like** | a `setProperty` with `const QString name` instead of `const char * name` |
| **To** | improve camitk code consistency |
| **Epic/Topics** | Property setProperty QString char...| | |
|--|--|
| **As a** | CEP developer |
| **I would like** | a `setProperty` with `const QString name` instead of `const char * name` |
| **To** | improve camitk code consistency |
| **Epic/Topics** | Property setProperty QString char* |
## Description / Overview
I noticed that the `QObject::setProperty` method prototype demands a `const char *` type for the first argument whereas the `camitk::Property` constructor and the `getProperty` method use a `QString` type.
I think it might be a good idea to implement a method looking like
```cpp
//PropertyObject.h
virtual bool setProperty(const QString name, const QVariant &value);
```
```cpp
//PropertyObject.cpp
bool PropertyObject::setProperty(const QString name, const QVariant &value) {
if (propertiesMap.contains(name)) {
return setProperty(name.toStdString().c_str(), value);
}
else {
return false;
}
}
```
,
to be re-implemented in component and action.
(just like `getPropertyValue` (which I think should be re-implemented in component and action too (for the same reason)))
This would allow manipulating camitk properties only with QStrings and not with a mix of qstrings and char* types depending on the method being used.
## Acceptance tests
- **SetProperty works with QString**
One is able to set a property with the setProperty method using a QSting for the first argument
- **All uses of setProperty in CamiTK and CEPs are updated**
CamiTK and CEPs compile without errors regarding the setProperty method
## Track
One (or two) of:
## Misc
- Automatic subscription of issue creator:
**Do not forget to mark this issue as "confidential"** by checking the tick box below (if appropriate)https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/101viewer extension dependencies in wizard2023-06-02T16:49:24+02:00Maxime Calkaviewer extension dependencies in wizard## About you
Occasional CamiTK developer
## Product
Wizard
## Overview
Add in the dependencies of the extension the possibilities to link a viewer extension.
## Relevant logs and/or screenshots
Already implemented:
![image](/uploa...## About you
Occasional CamiTK developer
## Product
Wizard
## Overview
Add in the dependencies of the extension the possibilities to link a viewer extension.
## Relevant logs and/or screenshots
Already implemented:
![image](/uploads/d5dac9ba6884a5565013cbc41f370457/image.png)
Needed:
![image](/uploads/4c4851f8c2277b4c451ecd4129a12339/image.png)Maxime CalkaMaxime Calkahttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/132Option to highlight selected object by silhouette2023-04-21T19:56:41+02:00Manik BhattacharjeeOption to highlight selected object by silhouette## About you
CamiTK developer
## Product
Core in InteractiveViewer.
## Overview
In the main viewer, unselected elements are transparent, selected elements are not.
Add an option to show unselected elements as non-transparent, and selec...## About you
CamiTK developer
## Product
Core in InteractiveViewer.
## Overview
In the main viewer, unselected elements are transparent, selected elements are not.
Add an option to show unselected elements as non-transparent, and selected elements with an highlighted sihouette.
This is identical to [the VTK Silhouette example](https://kitware.github.io/vtk-examples/site/Cxx/Picking/HighlightWithSilhouette/)
---
**please do not remove anything below this line**Manik BhattacharjeeManik Bhattacharjeehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/138Add support for RGBA color2023-06-05T17:16:25+02:00Manik BhattacharjeeAdd support for RGBA color## About you
CamiTK developer
## Product
MeshComponent
## Overview
MeshComponent can have associated data. If the display mode is COLOR, the data is read as RGB data.
If there is a 4th dimension (A for alpha transparency), this is no...## About you
CamiTK developer
## Product
MeshComponent
## Overview
MeshComponent can have associated data. If the display mode is COLOR, the data is read as RGB data.
If there is a 4th dimension (A for alpha transparency), this is not supported.
It should be checked whether data works if it is encoded as:
- double/float between 0 and 1,
- int 8/16/32 bits in their respective range
## Relevant logs and/or screenshots
Check commit d827e23daf036652c10657bd57f12d0819ba0891
In libraries/core/mesh/MeshComponent.cpp
`colorArrayToDisplay->SetTuple3(i, val[0], val[1], val[2]);`
should work when there are 4 values with setTuple4. Hopefully VTK would use that as RGBA.
---
**please do not remove anything below this line**Manik BhattacharjeeManik Bhattacharjeehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/139CamiTK does not read OBJ material file2023-06-05T17:22:36+02:00Manik BhattacharjeeCamiTK does not read OBJ material file## About you
CamiTK developer
## Product
sdk/obj/ObjComponent
## Overview
The OBJ file format can be associated with a .mtl file that store the material (RGBA color). This is ignored by CamiTK.
## Relevant logs and/or screenshots
V...## About you
CamiTK developer
## Product
sdk/obj/ObjComponent
## Overview
The OBJ file format can be associated with a .mtl file that store the material (RGBA color). This is ignored by CamiTK.
## Relevant logs and/or screenshots
VTK has two objects to read obj files: CamiTK should use VtkObjImporter (and not VtkObjReader) and use its support for mtl files.
A test object can be easily generated in Blender (standard cube + material exported as obj file).
---
**please do not remove anything below this line**Manik BhattacharjeeManik Bhattacharjeehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/140Better LUT editor, standard LUT should be provided as well2024-03-25T17:37:38+01:00Manik BhattacharjeeBetter LUT editor, standard LUT should be provided as well## About you
CamiTK developer
## Product
sdk/actions/image/imagelut
## Overview
The LUT editor only allows to choose one color (changing the first color does nothing) and go from black to that color.
There is no way to create a LUT t...## About you
CamiTK developer
## Product
sdk/actions/image/imagelut
## Overview
The LUT editor only allows to choose one color (changing the first color does nothing) and go from black to that color.
There is no way to create a LUT that goes from blue to yellow to red for example, and that should be possible.
We should also provide a list of "standard" LUTs, maybe taken from another opensource project (Brainvisa/Anatomist ?).
The same editor could be used for the 3D rendering widget as well if we can also set transparency (RGBA) of the reference values
Saving a user's custom LUTs would be useful too.
To avoid the UI being too complex,
- use one tab to select a palette and set window level and width (adapted to the range of the image type - e.g. 0-65535 for uint16 or -2B/+2B for int32, not 0-255 in all cases)
- use another tab to create a new palette
## Relevant logs and/or screenshots
BrainVisa/Anatomist palette system: https://brainvisa.info/anatomist-5.0/user_doc/anatomist_tutorial.html#modification-of-color-palette
---
**please do not remove anything below this line**Manik BhattacharjeeManik Bhattacharjeehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/141Add icon next to components to show/hide components in viewers2023-11-24T19:10:15+01:00Manik BhattacharjeeAdd icon next to components to show/hide components in viewers## About you
CamiTK developer
## Product
Main IMP interface - Component explorer
## Overview
In the list of components in camitk-imp, it would be useful to have an eye icon next to the component's name to click on to show or hide co...## About you
CamiTK developer
## Product
Main IMP interface - Component explorer
## Overview
In the list of components in camitk-imp, it would be useful to have an eye icon next to the component's name to click on to show or hide components in views.
As visibility depends on the view:
- should we add a ViewerExplorer in IMP that would allow to select views (adding or removing components from views before setting visibility,
- just show/hide on all views ?
- Allow drag and drop of a component into a viewer to make it visible in that viewer.
## Relevant logs and/or screenshots
Eye icons that are already present in CamiTK: sdk/libraries/core/resources/oxygen_icons/actions/layer-visible-on.png
---
**please do not remove anything below this line**Manik BhattacharjeeManik Bhattacharjeehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/142Toolbar for each viewer2023-06-14T08:19:10+02:00Manik BhattacharjeeToolbar for each viewer## About you
CamiTK developer
## Product
IMP UI and Viewers
## Overview
The main toolbar does not apply to all viewers, which is confusing, and does not allow buttons specific to a viewer (e.g. display mode).
Code structure is alread...## About you
CamiTK developer
## Product
IMP UI and Viewers
## Overview
The main toolbar does not apply to all viewers, which is confusing, and does not allow buttons specific to a viewer (e.g. display mode).
Code structure is already developed with viewer-specific toolbars in mind.
---
**please do not remove anything below this line**Manik BhattacharjeeManik Bhattacharjeehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/166Python bindings: Python CEP and scripting2023-10-13T18:11:11+02:00Manik BhattacharjeePython bindings: Python CEP and scripting## About you
CamiTK developers
## Product
CamiTK
## Overview
Allow Python CEP and Python scripting
---
**please do not remove anything below this line**## About you
CamiTK developers
## Product
CamiTK
## Overview
Allow Python CEP and Python scripting
---
**please do not remove anything below this line**Emmanuel PromayonEmmanuel Promayonhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/167ITK Registration Action2023-10-26T16:58:56+02:00Celine FouardITK Registration Action| | |
|--|--|
| **As a** | CamiTK User / Student |
| **I would like to** | Use basic registration technics to align 2 images |
| **So that** | I could visualize registration results directly on CamiTK |
| **Epic/Topics** | Integrate ITK ...| | |
|--|--|
| **As a** | CamiTK User / Student |
| **I would like to** | Use basic registration technics to align 2 images |
| **So that** | I could visualize registration results directly on CamiTK |
| **Epic/Topics** | Integrate ITK Registration into CamiTK |
## Description / Overview
Select mandatory registration parameters on an Action interface. Apply registration
## Acceptance tests
[Please enter acceptance tests as TODOs. Acceptance test explains how to test that this issue is solved]
- [ ] [Test 1]
- [ ] [Test 2]
- [ ] [...]
## Track
[Please keep only one of the following label]
## Misc
- Automatic subscription of issue creator:
**If appropriate, do not forget to mark this issue as "confidential"** by checking the corresponding tick box belowCeline FouardCeline Fouardhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/169add dbus connection2023-10-29T13:49:12+01:00Emmanuel Promayonadd dbus connection## About you
CamiTK dev
## Product
CamiTK Core / Application
## Overview
Issue #168 was not detected during configure/make/test as it is not possible to set a test where an application that starts a user interaction loop would be ru...## About you
CamiTK dev
## Product
CamiTK Core / Application
## Overview
Issue #168 was not detected during configure/make/test as it is not possible to set a test where an application that starts a user interaction loop would be run and stopped automatically after a while. For example, in the case of `camitk-fancy` that would have allowed for a simple start and exit. In the presence of a bug similar to #168, the test would then have failed.
A possible way of offering extended testing for application would be to add the possibility for any CamiTK application to listen to dbus messages.
- it would then be possible to send message from outside the application (e.g. a shell, a test script or program...) such as "run action `Quit`".
- it would also add the **great** advantage of opening a whole lot of testing and automation. For instance by sending message analog to state in the action state machine (e.g. by sending XML/json message containing the action to apply and its parameter).
## Relevant logs and/or screenshots
### Adding dbus message support in CamiTK::Application
For instance by using:
```cpp
QDBusConnection::sessionBus().connect(QString(), QString(), "camitk.action", "apply", this, SLOT(applyActionFromDBus(QString)));
...
void Application::applyActionFromDBus(const QString &message) {
if(message=="...") {
...
}
}
```
### From the test application
```cpp
QProcess myProcess;
myProcess.start("camitk-fancy", "");
if (!myProcess.waitForStarted())
return false;
QDBusMessage msg = QDBusMessage::createSignal("/", "camitk.action", "apply");
message="Quit"
QDBusConnection::sessionBus().send(msg);
if (!myProcess.waitForFinished())
return false;
```
**Note**
DBus is supported on Linux desktops by default. A [windows port exists](https://www.freedesktop.org/wiki/Software/dbus/#download) but this need further checks.
### dbus not allowed by default
For security reason, the default behaviour should be _not_ to listen to DBus, and flag `--dbus` should be added to the arguments to enable the feature in the application.
### See also
[KDE doc for creating dbus interface](https://develop.kde.org/docs/features/d-bus/creating_dbus_interfaces/)
---https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/178Pick a point in 3D Viewer, view a 3D cursor2024-01-31T18:55:06+01:00Manik BhattacharjeePick a point in 3D Viewer, view a 3D cursor## About you
CamiTK developer, from multiple users' wishlist.
## Product
Medical Image Viewer, 3D Viewer
## Overview
Currently, the user cannot ctrl+click on a point in the 3D Viewer (except to select a part of a Mesh), and the curre...## About you
CamiTK developer, from multiple users' wishlist.
## Product
Medical Image Viewer, 3D Viewer
## Overview
Currently, the user cannot ctrl+click on a point in the 3D Viewer (except to select a part of a Mesh), and the currently selected point is not visible in the 3D View.
- The users would like to be able to click on an ImageComponent to set the coordinates of a point, like when using Ctrl+Click on 2D Views.
- This should also work on a MeshComponent.
- Showing the position of this point as a 3D cursor (such as a 3D cross) would be a plus.
- Clicking on an Actor could also be used to select components (e.g. clicking on a mesh should select the associated mesh component)
---
**please do not remove anything below this line**https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/179Persistence: select parts to save, support Action properties, automatic actio...2024-03-26T19:15:48+01:00Manik BhattacharjeePersistence: select parts to save, support Action properties, automatic action replay and processing scenarios in camitk files## About you
CamiTK developer
## Product
PersistenceManager and Actions
## Overview
- PersistenceManager should allow to select which parts to save in saveWorkspace, maybe with flags (components/actions/history/mainwindow/viewers...)...## About you
CamiTK developer
## Product
PersistenceManager and Actions
## Overview
- PersistenceManager should allow to select which parts to save in saveWorkspace, maybe with flags (components/actions/history/mainwindow/viewers...)
- Action properties should be loaded without causing a crash: add a flag to Action to say whether they support parameter reloading
- Actions should specify (with a flag) whether they should be replayed (e.g. Mesh Projection: when the workspace is loaded, we want to show again the mesh projections, SmoothingFilter should be re-applied to show smooth meshes)
- Processing scenarios and History support should be added in CamiTK files and saveWorkspace, with a corresponding load function.
- Add an "Export Workspace" that saves the workspace in a directory and "save as" all components in this directory. This avoids the problem of unsaved components when saving a workspace (e.g. with CEP Focus, ultrasound acquisitions can produce many volume images, and the user wants to save everything without entering a filename for each component, so exporting the whole workspace, components included would be useful)
---
**please do not remove anything below this line**Manik BhattacharjeeManik Bhattacharjeehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/180Simplify CamiTKVersion.h management2024-02-23T11:20:59+01:00Emmanuel PromayonSimplify CamiTKVersion.h management| | |
|--|--|
| **As a** | CamiTK developer and packager |
| **I would like to** | simplify the release and packaging process |
| **So that** | it would be easier to publish and package a new version |
| **Epic/Topics** | release managem...| | |
|--|--|
| **As a** | CamiTK developer and packager |
| **I would like to** | simplify the release and packaging process |
| **So that** | it would be easier to publish and package a new version |
| **Epic/Topics** | release management |
## Description / Overview
This point for this issue is:
- gather explanation about/rationale behind the existence of `CamiTKVersion.h` and `CamiTKVersion.h.in` file
- explain some consequence of the existence of this file
- work on how it can be simplified
## Hints
`CamiTKVersion.h` contains static information about the version number, debug postfix and `libDir`.
This file generates some complicated maneuvers during release management and packaging (see below).
### Some background on plugins
- CamiTK has a core library and uses plugins to add I/O (components), processing (actions) and viewer functionalities
- the plugins are made available using .so stored in "camitk repository", a directory that has a specific structure with subdirectories to sort plugins depending on their nature (actions, components, viewers)
- at run time, the core library looks into different paths for locating the existing camitk repositories (working directory, user installed, locally installed, or globally installed) in order to dynamically load all the available plugins.
- The libDir variable is used to check the camitk repository paths, that should all be ending with "some/path/" + libDir + "/camitk-x.y" (where x.y are major.minor camitk version numbers).
- The CamiTKVersion.h header file is used to specify this statically.
- On the upstream develop branch, libDir is generated at configure time by CMake, using the CMAKE_INSTALL_LIBDIR variable which is either set to "lib/ARCH" (if CMAKE_INSTALL_PATH is set to "/usr") or to just "lib/" (if CMAKE_INSTALL_PATH is empty).
- on the upstream master branch (the stable version, used to generate the tar ball), this is fixed to "lib". **TODO: describe rationale behind this**
### Generated burden
It might not be the best way to proceed, it is a bit complicated... That's what we came up with at the time (pre 2011) to answer to the following support constraints :
- multiple os,
- multiple camitk repositories,
- and multiple build situation (inbuild, sdk, install, cep dev)
It looks more like technical debt and could probably be simplified as it impact
- the release management process
- the packaging process (s.g. during 5.2 release `CamiTKVersion.h` was different on debian salsa master and in the upstream tarball), see also d/r and the line that uses `sed` to correct the file on debian...
### Note on `libDir` introduction in CamiTK version
`libDir` in CamiTKVersion was introduced #109 and #117 (commit de1794622009c4edd6cf4220773b61dbd644c37e) in order to support gentoo, and was later modified to take into account more situations:
- lib (default)
- lib64 (used on some Linux/platform)
- lib/<multiarch-tuple> (on Debian)
### Fixing this issue
Fixing this issue can be done either by
- option 1: confirming that a static `CamiTKVersion.h` (part of all of it) is required in `master`
- option 2: removing `CamiTKVersion.h` in master and generated release version tarball
## Acceptance tests
- [ ] option 1: better documentation to explain why a static `CamiTKVersion.h` is required
- [ ] option 2: a branch fixing this issue is merged (therefore CI passed)
- [ ] option 2: successful debian packaging process test
## Track
## Misc
- Automatic subscription of issue creator: