[Ctk-developers] XDOM - decorator pattern

[Stephen Aylward]

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