[Ctk-developers] XDOM - decorator pattern
Steve Pieper
pieper at bwh.harvard.edu
Wed Nov 11 21:03:18 UTC 2009
Whew... that's a pretty broad new rule and not one I'm willing to buy
into without more discussion.
In particular, to throw some more red meat on the table:
* I would love to see a base set of object classes that are truly shared
among vtk, itk, and all other toolkits. The fact that vtk and itk are
so similar but different is a problem IMO.
* I vastly prefer the runtime polymorphic behavior of vtk data
structures (vtkPolyData, vtkImageData, etc) over their templated itk
analogs.
* Whatever programming system we adopt should be as widely used as
possible through CTK and it should support things like wrapping really
well. Traditionally I've liked vtk's wrapping over itk's, but Qt +
PySide has the potential to be even better. Also I think Qt's signals
and slots or much better than the vtk or itk events.
At various time we have said we don't want to reinvent the wheel with
'yet another object system' so in spirit I agree with Stephen - in
practice I'm not convinced that itk's object system is the logical choice.
-Steve
Stephen Aylward wrote:
> 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
>>
>>
>>
>>
>
>
>
More information about the Ctk-developers
mailing list