dtk issueshttps://gitlab.inria.fr/dtk/dtk/-/issues2020-05-04T11:08:28+02:00https://gitlab.inria.fr/dtk/dtk/-/issues/44Warning about dtkComposerScenePort::type()2020-05-04T11:08:28+02:00RINEAU LaurentWarning about dtkComposerScenePort::type()During the development of `dtk-continuous-geometry` I found that warning:
```
dtk/src/dtkComposer/dtkComposerScenePort.h:41:32: warning: 'dtkComposerScenePort::type' hides overloaded virtual function [-Woverloaded-virtual]
dtkCompose...During the development of `dtk-continuous-geometry` I found that warning:
```
dtk/src/dtkComposer/dtkComposerScenePort.h:41:32: warning: 'dtkComposerScenePort::type' hides overloaded virtual function [-Woverloaded-virtual]
dtkComposerScenePort::Type type(void);
^
/usr/include/qt5/QtWidgets/qgraphicsitem.h:421:17: note: hidden overloaded virtual function 'QGraphicsItem::type' declared here: different return type ('int' vs 'dtkComposerScenePort::Type')
virtual int type() const;
^
```
That is annoying, and I think it cannot be fixed easily. I my opinion, that function `type()`
should be renamed to something like `portType()`, but that will have impact on all pieces of code using that API.https://gitlab.inria.fr/dtk/dtk/-/issues/42Supress extracted source tree and switch to new implementation scheme.2018-07-18T14:19:32+02:00Julien WintzSupress extracted source tree and switch to new implementation scheme.2.0.0Julien WintzJulien Wintzhttps://gitlab.inria.fr/dtk/dtk/-/issues/41Extract fonts and widgets layers from dtk-visualization2018-05-14T16:24:55+02:00Julien WintzExtract fonts and widgets layers from dtk-visualization- See https://gitlab.inria.fr/dtk/dtk-fonts
- See https://gitlab.inria.fr/dtk/dtk-widgets- See https://gitlab.inria.fr/dtk/dtk-fonts
- See https://gitlab.inria.fr/dtk/dtk-widgets2.0.0Julien WintzJulien Wintzhttps://gitlab.inria.fr/dtk/dtk/-/issues/40Remove ugly widget factory to replace it by a more robust system2018-05-14T16:26:23+02:00KLOCZKO ThibaudRemove ugly widget factory to replace it by a more robust system## Goal
Enable plugins that have specific setters and getters to be handled in the composer through widget editors.
## Summary of the new system
### Modifications in `dtkCore`
In `dtkCorePluginFactory`, add of method to recor...## Goal
Enable plugins that have specific setters and getters to be handled in the composer through widget editors.
## Summary of the new system
### Modifications in `dtkCore`
In `dtkCorePluginFactory`, add of method to record a widget_creator function and to create the widget using such a function.
As one only uses pointers to `QWidget`, no link to neither inclusion of QtWidgets is required, thus avoiding spurious dependency.
### Addition in `dtkCore`
* [x] `dtkCorePluginWidgetManager` is a singleton that stores a map between concept objects encapsulated within a `QVariant` and widgets that have to be provided by the plugins.
### Consequences for `dtkComposer`
As a result, one is now able to factorize into `dtkComposerNodeObject` the management of the editor widget. Code is as follows:
```cpp
template <typename T> inline QWidget *dtkComposerNodeObject<T>::editor(void)
{
if (!m_factory) {
return nullptr;
}
QVariant v = dtkMetaType::variantFromValue(this->object());
QWidget *w = dtkCorePluginWidgetManager::instance().widget(v);
if (!w) {
w = m_factory->createWidget(m_implementation);
if (w) {
dtkCorePluginWidgetManager::instance().add(v, w);
}
}
return w;
}
```
First, one encapsulates the object into a `QVariant` so that one can ask the `dtkCorePluginWidgetManager` for a widget associated with the current object. If the widget exists, it is returned.
Else, one creates the widget using the factory and the name of the implementation of the current object.
When the creation is OK, the couple `(QVariant, QWidget*)` is added to the `dtkCorePluginWidgetManager`.
### Connection with the plugins
When one adds the couple `(QVariant, QWidget*)` in the `dtkCorePluginWidgetManager`, a signal `added(const QVariant&, QWidget*)` is emitted.
This signal can be connected to the widget provided by the plugin in order to get the instance of the object into the widget and makes connections between the specific setters and getters of the object and its dedicated widget.
For instance, let us consider the plugin `dtkVtkMeshingFilterPlugin` that implement the concept `dtkAbstractMeshingFilter` of `dtkImagingFilters` layer. The implementation has the following specific setter method:
```cpp
class dtkVtkMeshingFilter : public dtkAbstractMeshingFilter
{
...
public:
void setDecimate(bool decimate);
...
};
```
A widget has been created to handle this parameter through the composer editor:
```cpp
#pragma once
#include <QtWidgets>
namespace Ui {
class dtkVtkMeshingFilterWidget;
}
class dtkVtkMeshingFilterWidget : public QWidget
{
public:
dtkVtkMeshingFilterWidget(QWidget *parent = 0);
~dtkVtkMeshingFilterWidget();
private:
Ui::dtkVtkMeshingFilterWidget *ui;
QMetaObject::Connection m_connection;
};
inline QWidget *dtkVtkMeshingFilterWidgetCreator(void)
{
return new dtkVtkMeshingFilterWidget();
}
```
In the constructor, one can now connect the signal emitted by the `dtkCorePluginWidgetManager` to a lambda function that establish connection between the `QCheckBox` in the widget and the setter method handling the decimate parameter of the object contained in the `dtkComposerNodeObject`:
```cpp
dtkVtkMeshingFilterWidget::dtkVtkMeshingFilterWidget(QWidget *parent) : QWidget(parent), ui(new Ui::dtkVtkMeshingFilterWidget)
{
ui->setupUi(this);
m_connection = connect(&dtkCorePluginWidgetManager::instance(),
&dtkCorePluginWidgetManager::added,
[=] (const QVariant& v, QWidget *w) {
if (w != this) {
dtkTrace() << Q_FUNC_INFO << "Mismatch widget";
return;
}
dtkAbstractMeshingFilter *f = v.value<dtkAbstractMeshingFilter *>();
if (!f) {
dtkTrace() << Q_FUNC_INFO << "Wrong concept";
return;
}
dtkVtkMeshingFilter *filter = dynamic_cast<dtkVtkMeshingFilter *>(f);
if (!filter) {
dtkTrace() << Q_FUNC_INFO << "Wrong implementation";
return;
}
connect(ui->m_decimate, &QCheckBox::toggled, [=] (bool b) {
filter->setDecimate(b);
});
dtkTrace() << Q_FUNC_INFO << "Connection done";
});
}
dtkVtkMeshingFilterWidget::~dtkVtkMeshingFilterWidget()
{
disconnect(m_connection);
delete ui;
}
```
Destructor disconnects the connection.
### Less dependencies
The new system enables to remove dependencies to `dtkWidgets` and, in the present case, `dtkImagingWidgets`. We can even be able to compile the widget part of the plugin only when the composer is enabled.
## Outline
The new system works as a charm on my ubuntu 16.04. It compiles on windows 7 for at least dtk and dtk-imaging. I have not yet tested it for dtk-plugins-imaging on windows.
If it is convincing enough, we can remove `dtkWidgetFactory` from `dtkWidgets` layer. It will imply to modify layers and plugins that uses it.https://gitlab.inria.fr/dtk/dtk/-/issues/39Plugins switch in plugins implementation2018-05-14T16:26:23+02:00Julien WintzPlugins switch in plugins implementation*Created by: clebreto*
The dtk plugins factory allows for a given concept (defined in the applicative layer) several implementations through plugins.
_i.e._ : for dtkAbstractNurbsSurfaceData -> dtkNurbsSurfaceDataDefault/ dtkNurbsSurfa...*Created by: clebreto*
The dtk plugins factory allows for a given concept (defined in the applicative layer) several implementations through plugins.
_i.e._ : for dtkAbstractNurbsSurfaceData -> dtkNurbsSurfaceDataDefault/ dtkNurbsSurfaceDataOn/ dtkNurbsSurfaceDataSisl ...
The dtk plugin manager retrieves the available plugins for a given concept (thanks to the json plugins configuration files).
One of the nice outcomes is the option to switch among plugins for a given concept in the dtkVisualProgramming utility.
Yet, some concepts depends on other concepts, but not on a specific implementation (aka plugin).
_i.e._ : openNURBSBrepReader internally creates a dtkBrepOn(a bridge on dtkAbstractBrepData). At the moment, the choice of what implementation of dtkAbstractBrepData is to be used, is not given to the end-user, it is hard coded in the openNURBSBrepReader plugin.The end user could potentially want to switch between implementations of dtkAbstractBrepData plugins, for a whole bunch of reasons (benchmarking...).https://gitlab.inria.fr/dtk/dtk/-/issues/36versionning todo2018-05-14T16:26:23+02:00Julien Wintzversionning todo*Created by: tristancabel*
following July 8th discussion, the current proposition is:
- **1.1** actual version
- **1.2** add Feature _support deprecated_
- **1.3** add Feature _monitoring_
- **2.0** delete layers _support_
*Created by: tristancabel*
following July 8th discussion, the current proposition is:
- **1.1** actual version
- **1.2** add Feature _support deprecated_
- **1.3** add Feature _monitoring_
- **2.0** delete layers _support_
https://gitlab.inria.fr/dtk/dtk/-/issues/35Widget box not actualised when switching between plugins2018-05-14T16:26:23+02:00Julien WintzWidget box not actualised when switching between plugins*Created by: clebreto*
I have an abstraction : mesh reader, and several plugins implementing this abstraction. Only one of the plugins is equipped with a widget editor. When I switch between my different plugins I would like the widget ...*Created by: clebreto*
I have an abstraction : mesh reader, and several plugins implementing this abstraction. Only one of the plugins is equipped with a widget editor. When I switch between my different plugins I would like the widget editor to disapear as it is not implemented for most of my plugins. But the only one which is implemented remains, regardless of the plugin.
Thx
https://gitlab.inria.fr/dtk/dtk/-/issues/29How to set plugin data without setter method in base class ?2018-05-14T16:26:23+02:00KLOCZKO ThibaudHow to set plugin data without setter method in base class ?## Issue
Many cases occurred for which it is needed to set some optional parameters into plugin classes whereas the related parent class does not exhibit a method to do so.
In order to keep as simpler as possible the class hierarchy fo...## Issue
Many cases occurred for which it is needed to set some optional parameters into plugin classes whereas the related parent class does not exhibit a method to do so.
In order to keep as simpler as possible the class hierarchy for any concept, the main constraint is to provide a solution of this issue using an external way.
In other words, it is not relevant to derive the concepts from a meta-concept which would offer an introspection mechanism.
First such an introspection is not systematically required, second, in the case it becomes necessary it would imply changes in the hierarchy breaking binary compatibility.
## dtkCorePluginTuner architecture
Owing to the above constraints, dtkCorePluginTuner is a not so beautiful attempt to set data into plugin classes without casting. dtkCorePluginTuner is a pure virtual class templated by the parent concept of the plugin. Here follows its current interface:
``` c++
template < typename T > class dtkCorePluginTuner
{
public:
dtkCorePluginTuner(void);
virtual ~dtkCorePluginTuner(void);
void setObject(T *object);
void setMap(const QVariantHash& map);
virtual void update(void) = 0;
T *object(void) const;
const QVariantHash& map(void) const;
private:
T *m_object;
QVariantHash m_map;
};
```
The `QVariantHash` is in charge of the matching between data names and data values of the derived class. The tuner can then be derived into plugin and one has just to implement `update()` method to set the data values.
Giving a base class `A` and its concrete class `B` that has a method `setRadius` which requires a double value, one can implement the following tuner:
``` c++
class dtkTunerB : public dtkCorePluginTuner<A>
{
public:
void update(void) {
B *b = dynamic_cast<B *>(this->object());
if (b) {
const QVariantHash m = this->map();
b->setRadius(m["Radius"].toDouble());
}
}
};
```
## dtkCorePluginFactory modifications
In order to register and to create the concrete tuner, the dtkCorePluginFactory has been equiped with `recordTuner()` and `createTuner()` methods:
``` c++
template < typename T > class dtkCorePluginFactory
{
public:
typedef dtkCorePluginTuner<T> *(*tunerCreator) ();
public:
void recordTuner(const QString& key, tunerCreator func);
public:
dtkCorePluginTuner<T> *createTuner(const QString& key) const;
};
```
## Outlooks
dtkCorePluginTuner has to be regarded as a first prototype to solve the issue. dtk developers are asked to bring improvements.
https://gitlab.inria.fr/dtk/dtk/-/issues/14dtkPlotSupport require dtkGuiSupport2018-05-14T16:26:23+02:00Julien WintzdtkPlotSupport require dtkGuiSupport*Created by: jwintz*
The build system should handle this. Concerned elements from `dtkGuiSupport` are:
- `dtkSpacer`
- `dtkColorButton`
*Created by: jwintz*
The build system should handle this. Concerned elements from `dtkGuiSupport` are:
- `dtkSpacer`
- `dtkColorButton`
https://gitlab.inria.fr/dtk/dtk/-/issues/13dtkComposer requires dtkCoreSupport2018-05-14T16:26:23+02:00Julien WintzdtkComposer requires dtkCoreSupport*Created by: jwintz*
When building `dtkComposer` layer, if `dtkCoreSupport` is not enabled, the compilation fails as follows:
``` bash
[ 50%] Building CXX object src/dtkComposer/CMakeFiles/dtkComposer.dir/dtkComposerViewLayoutItem.cpp....*Created by: jwintz*
When building `dtkComposer` layer, if `dtkCoreSupport` is not enabled, the compilation fails as follows:
``` bash
[ 50%] Building CXX object src/dtkComposer/CMakeFiles/dtkComposer.dir/dtkComposerViewLayoutItem.cpp.o
In file included from /Users/jwintz/Development/dtk/src/dtkComposer/dtkComposerViewLayoutItem.cpp:20:
In file included from /Users/jwintz/Development/dtk/src/dtkCoreSupport/dtkAbstractView.h:23:
/Users/jwintz/Development/dtk/src/dtkCoreSupport/dtkAbstractObject.h:23:10: fatal error: 'dtkCoreSupportExport.h' file
not found
#include "dtkCoreSupportExport.h"
^
1 error generated.
```
No more reference to `dtkAbstractView` should remain in non support layers.
https://gitlab.inria.fr/dtk/dtk/-/issues/12dtkComposer requires dtkMathSupport2018-05-14T16:26:23+02:00Julien WintzdtkComposer requires dtkMathSupport*Created by: jwintz*
If `dtkComposerMathSupport` is not enabled, `dtkComposer` fails to build with the following message.
``` bash
[ 25%] Building CXX object src/dtkComposer/CMakeFiles/dtkComposer.dir/dtkComposerEvaluator.cpp.o
In file...*Created by: jwintz*
If `dtkComposerMathSupport` is not enabled, `dtkComposer` fails to build with the following message.
``` bash
[ 25%] Building CXX object src/dtkComposer/CMakeFiles/dtkComposer.dir/dtkComposerEvaluator.cpp.o
In file included from /Users/jwintz/Development/dtk/src/dtkComposer/dtkComposerEvaluator.cpp:23:
In file included from /Users/jwintz/Development/dtk/src/dtkComposer/dtkComposerGraphEdge.h:25:
/Users/jwintz/Development/dtk/src/dtkMathSupport/dtkGraphEdge.h:18:10: fatal error: 'dtkMathSupportExport.h' file not
found
#include "dtkMathSupportExport.h"
^
1 error generated.
```
Either the build system should handle this, or `dtkComposer` should not rely on `dtkMathSupport`, which I personally think is the best option.
https://gitlab.inria.fr/dtk/dtk/-/issues/6dtkLogger2018-05-14T16:26:23+02:00Julien WintzdtkLogger*Created by: LoicCadour*
I am trying to integrate the dtkLogger inside medInria, and it works very well.
Maybe two features that might be interesting would be to:
- allow to set a maximum size for the log file, so that it doesn't explod...*Created by: LoicCadour*
I am trying to integrate the dtkLogger inside medInria, and it works very well.
Maybe two features that might be interesting would be to:
- allow to set a maximum size for the log file, so that it doesn't explode,
- and, this one might be more difficult, to allow multiple log levels according to the destination. For instance, you might want to see debug messages in the console, but just errors and warnings in the dtkLogView.