[Ctk-developers] XDOM - decorator pattern
Marco Viceconti
viceconti at tecno.ior.it
Thu Nov 12 10:07:14 UTC 2009
Dear Stephen:
there is nothing better that an a provocative statement to spark
discussion, which then let emerge very interesting points such as
those made by Piper and Paladini. Bravo.
But ....
a) if we agree to design CTK using the memory management and the inter-
object communication provided by Qt, if I am not wrong this means that
ALL CTK objects will have to be derived by QtObject of by a CtkObject
that wraps it, not only the data objects. So the decision is much
broader than this. For example one aspect that in my opinion would
be worth another discussion thread where the more tech people (Paolo
and Daniele on my side) start to say something is: given Gianluca
point on memory management (with which I agree 100%) is the memory
management mechanism (MMM) provided by QtObject sufficient for CTK?
If not, does it prevents of make more difficult the development of
more sophisticated MMM such as those described by Gianluca to
dynamically manage objects out-of-core? another aspect: how do we
ensure that if every object can send a message to any other object
after a while CTK code does not become a jungle which no one can
really debug? In MAF3 we plan to use a very strong encapsulation
between modules, and explicitly prevent that two objects residing
inside to separate modules can start to exchange messages directly.
Is this a good architectural decision, we could consider also for CTK?
b) the discussion in Oxford made very clear that the biggest problem
we share is the lack of extensibility, completeness, and efficacy in
the ALL the data object models we use in ALL our codes. All we have
done with respect to data models fall short to some extend, all except
maybe something in MedInria in not design to be extensible at run
time, which prevents programmers to add data types as plugins. Around
the idea of developing an extensible data object model (XDOM) revolves
the proposal we are putting together on the EU side, under the
coordination of the INRIA team. So a more realistic scenario is that
we:
i) discuss in depth what is wrong with each of the currently
available data object models (which is already happening in this thread)
ii) develop an XDOM component for CTK
iii) adopt it in the next version of our respective products,
including ITK and VTK (well this may take a while, but you got the
idea).
Cheers
Marco
Il giorno 11 Nov 2009, alle ore 16:49, Stephen Aylward ha scritto:
> Hi Marco,
>
> I was a bit short on time and details with my last email. Sorry.
>
> You raise an interesting point. Should (or could?) some of our
> primary data structures derive from Qt data structures. I don't think
> this is a good idea.
>
> Given that we have (a) images and objects, (b) image/object processing
> algorithms, (c) visualization algorithms, and (d) optional GUI
> components in CTK, I suggest we add the following rule:
>
> NEW RULE: When images, objects, and data structures (e.g., vectors)
> are exposed on an API that MAY be called by image/object algorithms or
> by visualization algorithms, those exposed images, objects, and data
> structs should be based on ITK (itk::Image, itk::Mesh, itk::Vector).
>
> What this means:
>
> a) Image/Object processing algorithms' inputs and outputs should be
> ITK data objects.
>
> b) Inputs to visualization algorithms should be ITK data objects.
> Outputs of visualization algorithms can be non-ITK (e.g., VTK,
> OpenInventor, ...) - assuming that they are passed directly to a GUI
> (i.e., not used by image/object processing algorithms and not used by
> other visualization algorithms). You cannot chain visualization
> algorithms together, unless they are passing only ITK objects.
>
> c) Qt should never be exposed by Image/Object processing algorithms or
> visualization algorithms.
>
> d) Use itk::Vector and NOT std::vector to represent mathematical
> vectors.
>
> e) Use itk::Array instead of std::list or std::vector.
>
> I know this is open to debate...so let's hear it....
>
> :)
>
> s
>
> On Wed, Nov 11, 2009 at 7:56 AM, Marco Viceconti <viceconti at tecno.ior.it
> > wrote:
>> Sorry I missed this point.
>>
>> Ok, I trust the group on this decision. By the way this also clear a
>> similar decision we are now taking inside MAF3 on whether to use
>> QtObject.
>>
>> I presume that no one disagree with the second statement in my
>> email: "Even
>> if we agree [to use Qt core], would not be better to ensure that
>> CTK is not
>> ridden of Qt
>> code, and find solutions such as the wrapping of the QtObject class
>> into a
>> CTK Class?
>>
>> thanks Stephen.
>>
>> Marco
>>
>>
>>
>> Il giorno 9 Nov 2009, alle ore 14:25, Stephen Aylward ha scritto:
>>
>>> 1) QtCore will supply system-level functions. "If a function we
>>> need
>>> exists in Qt, then we should use it"
>>>
>>> 2) QtGUI is optional
>>>
>>> It was more clearly stated in out meeting notes:
>>> http://www.na-mic.org/Wiki/index.php/Events:CTK-Workshop-June-2009
>>> See the section called "Technical Aspects."
>>>
>>> s
>>>
>>> On Mon, Nov 9, 2009 at 2:02 AM, Marco Viceconti <viceconti at tecno.ior.it
>>> >
>>> wrote:
>>>>
>>>> Worth to be said because when we agreed to use Qt, I am sure most
>>>> of us
>>>> were
>>>> thinking of the GUI, and not of a class from which every other
>>>> class in
>>>> the
>>>> framework would inherit.
>>>>
>>>> So before we carry on, at the cost of being pedantic, let me pose
>>>> this
>>>> question to the whole CTK group:
>>>>
>>>> Qt provide a portable GUI framework, that we agreed to adopt in
>>>> CTK.
>>>>
>>>> But it also provides some interesting low-level mechanisms, in
>>>> particular
>>>> a
>>>> extensive multi-threading library and inter-object communication
>>>> mechanism.
>>>> Do we all agree that also this part of Qt can be used to build
>>>> CTK?
>>>>
>>>> Even if we agree, would not be better to ensure that CTK is not
>>>> ridden of
>>>> Qt
>>>> code, and find solutions such as the wrapping of the QtObject
>>>> class into
>>>> a
>>>> CTK Class?
>>>>
>>>> Cheers
>>>>
>>>> Marco
>>>>
>>>>
>>>>
>>>> Il giorno 8 Nov 2009, alle ore 12:07, Marco Nolden ha scritto:
>>>>
>>>>> Marco Viceconti wrote:
>>>>>>
>>>>>> I suspect that the mechanism our colleagues in INRIA described
>>>>>> at the
>>>>>> CTK meeting in Oxford is strongly based on the ability of
>>>>>> QTObjects
>>>>>> and
>>>>>> derivative to exchange messages, making simple and efficient
>>>>>> the use
>>>>>> of
>>>>>> message-passing mechanisms. This however creates a strong
>>>>>> dependency
>>>>>> onto
>>>>>> QT, which we might want to discourage in CTK (we should
>>>>>> remember QT
>>>>>> already
>>>>>> changed license model 2 times :-) ).
>>>>>>
>>>>>>
>>>>> Dear Marco,
>>>>>
>>>>> at the first CTK meeting in Heidelberg we agreed on using Qt in
>>>>> CTK,
>>>>> since
>>>>> everyone is already using it. This does not necessarily include
>>>>> the Qt
>>>>> GUI
>>>>> classes, but the Qt Core module which offers the message-passing
>>>>> mechanisms.
>>>>> Of course such a strong dependency should always be discussed,
>>>>> but I'm
>>>>> not
>>>>> afraid of any licensing changes anymore.
>>>>>
>>>>> Regards
>>>>>
>>>>> Marco (the other one)
>>>>>
>>>>> --
>>>>> ----------------------------------------------------------------------
>>>>> Dipl.-Inform. Med. Marco Nolden
>>>>> Deutsches Krebsforschungszentrum (German Cancer Research
>>>>> Center)
>>>>> Div. Medical & Biological Informatics Tel: (+49)
>>>>> 6221-42 2325
>>>>> Im Neuenheimer Feld 280 Fax: (+49)
>>>>> 6221-42 2345
>>>>> D-69120 Heidelberg eMail: M.Nolden at dkfz.de
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --------------------------------------------------
>>>> MARCO VICECONTI, PhD (viceconti at tecno.ior.it
>>>> )
>>>> Laboratorio di Tecnologia Medica tel. 39-051-6366865
>>>> Istituto Ortopedico Rizzoli fax.
>>>> 39-051-6366863
>>>> via di Barbiano 1/10, 40136 - Bologna, Italy
>>>>
>>>> Tiger! Tiger! Burning bright in the forest of the night,
>>>> what immortal hand or eye could frame thy fearful symmetry?
>>>> --------------------------------------------------
>>>> Opinions expressed here do not necessarily reflect those of my
>>>> employer
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ctk-developers mailing list
>>>> Ctk-developers at commontk.org
>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>>>
>>>
>>>
>>>
>>> --
>>> Stephen R. Aylward, Ph.D.
>>> Director of Medical Imaging Research
>>> Kitware, Inc. - North Carolina Office
>>> http://www.kitware.com
>>> stephen.aylward (Skype)
>>> (919) 969-6990 x300
>>>
>>
>> --------------------------------------------------
>> MARCO VICECONTI, PhD (viceconti at tecno.ior.it
>> )
>> Laboratorio di Tecnologia Medica tel. 39-051-6366865
>> Istituto Ortopedico Rizzoli fax.
>> 39-051-6366863
>> via di Barbiano 1/10, 40136 - Bologna, Italy
>>
>> Tiger! Tiger! Burning bright in the forest of the night,
>> what immortal hand or eye could frame thy fearful symmetry?
>> --------------------------------------------------
>> Opinions expressed here do not necessarily reflect those of my
>> employer
>>
>>
>>
>>
>
>
>
> --
> Stephen R. Aylward, Ph.D.
> Director of Medical Imaging Research
> Kitware, Inc. - North Carolina Office
> http://www.kitware.com
> stephen.aylward (Skype)
> (919) 969-6990 x300
>
--------------------------------------------------
MARCO VICECONTI, PhD
(viceconti at tecno.ior.it)
Laboratorio di Tecnologia Medica tel. 39-051-6366865
Istituto Ortopedico Rizzoli fax.
39-051-6366863
via di Barbiano 1/10, 40136 - Bologna, Italy
Tiger! Tiger! Burning bright in the forest of the night,
what immortal hand or eye could frame thy fearful symmetry?
--------------------------------------------------
Opinions expressed here do not necessarily reflect those of my employer
More information about the Ctk-developers
mailing list