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/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/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/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