CamiTK Community Edition issueshttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues2024-03-25T18:19:08+01:00https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/183Update Windows toolchain and docker fo CI2024-03-25T18:19:08+01:00Emmanuel PromayonUpdate Windows toolchain and docker fo CI| | |
|--|--|
| **As a** | CamiTK developer |
| **I would like to** | have a new toolchain on windows and a new docker image for CI |
| **So that** | I spend less time on installing and building CamiTK CE |
| | |
|--|--|
| **As a** | CE...| | |
|--|--|
| **As a** | CamiTK developer |
| **I would like to** | have a new toolchain on windows and a new docker image for CI |
| **So that** | I spend less time on installing and building CamiTK CE |
| | |
|--|--|
| **As a** | CEP developer on Windows |
| **I would like to** | have a simpler way to install the toolchain and develop my extension |
| **So that** | I spend less time on the setup and have less difficulties to develop on Windows |
## Description / Overview
Windows setup is fastidious and can have side effect on the installation (or the local installation can have side effect on the CEP development, e.g. installation of some LaTeX software provides Qt DLL that conflict with the CamiTK setup).
Some package/dev environment setup systems exist on Windows
- [msys2](https://www.msys2.org/) has an [extensive list of available packages](https://github.com/msys2/MINGW-packages), and a [good documentation](https://www.msys2.org/docs/package-management/). The compiler is mingw64.
- chocolatey (that what is used at the moment). The compiler is MSVC
- [vcpkg](https://learn.microsoft.com/en-us/vcpkg/get_started/overview).
This issue contains many aspect and:
- must answer the question : Should we move to msys2 or vcpkg or stay on chocolatey+MSVC?
- must provide a new toolchain documentation
- must provide a new docker image for CI
- (if possible) must provide a new documentation on how to use the docker image to develop on windows without installing software
See:
- [msys2 description](https://www.msys2.org/docs/what-is-msys2/)
- [project that use msys2](https://www.msys2.org/docs/who-is-using-msys2/), to check how they use it, what's the impact on their toolchain, and how they manage their CI (e.g., [inkscape](https://wiki.inkscape.org/wiki/Compiling_Inkscape_on_Windows_with_MSYS2) and [inkscape CI on gitlab.com](https://gitlab.com/inkscape/inkscape/-/raw/master/buildtools/msys2installdeps.sh)).
- [dockerization tentative for msys2](https://github.com/Amitie10g/docker-msys2)
If MSys2 is adopted:
- All dependencies library should be available (xerces-c,...), including some that are not directly used in CCE but are known to be used/supported in CEPs (e.g., opencv, SDL2,...)
- MSC++ will not be used as the default compiler on windows (subsidiary question: does it have other side effects? Any impact on the future python binding?)
- that reinforce the recommendation of vscode as an ide on all platform (see #181), including windows [mingw for vscode documentation](https://code.visualstudio.com/docs/cpp/config-mingw#_adding-additional-cc-settings)
**Additional questions**
- impact CI performance (subsidiary question: is there a way to optimize the docker handling by windows? Is win11 better than win10 for handling containerized toolchain?)
- can the window docker image be used to build and run CEPs by CEP developers. That would certainly ease the setup process and will have zero impact on the developer installation. Iit is probably easy to build a CEP from vscode + devcontainer using the window docker image, but it might be harder/not possible/not efficient to run `camitk-imp` from the docker container → that remain to be tested!
- :warning: **CMake macros.** Some CamiTK CMake code (configuration and CI) depends on checking if the compiler is MSVC. There might be some problems to fix there as well if changing to mingw64.
- using mingw64 might automatically close #64 (declimport/declexport). But then another decision will have to be taken about what to do with legacy code (remove the macros for managing declimport/declexport or not). And also a decision has to be taken for using the CMake property from now on...
## Acceptance tests
- [ ] Internal document to explain the decision
- [ ] window docker image for CI (updated or renewed)
- [ ] re-generate the CamiTK5.2 package using the new image (to test the release process for future release)
- [ ] update website setup documentation
- [ ] update [support policy web page](https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/DevTeam/camitk-website/-/blob/master/content/en/docs/advanced%20topics/developers/support%20policy.md)
- [ ] in the `develop` branch check `CMakeLists.txt` for minimal version and check if update is required
- [ ] in the `develop` branch move version requirements for the tests (VTK and ITK version) and update test file if required. For instance : `component-stl-level3-2`, `vtkimage`...
- [ ] update release documentation to add a step that uses the Windows toolchain and solve the compiler/linker warnings before adding the release tag (same as the clang)
**Note** Use tag `:2025` for the image instead of `5.3` (change of docker image naming convention)Emmanuel PromayonEmmanuel Promayonhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/181VS Code extension pack and settings for CamiTK developers2024-03-25T15:25:09+01:00Emmanuel PromayonVS Code extension pack and settings for CamiTK developers| | |
|--|--|
| **As a** | CEP developer |
| **I would like to** | have guideline and default settings for Visual Studio Code / codium |
| **So that** | I can quickly start and efficiently develop my CamiTK extension |
## Description /...| | |
|--|--|
| **As a** | CEP developer |
| **I would like to** | have guideline and default settings for Visual Studio Code / codium |
| **So that** | I can quickly start and efficiently develop my CamiTK extension |
## Description / Overview
This should supersede Issue #143.
VS Code / Codium is more and more used among developers, including C++ developers. It has many advantages over previous recommended solution (e.g., KDevelop, Visual Studio):
- it supports both Linux and Windows the same way
- it is versatile as you can use it to write code, markdown documentation or report, article with LaTeX...
- it can be used to develop inside docker containers
- it integrates every tools that makes it easier for developer (debugger, git...)
[Check the google trend](https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F0134xwrk,%2Fm%2F01r_y0,%2Fm%2F08rjyp,%2Fm%2F063zx_g,%2Fg%2F11c3kh6nh5)
It would be nice for developers if the CamiTK team recommend a list of extension and/or provide a default `VS code` configuration file that sets everything up.
## Hints
List of currently used and recommended (to cleanup/update/verify/classify in subcategories):
- MS C/C++ / MS C/C++ Extension pack
- native debug
- CMake Tools and CMake
- astyle + astyle configuration (in `${workspaceRoot}/.vscode/astylerc`)
- TODO highlight
- MS Dev Containers
- Git : git graph ???, GitLab Workflow???, GitLens ???
We can also have recommandation for other categories such as: markdown preview enhanced, markdownlint, LTeX grammar check, Atom One light theme, better C++ syntax, bookmarks, code spell checker, docker, LaTeX Workshop, project manager, Paste image, how to install plantuml local server, ...
See also [old internal doc](https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/DevTeam/pilotage-technique/-/blob/e0f41e6493af51d73614f1a61932efee48b8ed0b/sp%C3%A9cifications/vs%20code/vs%20code.md)
## Acceptance tests
A progressive list of deliverables
- [ ] Website page describing the recommended extensions
- [ ] add the command to install the extensions (from the command line and from inside code) in the website page
- [ ] add the recommended way to install VS code and codium depending on the OS
- [ ] create a CamiTK extension pack [see this](https://code.visualstudio.com/blogs/2017/03/07/extension-pack-roundup) [or that](https://www.digitalocean.com/community/tutorials/how-to-create-an-extension-pack-for-visual-studio-code)
- [ ] configuration template in the CamiTK Community Edition source (something like `.vscode/.vscode-template` or at the user level in `~/.config`)
- [ ] configuration template `.devcontainer` for working inside docker containers
## Trackhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/143Visual studio code settings for CamiTK developers2024-03-25T15:25:09+01:00Manik BhattacharjeeVisual studio code settings for CamiTK developers| | |
|--|--|
| **As a** | CamiTK developer/CEP developer|
| **I would like to** | have good presets for visual studio code |
| **So that** | CamiTK development is easier (including coding style) |
## Description / Overview
Add to the ...| | |
|--|--|
| **As a** | CamiTK developer/CEP developer|
| **I would like to** | have good presets for visual studio code |
| **So that** | CamiTK development is easier (including coding style) |
## Description / Overview
Add to the repository vscode configuration files to help developers with their configuration, such as the version of c++ standard.
Coding style: it seems that Visual Code studio supports clang-format options to enforce a coding style.
Currently in [CamiTK Programming guidelines](https://camitk.imag.fr/guidelines/CamiTK%20Programming%20Guidelines%20v1.pdf) the style can be checked using astyle:
```astyle --style=java \
--break-closing-brackets \
--add-brackets \
--unpad-paren \
--pad-oper \
--pad-header \
--align-pointer=type \
--indent-switches \
-R *.cpp *.h
```
The equivalent should be written for clang-format.
## Hints
[This site explains multiple ways to set the style in Visual Studio](https://dev.to/dhanu0510/how-to-configure-c-code-formatting-in-visual-studio-code-4d5m)
## Acceptance tests
[Please enter acceptance tests as TODOs. Acceptance test explains how to test that this issue is solved]
- [ ] Coding style is enforced
- [ ] cppStandard version is set
- [ ] these files should be either templates (.vscode-recommended) or declared in a .gitignore file so that a developer's configuration is not committed by mistake.
## Track
## Misc
- Automatic subscription of issue creator:
**If appropriate, do not forget to mark this issue as "confidential"** by checking the corresponding tick box belowhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/109Wrong installation directory for libraries2024-02-23T11:13:30+01:00Theophile TiffetWrong installation directory for libraries## About you
Tiffet Théophile PhD student
## Overview
Variable CMAKE_INSTALL_LIBDIR and CMAKE_INSTALL_BINDIR are no respected during install, which can lead to problems on some distribution.
## Interpretation & Possible fixes
The var...## About you
Tiffet Théophile PhD student
## Overview
Variable CMAKE_INSTALL_LIBDIR and CMAKE_INSTALL_BINDIR are no respected during install, which can lead to problems on some distribution.
## Interpretation & Possible fixes
The variables CMAKE_INSTALL_LIBDIR and CMAKE_INSTALL_BINDIR should be used instead of hard coded path.
## CamiTK Version
Last develop version (933bc0c2)
---
**please do not remove anything below this line**CamiTK 4.2 Sprint # 3Emmanuel PromayonEmmanuel Promayonhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/133imp and actionstatemachine requires linking with specific viewers2023-11-29T11:23:11+01:00Emmanuel Promayonimp and actionstatemachine requires linking with specific viewers## About you
camitk developer
## Overview
imp and actionstatemachine requires linking with specific viewers.
This means they are _linked_ to for instance medicalimageviewer lib.
This is not admissible as this means LD_LIBRARY_PATH ha...## About you
camitk developer
## Overview
imp and actionstatemachine requires linking with specific viewers.
This means they are _linked_ to for instance medicalimageviewer lib.
This is not admissible as this means LD_LIBRARY_PATH has to be modified to include lib/camitk-x.y/viewers which is not a standard or easy thing to set.
## Steps to Reproduce
`ldd -r bin/camitk-imp` shows the dependencies
## Actual VS Expected Result
sdk applications should not have to be linked to viewers.
**Note** This might be ok for CEP applications (very rare case, see `tutorials/applications/fancy` for an example where this might be required).
## Relevant logs and/or screenshots
Test using docker:
```bash
$ docker pull gricad-registry.univ-grenoble-alpes.fr/camitk/camitk/camitk-lts:5.1
$ docker run --privileged=true --rm -v /tmp/.X11-unix:/tmp/.X11-unix -v ./build:/home/camitk/build -w /home/camitk/build -e "LD_LIBRARY_PATH=/home/camitk/build/lib" -e "DISPLAY=:0" -ti gricad-registry.univ-grenoble-alpes.fr/camitk/camitk/camitk-lts:5.1 bin/camitk-config --version
bin/camitk-config build using CamiTK 5.1.dev.develop.db3bf90b
$ docker run --privileged=true --rm -v /tmp/.X11-unix:/tmp/.X11-unix -v ./build:/home/camitk/build -w /home/camitk/build -e "LD_LIBRARY_PATH=/home/camitk/build/lib" -e "DISPLAY=:0" -ti gricad-registry.univ-grenoble-alpes.fr/camitk/camitk/camitk-lts:5.1 bin/camitk-imp --version
bin/camitk-imp: error while loading shared libraries: libactionviewer.so.5: cannot open shared object file: No such file or directory
```
## Interpretation & Possible fixes
For sdk application only user `Viewer` API and do not use specific method.
That might means a rewrite of `MedicalImageViewer::setToolbarAutoVisibility` and `MedicalImageViewer::setToolBarVisibility`
Even if this might mean few duplicated lines, check if it possible to also remove dependencies to Medical Image Viewer in `tutorials/applications/fancy` as well.
## CamiTK Version
CamiTK 5.1.dev.develop.db3bf90b
---
**please do not remove anything below this line**Emmanuel PromayonEmmanuel Promayonhttps://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/144Documentation issue2023-06-29T20:28:20+02:00Manik BhattacharjeeDocumentation issue**Note :** This is generic issue, please reopen it every time you need to correct any typo in or improve the documentation or comments.
There could be multiple branches opened for fixing this (recurrent) issue along the way.
**:warning...**Note :** This is generic issue, please reopen it every time you need to correct any typo in or improve the documentation or comments.
There could be multiple branches opened for fixing this (recurrent) issue along the way.
**:warning: When you reopen this issue please add a comment to specify current objective.**Manik BhattacharjeeManik Bhattacharjeehttps://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/125Packaging configuration does not define Core::libDir2021-05-03T17:50:24+02:00Emmanuel PromayonPackaging configuration does not define Core::libDir## Actual VS Expected Result
After configuration, build/CamiTKPackageVersion.h shows
```cpp
...
const char * Core::libDir = "";
```
Should be
```cpp
...
const char * Core::libDir = "lib";
```
## Interpretation & Possible fixes
`SDKC...## Actual VS Expected Result
After configuration, build/CamiTKPackageVersion.h shows
```cpp
...
const char * Core::libDir = "";
```
Should be
```cpp
...
const char * Core::libDir = "lib";
```
## Interpretation & Possible fixes
`SDKConfig.cmake` configure line is called before `GNUinstall` cmake script.
→ move the `configure_file` accordingly
## CamiTK Version
CamiTK 5.0.dev.develop.d0704b93Emmanuel PromayonEmmanuel Promayonhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/110Outdated documentation2021-01-18T17:29:51+01:00Theophile TiffetOutdated documentation## About you
Tiffet Théophile PhD student
## Product
Documentation for CamiTK
## Overview
Following the modification of the viewers, their doxygen documentation was not updated. Classes like PropertyExplorer, MedicalImageViewer and o...## About you
Tiffet Théophile PhD student
## Product
Documentation for CamiTK
## Overview
Following the modification of the viewers, their doxygen documentation was not updated. Classes like PropertyExplorer, MedicalImageViewer and others still are considered singleton with a getInstance static method in the documentation. This should be with the new way of refreshing them, getting access to them with the string you have to use.
A migration guide would also be welcome.
---
**please do not remove anything below this line**CamiTK 4.2 Sprint # 3Emmanuel PromayonEmmanuel Promayonhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/119CMake error when trying to install a CEP dependent on another CEP2021-01-14T14:13:23+01:00Emmanuel PromayonCMake error when trying to install a CEP dependent on another CEP## About you
CamiTK developer/maintainer
## Overview
In CamiTK community edition, the cep-generator test allows us to check that everything works when compiling a CEP that depends on CamiTK SDK
There is no test that check the third-le...## About you
CamiTK developer/maintainer
## Overview
In CamiTK community edition, the cep-generator test allows us to check that everything works when compiling a CEP that depends on CamiTK SDK
There is no test that check the third-level dependency, i.e., when trying to compile and install a CEP that depends on another CEP that depends on CamiTK SDK.
With recent version of CMake, warnings about missing autogen target became errors.
Now it is not possible to install a CEP that depends on another already installed CEP without a CMake error (although it is possible to build it...).
## Steps to Reproduce
This is quite long to reproduce:
1. build and install the latest develop version of CamiTK CE
2. create a CEP called level2cep that has dependencies to CamiTK SDK, e.g. that have a component that depends on medicalimageviewer or vtkmesh. This CEP should create a new component, lets call it level2comp
3. build an install level2cep
4. create a CEP called level3cep that has dependencies to level2Cp, e.g. that have a component that depends on level2comp
5. build level3cep
At configure time you should see an error:
```cmake
CMake Error in components/level2comp/CMakeLists.txt:
The dependency target "component-level2comp" of target
"component-level2comp_autogen" does not exist.
```
BUT the build will finish and everything will work
6. try to install level3cep, you you will get the same error but the install will fail.
## Actual VS Expected Result
There should be no error and the the install should work.
## Interpretation & Possible fixes
CMake camitk_extension macro should take into account the fact that if a target is not found, it should be declared as imported.
Possible fix: add a test in camitk_extension to check if a target exist or not using `if (NOT TARGET ...)`
**Caveat:** using `if (NOT TARGET ...)` will not be able to distinguish between external targets and local targets that are not yet declared in the configuration process.
## CamiTK Version
CamiTK 4.2.dev.develop.ae2812e8
---
**please do not remove anything below this line**CamiTK 4.2 Sprint # 3Emmanuel PromayonEmmanuel Promayonhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/60Developer documentation for MainWindow2020-10-06T16:50:16+02:00Emmanuel PromayonDeveloper documentation for MainWindow## About you:
Submitted by Guillaume Custillon on Bugzilla, 2014-04-07
## Product:
CamiTK CE (SDK)
## Overview:
> The global documentation for MainWindow is not enough.
> It would be a good idea to...## About you:
Submitted by Guillaume Custillon on Bugzilla, 2014-04-07
## Product:
CamiTK CE (SDK)
## Overview:
> The global documentation for MainWindow is not enough.
> It would be a good idea to write a more detailed one (listing step by step what you have to do to create a MainWindow, ie how to add viewers etc…).
> This could be added in the global documentation for MyMainWindow or maybe in a wiki pagehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/73Procedure entry point not located when building a CEP from Sources with Cmake2020-06-15T10:53:29+02:00Guillaume LapougeProcedure entry point not located when building a CEP from Sources with Cmake## About you
PhD Student at TIMC-IMAG, I work on CamiTK for needle steering
## Overview
On windows 10 64bits (Family edition) with CamiTK 4.1.2 successfully installed with the community package.
Cmake version 3.9.6, QT 5.6.1.
Any CEP w...## About you
PhD Student at TIMC-IMAG, I work on CamiTK for needle steering
## Overview
On windows 10 64bits (Family edition) with CamiTK 4.1.2 successfully installed with the community package.
Cmake version 3.9.6, QT 5.6.1.
Any CEP won't be built by CMAKE. Windows displays an error "Procedure entry point not located" concerning some QT5 dlls.
## Steps to Reproduce
See above
## Actual VS Expected Result
We expect the CEP to be built because CamiTK was sucessfully installed with the same softwares. But Cmake displays an error before even building the project.
## Relevant logs and/or screenshots
![issueCamiTK](/uploads/7a66ee2d6238455af656ada8ee8a7ca5/issueCamiTK.png)
## Interpretation & Possible fixes
My interpretation is that the QT dll in QT 5.6.1 install folder are not found by Cmake.
Instead, Cmake seems to use the QT .dll files at \CmakeInstallFolder\CMake\bin.
A fix is to force Cmake to use the right dlls by pasting them in the folder mentioned above, replacing the old ones.
From QtInstallFolder\Qt5.6.1\5.6\msvc2015_64\bin, copy the following files :
Qt5Core.dll
Qt5Gui.dll
Qt5Widgets.dll
Qt5Xml.dll
To replace those in \CmakeInstallFolder\CMake\bin. (Make a copy of the old ones for more safety).
## CamiTK Version
CamiTK Version:
- CamiTK version........................... CamiTK 4.1.2
- CamiTK Short Version..................... camitk-4.1
- CamiTK SO NAME........................... 4
- Operating System......................... WIN32
- Build type............................... RELEASE
- QT Version............................... 5.6.1
- VTK Version.............................. 6.3.0
- Global Installation Directory [G]........ D:/dev/CamiTK/CamiTK-4.1.2/install
- Local Installation Directory [L]......... C:/Users/guill/AppData/Roaming/CamiTK
- Current Working Directory [W]............ D:/dev/CamiTK/CamiTK-4.1.2/install/bin
- Test Data Directory...................... D:/dev/CamiTK/CamiTK-4.1.2/install/share/camitk-4.1/testdata
- Component Extension Directories.......... D:/dev/CamiTK/CamiTK-4.1.2/install/lib/camitk-4.1/components
- Action Extension Directories............. D:/dev/CamiTK/CamiTK-4.1.2/install/lib/camitk-4.1/actions
- Number of Component Extensions........... 11 (locations: 11 global, 0 local, 0 in working directory, 0 manually installed by user)
- Number of File Extensions Supported...... 34
- Number of Action Extensions.............. 19 (locations: 19 global, 0 local, 0 in working directory, 0 manually installed by user)
- Number of Actions........................ 91
- Registered components:
- [G] Alias Wavefront OBJ Component...... obj
- [G] ItkImages Component................ hdr, spr, gipl, pic, lsm, nrrd, hdr.gz, nii, nii.gz, img, img.gz
- [G] MML Component...................... mml, scn
- [G] Msh Component...................... msh
- [G] Off Component...................... off
- [G] PML Component...................... pml
- [G] STL Component...................... stl, STL
- [G] VRML 2 Component................... vrml, wrl
- [G] VTK Component...................... vtk
- [G] vtkImages Component................ jpg, png, tiff, tif, bmp, pbm, pgm, ppm, mhd, mha, raw
- [G] DICOM.............................. directory
- Registered actions:
- [G] Application Level Actions.......... 21 actions
- [G] Basic Mesh Extension............... 9 actions
- [G] Basic Topology..................... 2 actions
- [G] BoxVOIExtension.................... 1 actions
- [G] Frame Edition Extension............ 1 actions
- [G] ITK Filters........................ 14 actions
- [G] ITK Segmentation................... 3 actions
- [G] Image LUT.......................... 1 actions
- [G] ImageAcquisitionActionExtension.... 7 actions
- [G] MML................................ 2 actions
- [G] Mesh Processing.................... 17 actions
- [G] MultiPickingExtension.............. 1 actions
- [G] PMLExploreExtension................ 2 actions
- [G] Pixel Color Changer................ 1 actions
- [G] Reconstruction..................... 1 actions
- [G] Reorient Image Extension........... 1 actions
- [G] ResampleExtension.................. 1 actions
- [G] ShowIn3DExtension.................. 5 actions
- [G] VolumeRenderingExtension........... 1 actions
---
**please do not remove anything below this line**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