From julien.finet at kitware.com  Mon Aug  1 02:13:52 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Sun, 31 Jul 2011 22:13:52 -0400
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
References: <4E32755D.6000402@offis.de>
	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
Message-ID: <CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>

Here are the errors on windows:
http://my.cdash.org/viewBuildError.php?onlydeltap&buildid=214815

Regards,
Julien.

On Sun, Jul 31, 2011 at 5:52 PM, Julien Finet <julien.finet at kitware.com>wrote:

> Hi Michael,
>
> Nice job !!!
>
> It seems that nightly builds are now failing.
> -fPIC is missing: http://my.cdash.org/viewBuildError.php?buildid=214617
> - Warning with the compilation of dcmtk:
> http://my.cdash.org/viewBuildError.php?type=1&buildid=214303
>
> Can you give a look ?**
>
> Thanks,
> Julien.
>
> On Fri, Jul 29, 2011 at 4:54 AM, OFFIS DICOM Team <dicom at offis.de> wrote:
>
>> Dear all,
>>
>> the last two days I merged my changes regarding the adaptation of CTK to
>> the
>> latest DCMTK back in to the CTK master branch. I commited this stuff a few
>> minutes ago.
>>
>> I also included some fixes where I stumbled over things that seemed wrong
>> to
>> me. Further, I added minor features at some positions, e.g. color support
>> for the DICOM thumbnail/image rendering. Overall, I only worked on the
>> DICOM
>> parts, 99% on /Libs/DICOM, mostly the Core part.
>>
>> I also changed the repository location in the superbuild to fetch DCMTK
>> from
>> the official OFFIS repository at http://git.dcmtk.org/dcmtk.git . That
>> works
>> for me here.
>>
>> Nevertheless, since these are my first actual commits to CTK, I expect
>> that
>> I have done some mistakes, hopefully not too many serious ones ;) Please
>> tell me and I will correct that as soon as possible.
>>
>> Best regards,
>> Michael
>>
>> --
>> OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
>> E-Mail: dicom at offis.de, URL: http://dicom.offis.de
>> ______________________________**_________________
>> Ctk-developers mailing list
>> Ctk-developers at commontk.org
>> http://public.kitware.com/cgi-**bin/mailman/listinfo/ctk-**developers<http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110731/6e7d2d63/attachment.htm>

From jchris.fillionr at kitware.com  Mon Aug  1 14:35:37 2011
From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin)
Date: Mon, 1 Aug 2011 10:35:37 -0400
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
References: <4E32755D.6000402@offis.de>
	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
	<CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
Message-ID: <CANLz8R4cB7x2vRTw1LWYXJNL3+gww6f+XrjODCGt4W6CaQYFDw@mail.gmail.com>

Hi Folks,

Moving to the official DCMTK is great, it will minimize maintenance and
avoid a dependency on a custom version of DCMTK.

Nevertheless, it seems CTK build is now broken :(

Few remarks:

 1) In CMakeExternals/DCMTK.cmake - Instead of specifying "origin/master",
would it be possible to use a specific SHA1 as a GIT_TAG. Doing so will be
more deterministic and ensure all developers / checkout will behave the same
way. Before, origin/patched associated with our own DCMTK was a "controller"
moving target."

 Created issue https://github.com/commontk/CTK/issues/21 and assigned to
Michael

2) DCMTK build is broken - How should we address the problem:
   * Get write access to official dcmtk ?
   * Ask dcmtk folks to mirror DCMTK on github so that we can fork and
easily contribute patches ?
  * Mirror DCMTK ourself on commontk/dcmtk

Assigned issue https://github.com/commontk/CTK/issues/22 to Michael

In the mean time, I will update CMakeExternal/DCMTK.cmake so that fPIC is
passed.

3) Should we move to a master/next workflow ?

 Having a continuous dashboard setup for both master and next, we will be
able to easily identify issue and ensure that our change compile properly on
all targets platform.

Thanks
Jc


On Sun, Jul 31, 2011 at 10:13 PM, Julien Finet <julien.finet at kitware.com>wrote:

> Here are the errors on windows:
> http://my.cdash.org/viewBuildError.php?onlydeltap&buildid=214815
>
> Regards,
> Julien.
>
> On Sun, Jul 31, 2011 at 5:52 PM, Julien Finet <julien.finet at kitware.com>wrote:
>
>> Hi Michael,
>>
>> Nice job !!!
>>
>> It seems that nightly builds are now failing.
>> -fPIC is missing: http://my.cdash.org/viewBuildError.php?buildid=214617
>> - Warning with the compilation of dcmtk:
>> http://my.cdash.org/viewBuildError.php?type=1&buildid=214303
>>
>> Can you give a look ?**
>>
>> Thanks,
>> Julien.
>>
>> On Fri, Jul 29, 2011 at 4:54 AM, OFFIS DICOM Team <dicom at offis.de> wrote:
>>
>>> Dear all,
>>>
>>> the last two days I merged my changes regarding the adaptation of CTK to
>>> the
>>> latest DCMTK back in to the CTK master branch. I commited this stuff a
>>> few
>>> minutes ago.
>>>
>>> I also included some fixes where I stumbled over things that seemed wrong
>>> to
>>> me. Further, I added minor features at some positions, e.g. color support
>>> for the DICOM thumbnail/image rendering. Overall, I only worked on the
>>> DICOM
>>> parts, 99% on /Libs/DICOM, mostly the Core part.
>>>
>>> I also changed the repository location in the superbuild to fetch DCMTK
>>> from
>>> the official OFFIS repository at http://git.dcmtk.org/dcmtk.git . That
>>> works
>>> for me here.
>>>
>>> Nevertheless, since these are my first actual commits to CTK, I expect
>>> that
>>> I have done some mistakes, hopefully not too many serious ones ;) Please
>>> tell me and I will correct that as soon as possible.
>>>
>>> Best regards,
>>> Michael
>>>
>>> --
>>> OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
>>> E-Mail: dicom at offis.de, URL: http://dicom.offis.de
>>> ______________________________**_________________
>>> Ctk-developers mailing list
>>> Ctk-developers at commontk.org
>>> http://public.kitware.com/cgi-**bin/mailman/listinfo/ctk-**developers<http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers>
>>>
>>
>>
>
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>


-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110801/9a1737eb/attachment.htm>

From dicom at offis.de  Mon Aug  1 15:32:38 2011
From: dicom at offis.de (OFFIS DICOM Team)
Date: Mon, 01 Aug 2011 17:32:38 +0200
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
References: <4E32755D.6000402@offis.de>
	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
	<CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
Message-ID: <4E36C716.2050401@offis.de>

Hi,

Am 01.08.2011 04:13, schrieb Julien Finet:
> Here are the errors on windows:
> http://my.cdash.org/viewBuildError.php?onlydeltap&buildid=214815
> <http://my.cdash.org/viewBuildError.php?onlydeltap&buildid=214815>

sorry for this. This is since DCMTK originally uses /MT and /MTd for
building, which is not the case for CTK. I changed that locally, but did not
push this change to the repository. I know adapted
CMakeExternals\DCMTK.cmake to rely on the CMake compiler flags, disabling
overriding through DCMTK that took place before.

It seems there are other issues, depending on the sytem configuration and
platform. I really expect that it will be pretty easy to fix this initial
stuff and then everything runs out of the box. Sorry for the trouble guys!

Best regards,
Michael

-- 
OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
E-Mail: dicom at offis.de, URL: http://dicom.offis.de


From dicom at offis.de  Mon Aug  1 15:45:24 2011
From: dicom at offis.de (OFFIS DICOM Team)
Date: Mon, 01 Aug 2011 17:45:24 +0200
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <CANLz8R4cB7x2vRTw1LWYXJNL3+gww6f+XrjODCGt4W6CaQYFDw@mail.gmail.com>
References: <4E32755D.6000402@offis.de>
	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
	<CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
	<CANLz8R4cB7x2vRTw1LWYXJNL3+gww6f+XrjODCGt4W6CaQYFDw@mail.gmail.com>
Message-ID: <4E36CA14.7060501@offis.de>

Hi JC,

Am 01.08.2011 16:35, schrieb Jean-Christophe Fillion-Robin:

> Nevertheless, it seems CTK build is now broken :(

Yes, and totally my fault ;)

> Few remarks:
>
> 1) In CMakeExternals/DCMTK.cmake - Instead of specifying
> "origin/master", would it be possible to use a specific SHA1 as a
> GIT_TAG. Doing so will be more deterministic and ensure all developers /
> checkout will behave the same way. Before, origin/patched associated with
> our own DCMTK was a "controller" moving target."

I think this is a good idea. Let's adapt the remaining issues to be fine on
the current DCMTK HEAD commit and take that one. I really do not recommend
taking 3.6.0 since I added C-MOVE code (needed for receiving images) to the
DcmSCU class afterwards.

> 2) DCMTK build is broken - How should we address the problem:

DCMTK itself is broken? There is a warning about mktemp, I guess that is
easy to fix and I will do it hopefully already today. Are there any other
issues, just let me know and I'll fix it in DCMTK.

> * Get write access to official dcmtk ? * Ask dcmtk folks to mirror DCMTK
> on github so that we can fork and easily contribute patches ? * Mirror
> DCMTK ourself on commontk/dcmtk

I would not be happy about any of these. Let's get things running on all
platforms now; I will do my part as good as possible and with priority. Then
we can take a fixed commit and update that from time to time in CTK. We can
do that regulary, as you like, or as I can give you a hint if interesting
features (for CTK) come in.
>
> Assigned issue https://github.com/commontk/CTK/issues/22 to Michael
>
> In the mean time, I will update CMakeExternal/DCMTK.cmake so that fPIC
> is passed.

Shouldn't we not just change DCMTK's CMakeLists.txt? We need these flags
anyway sooner or later, so we should also take it over. I would just take
over the solution from the link (issues/22) into DCMTK's CMakeLists.txt.
>
> 3) Should we move to a master/next workflow ?
>
> Having a continuous dashboard setup for both master and next, we will be
> able to easily identify issue and ensure that our change compile properly
> on all targets platform.

Given my beginner's status in git and somehow also CTK, I would totally
welcome that! So plus 1 from my side ...

Best regards,
Michael

-- 
OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
E-Mail: dicom at offis.de, URL: http://dicom.offis.de


From jchris.fillionr at kitware.com  Mon Aug  1 16:25:50 2011
From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin)
Date: Mon, 1 Aug 2011 12:25:50 -0400
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <4E36CA14.7060501@offis.de>
References: <4E32755D.6000402@offis.de>
	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
	<CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
	<CANLz8R4cB7x2vRTw1LWYXJNL3+gww6f+XrjODCGt4W6CaQYFDw@mail.gmail.com>
	<4E36CA14.7060501@offis.de>
Message-ID: <CANLz8R6W9vUCL8TecTKB=gAP6pRf-Gy2OTARkkPAHG=SiyLgmQ@mail.gmail.com>

Regarding MT and /MTd, would it make sens to have a CMake option named
DCMTK_MULTITHREADED ?

See also inline comments.

On Mon, Aug 1, 2011 at 11:45 AM, OFFIS DICOM Team <dicom at offis.de> wrote:

> Hi JC,
>
> Am 01.08.2011 16:35, schrieb Jean-Christophe Fillion-Robin:
>
>
>  Nevertheless, it seems CTK build is now broken :(
>>
>
> Yes, and totally my fault ;)


No prob :) Seems we identify and are on the good track to get the problem
fixed.


>
>
>  Few remarks:
>>
>> 1) In CMakeExternals/DCMTK.cmake - Instead of specifying
>> "origin/master", would it be possible to use a specific SHA1 as a
>> GIT_TAG. Doing so will be more deterministic and ensure all developers /
>> checkout will behave the same way. Before, origin/patched associated with
>> our own DCMTK was a "controller" moving target."
>>
>
> I think this is a good idea. Let's adapt the remaining issues to be fine on
> the current DCMTK HEAD commit and take that one. I really do not recommend
> taking 3.6.0 since I added C-MOVE code (needed for receiving images) to the
> DcmSCU class afterwards.


Make sens - It just a matter of specifying the SHA1 to be the latest head
known to compile.


>
>
>  2) DCMTK build is broken - How should we address the problem:
>>
>
> DCMTK itself is broken? There is a warning about mktemp, I guess that is
> easy to fix and I will do it hopefully already today. Are there any other
> issues, just let me know and I'll fix it in DCMTK.


DCMTK build by CTK is/was broken. The flag fPIC was not added automatically
...


>
>
>  * Get write access to official dcmtk ? * Ask dcmtk folks to mirror DCMTK
>> on github so that we can fork and easily contribute patches ? * Mirror
>> DCMTK ourself on commontk/dcmtk
>>
>
> I would not be happy about any of these. Let's get things running on all
> platforms now; I will do my part as good as possible and with priority.
> Then
> we can take a fixed commit and update that from time to time in CTK. We can
> do that regulary, as you like, or as I can give you a hint if interesting
> features (for CTK) come in.


I guess submitting patch to Offis directly seems to be the way to go. We
could also publish our topic branch on commontk/DCMTK to that you can review
them before final integration upstream.


>
>
>> Assigned issue https://github.com/commontk/**CTK/issues/22<https://github.com/commontk/CTK/issues/22>to Michael
>>
>> In the mean time, I will update CMakeExternal/DCMTK.cmake so that fPIC
>> is passed.
>>
>
> Shouldn't we not just change DCMTK's CMakeLists.txt? We need these flags
> anyway sooner or later, so we should also take it over. I would just take
> over the solution from the link (issues/22) into DCMTK's CMakeLists.txt.


Very true - i didn't know how responsive you would be. Do you know when
things will be fixed?


>
>
>> 3) Should we move to a master/next workflow ?
>>
>> Having a continuous dashboard setup for both master and next, we will be
>> able to easily identify issue and ensure that our change compile properly
>> on all targets platform.
>>
>
> Given my beginner's status in git and somehow also CTK, I would totally
> welcome that! So plus 1 from my side ...


Extra - Any other thoughts from the CTK community ?


>
>
> Best regards,
> Michael
>
> --
> OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
> E-Mail: dicom at offis.de, URL: http://dicom.offis.de
>



-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110801/c82bc4ab/attachment.htm>

From julien.finet at kitware.com  Mon Aug  1 16:50:33 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Mon, 1 Aug 2011 12:50:33 -0400
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <4E36C716.2050401@offis.de>
References: <4E32755D.6000402@offis.de>
	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
	<CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
	<4E36C716.2050401@offis.de>
Message-ID: <CAKoWPPH74S2PTN3MzBnodnA2Q9BJeqgWuO87bio9ErbtrOGqmw@mail.gmail.com>

Great, it now works again on Windows:
http://my.cdash.org/index.php?project=CTK&display=project&filtercount=3&showfilters=1&filtercombine=and&field1=buildname/string&compare1=61&value1=WindowsXP-VS2008Express-QT4.7.0-Release&field2=site/string&compare2=61&value2=erna.kitware&field3=buildstamp/string&compare3=61&value3=20110801-1604-Experimental&collapse=0

Thanks a lot,
Julien.

On Mon, Aug 1, 2011 at 11:32 AM, OFFIS DICOM Team <dicom at offis.de> wrote:

> Hi,
>
> Am 01.08.2011 04:13, schrieb Julien Finet:
>
>  Here are the errors on windows:
>> http://my.cdash.org/**viewBuildError.php?onlydeltap&**buildid=214815<http://my.cdash.org/viewBuildError.php?onlydeltap&buildid=214815>
>> <http://my.cdash.org/**viewBuildError.php?onlydeltap&**buildid=214815<http://my.cdash.org/viewBuildError.php?onlydeltap&buildid=214815>
>> >
>>
>
> sorry for this. This is since DCMTK originally uses /MT and /MTd for
> building, which is not the case for CTK. I changed that locally, but did
> not
> push this change to the repository. I know adapted
> CMakeExternals\DCMTK.cmake to rely on the CMake compiler flags, disabling
> overriding through DCMTK that took place before.
>
> It seems there are other issues, depending on the sytem configuration and
> platform. I really expect that it will be pretty easy to fix this initial
> stuff and then everything runs out of the box. Sorry for the trouble guys!
>
>
> Best regards,
> Michael
>
> --
> OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
> E-Mail: dicom at offis.de, URL: http://dicom.offis.de
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110801/00b16668/attachment.htm>

From dicom at offis.de  Mon Aug  1 17:00:13 2011
From: dicom at offis.de (OFFIS DICOM Team)
Date: Mon, 01 Aug 2011 19:00:13 +0200
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <CANLz8R6W9vUCL8TecTKB=gAP6pRf-Gy2OTARkkPAHG=SiyLgmQ@mail.gmail.com>
References: <4E32755D.6000402@offis.de>
	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
	<CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
	<CANLz8R4cB7x2vRTw1LWYXJNL3+gww6f+XrjODCGt4W6CaQYFDw@mail.gmail.com>
	<4E36CA14.7060501@offis.de>
	<CANLz8R6W9vUCL8TecTKB=gAP6pRf-Gy2OTARkkPAHG=SiyLgmQ@mail.gmail.com>
Message-ID: <4E36DB9D.2020901@offis.de>

Hi,

Am 01.08.2011 18:25, schrieb Jean-Christophe Fillion-Robin:
> Regarding MT and /MTd, would it make sens to have a CMake option named
> DCMTK_MULTITHREADED ?

If CMake automatically uses the flags it should and hands it over to all
external projects, this would be not needed. However, I'm not sure whether
this is actually the case.

We already have a WITH_THREADS flag in DCMTK which adds libpthread if
existing/necessary. Usually, with threads is turned on.

> Yes, and totally my fault ;)
>
>
> No prob :) Seems we identify and are on the good track to get the problem
> fixed.

Yes, I hope so :)

>
> DCMTK build by CTK is/was broken. The flag fPIC was not added
> automatically ...

Yes, ok; as I understood this is needed when linking against the shared
DCMTK libraries from outside.

> * Get write access to official dcmtk ? * Ask dcmtk folks to mirror DCMTK
> on github so that we can fork and easily contribute patches ? * Mirror
> DCMTK ourself on commontk/dcmtk
>
>
> I would not be happy about any of these. Let's get things running on all
> platforms now; I will do my part as good as possible and with priority.
> Then we can take a fixed commit and update that from time to time in CTK.
> We can do that regulary, as you like, or as I can give you a hint if
> interesting features (for CTK) come in.
>
>
> I guess submitting patch to Offis directly seems to be the way to go. We
>  could also publish our topic branch on commontk/DCMTK to that you can
> review them before final integration upstream.

Fine for me. My point is just that we should not let drift apart CTK too
much from the latest DCMTK version. Otherwise (like now..;)) it is double
work to align things again :)

> Assigned issue https://github.com/commontk/__CTK/issues/22
> <https://github.com/commontk/CTK/issues/22> to Michael
>
> In the mean time, I will update CMakeExternal/DCMTK.cmake so that fPIC is
> passed.
>
>
> Shouldn't we not just change DCMTK's CMakeLists.txt? We need these flags
> anyway sooner or later, so we should also take it over. I would just take
> over the solution from the link (issues/22) into DCMTK's CMakeLists.txt.
>
>
> Very true - i didn't know how responsive you would be. Do you know when
> things will be fixed?

I could commit it any time/immediately in DCMTK. My colleague noted that we
should take care that we only put -fPIC into effect if it is understood by
the compiler and needed, so I wonder whether "IF(UNIX" is a sufficient
guard. Any hints or recommendations?

Best regards,
Michael

-- 
OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
E-Mail: dicom at offis.de, URL: http://dicom.offis.de


From jchris.fillionr at kitware.com  Mon Aug  1 18:41:54 2011
From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin)
Date: Mon, 1 Aug 2011 14:41:54 -0400
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <4E36DB9D.2020901@offis.de>
References: <4E32755D.6000402@offis.de>
	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
	<CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
	<CANLz8R4cB7x2vRTw1LWYXJNL3+gww6f+XrjODCGt4W6CaQYFDw@mail.gmail.com>
	<4E36CA14.7060501@offis.de>
	<CANLz8R6W9vUCL8TecTKB=gAP6pRf-Gy2OTARkkPAHG=SiyLgmQ@mail.gmail.com>
	<4E36DB9D.2020901@offis.de>
Message-ID: <CANLz8R4dvRejW1Dqa8nN-tpSM=6TYj9F2qAzv=X15LHUtTi2Dg@mail.gmail.com>

On Mon, Aug 1, 2011 at 1:00 PM, OFFIS DICOM Team <dicom at offis.de> wrote:

> Hi,
>
> Am 01.08.2011 18:25, schrieb Jean-Christophe Fillion-Robin:
>
>  Regarding MT and /MTd, would it make sens to have a CMake option named
>> DCMTK_MULTITHREADED ?
>>
>
> If CMake automatically uses the flags it should and hands it over to all
> external projects, this would be not needed. However, I'm not sure whether
> this is actually the case.
>

CMake could pass down any additional flags by configuring the project with
CMAKE_CXX_FLAGS and CMAKE_C_FLAGS.



>
> We already have a WITH_THREADS flag in DCMTK which adds libpthread if
> existing/necessary. Usually, with threads is turned on.


Does it mean that turning WITH_THREAD OFF won't append the /MT or /MTd flags
?


>
>
>  Yes, and totally my fault ;)
>>
>>
>> No prob :) Seems we identify and are on the good track to get the problem
>> fixed.
>>
>
> Yes, I hope so :)
>
>
>
>> DCMTK build by CTK is/was broken. The flag fPIC was not added
>> automatically ...
>>
>
> Yes, ok; as I understood this is needed when linking against the shared
> DCMTK libraries from outside.

This happen when linking a shared 64bits library against  a static library.
The fPIC flag is required.

>
>
>  * Get write access to official dcmtk ? * Ask dcmtk folks to mirror DCMTK
>> on github so that we can fork and easily contribute patches ? * Mirror
>> DCMTK ourself on commontk/dcmtk
>>
>>
>> I would not be happy about any of these. Let's get things running on all
>> platforms now; I will do my part as good as possible and with priority.
>> Then we can take a fixed commit and update that from time to time in CTK.
>> We can do that regulary, as you like, or as I can give you a hint if
>> interesting features (for CTK) come in.
>>
>>
>> I guess submitting patch to Offis directly seems to be the way to go. We
>>  could also publish our topic branch on commontk/DCMTK to that you can
>> review them before final integration upstream.
>>
>
> Fine for me. My point is just that we should not let drift apart CTK too
> much from the latest DCMTK version. Otherwise (like now..;)) it is double
> work to align things again :)

Excellent - And thanks for helping us catching up with the current DCMTK.


>
>  Assigned issue https://github.com/commontk/__**CTK/issues/22<https://github.com/commontk/__CTK/issues/22>
>> <https://github.com/commontk/**CTK/issues/22<https://github.com/commontk/CTK/issues/22>>
>> to Michael
>>
>> In the mean time, I will update CMakeExternal/DCMTK.cmake so that fPIC is
>> passed.
>>
>>
>> Shouldn't we not just change DCMTK's CMakeLists.txt? We need these flags
>> anyway sooner or later, so we should also take it over. I would just take
>> over the solution from the link (issues/22) into DCMTK's CMakeLists.txt.
>>
>>
>> Very true - i didn't know how responsive you would be. Do you know when
>> things will be fixed?
>>
>
> I could commit it any time/immediately in DCMTK. My colleague noted that we
> should take care that we only put -fPIC into effect if it is understood by
> the compiler and needed, so I wonder whether "IF(UNIX" is a sufficient
> guard. Any hints or recommendations?


You could for example do:

#-----------------------------------------------------------------------------
# To fix compilation problem: relocation R_X86_64_32 against `a local
symbol' can not be
# used when making a shared object; recompile with -fPIC
# See http://www.cmake.org/pipermail/cmake/2007-May/014350.html
#
IF( CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64" )
  SET_TARGET_PROPERTIES(log4qt PROPERTIES COMPILE_FLAGS "-fPIC")
ENDIF( CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64" )




>
> Best regards,
> Michael
>
> --
> OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
> E-Mail: dicom at offis.de, URL: http://dicom.offis.de
>



-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110801/aa673cc0/attachment.htm>

From julien.finet at kitware.com  Mon Aug  1 21:30:07 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Mon, 1 Aug 2011 17:30:07 -0400
Subject: [Ctk-developers] org_commontk_dah_app depends on
	org_commontk_dah_core
Message-ID: <CAKoWPPGgFajM+0sV-LEeZ3SpxpEsW4RKLzRWcLbciJh5ROs=7g@mail.gmail.com>

Hola CTKers,

Is this normal that org_commontk_dah_app depends of org_commontk_dah_core ?
Is org_commontk_dah_core really a plugin ?

If so (or even if it shouldn't), a target_libraries.cmake
referencing org_commontk_dah_core is probably needed in order to avoid that
kind of error at first build:
  http://my.cdash.org/viewBuildError.php?onlydeltap&buildid=215143

I take the opportunity of this email to mention some warnings :-) :
http://my.cdash.org/viewBuildError.php?type=1&onlydeltap&buildid=215143

Thank you :-)
Julien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110801/519d136b/attachment.htm>

From dicom at offis.de  Mon Aug  1 21:41:25 2011
From: dicom at offis.de (OFFIS DICOM Team)
Date: Mon, 01 Aug 2011 23:41:25 +0200
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <CANLz8R4dvRejW1Dqa8nN-tpSM=6TYj9F2qAzv=X15LHUtTi2Dg@mail.gmail.com>
References: <4E32755D.6000402@offis.de>
	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
	<CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
	<CANLz8R4cB7x2vRTw1LWYXJNL3+gww6f+XrjODCGt4W6CaQYFDw@mail.gmail.com>
	<4E36CA14.7060501@offis.de>
	<CANLz8R6W9vUCL8TecTKB=gAP6pRf-Gy2OTARkkPAHG=SiyLgmQ@mail.gmail.com>
	<4E36DB9D.2020901@offis.de>
	<CANLz8R4dvRejW1Dqa8nN-tpSM=6TYj9F2qAzv=X15LHUtTi2Dg@mail.gmail.com>
Message-ID: <4E371D85.6050606@offis.de>

Hi,

Am 01.08.2011 20:41, schrieb Jean-Christophe Fillion-Robin:

> We already have a WITH_THREADS flag in DCMTK which adds libpthread if
> existing/necessary. Usually, with threads is turned on.
>
> Does it mean that turning WITH_THREAD OFF won't append the /MT or /MTd
> flags ?

No, on Windows we usually use /MT and /MTd in DCMTK. For CTK, we now (since
today) use the flags automatically determined by CMake, i.e. /MD and /MDd
for compilation. In both cases we do not care about whether
DCMTK_WITH_THREADS is on or off. Both, /MT(d) and /MD(d) flags, select a
microsoft runtime library including threaded versions, as far as I (and you
probably) know:

http://msdn.microsoft.com/en-us/library/2kzt1wy3(v=vs.71).aspx

If WITH_THREADS is off, DCMTK's thread classes like OFThread are not
compiled, and pthread and the like are not added to the linker.

> I could commit it any time/immediately in DCMTK. My colleague noted that
> we should take care that we only put -fPIC into effect if it is
> understood by the compiler and needed, so I wonder whether "IF(UNIX" is
> a sufficient guard. Any hints or recommendations?
>
>
> You could for example do: [...]

I inserted a flag DCMTK_FORCE_FPIC_ON_UNIX in DCMTK [1] which can be set
from CTK's DCMTK.cmake via CMAKE_ARGS. If this makes sense, I can change the
DCMTK.cmake accordingly. Also, I removed mktemp from the tparser.cc [2] so
the warning an unix should be gone now.

Thanks for helping!

Michael

[1]
http://git.dcmtk.org/web?p=dcmtk.git;a=commitdiff;h=09db15ff595da6c35330fd7f63669aeb9952e015

[2] 
http://git.dcmtk.org/web?p=dcmtk.git;a=commitdiff;h=96ce7c46b48245512385170bfb72ec3cdc32a3a6

-- 
OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
E-Mail: dicom at offis.de, URL: http://dicom.offis.de


From jchris.fillionr at kitware.com  Mon Aug  1 21:41:18 2011
From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin)
Date: Mon, 1 Aug 2011 17:41:18 -0400
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <CANLz8R4dvRejW1Dqa8nN-tpSM=6TYj9F2qAzv=X15LHUtTi2Dg@mail.gmail.com>
References: <4E32755D.6000402@offis.de>
	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
	<CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
	<CANLz8R4cB7x2vRTw1LWYXJNL3+gww6f+XrjODCGt4W6CaQYFDw@mail.gmail.com>
	<4E36CA14.7060501@offis.de>
	<CANLz8R6W9vUCL8TecTKB=gAP6pRf-Gy2OTARkkPAHG=SiyLgmQ@mail.gmail.com>
	<4E36DB9D.2020901@offis.de>
	<CANLz8R4dvRejW1Dqa8nN-tpSM=6TYj9F2qAzv=X15LHUtTi2Dg@mail.gmail.com>
Message-ID: <CANLz8R4CYzGUL5Lkd08PFp4gzW1ZWzsN+s2MvjuOS+B8tEer=Q@mail.gmail.com>

FYI - In the mean time, i pushed the following commit that take care of
explicitly specifying fPIC.

See
https://github.com/commontk/CTK/commit/4b95a9bef509e62a2d86621539829165500baa48

Thanks
Jc

On Mon, Aug 1, 2011 at 2:41 PM, Jean-Christophe Fillion-Robin <
jchris.fillionr at kitware.com> wrote:

>
>
> On Mon, Aug 1, 2011 at 1:00 PM, OFFIS DICOM Team <dicom at offis.de> wrote:
>
>> Hi,
>>
>> Am 01.08.2011 18:25, schrieb Jean-Christophe Fillion-Robin:
>>
>>  Regarding MT and /MTd, would it make sens to have a CMake option named
>>> DCMTK_MULTITHREADED ?
>>>
>>
>> If CMake automatically uses the flags it should and hands it over to all
>> external projects, this would be not needed. However, I'm not sure whether
>> this is actually the case.
>>
>
> CMake could pass down any additional flags by configuring the project with
> CMAKE_CXX_FLAGS and CMAKE_C_FLAGS.
>
>
>
>>
>> We already have a WITH_THREADS flag in DCMTK which adds libpthread if
>> existing/necessary. Usually, with threads is turned on.
>
>
> Does it mean that turning WITH_THREAD OFF won't append the /MT or /MTd
> flags ?
>
>
>>
>>
>>  Yes, and totally my fault ;)
>>>
>>>
>>> No prob :) Seems we identify and are on the good track to get the problem
>>> fixed.
>>>
>>
>> Yes, I hope so :)
>>
>>
>>
>>> DCMTK build by CTK is/was broken. The flag fPIC was not added
>>> automatically ...
>>>
>>
>> Yes, ok; as I understood this is needed when linking against the shared
>> DCMTK libraries from outside.
>
> This happen when linking a shared 64bits library against  a static library.
> The fPIC flag is required.
>
>>
>>
>>  * Get write access to official dcmtk ? * Ask dcmtk folks to mirror DCMTK
>>> on github so that we can fork and easily contribute patches ? * Mirror
>>> DCMTK ourself on commontk/dcmtk
>>>
>>>
>>> I would not be happy about any of these. Let's get things running on all
>>> platforms now; I will do my part as good as possible and with priority.
>>> Then we can take a fixed commit and update that from time to time in CTK.
>>> We can do that regulary, as you like, or as I can give you a hint if
>>> interesting features (for CTK) come in.
>>>
>>>
>>> I guess submitting patch to Offis directly seems to be the way to go. We
>>>  could also publish our topic branch on commontk/DCMTK to that you can
>>> review them before final integration upstream.
>>>
>>
>> Fine for me. My point is just that we should not let drift apart CTK too
>> much from the latest DCMTK version. Otherwise (like now..;)) it is double
>> work to align things again :)
>
> Excellent - And thanks for helping us catching up with the current DCMTK.
>
>
>>
>>  Assigned issue https://github.com/commontk/__**CTK/issues/22<https://github.com/commontk/__CTK/issues/22>
>>> <https://github.com/commontk/**CTK/issues/22<https://github.com/commontk/CTK/issues/22>>
>>> to Michael
>>>
>>> In the mean time, I will update CMakeExternal/DCMTK.cmake so that fPIC is
>>> passed.
>>>
>>>
>>> Shouldn't we not just change DCMTK's CMakeLists.txt? We need these flags
>>> anyway sooner or later, so we should also take it over. I would just take
>>> over the solution from the link (issues/22) into DCMTK's CMakeLists.txt.
>>>
>>>
>>> Very true - i didn't know how responsive you would be. Do you know when
>>> things will be fixed?
>>>
>>
>> I could commit it any time/immediately in DCMTK. My colleague noted that
>> we
>> should take care that we only put -fPIC into effect if it is understood by
>> the compiler and needed, so I wonder whether "IF(UNIX" is a sufficient
>> guard. Any hints or recommendations?
>
>
> You could for example do:
>
> #-----------------------------------------------------------------------------
>
> # To fix compilation problem: relocation R_X86_64_32 against `a local symbol' can not be
> # used when making a shared object; recompile with -fPIC
> # See http://www.cmake.org/pipermail/cmake/2007-May/014350.html
>
> #
> IF( CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64" )
>
>   SET_TARGET_PROPERTIES(log4qt PROPERTIES COMPILE_FLAGS "-fPIC")
> ENDIF( CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64" )
>
>
>
>
>>
>> Best regards,
>> Michael
>>
>> --
>> OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
>> E-Mail: dicom at offis.de, URL: http://dicom.offis.de
>>
>
>
>
> --
> +1 919 869 8849
>
>


-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110801/077dd2c8/attachment.htm>

From jchris.fillionr at kitware.com  Mon Aug  1 21:44:38 2011
From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin)
Date: Mon, 1 Aug 2011 17:44:38 -0400
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <4E371D85.6050606@offis.de>
References: <4E32755D.6000402@offis.de>
	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
	<CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
	<CANLz8R4cB7x2vRTw1LWYXJNL3+gww6f+XrjODCGt4W6CaQYFDw@mail.gmail.com>
	<4E36CA14.7060501@offis.de>
	<CANLz8R6W9vUCL8TecTKB=gAP6pRf-Gy2OTARkkPAHG=SiyLgmQ@mail.gmail.com>
	<4E36DB9D.2020901@offis.de>
	<CANLz8R4dvRejW1Dqa8nN-tpSM=6TYj9F2qAzv=X15LHUtTi2Dg@mail.gmail.com>
	<4E371D85.6050606@offis.de>
Message-ID: <CANLz8R63PrWx3QZDOcqapqyW2yL0qt6OuPqTiRT9xd70t3ywVQ@mail.gmail.com>

Excellent. I will revert my hack and set DCMTK_FORCE_FPIC_ON_UNIX to ON
instead.

Will also fix the SHA1.

Thanks
Jc

On Mon, Aug 1, 2011 at 5:41 PM, OFFIS DICOM Team <dicom at offis.de> wrote:

> Hi,
>
> Am 01.08.2011 20:41, schrieb Jean-Christophe Fillion-Robin:
>
>
>  We already have a WITH_THREADS flag in DCMTK which adds libpthread if
>> existing/necessary. Usually, with threads is turned on.
>>
>> Does it mean that turning WITH_THREAD OFF won't append the /MT or /MTd
>> flags ?
>>
>
> No, on Windows we usually use /MT and /MTd in DCMTK. For CTK, we now (since
> today) use the flags automatically determined by CMake, i.e. /MD and /MDd
> for compilation. In both cases we do not care about whether
> DCMTK_WITH_THREADS is on or off. Both, /MT(d) and /MD(d) flags, select a
> microsoft runtime library including threaded versions, as far as I (and you
> probably) know:
>
> http://msdn.microsoft.com/en-**us/library/2kzt1wy3(v=vs.71).**aspx<http://msdn.microsoft.com/en-us/library/2kzt1wy3%28v=vs.71%29.aspx>
>
> If WITH_THREADS is off, DCMTK's thread classes like OFThread are not
> compiled, and pthread and the like are not added to the linker.
>
>  I could commit it any time/immediately in DCMTK. My colleague noted that
>> we should take care that we only put -fPIC into effect if it is
>> understood by the compiler and needed, so I wonder whether "IF(UNIX" is
>> a sufficient guard. Any hints or recommendations?
>>
>>
>> You could for example do: [...]
>>
>
> I inserted a flag DCMTK_FORCE_FPIC_ON_UNIX in DCMTK [1] which can be set
> from CTK's DCMTK.cmake via CMAKE_ARGS. If this makes sense, I can change
> the
> DCMTK.cmake accordingly. Also, I removed mktemp from the tparser.cc [2] so
> the warning an unix should be gone now.
>
> Thanks for helping!
>
> Michael
>
> [1]
> http://git.dcmtk.org/web?p=**dcmtk.git;a=commitdiff;h=**
> 09db15ff595da6c35330fd7f63669a**eb9952e015<http://git.dcmtk.org/web?p=dcmtk.git;a=commitdiff;h=09db15ff595da6c35330fd7f63669aeb9952e015>
>
> [2] http://git.dcmtk.org/web?p=**dcmtk.git;a=commitdiff;h=**
> 96ce7c46b48245512385170bfb72ec**3cdc32a3a6<http://git.dcmtk.org/web?p=dcmtk.git;a=commitdiff;h=96ce7c46b48245512385170bfb72ec3cdc32a3a6>
>
>
> --
> OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
> E-Mail: dicom at offis.de, URL: http://dicom.offis.de
>



-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110801/ec4cd337/attachment.htm>

From jchris.fillionr at kitware.com  Mon Aug  1 22:03:45 2011
From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin)
Date: Mon, 1 Aug 2011 18:03:45 -0400
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <CANLz8R63PrWx3QZDOcqapqyW2yL0qt6OuPqTiRT9xd70t3ywVQ@mail.gmail.com>
References: <4E32755D.6000402@offis.de>
	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
	<CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
	<CANLz8R4cB7x2vRTw1LWYXJNL3+gww6f+XrjODCGt4W6CaQYFDw@mail.gmail.com>
	<4E36CA14.7060501@offis.de>
	<CANLz8R6W9vUCL8TecTKB=gAP6pRf-Gy2OTARkkPAHG=SiyLgmQ@mail.gmail.com>
	<4E36DB9D.2020901@offis.de>
	<CANLz8R4dvRejW1Dqa8nN-tpSM=6TYj9F2qAzv=X15LHUtTi2Dg@mail.gmail.com>
	<4E371D85.6050606@offis.de>
	<CANLz8R63PrWx3QZDOcqapqyW2yL0qt6OuPqTiRT9xd70t3ywVQ@mail.gmail.com>
Message-ID: <CANLz8R4sOH-F-G_LCedDmsU60hupU=PVX058M1nwckH5dE67zA@mail.gmail.com>

All set - See
https://github.com/commontk/CTK/commit/d4fb3a60ce5d729e44527071d6951f933d6607bd

Issues #21 and #22 are closed.

Note also that adding "Closes #21" to the commit message automatically
closes and links the commit with the issue.

See https://github.com/blog/411-github-issue-tracker for more details.

Thanks
Jc

On Mon, Aug 1, 2011 at 5:44 PM, Jean-Christophe Fillion-Robin <
jchris.fillionr at kitware.com> wrote:

> Excellent. I will revert my hack and set DCMTK_FORCE_FPIC_ON_UNIX to ON
> instead.
>
> Will also fix the SHA1.
>
> Thanks
> Jc
>
>
> On Mon, Aug 1, 2011 at 5:41 PM, OFFIS DICOM Team <dicom at offis.de> wrote:
>
>> Hi,
>>
>> Am 01.08.2011 20:41, schrieb Jean-Christophe Fillion-Robin:
>>
>>
>>  We already have a WITH_THREADS flag in DCMTK which adds libpthread if
>>> existing/necessary. Usually, with threads is turned on.
>>>
>>> Does it mean that turning WITH_THREAD OFF won't append the /MT or /MTd
>>> flags ?
>>>
>>
>> No, on Windows we usually use /MT and /MTd in DCMTK. For CTK, we now
>> (since
>> today) use the flags automatically determined by CMake, i.e. /MD and /MDd
>> for compilation. In both cases we do not care about whether
>> DCMTK_WITH_THREADS is on or off. Both, /MT(d) and /MD(d) flags, select a
>> microsoft runtime library including threaded versions, as far as I (and
>> you
>> probably) know:
>>
>> http://msdn.microsoft.com/en-**us/library/2kzt1wy3(v=vs.71).**aspx<http://msdn.microsoft.com/en-us/library/2kzt1wy3%28v=vs.71%29.aspx>
>>
>> If WITH_THREADS is off, DCMTK's thread classes like OFThread are not
>> compiled, and pthread and the like are not added to the linker.
>>
>>  I could commit it any time/immediately in DCMTK. My colleague noted that
>>> we should take care that we only put -fPIC into effect if it is
>>> understood by the compiler and needed, so I wonder whether "IF(UNIX" is
>>> a sufficient guard. Any hints or recommendations?
>>>
>>>
>>> You could for example do: [...]
>>>
>>
>> I inserted a flag DCMTK_FORCE_FPIC_ON_UNIX in DCMTK [1] which can be set
>> from CTK's DCMTK.cmake via CMAKE_ARGS. If this makes sense, I can change
>> the
>> DCMTK.cmake accordingly. Also, I removed mktemp from the tparser.cc [2] so
>> the warning an unix should be gone now.
>>
>> Thanks for helping!
>>
>> Michael
>>
>> [1]
>> http://git.dcmtk.org/web?p=**dcmtk.git;a=commitdiff;h=**
>> 09db15ff595da6c35330fd7f63669a**eb9952e015<http://git.dcmtk.org/web?p=dcmtk.git;a=commitdiff;h=09db15ff595da6c35330fd7f63669aeb9952e015>
>>
>> [2] http://git.dcmtk.org/web?p=**dcmtk.git;a=commitdiff;h=**
>> 96ce7c46b48245512385170bfb72ec**3cdc32a3a6<http://git.dcmtk.org/web?p=dcmtk.git;a=commitdiff;h=96ce7c46b48245512385170bfb72ec3cdc32a3a6>
>>
>>
>> --
>> OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
>> E-Mail: dicom at offis.de, URL: http://dicom.offis.de
>>
>
>
>
> --
> +1 919 869 8849
>
>


-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110801/667836e6/attachment.htm>

From domibel at debian.org  Tue Aug  2 18:19:04 2011
From: domibel at debian.org (Dominique Belhachemi)
Date: Tue, 2 Aug 2011 14:19:04 -0400
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <CANLz8R4dvRejW1Dqa8nN-tpSM=6TYj9F2qAzv=X15LHUtTi2Dg@mail.gmail.com>
References: <4E32755D.6000402@offis.de>
	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
	<CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
	<CANLz8R4cB7x2vRTw1LWYXJNL3+gww6f+XrjODCGt4W6CaQYFDw@mail.gmail.com>
	<4E36CA14.7060501@offis.de>
	<CANLz8R6W9vUCL8TecTKB=gAP6pRf-Gy2OTARkkPAHG=SiyLgmQ@mail.gmail.com>
	<4E36DB9D.2020901@offis.de>
	<CANLz8R4dvRejW1Dqa8nN-tpSM=6TYj9F2qAzv=X15LHUtTi2Dg@mail.gmail.com>
Message-ID: <CAAvaLCzj+woOT_dMK7AXZQxFhSdnLzJUeXMRFJwbxxA48c=1mg@mail.gmail.com>

On Mon, Aug 1, 2011 at 2:41 PM, Jean-Christophe Fillion-Robin
<jchris.fillionr at kitware.com> wrote:
>

> You could for example do:
>
> #-----------------------------------------------------------------------------
>
> # To fix compilation problem: relocation R_X86_64_32 against `a local
> symbol' can not be
>
> # used when making a shared object; recompile with -fPIC
> # See http://www.cmake.org/pipermail/cmake/2007-May/014350.html
>
> #
> IF( CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64" )
>
> ??SET_TARGET_PROPERTIES(log4qt PROPERTIES COMPILE_FLAGS "-fPIC")
>
> ENDIF( CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64" )
>
>
>
Hi,
this won't help on other platforms than x86_64 . I opened a bug and
will think about a solution

   http://www.na-mic.org/Bug/view.php?id=1294

Thanks
Dominique


From jchris.fillionr at kitware.com  Tue Aug  2 18:33:55 2011
From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin)
Date: Tue, 2 Aug 2011 14:33:55 -0400
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <CAAvaLCzj+woOT_dMK7AXZQxFhSdnLzJUeXMRFJwbxxA48c=1mg@mail.gmail.com>
References: <4E32755D.6000402@offis.de>
	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
	<CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
	<CANLz8R4cB7x2vRTw1LWYXJNL3+gww6f+XrjODCGt4W6CaQYFDw@mail.gmail.com>
	<4E36CA14.7060501@offis.de>
	<CANLz8R6W9vUCL8TecTKB=gAP6pRf-Gy2OTARkkPAHG=SiyLgmQ@mail.gmail.com>
	<4E36DB9D.2020901@offis.de>
	<CANLz8R4dvRejW1Dqa8nN-tpSM=6TYj9F2qAzv=X15LHUtTi2Dg@mail.gmail.com>
	<CAAvaLCzj+woOT_dMK7AXZQxFhSdnLzJUeXMRFJwbxxA48c=1mg@mail.gmail.com>
Message-ID: <CANLz8R5Y4GBAx1q3TjrNmKPbW4-QHt6w__19pPcLAKgV7swZwA@mail.gmail.com>

Hi Folks,

Thanks Dominique for looking into that specific issue.

Could you involve the CMake community so that everybody come to a consensus
regarding the best of addressing the problem ?

Otherwise, there are still issue related to building against DCMTK.

See https://github.com/commontk/CTK/issues/25

I won't have time to look into these issues. Will be leaving for vacation in
few hours and will be back ~August 13th.

If somebody take the lead on that issue. Please assign it to your self.

Thanks
Jc


On Tue, Aug 2, 2011 at 2:19 PM, Dominique Belhachemi <domibel at debian.org>wrote:

> On Mon, Aug 1, 2011 at 2:41 PM, Jean-Christophe Fillion-Robin
> <jchris.fillionr at kitware.com> wrote:
> >
>
> > You could for example do:
> >
> >
> #-----------------------------------------------------------------------------
> >
> > # To fix compilation problem: relocation R_X86_64_32 against `a local
> > symbol' can not be
> >
> > # used when making a shared object; recompile with -fPIC
> > # See http://www.cmake.org/pipermail/cmake/2007-May/014350.html
> >
> > #
> > IF( CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64" )
> >
> >   SET_TARGET_PROPERTIES(log4qt PROPERTIES COMPILE_FLAGS "-fPIC")
> >
> > ENDIF( CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64" )
> >
> >
> >
> Hi,
> this won't help on other platforms than x86_64 . I opened a bug and
> will think about a solution
>
>   http://www.na-mic.org/Bug/view.php?id=1294
>
> Thanks
> Dominique
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>



-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110802/c4fc52a9/attachment.htm>

From jchris.fillionr at kitware.com  Tue Aug  2 19:06:51 2011
From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin)
Date: Tue, 2 Aug 2011 15:06:51 -0400
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <4E3849AA.2010704@dkfz-heidelberg.de>
References: <4E32755D.6000402@offis.de>
	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
	<CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
	<CANLz8R4cB7x2vRTw1LWYXJNL3+gww6f+XrjODCGt4W6CaQYFDw@mail.gmail.com>
	<4E36CA14.7060501@offis.de>
	<CANLz8R6W9vUCL8TecTKB=gAP6pRf-Gy2OTARkkPAHG=SiyLgmQ@mail.gmail.com>
	<4E36DB9D.2020901@offis.de>
	<CANLz8R4dvRejW1Dqa8nN-tpSM=6TYj9F2qAzv=X15LHUtTi2Dg@mail.gmail.com>
	<CAAvaLCzj+woOT_dMK7AXZQxFhSdnLzJUeXMRFJwbxxA48c=1mg@mail.gmail.com>
	<CANLz8R5Y4GBAx1q3TjrNmKPbW4-QHt6w__19pPcLAKgV7swZwA@mail.gmail.com>
	<4E3849AA.2010704@dkfz-heidelberg.de>
Message-ID: <CANLz8R7ybDCCCM0kj+gDc79ZX=adh4whCMzZ=dZmGXLUoHxwHQ@mail.gmail.com>

Thanks ! Leaving for real now ..
Jc

On Tue, Aug 2, 2011 at 3:02 PM, Sascha Zelzer
<s.zelzer at dkfz-heidelberg.de>wrote:

> **
> Hi,
>
> I will fix issue #25, no big deal.
>
> Have a nice vacation and do not check your mail :-)
>
> - Sascha
>
>
> On 08/02/2011 08:33 PM, Jean-Christophe Fillion-Robin wrote:
>
> Hi Folks,
>
> Thanks Dominique for looking into that specific issue.
>
> Could you involve the CMake community so that everybody come to a consensus
> regarding the best of addressing the problem ?
>
> Otherwise, there are still issue related to building against DCMTK.
>
> See https://github.com/commontk/CTK/issues/25
>
> I won't have time to look into these issues. Will be leaving for vacation
> in few hours and will be back ~August 13th.
>
> If somebody take the lead on that issue. Please assign it to your self.
>
> Thanks
> Jc
>
>
> On Tue, Aug 2, 2011 at 2:19 PM, Dominique Belhachemi <domibel at debian.org>wrote:
>
>> On Mon, Aug 1, 2011 at 2:41 PM, Jean-Christophe Fillion-Robin
>> <jchris.fillionr at kitware.com> wrote:
>> >
>>
>>  > You could for example do:
>> >
>> >
>> #-----------------------------------------------------------------------------
>> >
>> > # To fix compilation problem: relocation R_X86_64_32 against `a local
>> > symbol' can not be
>> >
>> > # used when making a shared object; recompile with -fPIC
>> > # See http://www.cmake.org/pipermail/cmake/2007-May/014350.html
>> >
>> > #
>> > IF( CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64" )
>> >
>> >   SET_TARGET_PROPERTIES(log4qt PROPERTIES COMPILE_FLAGS "-fPIC")
>> >
>> > ENDIF( CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64" )
>> >
>> >
>> >
>>  Hi,
>> this won't help on other platforms than x86_64 . I opened a bug and
>> will think about a solution
>>
>>   http://www.na-mic.org/Bug/view.php?id=1294
>>
>> Thanks
>> Dominique
>>  _______________________________________________
>> Ctk-developers mailing list
>> Ctk-developers at commontk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>
>
>
>
> --
> +1 919 869 8849
>
>
>


-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110802/312da0a2/attachment.htm>

From s.zelzer at dkfz-heidelberg.de  Tue Aug  2 19:02:02 2011
From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer)
Date: Tue, 02 Aug 2011 21:02:02 +0200
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <CANLz8R5Y4GBAx1q3TjrNmKPbW4-QHt6w__19pPcLAKgV7swZwA@mail.gmail.com>
References: <4E32755D.6000402@offis.de>	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>	<CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>	<CANLz8R4cB7x2vRTw1LWYXJNL3+gww6f+XrjODCGt4W6CaQYFDw@mail.gmail.com>	<4E36CA14.7060501@offis.de>	<CANLz8R6W9vUCL8TecTKB=gAP6pRf-Gy2OTARkkPAHG=SiyLgmQ@mail.gmail.com>	<4E36DB9D.2020901@offis.de>	<CANLz8R4dvRejW1Dqa8nN-tpSM=6TYj9F2qAzv=X15LHUtTi2Dg@mail.gmail.com>	<CAAvaLCzj+woOT_dMK7AXZQxFhSdnLzJUeXMRFJwbxxA48c=1mg@mail.gmail.com>
	<CANLz8R5Y4GBAx1q3TjrNmKPbW4-QHt6w__19pPcLAKgV7swZwA@mail.gmail.com>
Message-ID: <4E3849AA.2010704@dkfz-heidelberg.de>

Hi,

I will fix issue #25, no big deal.

Have a nice vacation and do not check your mail :-)

- Sascha

On 08/02/2011 08:33 PM, Jean-Christophe Fillion-Robin wrote:
> Hi Folks,
>
> Thanks Dominique for looking into that specific issue.
>
> Could you involve the CMake community so that everybody come to a 
> consensus regarding the best of addressing the problem ?
>
> Otherwise, there are still issue related to building against DCMTK.
>
> See https://github.com/commontk/CTK/issues/25
>
> I won't have time to look into these issues. Will be leaving for 
> vacation in few hours and will be back ~August 13th.
>
> If somebody take the lead on that issue. Please assign it to your self.
>
> Thanks
> Jc
>
>
> On Tue, Aug 2, 2011 at 2:19 PM, Dominique Belhachemi 
> <domibel at debian.org <mailto:domibel at debian.org>> wrote:
>
>     On Mon, Aug 1, 2011 at 2:41 PM, Jean-Christophe Fillion-Robin
>     <jchris.fillionr at kitware.com <mailto:jchris.fillionr at kitware.com>>
>     wrote:
>     >
>
>     > You could for example do:
>     >
>     >
>     #-----------------------------------------------------------------------------
>     >
>     > # To fix compilation problem: relocation R_X86_64_32 against `a
>     local
>     > symbol' can not be
>     >
>     > # used when making a shared object; recompile with -fPIC
>     > # See http://www.cmake.org/pipermail/cmake/2007-May/014350.html
>     >
>     > #
>     > IF( CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64" )
>     >
>     >   SET_TARGET_PROPERTIES(log4qt PROPERTIES COMPILE_FLAGS "-fPIC")
>     >
>     > ENDIF( CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64" )
>     >
>     >
>     >
>     Hi,
>     this won't help on other platforms than x86_64 . I opened a bug and
>     will think about a solution
>
>     http://www.na-mic.org/Bug/view.php?id=1294
>
>     Thanks
>     Dominique
>     _______________________________________________
>     Ctk-developers mailing list
>     Ctk-developers at commontk.org <mailto:Ctk-developers at commontk.org>
>     http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>
>
>
> -- 
> +1 919 869 8849 <tel:%2B1%20919%20869%208849>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110802/7ab09dad/attachment.htm>

From s.zelzer at dkfz-heidelberg.de  Wed Aug  3 07:41:30 2011
From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer)
Date: Wed, 03 Aug 2011 09:41:30 +0200
Subject: [Ctk-developers] VS2010 support
In-Reply-To: <4E29A040.3080405@dkfz-heidelberg.de>
References: <4E296184.20903@dkfz-heidelberg.de>
	<4E29A040.3080405@dkfz-heidelberg.de>
Message-ID: <4E38FBAA.8010807@dkfz-heidelberg.de>

Hi again,

thanks to JC (who forwarded my post to the CMake mailing list) I could 
identify the problem (for details, see 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/37472 ).

Essentially, supplying a GIT_TAG argument together with a UPDATE_COMMAND 
(could also be the default update command, which may be non-empty) in 
the ExternalProject_Add() macro call will skip all steps after the 
update step in Visual Studio 2010.

This problem actually reveals some "issues" with our scripts in the 
CMakeExternals directory. I would like to suggest the following:

1.) Projects which are hosted on github/commontk

I would prefer to keep GIT_TAG origin/patched or similar, but until the 
bug is fixed, we could specify a specific SHA1 value and add 
UPDATE_COMMAND ""

This affects: CTKData, Log4Qt, PythonQt, QtSOAP, ZMQ (although hosted at 
github.com/patrickcheng/zmq2)

2.) True external projects

Here I would actually prefer GIT_TAG origin/tag where "tag" points to a 
release version. The relevant projects are:

- DCMTK: we already use a fixed tag, just needs UPDATE_COMMAND ""
- ITK: Use GIT_TAG v3.20.0
- VTK: If I rember correctly, the CTK VTK widgets need a very recent 
VTK, so use a fixed SHA1 instead of origin/master


I made these changes locally and successfully compiled CTK (I enabled 
everything without Python support) with VS2010 SP1.

What do you think?


Thanks,
Sascha


On 07/22/2011 06:07 PM, Sascha Zelzer wrote:
> Hi,
>
> there is something very strange going on. The generated VS 2010 projects
> (I am using the Express editions, 32bit) for the external dependencies
> like DCMTK, Log4Qt, etc. only call the download step of the
> ExternalProject_add call in our superbuild scripts. The projects are not
> configured and build.
>
> Did anybody experience the same? I tried with and without the VS 2010
> SP1 and with CMake 2.8.4 and 2.8.5.
>
> Thanks,
> Sascha
>
> On 07/22/2011 01:39 PM, Sascha Zelzer wrote:
>> Hi Folks,
>>
>> I would like to get Visual Studio 2010 compatibility for CTK.
>>
>> Currently, it looks like I will have to copy ExternalProject.cmake to
>> CTK for the CMAKE_CACHE_ARGS argument. Then a couple of small
>> modifications should do.
>>
>> Any other ideas or objections?
>>
>> Thanks,
>>
>> Sascha
>> _______________________________________________
>> Ctk-developers mailing list
>> Ctk-developers at commontk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers



From s.zelzer at dkfz-heidelberg.de  Wed Aug  3 08:07:36 2011
From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer)
Date: Wed, 03 Aug 2011 10:07:36 +0200
Subject: [Ctk-developers] org_commontk_dah_app depends on
	org_commontk_dah_core
In-Reply-To: <CAKoWPPGgFajM+0sV-LEeZ3SpxpEsW4RKLzRWcLbciJh5ROs=7g@mail.gmail.com>
References: <CAKoWPPGgFajM+0sV-LEeZ3SpxpEsW4RKLzRWcLbciJh5ROs=7g@mail.gmail.com>
Message-ID: <4E3901C8.9090409@dkfz-heidelberg.de>

Hi Julien

On 08/01/2011 11:30 PM, Julien Finet wrote:
> Hola CTKers,
>
> Is this normal that org_commontk_dah_app depends 
> of org_commontk_dah_core ?
Yes, that is intended.
> Is org_commontk_dah_core really a plugin ?
Yes.
>
> If so (or even if it shouldn't), a target_libraries.cmake 
> referencing org_commontk_dah_core is probably needed in order to avoid 
> that kind of error at first build:
> http://my.cdash.org/viewBuildError.php?onlydeltap&buildid=215143 
> <http://my.cdash.org/viewBuildError.php?onlydeltap&buildid=215143>
>
For plug-ins, dependencies to other plug-ins are encoded in the 
manifest_headers.cmake file (instead of target_libraries.cmake). This 
makes the information available at runtime. The dependencies are already 
correctly set-up but the order of the plug-ins in the CMakeLists.txt did 
not reflect their dependencies. Multiple CMake configure runs hid the 
problem and I fixed it just now.

> I take the opportunity of this email to mention some warnings :-) :
> http://my.cdash.org/viewBuildError.php?type=1&onlydeltap&buildid=215143 <http://my.cdash.org/viewBuildError.php?type=1&onlydeltap&buildid=215143>
>
>
Fixed.

Thanks for reporting the issues,

Sascha


From benoit.bleuze at inria.fr  Wed Aug  3 13:36:49 2011
From: benoit.bleuze at inria.fr (Benoit Bleuze)
Date: Wed, 3 Aug 2011 15:36:49 +0200 (CEST)
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <4E3298C5.6040402@dkfz-heidelberg.de>
Message-ID: <1509021664.1935157.1312378609220.JavaMail.root@zmbs4.inria.fr>

This discussion is a bit diverging from the the engineering side towards compilation issues.

Of course solution 1 requires to take special care that each new commit in DCMTK head doesn't break parts that were deemed common to both versions at first.
That is to me the biggest problem with solution 1. and therefore I would discard it.

I can share the experience we have developing Medinria 2.x: we froze to 3.6  (in fact some commits after that allowed for shared libraries). We are still checking out that specific SHA1.
I don't think you guys at Offis tag your repos with regular snapshots? At least not since 3.6.0, but do you plan doing so for say intermediate versions as Marco suggested?
If you don't, then I would stick to 3.6.0 strictly, now if DCMTK does release intermediate tagged versions, I would try to stick to these snapshots, but definitely no dual versions except in a specific DCMTK-BleedingEdge branch of CTK.

And indeed Marco, Just a tag at several intervals in time would be beneficial to CTK itself I reckon.
Even you don't "release" anything, a tag on a commit that generally compiles well and with no obvious crash in core functionalities happening soonish, 
and then every month or so would be a blessing, just to know what we are talking about. Also it help when doing regression tests (when not using the git bissect command).

My useless two cents,
Ben

----- Original Message -----
> Hi all,
> 
> regarding fixed version vs HEAD I want to describe the situation for
> MITK and DCMTK here but maybe it also affects other projects using CTK
> and we could use it as a blueprint for similar situations:
> 
> - we already use DCMTK in MITK
> - some projects using MITK require fixed versions of external
> libraries,
> at least for "critical" components, and DCMTK is critical since it
> deals
> with patient and image data
> - recently we started using CTK in MITK and of course we would like to
> "share" the same version of DCMTK
> 
> In my opinion there are different solutions to this:
> 
> 1. We adapt the CTK code that uses DCMTK in a way that it supports
> both
> 3.6 and the current HEAD. Then projects using CTK could provide their
> own DCMTK and everything works. It would still duplicate the CMake
> code
> to build DCMTK as an external project, so we could maybe insert a
> switch
> in CTK to select 3.6 or HEAD.
> 
> 2. We leave the HEAD version. External projects have to make sure by
> their own testing that the required DCMTK functionality works as
> expected. Even then there should be some CMake mechanism to "freeze"
> the
> DCMTK version that is checked out.
> 
> 3. We stick to 3.6 and wait for the next official release.
> 
> I would prefer 1., but I cannot estimate how much effort this would be
> and how much functionality we would "loose" in CTK while using the
> stable version.
> For 2.: maybe the intermediate versions of DCMTK are also very
> reliable
> and stable and the "official releases" are only snapshots without
> special testing.
> 
> Another remark regarding "versions": I know we agreed that CTK won't
> have released versions soon since it is under heavy development. But I
> think we shouldn't wait too long. For MITK we are now referring to
> fixed
> version by using GIT hashes which works but is sometimes cubersome.
> The
> debian packages already have a version number (0.1-2, 0.1-3). I know
> this is very experimental, but still we could think of tagging certain
> version of CTK just as a reference point for external projects.
> 
> Ok, sorry for the long mail, please comment!
> 
> Marco
> 
> 
> 
> 
> 
> 
> 
> On 07/29/2011 12:05 PM, OFFIS DICOM Team wrote:
> > Hi Marco,
> >
> > thanks for scanning through the changes!
> >
> > Am 29.07.2011 11:57, schrieb Marco Nolden:
> >
> >>> I also changed the repository location in the superbuild to fetch
> >>> DCMTK
> >>> from the official OFFIS repository at
> >>> http://git.dcmtk.org/dcmtk.git .
> >>> That works for me here.
> >>
> >> It works, but it is rather slow, takes about 10 minutes to clone
> >> from
> >> DKFZ. I would also prefer to have an option to use an official
> >> release of
> >> DCMTK, since we do that in MITK and also use CTK there. I already
> >> commented on github, overlapping with this email, so I post the
> >> link
> >> here, maybe the others could also comment on that topic:
> >>
> >> https://github.com/commontk/CTK/commit/1414293aec6c76bc5788e3ade9979150974bc568#commitcomment-502670
> >
> > Please see some comments there.
> >
> > Regarding the clone time: I guess the server is not the fastest
> > machine and
> > also http is not really the fastest git protocol ;) Maybe we can
> > work on the
> > second issue.
> >
> > However, also consider that fetching updates will be much faster
> > once you
> > have a cloned copy.
> >
> > Another option would be to not clone all commits from the last 15
> > years from
> > DCMTK but to only clone the last 3 years or something. I did not try
> > that but guess it is possible with git (right?) and maybe leads to a
> > huge
> > speedup.
> >
> >>> Nevertheless, since these are my first actual commits to CTK, I
> >>> expect
> >>>  that I have done some mistakes, hopefully not too many serious
> >>>  ones ;)
> >>>  Please tell me and I will correct that as soon as possible.
> >>>
> >> Everything looks fine to me. There is just one "Merge
> >> remote-tracking
> >> branch 'origin/master'" commit we try to avoid in CTK by rebasing,
> >> but
> >> that was probably just an accident.
> >
> > Yes, thanks for noting and sorry for that. I should take better care
> > of this
> > in the future.
> >
> > All the best,
> > Michael
> >
> 
> 
> --
> ----------------------------------------------------------------------
> 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
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers


From dicom at offis.de  Wed Aug  3 14:07:26 2011
From: dicom at offis.de (OFFIS DICOM Team)
Date: Wed, 03 Aug 2011 16:07:26 +0200
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <1509021664.1935157.1312378609220.JavaMail.root@zmbs4.inria.fr>
References: <1509021664.1935157.1312378609220.JavaMail.root@zmbs4.inria.fr>
Message-ID: <4E39561E.1040203@offis.de>

Hi Benoit and everbody,

Am 03.08.2011 15:36, schrieb Benoit Bleuze:
> This discussion is a bit diverging from the the engineering side towards
>  compilation issues.

Hopefully those are mostly solved now so everybody can compile and use CTK
with the current DCMTK. If there are any urgent issues, let me know or open
an issue on github and assign me. IMHO many of problems can be solved once
and will not appear again to soon, since most of them were due to
incompatible/insufficient build settings.
>
> Of course solution 1 requires to take special care that each new commit
> in DCMTK head doesn't break parts that were deemed common to both
> versions at first. That is to me the biggest problem with solution 1. and
> therefore I would discard it.
>
> I can share the experience we have developing Medinria 2.x: we froze to
> 3.6  (in fact some commits after that allowed for shared libraries). We
> are still checking out that specific SHA1. I don't think you guys at
> Offis tag your repos with regular snapshots?

No, so far we do not on git. We offer regular snapshot packages [1] every
1-2 months if we added a special feature, or did another step forward that
we think is worth releasing a new packaged version. Note that a snapshot
does not undergo significantly more testing than a normal checkin.

> At least not since 3.6.0, but do you plan doing so for say intermediate
> versions as Marco suggested? If you don't, then I would stick to 3.6.0
> strictly, now if DCMTK does release intermediate tagged versions, I
> would try to stick to these snapshots, but definitely no dual versions
> except in a specific DCMTK-BleedingEdge branch of CTK.

This is somehow what we do now in CTK -- selecting a specific tag and use
that. I think this is a good way to do it, if there are no snapshot
taggings. We could add those tags (must talk to my colleagues though) but I
doubt that you would win too much.

We could also informally align CTK with the snapshots, i.e. if a snapshot
comes out every 1-2 months, I locally update CTK (if necessary) to that
DCMTK tag, test that on my windows and linux maschines and publish the patch
to you, preferably (:-)) on my own branch on github. Then people can test it
before the new DCMTK snapshot version is taken over into the main branch.
>
> And indeed Marco, Just a tag at several intervals in time would be
> beneficial to CTK itself I reckon. Even you don't "release" anything, a
> tag on a commit that generally compiles well and with no obvious crash in
> core functionalities happening soonish, and then every month or so would
> be a blessing, just to know what we are talking about. Also it help when
> doing regression tests (when not using the git bissect command).

I agree.

> My useless two cents

and another two ;)

Michael

[1] http://dicom.offis.de/download/dcmtk/snapshot/

-- 
OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
E-Mail: dicom at offis.de, URL: http://dicom.offis.de


From julien.finet at kitware.com  Wed Aug  3 14:29:39 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Wed, 3 Aug 2011 10:29:39 -0400
Subject: [Ctk-developers] org_commontk_dah_app depends on
	org_commontk_dah_core
In-Reply-To: <4E3901C8.9090409@dkfz-heidelberg.de>
References: <CAKoWPPGgFajM+0sV-LEeZ3SpxpEsW4RKLzRWcLbciJh5ROs=7g@mail.gmail.com>
	<4E3901C8.9090409@dkfz-heidelberg.de>
Message-ID: <CAKoWPPGMMU1iWnjbiV3+LBJn6ox9_55GogD6JNF_cb4JAdOL+w@mail.gmail.com>

On Wed, Aug 3, 2011 at 4:07 AM, Sascha Zelzer
<s.zelzer at dkfz-heidelberg.de>wrote:

> For plug-ins, dependencies to other plug-ins are encoded in the
> manifest_headers.cmake file (instead of target_libraries.cmake). This makes
> the information available at runtime. The dependencies are already correctly
> set-up but the order of the plug-ins in the CMakeLists.txt did not reflect
> their dependencies. Multiple CMake configure runs hid the problem and I
> fixed it just now.'
>

Do you mean that the dependency is now handled by the order of
add_subdirectory calls ?
If I understand correctly, org_commontk_dah_app can only be built if
org_commontk_dah_core
is built (not just configured).
As there is no direct dependencies between org_commontk_dah_app and
org_commontk_dah_core,
Visual Studio can run them in parallel, no ? (and Visual Studio, by default,
build projects in parallel)
So it seems to be prone to a race condition. Is there something I didn't
take into account ?


>  I take the opportunity of this email to mention some warnings :-) :
>> http://my.cdash.org/**viewBuildError.php?type=1&**
>> onlydeltap&buildid=215143<http://my.cdash.org/viewBuildError.php?type=1&onlydeltap&buildid=215143><
>> http://my.cdash.org/**viewBuildError.php?type=1&**
>> onlydeltap&buildid=215143<http://my.cdash.org/viewBuildError.php?type=1&onlydeltap&buildid=215143>
>> >
>>
> Fixed.
>
Thanks !

Julien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110803/e29c2f29/attachment.htm>

From julien.finet at kitware.com  Wed Aug  3 14:44:53 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Wed, 3 Aug 2011 10:44:53 -0400
Subject: [Ctk-developers] VS2010 support
In-Reply-To: <4E38FBAA.8010807@dkfz-heidelberg.de>
References: <4E296184.20903@dkfz-heidelberg.de>
	<4E29A040.3080405@dkfz-heidelberg.de>
	<4E38FBAA.8010807@dkfz-heidelberg.de>
Message-ID: <CAKoWPPFDxCO4fNv2qhYWBmQtCK-qR5sZCQsgYi57ELb=a6N+0g@mail.gmail.com>

That sounds fine by me, however, I think we should have some way to
optionally specify a custom tag ?
So that we could have dashboards (on a next branch?) running with external
bleeding edge branches.

Julien.

On Wed, Aug 3, 2011 at 3:41 AM, Sascha Zelzer
<s.zelzer at dkfz-heidelberg.de>wrote:

> Hi again,
>
> thanks to JC (who forwarded my post to the CMake mailing list) I could
> identify the problem (for details, see http://thread.gmane.org/gmane.**
> comp.programming.tools.cmake.**user/37472<http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/37472>).
>
> Essentially, supplying a GIT_TAG argument together with a UPDATE_COMMAND
> (could also be the default update command, which may be non-empty) in the
> ExternalProject_Add() macro call will skip all steps after the update step
> in Visual Studio 2010.
>
> This problem actually reveals some "issues" with our scripts in the
> CMakeExternals directory. I would like to suggest the following:
>
> 1.) Projects which are hosted on github/commontk
>
> I would prefer to keep GIT_TAG origin/patched or similar, but until the bug
> is fixed, we could specify a specific SHA1 value and add UPDATE_COMMAND ""
>
> This affects: CTKData, Log4Qt, PythonQt, QtSOAP, ZMQ (although hosted at
> github.com/patrickcheng/zmq2)
>
> 2.) True external projects
>
> Here I would actually prefer GIT_TAG origin/tag where "tag" points to a
> release version. The relevant projects are:
>
> - DCMTK: we already use a fixed tag, just needs UPDATE_COMMAND ""
> - ITK: Use GIT_TAG v3.20.0
> - VTK: If I rember correctly, the CTK VTK widgets need a very recent VTK,
> so use a fixed SHA1 instead of origin/master
>
>
> I made these changes locally and successfully compiled CTK (I enabled
> everything without Python support) with VS2010 SP1.
>
> What do you think?
>
>
> Thanks,
> Sascha
>
>
>
> On 07/22/2011 06:07 PM, Sascha Zelzer wrote:
>
>> Hi,
>>
>> there is something very strange going on. The generated VS 2010 projects
>> (I am using the Express editions, 32bit) for the external dependencies
>> like DCMTK, Log4Qt, etc. only call the download step of the
>> ExternalProject_add call in our superbuild scripts. The projects are not
>> configured and build.
>>
>> Did anybody experience the same? I tried with and without the VS 2010
>> SP1 and with CMake 2.8.4 and 2.8.5.
>>
>> Thanks,
>> Sascha
>>
>> On 07/22/2011 01:39 PM, Sascha Zelzer wrote:
>>
>>> Hi Folks,
>>>
>>> I would like to get Visual Studio 2010 compatibility for CTK.
>>>
>>> Currently, it looks like I will have to copy ExternalProject.cmake to
>>> CTK for the CMAKE_CACHE_ARGS argument. Then a couple of small
>>> modifications should do.
>>>
>>> Any other ideas or objections?
>>>
>>> Thanks,
>>>
>>> Sascha
>>> ______________________________**_________________
>>> Ctk-developers mailing list
>>> Ctk-developers at commontk.org
>>> http://public.kitware.com/cgi-**bin/mailman/listinfo/ctk-**developers<http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers>
>>>
>> ______________________________**_________________
>> Ctk-developers mailing list
>> Ctk-developers at commontk.org
>> http://public.kitware.com/cgi-**bin/mailman/listinfo/ctk-**developers<http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers>
>>
>
> ______________________________**_________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-**bin/mailman/listinfo/ctk-**developers<http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110803/01a1b5bb/attachment.htm>

From s.zelzer at dkfz-heidelberg.de  Wed Aug  3 14:50:08 2011
From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer)
Date: Wed, 03 Aug 2011 16:50:08 +0200
Subject: [Ctk-developers] org_commontk_dah_app depends on
	org_commontk_dah_core
In-Reply-To: <CAKoWPPGMMU1iWnjbiV3+LBJn6ox9_55GogD6JNF_cb4JAdOL+w@mail.gmail.com>
References: <CAKoWPPGgFajM+0sV-LEeZ3SpxpEsW4RKLzRWcLbciJh5ROs=7g@mail.gmail.com>
	<4E3901C8.9090409@dkfz-heidelberg.de>
	<CAKoWPPGMMU1iWnjbiV3+LBJn6ox9_55GogD6JNF_cb4JAdOL+w@mail.gmail.com>
Message-ID: <4E396020.60908@dkfz-heidelberg.de>

On 08/03/2011 04:29 PM, Julien Finet wrote:
> On Wed, Aug 3, 2011 at 4:07 AM, Sascha Zelzer 
> <s.zelzer at dkfz-heidelberg.de <mailto:s.zelzer at dkfz-heidelberg.de>> wrote:
>
>     For plug-ins, dependencies to other plug-ins are encoded in the
>     manifest_headers.cmake file (instead of target_libraries.cmake).
>     This makes the information available at runtime. The dependencies
>     are already correctly set-up but the order of the plug-ins in the
>     CMakeLists.txt did not reflect their dependencies. Multiple CMake
>     configure runs hid the problem and I fixed it just now.'
>
>
> Do you mean that the dependency is now handled by the order of 
> add_subdirectory calls ?
Well, the dependencies are still handled via the target_libraries and 
additionally for plug-ins via the manifest_headers.cmake files. However, 
the order of the add_subdirectory calls is important (both for Libs and 
Plug-ins) for automatically figuring out transitive include directories. 
A bit simplified, the macros look for a <plugin-dependency>_SRC_DIR 
variable which is automatically set by CMake due to the 
project(<plugin-dependency>) call in each plug-in (or lib). If the 
add_subdirectory order is wrong, those variables may not exist yet. This 
was the actual problem: org_commontk_dah_app was missing a the include 
directory to org_commontk_dah_core .
> If I understand correctly, org_commontk_dah_app can only be built if 
> org_commontk_dah_core is built (not just configured).
> As there is no direct dependencies between org_commontk_dah_app and 
> org_commontk_dah_core, Visual Studio can run them in parallel, no ? 
> (and Visual Studio, by default, build projects in parallel)
> So it seems to be prone to a race condition. Is there something I 
> didn't take into account ?
org_commontk_dah_app uses classes from org_commontk_dah_core (like the 
ctkSimpleSoapServer). It's object files can be built in parallel to the 
object files of org_commontk_dah_core, but the linking step will only 
take place after the org_commontk_dah_core import library has been 
created. Visual Studio takes care of that.

- Sascha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110803/5c14feca/attachment.htm>

From s.zelzer at dkfz-heidelberg.de  Wed Aug  3 14:56:33 2011
From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer)
Date: Wed, 03 Aug 2011 16:56:33 +0200
Subject: [Ctk-developers] VS2010 support
In-Reply-To: <CAKoWPPFDxCO4fNv2qhYWBmQtCK-qR5sZCQsgYi57ELb=a6N+0g@mail.gmail.com>
References: <4E296184.20903@dkfz-heidelberg.de>
	<4E29A040.3080405@dkfz-heidelberg.de>
	<4E38FBAA.8010807@dkfz-heidelberg.de>
	<CAKoWPPFDxCO4fNv2qhYWBmQtCK-qR5sZCQsgYi57ELb=a6N+0g@mail.gmail.com>
Message-ID: <4E3961A1.1020003@dkfz-heidelberg.de>

Yes, could be handy.

In each CMakeExternals/*.cmake script we could check for a CMake 
variable <project_name>_REVISION_TAG and if it exists (i.e. manually 
added in the CMake GUI or in a dart-client script) we use this one 
instead of the default.

Does that make sense?

- Sascha

On 08/03/2011 04:44 PM, Julien Finet wrote:
> That sounds fine by me, however, I think we should have some way to 
> optionally specify a custom tag ?
> So that we could have dashboards (on a next branch?) running with 
> external bleeding edge branches.
>
> Julien.
>
> On Wed, Aug 3, 2011 at 3:41 AM, Sascha Zelzer 
> <s.zelzer at dkfz-heidelberg.de <mailto:s.zelzer at dkfz-heidelberg.de>> wrote:
>
>     Hi again,
>
>     thanks to JC (who forwarded my post to the CMake mailing list) I
>     could identify the problem (for details, see
>     http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/37472
>     ).
>
>     Essentially, supplying a GIT_TAG argument together with a
>     UPDATE_COMMAND (could also be the default update command, which
>     may be non-empty) in the ExternalProject_Add() macro call will
>     skip all steps after the update step in Visual Studio 2010.
>
>     This problem actually reveals some "issues" with our scripts in
>     the CMakeExternals directory. I would like to suggest the following:
>
>     1.) Projects which are hosted on github/commontk
>
>     I would prefer to keep GIT_TAG origin/patched or similar, but
>     until the bug is fixed, we could specify a specific SHA1 value and
>     add UPDATE_COMMAND ""
>
>     This affects: CTKData, Log4Qt, PythonQt, QtSOAP, ZMQ (although
>     hosted at github.com/patrickcheng/zmq2
>     <http://github.com/patrickcheng/zmq2>)
>
>     2.) True external projects
>
>     Here I would actually prefer GIT_TAG origin/tag where "tag" points
>     to a release version. The relevant projects are:
>
>     - DCMTK: we already use a fixed tag, just needs UPDATE_COMMAND ""
>     - ITK: Use GIT_TAG v3.20.0
>     - VTK: If I rember correctly, the CTK VTK widgets need a very
>     recent VTK, so use a fixed SHA1 instead of origin/master
>
>
>     I made these changes locally and successfully compiled CTK (I
>     enabled everything without Python support) with VS2010 SP1.
>
>     What do you think?
>
>
>     Thanks,
>     Sascha
>
>
>
>     On 07/22/2011 06:07 PM, Sascha Zelzer wrote:
>
>         Hi,
>
>         there is something very strange going on. The generated VS
>         2010 projects
>         (I am using the Express editions, 32bit) for the external
>         dependencies
>         like DCMTK, Log4Qt, etc. only call the download step of the
>         ExternalProject_add call in our superbuild scripts. The
>         projects are not
>         configured and build.
>
>         Did anybody experience the same? I tried with and without the
>         VS 2010
>         SP1 and with CMake 2.8.4 and 2.8.5.
>
>         Thanks,
>         Sascha
>
>         On 07/22/2011 01:39 PM, Sascha Zelzer wrote:
>
>             Hi Folks,
>
>             I would like to get Visual Studio 2010 compatibility for CTK.
>
>             Currently, it looks like I will have to copy
>             ExternalProject.cmake to
>             CTK for the CMAKE_CACHE_ARGS argument. Then a couple of small
>             modifications should do.
>
>             Any other ideas or objections?
>
>             Thanks,
>
>             Sascha
>             _______________________________________________
>             Ctk-developers mailing list
>             Ctk-developers at commontk.org
>             <mailto:Ctk-developers at commontk.org>
>             http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>         _______________________________________________
>         Ctk-developers mailing list
>         Ctk-developers at commontk.org <mailto:Ctk-developers at commontk.org>
>         http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>
>     _______________________________________________
>     Ctk-developers mailing list
>     Ctk-developers at commontk.org <mailto:Ctk-developers at commontk.org>
>     http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110803/4661d8d1/attachment.htm>

From julien.finet at kitware.com  Wed Aug  3 15:05:47 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Wed, 3 Aug 2011 11:05:47 -0400
Subject: [Ctk-developers] org_commontk_dah_app depends on
	org_commontk_dah_core
In-Reply-To: <4E396020.60908@dkfz-heidelberg.de>
References: <CAKoWPPGgFajM+0sV-LEeZ3SpxpEsW4RKLzRWcLbciJh5ROs=7g@mail.gmail.com>
	<4E3901C8.9090409@dkfz-heidelberg.de>
	<CAKoWPPGMMU1iWnjbiV3+LBJn6ox9_55GogD6JNF_cb4JAdOL+w@mail.gmail.com>
	<4E396020.60908@dkfz-heidelberg.de>
Message-ID: <CAKoWPPGoP=tAK4yT5ms58OGXRCAuMJaTE-oJMJrU1QwGJkfL9w@mail.gmail.com>

On Wed, Aug 3, 2011 at 10:50 AM, Sascha Zelzer
<s.zelzer at dkfz-heidelberg.de>wrote:

> **
> On 08/03/2011 04:29 PM, Julien Finet wrote:
>
> On Wed, Aug 3, 2011 at 4:07 AM, Sascha Zelzer <s.zelzer at dkfz-heidelberg.de
> > wrote:
>
>> For plug-ins, dependencies to other plug-ins are encoded in the
>> manifest_headers.cmake file (instead of target_libraries.cmake). This makes
>> the information available at runtime. The dependencies are already correctly
>> set-up but the order of the plug-ins in the CMakeLists.txt did not reflect
>> their dependencies. Multiple CMake configure runs hid the problem and I
>> fixed it just now.'
>>
>
>  Do you mean that the dependency is now handled by the order of
> add_subdirectory calls ?
>
> Well, the dependencies are still handled via the target_libraries and
> additionally for plug-ins via the manifest_headers.cmake files. However, the
> order of the add_subdirectory calls is important (both for Libs and
> Plug-ins) for automatically figuring out transitive include directories. A
> bit simplified, the macros look for a <plugin-dependency>_SRC_DIR variable
> which is automatically set by CMake due to the project(<plugin-dependency>)
> call in each plug-in (or lib). If the add_subdirectory order is wrong, those
> variables may not exist yet. This was the actual problem:
> org_commontk_dah_app was missing a the include directory to
> org_commontk_dah_core .
>
Understood:
the configure-time dependency of the 2 plugins is handled via the order of
add_subdirectory calls.
the build-time  dependency of the 2 plugins is handled
via manifest_headers.cmake.
Makes sense, thanks for the clarification.

>   org_commontk_dah_app uses classes from org_commontk_dah_core (like the
> ctkSimpleSoapServer). It's object files can be built in parallel to the
> object files of org_commontk_dah_core, but the linking step will only take
> place after the org_commontk_dah_core import library has been created.
> Visual Studio takes care of that.
>

Don't we have 2 kind of dependencies here ? At link-ing time (and I trust
you that Visual Studio takes care of it if we told him
so(manifest_headers.cmake)), but there is a prior dependency, at moc-ing
time (so the error: *


Undefined interface

*). Would Visual Studio handle that as well ?

Right now the CMake code for configuring plugins is directly in
CTK/CMakeLists.txt. Wouldn't it make more sense to have it in
CTK/Plugins/CMakeLists.txt (or some other CMakeLists.txt)?

Julien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110803/139219c3/attachment.htm>

From julien.finet at kitware.com  Wed Aug  3 15:07:13 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Wed, 3 Aug 2011 11:07:13 -0400
Subject: [Ctk-developers] VS2010 support
In-Reply-To: <4E3961A1.1020003@dkfz-heidelberg.de>
References: <4E296184.20903@dkfz-heidelberg.de>
	<4E29A040.3080405@dkfz-heidelberg.de>
	<4E38FBAA.8010807@dkfz-heidelberg.de>
	<CAKoWPPFDxCO4fNv2qhYWBmQtCK-qR5sZCQsgYi57ELb=a6N+0g@mail.gmail.com>
	<4E3961A1.1020003@dkfz-heidelberg.de>
Message-ID: <CAKoWPPEjX7pJcDxi3Ozowd5eJ9GJ76W_gxGjcCQU33Mw-tgv8A@mail.gmail.com>

Love it :-)
As soon as it's in, I'll setup some dashboards with that :-)
Julien.

On Wed, Aug 3, 2011 at 10:56 AM, Sascha Zelzer
<s.zelzer at dkfz-heidelberg.de>wrote:

> **
> Yes, could be handy.
>
> In each CMakeExternals/*.cmake script we could check for a CMake variable
> <project_name>_REVISION_TAG and if it exists (i.e. manually added in the
> CMake GUI or in a dart-client script) we use this one instead of the
> default.
>
> Does that make sense?
>
> - Sascha
>
>
> On 08/03/2011 04:44 PM, Julien Finet wrote:
>
> That sounds fine by me, however, I think we should have some way to
> optionally specify a custom tag ?
> So that we could have dashboards (on a next branch?) running with external
> bleeding edge branches.
>
>  Julien.
>
> On Wed, Aug 3, 2011 at 3:41 AM, Sascha Zelzer <s.zelzer at dkfz-heidelberg.de
> > wrote:
>
>> Hi again,
>>
>> thanks to JC (who forwarded my post to the CMake mailing list) I could
>> identify the problem (for details, see
>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/37472 ).
>>
>> Essentially, supplying a GIT_TAG argument together with a UPDATE_COMMAND
>> (could also be the default update command, which may be non-empty) in the
>> ExternalProject_Add() macro call will skip all steps after the update step
>> in Visual Studio 2010.
>>
>> This problem actually reveals some "issues" with our scripts in the
>> CMakeExternals directory. I would like to suggest the following:
>>
>> 1.) Projects which are hosted on github/commontk
>>
>> I would prefer to keep GIT_TAG origin/patched or similar, but until the
>> bug is fixed, we could specify a specific SHA1 value and add UPDATE_COMMAND
>> ""
>>
>> This affects: CTKData, Log4Qt, PythonQt, QtSOAP, ZMQ (although hosted at
>> github.com/patrickcheng/zmq2)
>>
>> 2.) True external projects
>>
>> Here I would actually prefer GIT_TAG origin/tag where "tag" points to a
>> release version. The relevant projects are:
>>
>> - DCMTK: we already use a fixed tag, just needs UPDATE_COMMAND ""
>> - ITK: Use GIT_TAG v3.20.0
>> - VTK: If I rember correctly, the CTK VTK widgets need a very recent VTK,
>> so use a fixed SHA1 instead of origin/master
>>
>>
>> I made these changes locally and successfully compiled CTK (I enabled
>> everything without Python support) with VS2010 SP1.
>>
>> What do you think?
>>
>>
>> Thanks,
>>  Sascha
>>
>>
>>
>> On 07/22/2011 06:07 PM, Sascha Zelzer wrote:
>>
>>> Hi,
>>>
>>> there is something very strange going on. The generated VS 2010 projects
>>> (I am using the Express editions, 32bit) for the external dependencies
>>> like DCMTK, Log4Qt, etc. only call the download step of the
>>> ExternalProject_add call in our superbuild scripts. The projects are not
>>> configured and build.
>>>
>>> Did anybody experience the same? I tried with and without the VS 2010
>>> SP1 and with CMake 2.8.4 and 2.8.5.
>>>
>>> Thanks,
>>> Sascha
>>>
>>> On 07/22/2011 01:39 PM, Sascha Zelzer wrote:
>>>
>>>> Hi Folks,
>>>>
>>>> I would like to get Visual Studio 2010 compatibility for CTK.
>>>>
>>>> Currently, it looks like I will have to copy ExternalProject.cmake to
>>>> CTK for the CMAKE_CACHE_ARGS argument. Then a couple of small
>>>> modifications should do.
>>>>
>>>> Any other ideas or objections?
>>>>
>>>> Thanks,
>>>>
>>>> Sascha
>>>> _______________________________________________
>>>> Ctk-developers mailing list
>>>> Ctk-developers at commontk.org
>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>>>
>>> _______________________________________________
>>> Ctk-developers mailing list
>>> Ctk-developers at commontk.org
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>>
>>
>> _______________________________________________
>> Ctk-developers mailing list
>> Ctk-developers at commontk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110803/75f3ff56/attachment.htm>

From s.zelzer at dkfz-heidelberg.de  Wed Aug  3 15:29:48 2011
From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer)
Date: Wed, 03 Aug 2011 17:29:48 +0200
Subject: [Ctk-developers] org_commontk_dah_app depends on
	org_commontk_dah_core
In-Reply-To: <CAKoWPPGoP=tAK4yT5ms58OGXRCAuMJaTE-oJMJrU1QwGJkfL9w@mail.gmail.com>
References: <CAKoWPPGgFajM+0sV-LEeZ3SpxpEsW4RKLzRWcLbciJh5ROs=7g@mail.gmail.com>
	<4E3901C8.9090409@dkfz-heidelberg.de>
	<CAKoWPPGMMU1iWnjbiV3+LBJn6ox9_55GogD6JNF_cb4JAdOL+w@mail.gmail.com>
	<4E396020.60908@dkfz-heidelberg.de>
	<CAKoWPPGoP=tAK4yT5ms58OGXRCAuMJaTE-oJMJrU1QwGJkfL9w@mail.gmail.com>
Message-ID: <4E39696C.6090800@dkfz-heidelberg.de>

On 08/03/2011 05:05 PM, Julien Finet wrote:
> On Wed, Aug 3, 2011 at 10:50 AM, Sascha Zelzer 
> <s.zelzer at dkfz-heidelberg.de <mailto:s.zelzer at dkfz-heidelberg.de>> wrote:
>
>     On 08/03/2011 04:29 PM, Julien Finet wrote:
>>     On Wed, Aug 3, 2011 at 4:07 AM, Sascha Zelzer
>>     <s.zelzer at dkfz-heidelberg.de
>>     <mailto:s.zelzer at dkfz-heidelberg.de>> wrote:
>>
>>         For plug-ins, dependencies to other plug-ins are encoded in
>>         the manifest_headers.cmake file (instead of
>>         target_libraries.cmake). This makes the information available
>>         at runtime. The dependencies are already correctly set-up but
>>         the order of the plug-ins in the CMakeLists.txt did not
>>         reflect their dependencies. Multiple CMake configure runs hid
>>         the problem and I fixed it just now.'
>>
>>
>>     Do you mean that the dependency is now handled by the order of
>>     add_subdirectory calls ?
>     Well, the dependencies are still handled via the target_libraries
>     and additionally for plug-ins via the manifest_headers.cmake
>     files. However, the order of the add_subdirectory calls is
>     important (both for Libs and Plug-ins) for automatically figuring
>     out transitive include directories. A bit simplified, the macros
>     look for a <plugin-dependency>_SRC_DIR variable which is
>     automatically set by CMake due to the project(<plugin-dependency>)
>     call in each plug-in (or lib). If the add_subdirectory order is
>     wrong, those variables may not exist yet. This was the actual
>     problem: org_commontk_dah_app was missing a the include directory
>     to org_commontk_dah_core .
>
> Understood:
> the configure-time dependency of the 2 plugins is handled via the 
> order of add_subdirectory calls.
> the build-time  dependency of the 2 plugins is handled 
> via manifest_headers.cmake.
> Makes sense, thanks for the clarification.

Correct.

>     org_commontk_dah_app uses classes from org_commontk_dah_core (like
>     the ctkSimpleSoapServer). It's object files can be built in
>     parallel to the object files of org_commontk_dah_core, but the
>     linking step will only take place after the org_commontk_dah_core
>     import library has been created. Visual Studio takes care of that.
>
>
> Don't we have 2 kind of dependencies here ? At link-ing time (and I 
> trust you that Visual Studio takes care of it if we told him 
> so(manifest_headers.cmake)), but there is a prior dependency, at 
> moc-ing time (so the error: *
> Undefined interface
> *). Would Visual Studio handle that as well ?

That error was actually a bit misleading. The C++ parser shipped with 
"moc" does not complain if it cannot resolve an #include <...> 
statement. Since the include directories were wrong (due to the wrong 
configure-time dependency) the header file could not be included by moc 
and hence it did not know about the "interface" declared in that header 
file.

>
> Right now the CMake code for configuring plugins is directly in 
> CTK/CMakeLists.txt. Wouldn't it make more sense to have it in 
> CTK/Plugins/CMakeLists.txt (or some other CMakeLists.txt)?
>

We could move the creation of the CMake variable which contains the list 
of plug-ins (and libs) to a separate file inside an appropriate 
directory. However, this file must still be included in the top-level 
CMakeLists.file due to the way the ctkMacroValidateBuildOptions macro works.

- Sascha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110803/03be3be5/attachment.htm>

From julien.finet at kitware.com  Wed Aug  3 17:16:56 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Wed, 3 Aug 2011 13:16:56 -0400
Subject: [Ctk-developers] org_commontk_dah_app depends on
	org_commontk_dah_core
In-Reply-To: <4E39696C.6090800@dkfz-heidelberg.de>
References: <CAKoWPPGgFajM+0sV-LEeZ3SpxpEsW4RKLzRWcLbciJh5ROs=7g@mail.gmail.com>
	<4E3901C8.9090409@dkfz-heidelberg.de>
	<CAKoWPPGMMU1iWnjbiV3+LBJn6ox9_55GogD6JNF_cb4JAdOL+w@mail.gmail.com>
	<4E396020.60908@dkfz-heidelberg.de>
	<CAKoWPPGoP=tAK4yT5ms58OGXRCAuMJaTE-oJMJrU1QwGJkfL9w@mail.gmail.com>
	<4E39696C.6090800@dkfz-heidelberg.de>
Message-ID: <CAKoWPPFrmRDUnOCFmOFz8VK_7T9_RwP+m2Fg32aDU+OsyxbfVw@mail.gmail.com>

On Wed, Aug 3, 2011 at 11:29 AM, Sascha Zelzer
<s.zelzer at dkfz-heidelberg.de>wrote:

> **
> That error was actually a bit misleading. The C++ parser shipped with "moc"
> does not complain if it cannot resolve an #include <...> statement. Since
> the include directories were wrong (due to the wrong configure-time
> dependency) the header file could not be included by moc and hence it did
> not know about the "interface" declared in that header file.
>
Understood, thanks.

We could move the creation of the CMake variable which contains the list of
> plug-ins (and libs) to a separate file inside an appropriate directory.
> However, this file must still be included in the top-level CMakeLists.file
> due to the way the ctkMacroValidateBuildOptions macro works.
>
Sounds good, so moving that code into Plugins/CMakeLists.txt and doing
include(Plugins/CMakeLists.txt) (instead of add_subdirectory) from the
toplevel CMakeLists.txt, should work then. Or maybe you don't want to call
it Plugins/CMakeLists.txt ?

Julien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110803/5bd0918e/attachment.htm>

From jchris.fillionr at kitware.com  Thu Aug  4 04:42:12 2011
From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin)
Date: Thu, 4 Aug 2011 00:42:12 -0400
Subject: [Ctk-developers] VS2010 support
In-Reply-To: <CAKoWPPEjX7pJcDxi3Ozowd5eJ9GJ76W_gxGjcCQU33Mw-tgv8A@mail.gmail.com>
References: <4E296184.20903@dkfz-heidelberg.de>
	<4E29A040.3080405@dkfz-heidelberg.de>
	<4E38FBAA.8010807@dkfz-heidelberg.de>
	<CAKoWPPFDxCO4fNv2qhYWBmQtCK-qR5sZCQsgYi57ELb=a6N+0g@mail.gmail.com>
	<4E3961A1.1020003@dkfz-heidelberg.de>
	<CAKoWPPEjX7pJcDxi3Ozowd5eJ9GJ76W_gxGjcCQU33Mw-tgv8A@mail.gmail.com>
Message-ID: <CANLz8R7pZSTn=yA+YhOhXMXaM4=QkFk_A4H8OJ2KjmZbOOYCow@mail.gmail.com>

+1
Jc

On Wed, Aug 3, 2011 at 11:07 AM, Julien Finet <julien.finet at kitware.com>wrote:

> Love it :-)
> As soon as it's in, I'll setup some dashboards with that :-)
> Julien.
>
>
> On Wed, Aug 3, 2011 at 10:56 AM, Sascha Zelzer <
> s.zelzer at dkfz-heidelberg.de> wrote:
>
>> **
>> Yes, could be handy.
>>
>> In each CMakeExternals/*.cmake script we could check for a CMake variable
>> <project_name>_REVISION_TAG and if it exists (i.e. manually added in the
>> CMake GUI or in a dart-client script) we use this one instead of the
>> default.
>>
>> Does that make sense?
>>
>> - Sascha
>>
>>
>> On 08/03/2011 04:44 PM, Julien Finet wrote:
>>
>> That sounds fine by me, however, I think we should have some way to
>> optionally specify a custom tag ?
>> So that we could have dashboards (on a next branch?) running with external
>> bleeding edge branches.
>>
>>  Julien.
>>
>> On Wed, Aug 3, 2011 at 3:41 AM, Sascha Zelzer <
>> s.zelzer at dkfz-heidelberg.de> wrote:
>>
>>> Hi again,
>>>
>>> thanks to JC (who forwarded my post to the CMake mailing list) I could
>>> identify the problem (for details, see
>>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/37472 ).
>>>
>>> Essentially, supplying a GIT_TAG argument together with a UPDATE_COMMAND
>>> (could also be the default update command, which may be non-empty) in the
>>> ExternalProject_Add() macro call will skip all steps after the update step
>>> in Visual Studio 2010.
>>>
>>> This problem actually reveals some "issues" with our scripts in the
>>> CMakeExternals directory. I would like to suggest the following:
>>>
>>> 1.) Projects which are hosted on github/commontk
>>>
>>> I would prefer to keep GIT_TAG origin/patched or similar, but until the
>>> bug is fixed, we could specify a specific SHA1 value and add UPDATE_COMMAND
>>> ""
>>>
>>> This affects: CTKData, Log4Qt, PythonQt, QtSOAP, ZMQ (although hosted at
>>> github.com/patrickcheng/zmq2)
>>>
>>> 2.) True external projects
>>>
>>> Here I would actually prefer GIT_TAG origin/tag where "tag" points to a
>>> release version. The relevant projects are:
>>>
>>> - DCMTK: we already use a fixed tag, just needs UPDATE_COMMAND ""
>>> - ITK: Use GIT_TAG v3.20.0
>>> - VTK: If I rember correctly, the CTK VTK widgets need a very recent VTK,
>>> so use a fixed SHA1 instead of origin/master
>>>
>>>
>>> I made these changes locally and successfully compiled CTK (I enabled
>>> everything without Python support) with VS2010 SP1.
>>>
>>> What do you think?
>>>
>>>
>>> Thanks,
>>>  Sascha
>>>
>>>
>>>
>>> On 07/22/2011 06:07 PM, Sascha Zelzer wrote:
>>>
>>>> Hi,
>>>>
>>>> there is something very strange going on. The generated VS 2010 projects
>>>> (I am using the Express editions, 32bit) for the external dependencies
>>>> like DCMTK, Log4Qt, etc. only call the download step of the
>>>> ExternalProject_add call in our superbuild scripts. The projects are not
>>>> configured and build.
>>>>
>>>> Did anybody experience the same? I tried with and without the VS 2010
>>>> SP1 and with CMake 2.8.4 and 2.8.5.
>>>>
>>>> Thanks,
>>>> Sascha
>>>>
>>>> On 07/22/2011 01:39 PM, Sascha Zelzer wrote:
>>>>
>>>>> Hi Folks,
>>>>>
>>>>> I would like to get Visual Studio 2010 compatibility for CTK.
>>>>>
>>>>> Currently, it looks like I will have to copy ExternalProject.cmake to
>>>>> CTK for the CMAKE_CACHE_ARGS argument. Then a couple of small
>>>>> modifications should do.
>>>>>
>>>>> Any other ideas or objections?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Sascha
>>>>> _______________________________________________
>>>>> Ctk-developers mailing list
>>>>> Ctk-developers at commontk.org
>>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>>>>
>>>> _______________________________________________
>>>> Ctk-developers mailing list
>>>> Ctk-developers at commontk.org
>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>>>
>>>
>>> _______________________________________________
>>> Ctk-developers mailing list
>>> Ctk-developers at commontk.org
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>>
>>
>>
>>
>
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>


-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110804/b55cef7a/attachment.htm>

From s.zelzer at dkfz-heidelberg.de  Thu Aug  4 11:29:34 2011
From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer)
Date: Thu, 04 Aug 2011 13:29:34 +0200
Subject: [Ctk-developers] VS2010 support
In-Reply-To: <CAKoWPPEjX7pJcDxi3Ozowd5eJ9GJ76W_gxGjcCQU33Mw-tgv8A@mail.gmail.com>
References: <4E296184.20903@dkfz-heidelberg.de>
	<4E29A040.3080405@dkfz-heidelberg.de>
	<4E38FBAA.8010807@dkfz-heidelberg.de>
	<CAKoWPPFDxCO4fNv2qhYWBmQtCK-qR5sZCQsgYi57ELb=a6N+0g@mail.gmail.com>
	<4E3961A1.1020003@dkfz-heidelberg.de>
	<CAKoWPPEjX7pJcDxi3Ozowd5eJ9GJ76W_gxGjcCQU33Mw-tgv8A@mail.gmail.com>
Message-ID: <4E3A829E.3020201@dkfz-heidelberg.de>

Okay, I pushed my modifications. See here:

https://github.com/commontk/CTK/commit/ec0344d464fadf7adc785f5548c4e85888e21413

- Sascha

On 08/03/2011 05:07 PM, Julien Finet wrote:
> Love it :-)
> As soon as it's in, I'll setup some dashboards with that :-)
> Julien.
>
> On Wed, Aug 3, 2011 at 10:56 AM, Sascha Zelzer 
> <s.zelzer at dkfz-heidelberg.de <mailto:s.zelzer at dkfz-heidelberg.de>> wrote:
>
>     Yes, could be handy.
>
>     In each CMakeExternals/*.cmake script we could check for a CMake
>     variable <project_name>_REVISION_TAG and if it exists (i.e.
>     manually added in the CMake GUI or in a dart-client script) we use
>     this one instead of the default.
>
>     Does that make sense?
>
>     - Sascha
>
>
>     On 08/03/2011 04:44 PM, Julien Finet wrote:
>>     That sounds fine by me, however, I think we should have some way
>>     to optionally specify a custom tag ?
>>     So that we could have dashboards (on a next branch?) running with
>>     external bleeding edge branches.
>>
>>     Julien.
>>
>>     On Wed, Aug 3, 2011 at 3:41 AM, Sascha Zelzer
>>     <s.zelzer at dkfz-heidelberg.de
>>     <mailto:s.zelzer at dkfz-heidelberg.de>> wrote:
>>
>>         Hi again,
>>
>>         thanks to JC (who forwarded my post to the CMake mailing
>>         list) I could identify the problem (for details, see
>>         http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/37472
>>         ).
>>
>>         Essentially, supplying a GIT_TAG argument together with a
>>         UPDATE_COMMAND (could also be the default update command,
>>         which may be non-empty) in the ExternalProject_Add() macro
>>         call will skip all steps after the update step in Visual
>>         Studio 2010.
>>
>>         This problem actually reveals some "issues" with our scripts
>>         in the CMakeExternals directory. I would like to suggest the
>>         following:
>>
>>         1.) Projects which are hosted on github/commontk
>>
>>         I would prefer to keep GIT_TAG origin/patched or similar, but
>>         until the bug is fixed, we could specify a specific SHA1
>>         value and add UPDATE_COMMAND ""
>>
>>         This affects: CTKData, Log4Qt, PythonQt, QtSOAP, ZMQ
>>         (although hosted at github.com/patrickcheng/zmq2
>>         <http://github.com/patrickcheng/zmq2>)
>>
>>         2.) True external projects
>>
>>         Here I would actually prefer GIT_TAG origin/tag where "tag"
>>         points to a release version. The relevant projects are:
>>
>>         - DCMTK: we already use a fixed tag, just needs UPDATE_COMMAND ""
>>         - ITK: Use GIT_TAG v3.20.0
>>         - VTK: If I rember correctly, the CTK VTK widgets need a very
>>         recent VTK, so use a fixed SHA1 instead of origin/master
>>
>>
>>         I made these changes locally and successfully compiled CTK (I
>>         enabled everything without Python support) with VS2010 SP1.
>>
>>         What do you think?
>>
>>
>>         Thanks,
>>         Sascha
>>
>>
>>
>>         On 07/22/2011 06:07 PM, Sascha Zelzer wrote:
>>
>>             Hi,
>>
>>             there is something very strange going on. The generated
>>             VS 2010 projects
>>             (I am using the Express editions, 32bit) for the external
>>             dependencies
>>             like DCMTK, Log4Qt, etc. only call the download step of the
>>             ExternalProject_add call in our superbuild scripts. The
>>             projects are not
>>             configured and build.
>>
>>             Did anybody experience the same? I tried with and without
>>             the VS 2010
>>             SP1 and with CMake 2.8.4 and 2.8.5.
>>
>>             Thanks,
>>             Sascha
>>
>>             On 07/22/2011 01:39 PM, Sascha Zelzer wrote:
>>
>>                 Hi Folks,
>>
>>                 I would like to get Visual Studio 2010 compatibility
>>                 for CTK.
>>
>>                 Currently, it looks like I will have to copy
>>                 ExternalProject.cmake to
>>                 CTK for the CMAKE_CACHE_ARGS argument. Then a couple
>>                 of small
>>                 modifications should do.
>>
>>                 Any other ideas or objections?
>>
>>                 Thanks,
>>
>>                 Sascha
>>                 _______________________________________________
>>                 Ctk-developers mailing list
>>                 Ctk-developers at commontk.org
>>                 <mailto:Ctk-developers at commontk.org>
>>                 http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>
>>             _______________________________________________
>>             Ctk-developers mailing list
>>             Ctk-developers at commontk.org
>>             <mailto:Ctk-developers at commontk.org>
>>             http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>
>>
>>         _______________________________________________
>>         Ctk-developers mailing list
>>         Ctk-developers at commontk.org <mailto:Ctk-developers at commontk.org>
>>         http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110804/0d7769da/attachment.htm>

From julien.finet at kitware.com  Thu Aug  4 15:00:47 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Thu, 4 Aug 2011 11:00:47 -0400
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <4E371D85.6050606@offis.de>
References: <4E32755D.6000402@offis.de>
	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
	<CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
	<CANLz8R4cB7x2vRTw1LWYXJNL3+gww6f+XrjODCGt4W6CaQYFDw@mail.gmail.com>
	<4E36CA14.7060501@offis.de>
	<CANLz8R6W9vUCL8TecTKB=gAP6pRf-Gy2OTARkkPAHG=SiyLgmQ@mail.gmail.com>
	<4E36DB9D.2020901@offis.de>
	<CANLz8R4dvRejW1Dqa8nN-tpSM=6TYj9F2qAzv=X15LHUtTi2Dg@mail.gmail.com>
	<4E371D85.6050606@offis.de>
Message-ID: <CAKoWPPEDwVXXDq4-kcB+CoNV1o26QgE3eVxh7ReiKs=48zndOA@mail.gmail.com>

Hi Michael,

There is still a mktemp warning on Windows:
*


3>51>..\..\..\DCMTK\dcmnet\apps\storescp.cc(87) : warning C4273:
'mktemp' : inconsistent dll linkage

*
http://my.cdash.org/viewBuildError.php?type=1&buildid=216374

Regards,
Julien.

On Mon, Aug 1, 2011 at 5:41 PM, OFFIS DICOM Team <dicom at offis.de> wrote:

> Hi,
>
> Am 01.08.2011 20:41, schrieb Jean-Christophe Fillion-Robin:
>
>
>  We already have a WITH_THREADS flag in DCMTK which adds libpthread if
>> existing/necessary. Usually, with threads is turned on.
>>
>> Does it mean that turning WITH_THREAD OFF won't append the /MT or /MTd
>> flags ?
>>
>
> No, on Windows we usually use /MT and /MTd in DCMTK. For CTK, we now (since
> today) use the flags automatically determined by CMake, i.e. /MD and /MDd
> for compilation. In both cases we do not care about whether
> DCMTK_WITH_THREADS is on or off. Both, /MT(d) and /MD(d) flags, select a
> microsoft runtime library including threaded versions, as far as I (and you
> probably) know:
>
> http://msdn.microsoft.com/en-**us/library/2kzt1wy3(v=vs.71).**aspx<http://msdn.microsoft.com/en-us/library/2kzt1wy3(v=vs.71).aspx>
>
> If WITH_THREADS is off, DCMTK's thread classes like OFThread are not
> compiled, and pthread and the like are not added to the linker.
>
>  I could commit it any time/immediately in DCMTK. My colleague noted that
>> we should take care that we only put -fPIC into effect if it is
>> understood by the compiler and needed, so I wonder whether "IF(UNIX" is
>> a sufficient guard. Any hints or recommendations?
>>
>>
>> You could for example do: [...]
>>
>
> I inserted a flag DCMTK_FORCE_FPIC_ON_UNIX in DCMTK [1] which can be set
> from CTK's DCMTK.cmake via CMAKE_ARGS. If this makes sense, I can change
> the
> DCMTK.cmake accordingly. Also, I removed mktemp from the tparser.cc [2] so
> the warning an unix should be gone now.
>
> Thanks for helping!
>
> Michael
>
> [1]
> http://git.dcmtk.org/web?p=**dcmtk.git;a=commitdiff;h=**
> 09db15ff595da6c35330fd7f63669a**eb9952e015<http://git.dcmtk.org/web?p=dcmtk.git;a=commitdiff;h=09db15ff595da6c35330fd7f63669aeb9952e015>
>
> [2] http://git.dcmtk.org/web?p=**dcmtk.git;a=commitdiff;h=**
> 96ce7c46b48245512385170bfb72ec**3cdc32a3a6<http://git.dcmtk.org/web?p=dcmtk.git;a=commitdiff;h=96ce7c46b48245512385170bfb72ec3cdc32a3a6>
>
>
> --
> OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
> E-Mail: dicom at offis.de, URL: http://dicom.offis.de
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110804/c4e1a0eb/attachment.htm>

From dicom at offis.de  Thu Aug  4 16:39:58 2011
From: dicom at offis.de (OFFIS DICOM Team)
Date: Thu, 04 Aug 2011 18:39:58 +0200
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <CAKoWPPEDwVXXDq4-kcB+CoNV1o26QgE3eVxh7ReiKs=48zndOA@mail.gmail.com>
References: <4E32755D.6000402@offis.de>
	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
	<CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
	<CANLz8R4cB7x2vRTw1LWYXJNL3+gww6f+XrjODCGt4W6CaQYFDw@mail.gmail.com>
	<4E36CA14.7060501@offis.de>
	<CANLz8R6W9vUCL8TecTKB=gAP6pRf-Gy2OTARkkPAHG=SiyLgmQ@mail.gmail.com>
	<4E36DB9D.2020901@offis.de>
	<CANLz8R4dvRejW1Dqa8nN-tpSM=6TYj9F2qAzv=X15LHUtTi2Dg@mail.gmail.com>
	<4E371D85.6050606@offis.de>
	<CAKoWPPEDwVXXDq4-kcB+CoNV1o26QgE3eVxh7ReiKs=48zndOA@mail.gmail.com>
Message-ID: <4E3ACB5E.5080408@offis.de>

Hi Julien,

Am 04.08.2011 17:00, schrieb Julien Finet:
> Hi Michael,
>
> There is still a mktemp warning on Windows: *
>
>
> 3>51>..\..\..\DCMTK\dcmnet\apps\storescp.cc(87) : warning C4273:'mktemp'
> : inconsistent dll linkage

thanks for pointing me to that issue. It just showed up since CTK uses the
CMake-determined compiler flags by disabling the DCMTK pre-defined flags
(which caused a problem due to /MT flag). So we did not notice it before, sorry.

It was fixed yesterday. So if you switch to a newer revision of DCMTK in
DCMTK.cmake the warning will be gone.

The minimum commit is 901ba8f1e50ef91627b0cdbb623835d64e3f6fe4.
The latest  commit is 085525e643cab5ac826823c7a3169437761fe0d3 (two later).

Works for me in CTK under Win XP and Win 7 (32 bit), as well as on Kubuntu
64 bit. If someone from the CTK core team can confirm that, he might upgrade
the DCMTK commit hash or I do if I have an OK. Getting more careful now :-)

HTH,
Michael

-- 
OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
E-Mail: dicom at offis.de, URL: http://dicom.offis.de


From julien.finet at kitware.com  Thu Aug  4 18:36:23 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Thu, 4 Aug 2011 14:36:23 -0400
Subject: [Ctk-developers] CTK Update to latest DCMTK
In-Reply-To: <4E3ACB5E.5080408@offis.de>
References: <4E32755D.6000402@offis.de>
	<CAKoWPPGc3tGb0mgcNz3mzRFUQ=2upBtEHMSL+h1WiwEy3xTXyQ@mail.gmail.com>
	<CAKoWPPEM3D=1QZFTmwhiG1WnA173ajVDkvDC=n_Kibu6Qvsgig@mail.gmail.com>
	<CANLz8R4cB7x2vRTw1LWYXJNL3+gww6f+XrjODCGt4W6CaQYFDw@mail.gmail.com>
	<4E36CA14.7060501@offis.de>
	<CANLz8R6W9vUCL8TecTKB=gAP6pRf-Gy2OTARkkPAHG=SiyLgmQ@mail.gmail.com>
	<4E36DB9D.2020901@offis.de>
	<CANLz8R4dvRejW1Dqa8nN-tpSM=6TYj9F2qAzv=X15LHUtTi2Dg@mail.gmail.com>
	<4E371D85.6050606@offis.de>
	<CAKoWPPEDwVXXDq4-kcB+CoNV1o26QgE3eVxh7ReiKs=48zndOA@mail.gmail.com>
	<4E3ACB5E.5080408@offis.de>
Message-ID: <CAKoWPPEzDoqLJV7xkeFBg5g1=SJvjPNgBri5+r8GcP3rVQYAkQ@mail.gmail.com>

Hi Michael,
Using 085525e643cab5ac826823c7a31694**37761fe0d3 seems to fix the warning:
http://my.cdash.org/index.php?project=CTK&display=project&filtercount=3&showfilters=1&filtercombine=and&field1=buildname/string&compare1=61&value1=WindowsXP-VS2008Express-QT4.6.3-Debug&field2=site/string&compare2=61&value2=erna.kitware&field3=buildstamp/string&compare3=61&value3=20110804-1757-Experimental&collapse=0

I think you can go ahead and update the default git SHA1 tag for DCMTK.

Thanks,
Julien.

On Thu, Aug 4, 2011 at 12:39 PM, OFFIS DICOM Team <dicom at offis.de> wrote:

> Hi Julien,
>
> Am 04.08.2011 17:00, schrieb Julien Finet:
>
>  Hi Michael,
>>
>> There is still a mktemp warning on Windows: *
>>
>>
>> 3>51>..\..\..\DCMTK\dcmnet\**apps\storescp.cc(87) : warning
>> C4273:'mktemp'
>> : inconsistent dll linkage
>>
>
> thanks for pointing me to that issue. It just showed up since CTK uses the
> CMake-determined compiler flags by disabling the DCMTK pre-defined flags
> (which caused a problem due to /MT flag). So we did not notice it before,
> sorry.
>
> It was fixed yesterday. So if you switch to a newer revision of DCMTK in
> DCMTK.cmake the warning will be gone.
>
> The minimum commit is 901ba8f1e50ef91627b0cdbb623835**d64e3f6fe4.
> The latest  commit is 085525e643cab5ac826823c7a31694**37761fe0d3 (two
> later).
>
> Works for me in CTK under Win XP and Win 7 (32 bit), as well as on Kubuntu
> 64 bit. If someone from the CTK core team can confirm that, he might
> upgrade
> the DCMTK commit hash or I do if I have an OK. Getting more careful now :-)
>
> HTH,
> Michael
>
>
> --
> OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
> E-Mail: dicom at offis.de, URL: http://dicom.offis.de
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110804/d64935c7/attachment.htm>

From julien.finet at kitware.com  Thu Aug  4 21:39:40 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Thu, 4 Aug 2011 17:39:40 -0400
Subject: [Ctk-developers] New nightly dashboards
Message-ID: <CAKoWPPEeVRvz-_N0D=vC86j4P4utEU1pZ6i-WLWKD7rZuNFTZw@mail.gmail.com>

For information, we have 6 new nightly dashboards for CTK:

   - WindowsXP 32bits Visual Studio 2008 Express
      - Debug - Qt 4.6.3
      - Release - Qt 4.6.3
      - Debug - Qt 4.7.0
      - Release - Qt 4.7.0


   - Windows Vista 64bits Visual Studio 2010 Express
      - Debug - Qt 4.7.3
      - Release - Qt 4.7.3

And all of them have green build status :-) but some failing tests :-(.

Right now, they only compile CTK with DICOM support. I'll add VTK and
python support soon.
Let me know if you want me to activate other options.

Many thanks to all of you to make it happen,
Julien.
p.s. Michael, if you feel idle, you can look at the warnings with DCMTK
with 64bits :-) http://my.cdash.org/viewBuildError.php?type=1&buildid=216486
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110804/02c59507/attachment.htm>

From julien.finet at kitware.com  Fri Aug  5 14:49:26 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Fri, 5 Aug 2011 10:49:26 -0400
Subject: [Ctk-developers] mac nightly 7-30
In-Reply-To: <108FFF21-C3C4-4EE8-BAC2-BBB476422567@ge.com>
References: <4E341671.1060001@bwh.harvard.edu>
	<CAKoWPPFc1m991CodBNxftD-maQfV71wLLT8TwDxpT+9sBHTdnQ@mail.gmail.com>
	<4E36262D.8030608@bwh.harvard.edu>
	<CAKoWPPHYiggJszTEkDhQVgrH=j8n6sedKSrso3jfkENSJsvQYQ@mail.gmail.com>
	<4E36BB90.5060904@bwh.harvard.edu>
	<CAKoWPPFJZb1J26QY-hVibyXFyibE1nBo9bDPNy8Eht0maGnAZQ@mail.gmail.com>
	<108FFF21-C3C4-4EE8-BAC2-BBB476422567@ge.com>
Message-ID: <CAKoWPPFSBK4OWCMpfEQdAf1aL2CF7ZbBbYneNxjHL22Mb5cc4Q@mail.gmail.com>

Hi Jim,

We were not aware of the problem and we don't have any Mac OsX 10.7
dashboards for CTK.

Can you submit a clean experimental dashboard (CTK only, not within Slicer)
of the most recent version of CTK (git clone git://
github.com/commontk/CTK.git)?
I enclosed the template for the dashboard script.
Then just do
ctest -V -S myReleaseExperimentalDashboardScript.cmake -C Release

That would be helpful.

Does the offis team has an idea with what could go wrong here ?

Thanks,
Julien.

On Fri, Aug 5, 2011 at 10:31 AM, Jim Miller <millerjv at ge.com> wrote:

> Has anyone seen/resolved issues with building CTK on Mac OS X Lion?
>
> I get two issues. One is warning from Qt about an unsupported version of
> the OS (10.7). The other is a set of undefined variables.
>
> Jim
>
>
> /Developer/SDKs/MacOSX10.7.sdk/Library/Frameworks/QtCore.framework/Headers/qglobal.h:320:6:
> warning: #warning "This version of Mac OS X is unsupported"
> Linking CXX shared library ../../../bin/libCTKDICOMCore.dylib
> Undefined symbols for architecture x86_64:
>   "_inflate", referenced from:
>       DcmZLibInputFilter::decompress(void const*, long)in
> libdcmdata.a(dcistrmz.o)
>   "_inflateEnd", referenced from:
>       DcmZLibInputFilter::~DcmZLibInputFilter()in libdcmdata.a(dcistrmz.o)
>       DcmZLibInputFilter::~DcmZLibInputFilter()in libdcmdata.a(dcistrmz.o)
>       DcmZLibInputFilter::~DcmZLibInputFilter()in libdcmdata.a(dcistrmz.o)
>   "_inflateInit_", referenced from:
>       DcmZLibInputFilter::DcmZLibInputFilter()in libdcmdata.a(dcistrmz.o)
>       DcmZLibInputFilter::DcmZLibInputFilter()in libdcmdata.a(dcistrmz.o)
>   "_inflateInit2_", referenced from:
>       DcmZLibInputFilter::DcmZLibInputFilter()in libdcmdata.a(dcistrmz.o)
>       DcmZLibInputFilter::DcmZLibInputFilter()in libdcmdata.a(dcistrmz.o)
>   "_deflate", referenced from:
>       DcmZLibOutputFilter::compress(void const*, long, bool)in
> libdcmdata.a(dcostrmz.o)
>   "_deflateEnd", referenced from:
>       DcmZLibOutputFilter::~DcmZLibOutputFilter()in
> libdcmdata.a(dcostrmz.o)
>       DcmZLibOutputFilter::~DcmZLibOutputFilter()in
> libdcmdata.a(dcostrmz.o)
>       DcmZLibOutputFilter::~DcmZLibOutputFilter()in
> libdcmdata.a(dcostrmz.o)
>   "_deflateInit2_", referenced from:
>       DcmZLibOutputFilter::DcmZLibOutputFilter()in libdcmdata.a(dcostrmz.o)
>       DcmZLibOutputFilter::DcmZLibOutputFilter()in libdcmdata.a(dcostrmz.o)
> ld: symbol(s) not found for architecture x86_64
> collect2: ld returned 1 exit status
> make[8]: *** [bin/libCTKDICOMCore.0.1.0.dylib] Error 1
> make[7]: *** [Libs/DICOM/Core/CMakeFiles/CTKDICOMCore.dir/all] Error 2
> make[6]: *** [all] Error 2
> make[5]: *** [CTK-build-prefix/src/CTK-build-stamp/CTK-build-build] Error 2
> make[4]: *** [CMakeFiles/CTK-build.dir/all] Error 2
> make[3]: *** [all] Error 2
> make[2]: *** [CTK-prefix/src/CTK-stamp/CTK-build] Error 2
> make[1]: *** [CMakeFiles/CTK.dir/all] Error 2
> make: *** [all] Error 2
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110805/afb9b2f5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ctkDashboardScript.TEMPLATE.cmake
Type: application/octet-stream
Size: 3789 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110805/afb9b2f5/attachment.obj>

From julien.finet at kitware.com  Fri Aug  5 15:31:55 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Fri, 5 Aug 2011 11:31:55 -0400
Subject: [Ctk-developers] mac nightly 7-30
In-Reply-To: <CAKoWPPFSBK4OWCMpfEQdAf1aL2CF7ZbBbYneNxjHL22Mb5cc4Q@mail.gmail.com>
References: <4E341671.1060001@bwh.harvard.edu>
	<CAKoWPPFc1m991CodBNxftD-maQfV71wLLT8TwDxpT+9sBHTdnQ@mail.gmail.com>
	<4E36262D.8030608@bwh.harvard.edu>
	<CAKoWPPHYiggJszTEkDhQVgrH=j8n6sedKSrso3jfkENSJsvQYQ@mail.gmail.com>
	<4E36BB90.5060904@bwh.harvard.edu>
	<CAKoWPPFJZb1J26QY-hVibyXFyibE1nBo9bDPNy8Eht0maGnAZQ@mail.gmail.com>
	<108FFF21-C3C4-4EE8-BAC2-BBB476422567@ge.com>
	<CAKoWPPFSBK4OWCMpfEQdAf1aL2CF7ZbBbYneNxjHL22Mb5cc4Q@mail.gmail.com>
Message-ID: <CAKoWPPHjKjc1r61zhgM7mSv08G=zvbwdJv2acez=-gBiT97MYA@mail.gmail.com>

I forgot to mention to pass CTK_APP_ctkDICOM:BOOL=ON in
ADDITIONNAL_CMAKECACHE_OPTION
Julien.

On Fri, Aug 5, 2011 at 10:49 AM, Julien Finet <julien.finet at kitware.com>wrote:

> Hi Jim,
>
> We were not aware of the problem and we don't have any Mac OsX 10.7
> dashboards for CTK.
>
> Can you submit a clean experimental dashboard (CTK only, not within Slicer)
> of the most recent version of CTK (git clone git://
> github.com/commontk/CTK.git)?
> I enclosed the template for the dashboard script.
> Then just do
> ctest -V -S myReleaseExperimentalDashboardScript.cmake -C Release
>
> That would be helpful.
>
> Does the offis team has an idea with what could go wrong here ?
>
> Thanks,
> Julien.
>
> On Fri, Aug 5, 2011 at 10:31 AM, Jim Miller <millerjv at ge.com> wrote:
>
>> Has anyone seen/resolved issues with building CTK on Mac OS X Lion?
>>
>> I get two issues. One is warning from Qt about an unsupported version of
>> the OS (10.7). The other is a set of undefined variables.
>>
>> Jim
>>
>>
>> /Developer/SDKs/MacOSX10.7.sdk/Library/Frameworks/QtCore.framework/Headers/qglobal.h:320:6:
>> warning: #warning "This version of Mac OS X is unsupported"
>> Linking CXX shared library ../../../bin/libCTKDICOMCore.dylib
>> Undefined symbols for architecture x86_64:
>>   "_inflate", referenced from:
>>       DcmZLibInputFilter::decompress(void const*, long)in
>> libdcmdata.a(dcistrmz.o)
>>   "_inflateEnd", referenced from:
>>       DcmZLibInputFilter::~DcmZLibInputFilter()in libdcmdata.a(dcistrmz.o)
>>       DcmZLibInputFilter::~DcmZLibInputFilter()in libdcmdata.a(dcistrmz.o)
>>       DcmZLibInputFilter::~DcmZLibInputFilter()in libdcmdata.a(dcistrmz.o)
>>   "_inflateInit_", referenced from:
>>       DcmZLibInputFilter::DcmZLibInputFilter()in libdcmdata.a(dcistrmz.o)
>>       DcmZLibInputFilter::DcmZLibInputFilter()in libdcmdata.a(dcistrmz.o)
>>   "_inflateInit2_", referenced from:
>>       DcmZLibInputFilter::DcmZLibInputFilter()in libdcmdata.a(dcistrmz.o)
>>       DcmZLibInputFilter::DcmZLibInputFilter()in libdcmdata.a(dcistrmz.o)
>>   "_deflate", referenced from:
>>       DcmZLibOutputFilter::compress(void const*, long, bool)in
>> libdcmdata.a(dcostrmz.o)
>>   "_deflateEnd", referenced from:
>>       DcmZLibOutputFilter::~DcmZLibOutputFilter()in
>> libdcmdata.a(dcostrmz.o)
>>       DcmZLibOutputFilter::~DcmZLibOutputFilter()in
>> libdcmdata.a(dcostrmz.o)
>>       DcmZLibOutputFilter::~DcmZLibOutputFilter()in
>> libdcmdata.a(dcostrmz.o)
>>   "_deflateInit2_", referenced from:
>>       DcmZLibOutputFilter::DcmZLibOutputFilter()in
>> libdcmdata.a(dcostrmz.o)
>>       DcmZLibOutputFilter::DcmZLibOutputFilter()in
>> libdcmdata.a(dcostrmz.o)
>> ld: symbol(s) not found for architecture x86_64
>> collect2: ld returned 1 exit status
>> make[8]: *** [bin/libCTKDICOMCore.0.1.0.dylib] Error 1
>> make[7]: *** [Libs/DICOM/Core/CMakeFiles/CTKDICOMCore.dir/all] Error 2
>> make[6]: *** [all] Error 2
>> make[5]: *** [CTK-build-prefix/src/CTK-build-stamp/CTK-build-build] Error
>> 2
>> make[4]: *** [CMakeFiles/CTK-build.dir/all] Error 2
>> make[3]: *** [all] Error 2
>> make[2]: *** [CTK-prefix/src/CTK-stamp/CTK-build] Error 2
>> make[1]: *** [CMakeFiles/CTK.dir/all] Error 2
>> make: *** [all] Error 2
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110805/02d4c223/attachment.htm>

From dicom at offis.de  Fri Aug  5 15:55:46 2011
From: dicom at offis.de (OFFIS DICOM Team)
Date: Fri, 05 Aug 2011 17:55:46 +0200
Subject: [Ctk-developers] mac nightly 7-30
In-Reply-To: <CAKoWPPFSBK4OWCMpfEQdAf1aL2CF7ZbBbYneNxjHL22Mb5cc4Q@mail.gmail.com>
References: <4E341671.1060001@bwh.harvard.edu>
	<CAKoWPPFc1m991CodBNxftD-maQfV71wLLT8TwDxpT+9sBHTdnQ@mail.gmail.com>
	<4E36262D.8030608@bwh.harvard.edu>
	<CAKoWPPHYiggJszTEkDhQVgrH=j8n6sedKSrso3jfkENSJsvQYQ@mail.gmail.com>
	<4E36BB90.5060904@bwh.harvard.edu>
	<CAKoWPPFJZb1J26QY-hVibyXFyibE1nBo9bDPNy8Eht0maGnAZQ@mail.gmail.com>
	<108FFF21-C3C4-4EE8-BAC2-BBB476422567@ge.com>
	<CAKoWPPFSBK4OWCMpfEQdAf1aL2CF7ZbBbYneNxjHL22Mb5cc4Q@mail.gmail.com>
Message-ID: <4E3C1282.7040705@offis.de>

Hi,

Am 05.08.2011 16:49, schrieb Julien Finet:
> Hi Jim,
>
> We were not aware of the problem and we don't have any Mac OsX 10.7
> dashboards for CTK.

it seems it's the same problem that Sascha found on his linux machine, see

   https://github.com/commontk/CTK/issues/25

Thus, it should already be fixed, no? The reason is in any case that DCMTK
was configured and compiled with ZLIB support (DCMTK_WITH_ZLIB) and ZLIB is
then not added to the linker when CTK is built, using DCMTK.

So, are you sure you are on the latest CTK version? Maybe for safety be sure
to delete your DCMTK-related files in the CTK superbuild.

Best regards,
Michael

-- 
OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
E-Mail: dicom at offis.de, URL: http://dicom.offis.de


From dicom at offis.de  Fri Aug  5 15:58:52 2011
From: dicom at offis.de (OFFIS DICOM Team)
Date: Fri, 05 Aug 2011 17:58:52 +0200
Subject: [Ctk-developers] mac nightly 7-30
In-Reply-To: <4E3C1282.7040705@offis.de>
References: <4E341671.1060001@bwh.harvard.edu>
	<CAKoWPPFc1m991CodBNxftD-maQfV71wLLT8TwDxpT+9sBHTdnQ@mail.gmail.com>
	<4E36262D.8030608@bwh.harvard.edu>
	<CAKoWPPHYiggJszTEkDhQVgrH=j8n6sedKSrso3jfkENSJsvQYQ@mail.gmail.com>
	<4E36BB90.5060904@bwh.harvard.edu>
	<CAKoWPPFJZb1J26QY-hVibyXFyibE1nBo9bDPNy8Eht0maGnAZQ@mail.gmail.com>
	<108FFF21-C3C4-4EE8-BAC2-BBB476422567@ge.com>
	<CAKoWPPFSBK4OWCMpfEQdAf1aL2CF7ZbBbYneNxjHL22Mb5cc4Q@mail.gmail.com>
	<4E3C1282.7040705@offis.de>
Message-ID: <4E3C133C.3000607@offis.de>

Am 05.08.2011 17:55, schrieb OFFIS DICOM Team:

> https://github.com/commontk/CTK/issues/25
>
> Thus, it should already be fixed, no?

P.S: Well, I also should read the message subject ;-) On July 30 it was not
yet fixed. So if you update now I would expect that the problem is gone.

Michael

-- 
OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
E-Mail: dicom at offis.de, URL: http://dicom.offis.de


From julien.finet at kitware.com  Fri Aug  5 16:10:49 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Fri, 5 Aug 2011 12:10:49 -0400
Subject: [Ctk-developers] mac nightly 7-30
In-Reply-To: <4E3C1282.7040705@offis.de>
References: <4E341671.1060001@bwh.harvard.edu>
	<CAKoWPPFc1m991CodBNxftD-maQfV71wLLT8TwDxpT+9sBHTdnQ@mail.gmail.com>
	<4E36262D.8030608@bwh.harvard.edu>
	<CAKoWPPHYiggJszTEkDhQVgrH=j8n6sedKSrso3jfkENSJsvQYQ@mail.gmail.com>
	<4E36BB90.5060904@bwh.harvard.edu>
	<CAKoWPPFJZb1J26QY-hVibyXFyibE1nBo9bDPNy8Eht0maGnAZQ@mail.gmail.com>
	<108FFF21-C3C4-4EE8-BAC2-BBB476422567@ge.com>
	<CAKoWPPFSBK4OWCMpfEQdAf1aL2CF7ZbBbYneNxjHL22Mb5cc4Q@mail.gmail.com>
	<4E3C1282.7040705@offis.de>
Message-ID: <CAKoWPPFRg7sbjy1t+i+ViR94YPZ2-fa-1dNDW7thGTYeaFaJwg@mail.gmail.com>

Indeed, I didn't read the errors carefully enough.
Jim, these errors should be fixed in Slicer as well. (please delete DCMTK*
in CTK-build of Slicer-Superbuild).
Sorry about the noise,
Julien.

On Fri, Aug 5, 2011 at 11:55 AM, OFFIS DICOM Team <dicom at offis.de> wrote:

> Hi,
>
> Am 05.08.2011 16:49, schrieb Julien Finet:
>
>  Hi Jim,
>>
>> We were not aware of the problem and we don't have any Mac OsX 10.7
>> dashboards for CTK.
>>
>
> it seems it's the same problem that Sascha found on his linux machine, see
>
>  https://github.com/commontk/**CTK/issues/25<https://github.com/commontk/CTK/issues/25>
>
> Thus, it should already be fixed, no? The reason is in any case that DCMTK
> was configured and compiled with ZLIB support (DCMTK_WITH_ZLIB) and ZLIB is
> then not added to the linker when CTK is built, using DCMTK.
>
> So, are you sure you are on the latest CTK version? Maybe for safety be
> sure
> to delete your DCMTK-related files in the CTK superbuild.
>
> Best regards,
> Michael
>
> --
> OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
> E-Mail: dicom at offis.de, URL: http://dicom.offis.de
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110805/0ed16c20/attachment.htm>

From domibel at debian.org  Fri Aug  5 22:19:34 2011
From: domibel at debian.org (Dominique Belhachemi)
Date: Fri, 5 Aug 2011 18:19:34 -0400
Subject: [Ctk-developers] New nightly dashboards
In-Reply-To: <CAKoWPPEeVRvz-_N0D=vC86j4P4utEU1pZ6i-WLWKD7rZuNFTZw@mail.gmail.com>
References: <CAKoWPPEeVRvz-_N0D=vC86j4P4utEU1pZ6i-WLWKD7rZuNFTZw@mail.gmail.com>
Message-ID: <CAAvaLCyRtzCRJkML39wPSKQUYfUsKQG4p1Lcfv50X4pj-Ub-ew@mail.gmail.com>

Thanks Julien,

This motivated me to create additional 4 nightly dashboards.

ubuntu maverick i386 g++4.4.5 QT4.7.0
ubuntu maverick amd64 g++4.4.5 QT4.7.0
debian sid i386 g++4.6.1 QT4.7.3
debian sid amd64 g++4.6.1 QT4.7.3

Cheers
Dominique



On Thu, Aug 4, 2011 at 5:39 PM, Julien Finet <julien.finet at kitware.com> wrote:
> For information, we have 6 new nightly dashboards for CTK:
>
> WindowsXP 32bits Visual Studio 2008 Express
>
> Debug - Qt 4.6.3
> Release - Qt 4.6.3
> Debug - Qt 4.7.0
> Release?- Qt 4.7.0
>
> Windows Vista 64bits Visual Studio 2010 Express
>
> Debug - Qt 4.7.3
> Release?- Qt 4.7.3
>
> And all of them have green build status :-) but some failing tests :-(.
> Right now, they only compile CTK with DICOM support. I'll add VTK and
> python?support?soon.
> Let me know if you want me to activate other options.
> Many thanks to all of you to make it happen,
> Julien.
> p.s. Michael, if you feel idle, you can look at the warnings with DCMTK
> with?64bits?:-)?http://my.cdash.org/viewBuildError.php?type=1&buildid=216486
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>


From s.zelzer at dkfz-heidelberg.de  Sat Aug  6 06:26:34 2011
From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer)
Date: Sat, 06 Aug 2011 08:26:34 +0200
Subject: [Ctk-developers] New nightly dashboards
In-Reply-To: <CAAvaLCyRtzCRJkML39wPSKQUYfUsKQG4p1Lcfv50X4pj-Ub-ew@mail.gmail.com>
References: <CAKoWPPEeVRvz-_N0D=vC86j4P4utEU1pZ6i-WLWKD7rZuNFTZw@mail.gmail.com>
	<CAAvaLCyRtzCRJkML39wPSKQUYfUsKQG4p1Lcfv50X4pj-Ub-ew@mail.gmail.com>
Message-ID: <4E3CDE9A.5070701@dkfz-heidelberg.de>

Hi,

Having more systems submitting to the dashboard is great!

I just wanted to point out a bug in CDash concerning the build name. If 
it contains special characters (like a '+' in g++4.4.5) CDash does not 
resolve the link correctly. I would suggest to use gcc4.4.5 in the build 
name for example, instead of g++4.4.5.

Thanks,

Sascha

On 08/06/2011 12:19 AM, Dominique Belhachemi wrote:
> Thanks Julien,
>
> This motivated me to create additional 4 nightly dashboards.
>
> ubuntu maverick i386 g++4.4.5 QT4.7.0
> ubuntu maverick amd64 g++4.4.5 QT4.7.0
> debian sid i386 g++4.6.1 QT4.7.3
> debian sid amd64 g++4.6.1 QT4.7.3
>
> Cheers
> Dominique
>
>
>
> On Thu, Aug 4, 2011 at 5:39 PM, Julien Finet<julien.finet at kitware.com>  wrote:
>> For information, we have 6 new nightly dashboards for CTK:
>>
>> WindowsXP 32bits Visual Studio 2008 Express
>>
>> Debug - Qt 4.6.3
>> Release - Qt 4.6.3
>> Debug - Qt 4.7.0
>> Release - Qt 4.7.0
>>
>> Windows Vista 64bits Visual Studio 2010 Express
>>
>> Debug - Qt 4.7.3
>> Release - Qt 4.7.3
>>
>> And all of them have green build status :-) but some failing tests :-(.
>> Right now, they only compile CTK with DICOM support. I'll add VTK and
>> python support soon.
>> Let me know if you want me to activate other options.
>> Many thanks to all of you to make it happen,
>> Julien.
>> p.s. Michael, if you feel idle, you can look at the warnings with DCMTK
>> with 64bits :-) http://my.cdash.org/viewBuildError.php?type=1&buildid=216486
>> _______________________________________________
>> Ctk-developers mailing list
>> Ctk-developers at commontk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>
>>
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers



From haehn at bwh.harvard.edu  Thu Aug 11 17:15:15 2011
From: haehn at bwh.harvard.edu (Daniel Haehn)
Date: Thu, 11 Aug 2011 13:15:15 -0400
Subject: [Ctk-developers] ShowStatusTextUponGoToStepSuccess workflow feature,
	please review
Message-ID: <CAPDjdmZwuN-RSfRNPz3ZOgwmDTTN-QUrY6X+0VfjDBHoVyOCnQ@mail.gmail.com>

Hi Devels,

could anybody please review the following topic:

https://github.com/haehn/CTK/commits/add-ShowStatusTextUponGoToStepSuccess-workflow-feature

I added a property to be able to disable the Status Text update on the
origin step when a GoToStep(..)-call of a ctkWorkflow succeeds.

Looking forward to your feedback..

Daniel


From pieper at ibility.net  Mon Aug 15 23:47:14 2011
From: pieper at ibility.net (Steve Pieper)
Date: Mon, 15 Aug 2011 19:47:14 -0400
Subject: [Ctk-developers] Fwd: [Nipy-devel] Github code editor ...
In-Reply-To: <CAH6Pt5qjyOifDMDnptAchgnEP1c4by00h-RuDsCJ2vWxemQq1w@mail.gmail.com>
References: <CAH6Pt5qjyOifDMDnptAchgnEP1c4by00h-RuDsCJ2vWxemQq1w@mail.gmail.com>
Message-ID: <CA+OFd4wGeN_AB_fZNUKtDBTLzdsmpbBBGQDOcP++ZtnQ=S8oXg@mail.gmail.com>

Wow - another cool github feature!


---------- Forwarded message ----------
From: Matthew Brett <matthew.brett at gmail.com>
Date: Mon, Aug 15, 2011 at 7:44 PM
Subject: [Nipy-devel] Github code editor ...
To: NIPY Developer's List <nipy-devel at neuroimaging.scipy.org>


Hi,

Someone on another mailing just pointed out this new github feature.
Perfect for those docstring edits ...

See y'all,

Matthew


---------- Forwarded message ----------
From: Tim McNamara <tim.mcnamara at okfn.org>
Date: Mon, Aug 15, 2011 at 4:25 PM
Subject: [okfn-help] Technical contributions to OKF just got lots easier
To: OKFN Help <okfn-help at lists.okfn.org>


Github has just added a full-blown IDE in a browser to its offering.
If you would like to contribute to one of the OKF's technical projects
hosted on Github, all you need to do is click the edit button and the
site will take care of the fork/commit businesses.

Blog post: https://github.com/blog/905-edit-like-an-ace
OKF's projects: https://github.com/okfn/

_______________________________________________
okfn-help mailing list
okfn-help at lists.okfn.org
http://lists.okfn.org/mailman/listinfo/okfn-help
_______________________________________________
Nipy-devel mailing list
Nipy-devel at neuroimaging.scipy.org
http://mail.scipy.org/mailman/listinfo/nipy-devel


From haehn at bwh.harvard.edu  Tue Aug 16 16:35:42 2011
From: haehn at bwh.harvard.edu (Daniel Haehn)
Date: Tue, 16 Aug 2011 12:35:42 -0400
Subject: [Ctk-developers] ShowStatusTextUponGoToStepSuccess workflow
	feature, please review
In-Reply-To: <CAPDjdmZwuN-RSfRNPz3ZOgwmDTTN-QUrY6X+0VfjDBHoVyOCnQ@mail.gmail.com>
References: <CAPDjdmZwuN-RSfRNPz3ZOgwmDTTN-QUrY6X+0VfjDBHoVyOCnQ@mail.gmail.com>
Message-ID: <CAPDjdmY+3BLQyVCZoBf__Bu6-CEJN=cVASvMRVHvYvrvA+MPrA@mail.gmail.com>

Hi,

did anybody have a chance to look at it yet?

Thanks,
Daniel

On Thu, Aug 11, 2011 at 1:15 PM, Daniel Haehn <haehn at bwh.harvard.edu> wrote:
> Hi Devels,
>
> could anybody please review the following topic:
>
> https://github.com/haehn/CTK/commits/add-ShowStatusTextUponGoToStepSuccess-workflow-feature
>
> I added a property to be able to disable the Status Text update on the
> origin step when a GoToStep(..)-call of a ctkWorkflow succeeds.
>
> Looking forward to your feedback..
>
> Daniel
>


From haehn at bwh.harvard.edu  Tue Aug 16 16:37:15 2011
From: haehn at bwh.harvard.edu (Daniel Haehn)
Date: Tue, 16 Aug 2011 12:37:15 -0400
Subject: [Ctk-developers] ctkMatrixWidget: setValue not invokable from Python
Message-ID: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>

Hi guys,

it seems that it is not possible to set a value of a ctkMatrixWidget
from Python?

Shall we just enable Q_INVOKABLE on the ctkMatrixWidget::setValue method?

Thanks,
Daniel


From julien.finet at kitware.com  Tue Aug 16 17:48:34 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Tue, 16 Aug 2011 13:48:34 -0400
Subject: [Ctk-developers] ctkMatrixWidget: setValue not invokable from
	Python
In-Reply-To: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>
References: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>
Message-ID: <CAKoWPPEkcURxmR_xbqwtQHu8xMRugSLpnmeedYReXzTf-Cfk8Q@mail.gmail.com>

Either that or we make a Q_PROPERTY named "values":
Q_PROPERTY( QVector<double> values READ values WRITE setValues)

There is already: ctkMatrixWidget::setVector(QVector<double>), maybe it
could be renamed into setValues and values() should then also be written.

Julien.

On Tue, Aug 16, 2011 at 12:37 PM, Daniel Haehn <haehn at bwh.harvard.edu>wrote:

> Hi guys,
>
> it seems that it is not possible to set a value of a ctkMatrixWidget
> from Python?
>
> Shall we just enable Q_INVOKABLE on the ctkMatrixWidget::setValue method?
>
> Thanks,
> Daniel
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110816/850d41da/attachment.htm>

From haehn at bwh.harvard.edu  Tue Aug 16 19:04:54 2011
From: haehn at bwh.harvard.edu (Daniel Haehn)
Date: Tue, 16 Aug 2011 15:04:54 -0400
Subject: [Ctk-developers] ctkMatrixWidget: setValue not invokable from
	Python
In-Reply-To: <CAKoWPPEkcURxmR_xbqwtQHu8xMRugSLpnmeedYReXzTf-Cfk8Q@mail.gmail.com>
References: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>
	<CAKoWPPEkcURxmR_xbqwtQHu8xMRugSLpnmeedYReXzTf-Cfk8Q@mail.gmail.com>
Message-ID: <CAPDjdmZWXsHtE0PSdq2RtG0wC9U0Dcgn7Q1RedVMSrrWS6JGHg@mail.gmail.com>

Hi Julien,

why do you think a Q_PROPERTY is better? Anyway, I will give it a shot
and let you know.

Cheers,
Daniel

On Tue, Aug 16, 2011 at 1:48 PM, Julien Finet <julien.finet at kitware.com> wrote:
> Either that or we make a?Q_PROPERTY named?"values":
> Q_PROPERTY( QVector<double> values READ values WRITE setValues)
> There is already: ctkMatrixWidget::setVector(QVector<double>), maybe it
> could be renamed into setValues and values() should then also be written.
> Julien.
>
> On Tue, Aug 16, 2011 at 12:37 PM, Daniel Haehn <haehn at bwh.harvard.edu>
> wrote:
>>
>> Hi guys,
>>
>> it seems that it is not possible to set a value of a ctkMatrixWidget
>> from Python?
>>
>> Shall we just enable Q_INVOKABLE on the ctkMatrixWidget::setValue method?
>>
>> Thanks,
>> Daniel
>> _______________________________________________
>> Ctk-developers mailing list
>> Ctk-developers at commontk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>


From julien.finet at kitware.com  Tue Aug 16 19:11:12 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Tue, 16 Aug 2011 15:11:12 -0400
Subject: [Ctk-developers] ctkMatrixWidget: setValue not invokable from
	Python
In-Reply-To: <CAPDjdmZWXsHtE0PSdq2RtG0wC9U0Dcgn7Q1RedVMSrrWS6JGHg@mail.gmail.com>
References: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>
	<CAKoWPPEkcURxmR_xbqwtQHu8xMRugSLpnmeedYReXzTf-Cfk8Q@mail.gmail.com>
	<CAPDjdmZWXsHtE0PSdq2RtG0wC9U0Dcgn7Q1RedVMSrrWS6JGHg@mail.gmail.com>
Message-ID: <CAKoWPPHdWoY9k1qMpc2J1gYtNY_kfgCoiP0puufa7ed64Ah52Q@mail.gmail.com>

Because a "Q_PROPERTY adds features through the meta-object system".
Practically in this case, it allows the property to be wrapped with python,
and initial values can also be set directly via the Designer.
As a more philosophical point, the matrix "values" are a "property" of the
matrix.

Julien.

On Tue, Aug 16, 2011 at 3:04 PM, Daniel Haehn <haehn at bwh.harvard.edu> wrote:

> Hi Julien,
>
> why do you think a Q_PROPERTY is better? Anyway, I will give it a shot
> and let you know.
>
> Cheers,
> Daniel
>
> On Tue, Aug 16, 2011 at 1:48 PM, Julien Finet <julien.finet at kitware.com>
> wrote:
> > Either that or we make a Q_PROPERTY named "values":
> > Q_PROPERTY( QVector<double> values READ values WRITE setValues)
> > There is already: ctkMatrixWidget::setVector(QVector<double>), maybe it
> > could be renamed into setValues and values() should then also be written.
> > Julien.
> >
> > On Tue, Aug 16, 2011 at 12:37 PM, Daniel Haehn <haehn at bwh.harvard.edu>
> > wrote:
> >>
> >> Hi guys,
> >>
> >> it seems that it is not possible to set a value of a ctkMatrixWidget
> >> from Python?
> >>
> >> Shall we just enable Q_INVOKABLE on the ctkMatrixWidget::setValue
> method?
> >>
> >> Thanks,
> >> Daniel
> >> _______________________________________________
> >> Ctk-developers mailing list
> >> Ctk-developers at commontk.org
> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110816/a2a1a146/attachment.htm>

From jchris.fillionr at kitware.com  Tue Aug 16 19:39:08 2011
From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin)
Date: Tue, 16 Aug 2011 15:39:08 -0400
Subject: [Ctk-developers] ShowStatusTextUponGoToStepSuccess workflow
 feature, please review
In-Reply-To: <CAPDjdmY+3BLQyVCZoBf__Bu6-CEJN=cVASvMRVHvYvrvA+MPrA@mail.gmail.com>
References: <CAPDjdmZwuN-RSfRNPz3ZOgwmDTTN-QUrY6X+0VfjDBHoVyOCnQ@mail.gmail.com>
	<CAPDjdmY+3BLQyVCZoBf__Bu6-CEJN=cVASvMRVHvYvrvA+MPrA@mail.gmail.com>
Message-ID: <CANLz8R5A44TMgDG6UJR+YJF3e=k=N=UynmKXq=RvApv2+zeFyg@mail.gmail.com>

Hi Daniel,

Just looked at it.

Please consider the following remarks:
 - Regarding the git commit msg. See
http://www.commontk.org/index.php/Contributing_to_CTK#Git_Commit_Style

 - Regarding the patch:
     - May be you could just add a property named ErrorTextDisabled to
ctkWorkflowGroupBox ?
    - See line 110 of ctkWorkflowGroupBox.cpp

Danielle> What do you think ?

Thanks
Jc

On Tue, Aug 16, 2011 at 12:35 PM, Daniel Haehn <haehn at bwh.harvard.edu>wrote:

> Hi,
>
> did anybody have a chance to look at it yet?
>
> Thanks,
> Daniel
>
> On Thu, Aug 11, 2011 at 1:15 PM, Daniel Haehn <haehn at bwh.harvard.edu>
> wrote:
> > Hi Devels,
> >
> > could anybody please review the following topic:
> >
> >
> https://github.com/haehn/CTK/commits/add-ShowStatusTextUponGoToStepSuccess-workflow-feature
> >
> > I added a property to be able to disable the Status Text update on the
> > origin step when a GoToStep(..)-call of a ctkWorkflow succeeds.
> >
> > Looking forward to your feedback..
> >
> > Daniel
> >
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>



-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110816/f7365e1f/attachment.htm>

From jchris.fillionr at kitware.com  Tue Aug 16 19:57:38 2011
From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin)
Date: Tue, 16 Aug 2011 15:57:38 -0400
Subject: [Ctk-developers] ctkMatrixWidget: setValue not invokable from
	Python
In-Reply-To: <CAKoWPPHdWoY9k1qMpc2J1gYtNY_kfgCoiP0puufa7ed64Ah52Q@mail.gmail.com>
References: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>
	<CAKoWPPEkcURxmR_xbqwtQHu8xMRugSLpnmeedYReXzTf-Cfk8Q@mail.gmail.com>
	<CAPDjdmZWXsHtE0PSdq2RtG0wC9U0Dcgn7Q1RedVMSrrWS6JGHg@mail.gmail.com>
	<CAKoWPPHdWoY9k1qMpc2J1gYtNY_kfgCoiP0puufa7ed64Ah52Q@mail.gmail.com>
Message-ID: <CANLz8R4CrEYFb6hg-iiyeSs2eGJM=UYEFw+27nqB+5j-A2fL7g@mail.gmail.com>

+1 for setValues
Jc

On Tue, Aug 16, 2011 at 3:11 PM, Julien Finet <julien.finet at kitware.com>wrote:

> Because a "Q_PROPERTY adds features through the meta-object system".
> Practically in this case, it allows the property to be wrapped with python,
> and initial values can also be set directly via the Designer.
> As a more philosophical point, the matrix "values" are a "property" of the
> matrix.
>
> Julien.
>
> On Tue, Aug 16, 2011 at 3:04 PM, Daniel Haehn <haehn at bwh.harvard.edu>wrote:
>
>> Hi Julien,
>>
>> why do you think a Q_PROPERTY is better? Anyway, I will give it a shot
>> and let you know.
>>
>> Cheers,
>> Daniel
>>
>> On Tue, Aug 16, 2011 at 1:48 PM, Julien Finet <julien.finet at kitware.com>
>> wrote:
>> > Either that or we make a Q_PROPERTY named "values":
>> > Q_PROPERTY( QVector<double> values READ values WRITE setValues)
>> > There is already: ctkMatrixWidget::setVector(QVector<double>), maybe it
>> > could be renamed into setValues and values() should then also be
>> written.
>> > Julien.
>> >
>> > On Tue, Aug 16, 2011 at 12:37 PM, Daniel Haehn <haehn at bwh.harvard.edu>
>> > wrote:
>> >>
>> >> Hi guys,
>> >>
>> >> it seems that it is not possible to set a value of a ctkMatrixWidget
>> >> from Python?
>> >>
>> >> Shall we just enable Q_INVOKABLE on the ctkMatrixWidget::setValue
>> method?
>> >>
>> >> Thanks,
>> >> Daniel
>> >> _______________________________________________
>> >> Ctk-developers mailing list
>> >> Ctk-developers at commontk.org
>> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>> >
>> >
>>
>
>
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>


-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110816/8dbb7513/attachment.htm>

From julien.finet at kitware.com  Wed Aug 17 00:03:11 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Tue, 16 Aug 2011 20:03:11 -0400
Subject: [Ctk-developers] ShowStatusTextUponGoToStepSuccess workflow
 feature, please review
In-Reply-To: <CANLz8R5A44TMgDG6UJR+YJF3e=k=N=UynmKXq=RvApv2+zeFyg@mail.gmail.com>
References: <CAPDjdmZwuN-RSfRNPz3ZOgwmDTTN-QUrY6X+0VfjDBHoVyOCnQ@mail.gmail.com>
	<CAPDjdmY+3BLQyVCZoBf__Bu6-CEJN=cVASvMRVHvYvrvA+MPrA@mail.gmail.com>
	<CANLz8R5A44TMgDG6UJR+YJF3e=k=N=UynmKXq=RvApv2+zeFyg@mail.gmail.com>
Message-ID: <CAKoWPPHF1kkTBsKdXJ5NfoSNLwPTb4w2jJdd+N1kcjbcoYZ8nw@mail.gmail.com>

I usually prefer XXXEnabled to XXXDisabled.
Even if it is disabled by default.

Julien.

On Tue, Aug 16, 2011 at 3:39 PM, Jean-Christophe Fillion-Robin <
jchris.fillionr at kitware.com> wrote:

> Hi Daniel,
>
> Just looked at it.
>
> Please consider the following remarks:
>  - Regarding the git commit msg. See
> http://www.commontk.org/index.php/Contributing_to_CTK#Git_Commit_Style
>
>  - Regarding the patch:
>      - May be you could just add a property named ErrorTextDisabled to
> ctkWorkflowGroupBox ?
>     - See line 110 of ctkWorkflowGroupBox.cpp
>
> Danielle> What do you think ?
>
> Thanks
> Jc
>
>
> On Tue, Aug 16, 2011 at 12:35 PM, Daniel Haehn <haehn at bwh.harvard.edu>wrote:
>
>> Hi,
>>
>> did anybody have a chance to look at it yet?
>>
>> Thanks,
>> Daniel
>>
>> On Thu, Aug 11, 2011 at 1:15 PM, Daniel Haehn <haehn at bwh.harvard.edu>
>> wrote:
>> > Hi Devels,
>> >
>> > could anybody please review the following topic:
>> >
>> >
>> https://github.com/haehn/CTK/commits/add-ShowStatusTextUponGoToStepSuccess-workflow-feature
>> >
>> > I added a property to be able to disable the Status Text update on the
>> > origin step when a GoToStep(..)-call of a ctkWorkflow succeeds.
>> >
>> > Looking forward to your feedback..
>> >
>> > Daniel
>> >
>> _______________________________________________
>> Ctk-developers mailing list
>> Ctk-developers at commontk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>
>
>
>
> --
> +1 919 869 8849
>
>
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110816/3810f6bf/attachment.htm>

From jchris.fillionr at kitware.com  Wed Aug 17 00:08:17 2011
From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin)
Date: Tue, 16 Aug 2011 20:08:17 -0400
Subject: [Ctk-developers] ShowStatusTextUponGoToStepSuccess workflow
 feature, please review
In-Reply-To: <CAKoWPPHF1kkTBsKdXJ5NfoSNLwPTb4w2jJdd+N1kcjbcoYZ8nw@mail.gmail.com>
References: <CAPDjdmZwuN-RSfRNPz3ZOgwmDTTN-QUrY6X+0VfjDBHoVyOCnQ@mail.gmail.com>
	<CAPDjdmY+3BLQyVCZoBf__Bu6-CEJN=cVASvMRVHvYvrvA+MPrA@mail.gmail.com>
	<CANLz8R5A44TMgDG6UJR+YJF3e=k=N=UynmKXq=RvApv2+zeFyg@mail.gmail.com>
	<CAKoWPPHF1kkTBsKdXJ5NfoSNLwPTb4w2jJdd+N1kcjbcoYZ8nw@mail.gmail.com>
Message-ID: <CANLz8R7Ang1a2G==AGAGsRaE-KG4rtngeP=EfjaY8mH8JuNDzQ@mail.gmail.com>

+1

On Tue, Aug 16, 2011 at 8:03 PM, Julien Finet <julien.finet at kitware.com>wrote:

> I usually prefer XXXEnabled to XXXDisabled.
> Even if it is disabled by default.
>
> Julien.
>
>
> On Tue, Aug 16, 2011 at 3:39 PM, Jean-Christophe Fillion-Robin <
> jchris.fillionr at kitware.com> wrote:
>
>> Hi Daniel,
>>
>> Just looked at it.
>>
>> Please consider the following remarks:
>>  - Regarding the git commit msg. See
>> http://www.commontk.org/index.php/Contributing_to_CTK#Git_Commit_Style
>>
>>  - Regarding the patch:
>>      - May be you could just add a property named ErrorTextDisabled to
>> ctkWorkflowGroupBox ?
>>     - See line 110 of ctkWorkflowGroupBox.cpp
>>
>> Danielle> What do you think ?
>>
>> Thanks
>> Jc
>>
>>
>> On Tue, Aug 16, 2011 at 12:35 PM, Daniel Haehn <haehn at bwh.harvard.edu>wrote:
>>
>>> Hi,
>>>
>>> did anybody have a chance to look at it yet?
>>>
>>> Thanks,
>>> Daniel
>>>
>>> On Thu, Aug 11, 2011 at 1:15 PM, Daniel Haehn <haehn at bwh.harvard.edu>
>>> wrote:
>>> > Hi Devels,
>>> >
>>> > could anybody please review the following topic:
>>> >
>>> >
>>> https://github.com/haehn/CTK/commits/add-ShowStatusTextUponGoToStepSuccess-workflow-feature
>>> >
>>> > I added a property to be able to disable the Status Text update on the
>>> > origin step when a GoToStep(..)-call of a ctkWorkflow succeeds.
>>> >
>>> > Looking forward to your feedback..
>>> >
>>> > Daniel
>>> >
>>> _______________________________________________
>>> Ctk-developers mailing list
>>> Ctk-developers at commontk.org
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>>
>>
>>
>>
>> --
>> +1 919 869 8849
>>
>>
>> _______________________________________________
>> Ctk-developers mailing list
>> Ctk-developers at commontk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>
>>
>


-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110816/3b2bbddd/attachment.htm>

From haehn at bwh.harvard.edu  Wed Aug 17 19:15:11 2011
From: haehn at bwh.harvard.edu (Daniel Haehn)
Date: Wed, 17 Aug 2011 15:15:11 -0400
Subject: [Ctk-developers] ShowStatusTextUponGoToStepSuccess workflow
 feature, please review
In-Reply-To: <CANLz8R5A44TMgDG6UJR+YJF3e=k=N=UynmKXq=RvApv2+zeFyg@mail.gmail.com>
References: <CAPDjdmZwuN-RSfRNPz3ZOgwmDTTN-QUrY6X+0VfjDBHoVyOCnQ@mail.gmail.com>
	<CAPDjdmY+3BLQyVCZoBf__Bu6-CEJN=cVASvMRVHvYvrvA+MPrA@mail.gmail.com>
	<CANLz8R5A44TMgDG6UJR+YJF3e=k=N=UynmKXq=RvApv2+zeFyg@mail.gmail.com>
Message-ID: <CAPDjdma9maaf0812S512LNEDsJWDYgqyD+pSBdSECBX4uuFdNg@mail.gmail.com>

Hi JC,

thanks for the feedback.

If we would add the property ErrorTextDisabled to the
ctkWorkflowGroupBox, how can it be set from Python?

Cheers,
Daniel

On Tue, Aug 16, 2011 at 3:39 PM, Jean-Christophe Fillion-Robin
<jchris.fillionr at kitware.com> wrote:
> Hi Daniel,
>
> Just looked at it.
>
> Please consider the following remarks:
> ?- Regarding the git commit msg. See
> http://www.commontk.org/index.php/Contributing_to_CTK#Git_Commit_Style
>
> ?- Regarding the patch:
> ???? - May be you could just add a property named ErrorTextDisabled to
> ctkWorkflowGroupBox ?
> ??? - See line 110 of ctkWorkflowGroupBox.cpp
>
> Danielle> What do you think ?
>
> Thanks
> Jc
>
> On Tue, Aug 16, 2011 at 12:35 PM, Daniel Haehn <haehn at bwh.harvard.edu>
> wrote:
>>
>> Hi,
>>
>> did anybody have a chance to look at it yet?
>>
>> Thanks,
>> Daniel
>>
>> On Thu, Aug 11, 2011 at 1:15 PM, Daniel Haehn <haehn at bwh.harvard.edu>
>> wrote:
>> > Hi Devels,
>> >
>> > could anybody please review the following topic:
>> >
>> >
>> > https://github.com/haehn/CTK/commits/add-ShowStatusTextUponGoToStepSuccess-workflow-feature
>> >
>> > I added a property to be able to disable the Status Text update on the
>> > origin step when a GoToStep(..)-call of a ctkWorkflow succeeds.
>> >
>> > Looking forward to your feedback..
>> >
>> > Daniel
>> >
>> _______________________________________________
>> Ctk-developers mailing list
>> Ctk-developers at commontk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>
>
> --
> +1 919 869 8849
>
>


From julien.finet at kitware.com  Wed Aug 17 19:26:45 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Wed, 17 Aug 2011 15:26:45 -0400
Subject: [Ctk-developers] ShowStatusTextUponGoToStepSuccess workflow
 feature, please review
In-Reply-To: <CAPDjdma9maaf0812S512LNEDsJWDYgqyD+pSBdSECBX4uuFdNg@mail.gmail.com>
References: <CAPDjdmZwuN-RSfRNPz3ZOgwmDTTN-QUrY6X+0VfjDBHoVyOCnQ@mail.gmail.com>
	<CAPDjdmY+3BLQyVCZoBf__Bu6-CEJN=cVASvMRVHvYvrvA+MPrA@mail.gmail.com>
	<CANLz8R5A44TMgDG6UJR+YJF3e=k=N=UynmKXq=RvApv2+zeFyg@mail.gmail.com>
	<CAPDjdma9maaf0812S512LNEDsJWDYgqyD+pSBdSECBX4uuFdNg@mail.gmail.com>
Message-ID: <CAKoWPPF-AF8xrmW6HFuE++EwsPruL-pYDNbt6vefP8LAw+5LBQ@mail.gmail.com>

myWorkflowGroupBox.ErrorTextDisabled = True

no?
j.

On Wed, Aug 17, 2011 at 3:15 PM, Daniel Haehn <haehn at bwh.harvard.edu> wrote:

> Hi JC,
>
> thanks for the feedback.
>
> If we would add the property ErrorTextDisabled to the
> ctkWorkflowGroupBox, how can it be set from Python?
>
> Cheers,
> Daniel
>
> On Tue, Aug 16, 2011 at 3:39 PM, Jean-Christophe Fillion-Robin
> <jchris.fillionr at kitware.com> wrote:
> > Hi Daniel,
> >
> > Just looked at it.
> >
> > Please consider the following remarks:
> >  - Regarding the git commit msg. See
> > http://www.commontk.org/index.php/Contributing_to_CTK#Git_Commit_Style
> >
> >  - Regarding the patch:
> >      - May be you could just add a property named ErrorTextDisabled to
> > ctkWorkflowGroupBox ?
> >     - See line 110 of ctkWorkflowGroupBox.cpp
> >
> > Danielle> What do you think ?
> >
> > Thanks
> > Jc
> >
> > On Tue, Aug 16, 2011 at 12:35 PM, Daniel Haehn <haehn at bwh.harvard.edu>
> > wrote:
> >>
> >> Hi,
> >>
> >> did anybody have a chance to look at it yet?
> >>
> >> Thanks,
> >> Daniel
> >>
> >> On Thu, Aug 11, 2011 at 1:15 PM, Daniel Haehn <haehn at bwh.harvard.edu>
> >> wrote:
> >> > Hi Devels,
> >> >
> >> > could anybody please review the following topic:
> >> >
> >> >
> >> >
> https://github.com/haehn/CTK/commits/add-ShowStatusTextUponGoToStepSuccess-workflow-feature
> >> >
> >> > I added a property to be able to disable the Status Text update on the
> >> > origin step when a GoToStep(..)-call of a ctkWorkflow succeeds.
> >> >
> >> > Looking forward to your feedback..
> >> >
> >> > Daniel
> >> >
> >> _______________________________________________
> >> Ctk-developers mailing list
> >> Ctk-developers at commontk.org
> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >
> >
> >
> > --
> > +1 919 869 8849
> >
> >
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110817/1ee3c6a3/attachment.htm>

From haehn at bwh.harvard.edu  Wed Aug 17 19:32:40 2011
From: haehn at bwh.harvard.edu (Daniel Haehn)
Date: Wed, 17 Aug 2011 15:32:40 -0400
Subject: [Ctk-developers] ShowStatusTextUponGoToStepSuccess workflow
 feature, please review
In-Reply-To: <CAKoWPPF-AF8xrmW6HFuE++EwsPruL-pYDNbt6vefP8LAw+5LBQ@mail.gmail.com>
References: <CAPDjdmZwuN-RSfRNPz3ZOgwmDTTN-QUrY6X+0VfjDBHoVyOCnQ@mail.gmail.com>
	<CAPDjdmY+3BLQyVCZoBf__Bu6-CEJN=cVASvMRVHvYvrvA+MPrA@mail.gmail.com>
	<CANLz8R5A44TMgDG6UJR+YJF3e=k=N=UynmKXq=RvApv2+zeFyg@mail.gmail.com>
	<CAPDjdma9maaf0812S512LNEDsJWDYgqyD+pSBdSECBX4uuFdNg@mail.gmail.com>
	<CAKoWPPF-AF8xrmW6HFuE++EwsPruL-pYDNbt6vefP8LAw+5LBQ@mail.gmail.com>
Message-ID: <CAPDjdmbf8Esqpw2-DUO7uAMvJQHjThB7KeuoZkumP9HQXe+Cng@mail.gmail.com>

I don't think it is possible to access the groupbox if you created a
ctkWorkflowWidget in Python. So would it make sense to expose this one
as well?

Daniel

On Wed, Aug 17, 2011 at 3:26 PM, Julien Finet <julien.finet at kitware.com> wrote:
> myWorkflowGroupBox.ErrorTextDisabled = True
> no?
> j.
>
> On Wed, Aug 17, 2011 at 3:15 PM, Daniel Haehn <haehn at bwh.harvard.edu> wrote:
>>
>> Hi JC,
>>
>> thanks for the feedback.
>>
>> If we would add the property ErrorTextDisabled to the
>> ctkWorkflowGroupBox, how can it be set from Python?
>>
>> Cheers,
>> Daniel
>>
>> On Tue, Aug 16, 2011 at 3:39 PM, Jean-Christophe Fillion-Robin
>> <jchris.fillionr at kitware.com> wrote:
>> > Hi Daniel,
>> >
>> > Just looked at it.
>> >
>> > Please consider the following remarks:
>> > ?- Regarding the git commit msg. See
>> > http://www.commontk.org/index.php/Contributing_to_CTK#Git_Commit_Style
>> >
>> > ?- Regarding the patch:
>> > ???? - May be you could just add a property named ErrorTextDisabled to
>> > ctkWorkflowGroupBox ?
>> > ??? - See line 110 of ctkWorkflowGroupBox.cpp
>> >
>> > Danielle> What do you think ?
>> >
>> > Thanks
>> > Jc
>> >
>> > On Tue, Aug 16, 2011 at 12:35 PM, Daniel Haehn <haehn at bwh.harvard.edu>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> did anybody have a chance to look at it yet?
>> >>
>> >> Thanks,
>> >> Daniel
>> >>
>> >> On Thu, Aug 11, 2011 at 1:15 PM, Daniel Haehn <haehn at bwh.harvard.edu>
>> >> wrote:
>> >> > Hi Devels,
>> >> >
>> >> > could anybody please review the following topic:
>> >> >
>> >> >
>> >> >
>> >> > https://github.com/haehn/CTK/commits/add-ShowStatusTextUponGoToStepSuccess-workflow-feature
>> >> >
>> >> > I added a property to be able to disable the Status Text update on
>> >> > the
>> >> > origin step when a GoToStep(..)-call of a ctkWorkflow succeeds.
>> >> >
>> >> > Looking forward to your feedback..
>> >> >
>> >> > Daniel
>> >> >
>> >> _______________________________________________
>> >> Ctk-developers mailing list
>> >> Ctk-developers at commontk.org
>> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>> >
>> >
>> >
>> > --
>> > +1 919 869 8849
>> >
>> >
>> _______________________________________________
>> Ctk-developers mailing list
>> Ctk-developers at commontk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>


From jchris.fillionr at kitware.com  Wed Aug 17 19:36:27 2011
From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin)
Date: Wed, 17 Aug 2011 15:36:27 -0400
Subject: [Ctk-developers] ShowStatusTextUponGoToStepSuccess workflow
 feature, please review
In-Reply-To: <CAPDjdmbf8Esqpw2-DUO7uAMvJQHjThB7KeuoZkumP9HQXe+Cng@mail.gmail.com>
References: <CAPDjdmZwuN-RSfRNPz3ZOgwmDTTN-QUrY6X+0VfjDBHoVyOCnQ@mail.gmail.com>
	<CAPDjdmY+3BLQyVCZoBf__Bu6-CEJN=cVASvMRVHvYvrvA+MPrA@mail.gmail.com>
	<CANLz8R5A44TMgDG6UJR+YJF3e=k=N=UynmKXq=RvApv2+zeFyg@mail.gmail.com>
	<CAPDjdma9maaf0812S512LNEDsJWDYgqyD+pSBdSECBX4uuFdNg@mail.gmail.com>
	<CAKoWPPF-AF8xrmW6HFuE++EwsPruL-pYDNbt6vefP8LAw+5LBQ@mail.gmail.com>
	<CAPDjdmbf8Esqpw2-DUO7uAMvJQHjThB7KeuoZkumP9HQXe+Cng@mail.gmail.com>
Message-ID: <CANLz8R7Oe1-ji8feisf8=KWMChR0LDjx+sf_B7dUyat3dOzWOQ@mail.gmail.com>

You could expose the getter returning workflowGroupBox.. then the property
ErrorTextDisabled will be accessible.

Jc

On Wed, Aug 17, 2011 at 3:32 PM, Daniel Haehn <haehn at bwh.harvard.edu> wrote:

> I don't think it is possible to access the groupbox if you created a
> ctkWorkflowWidget in Python. So would it make sense to expose this one
> as well?
>
> Daniel
>
> On Wed, Aug 17, 2011 at 3:26 PM, Julien Finet <julien.finet at kitware.com>
> wrote:
> > myWorkflowGroupBox.ErrorTextDisabled = True
> > no?
> > j.
> >
> > On Wed, Aug 17, 2011 at 3:15 PM, Daniel Haehn <haehn at bwh.harvard.edu>
> wrote:
> >>
> >> Hi JC,
> >>
> >> thanks for the feedback.
> >>
> >> If we would add the property ErrorTextDisabled to the
> >> ctkWorkflowGroupBox, how can it be set from Python?
> >>
> >> Cheers,
> >> Daniel
> >>
> >> On Tue, Aug 16, 2011 at 3:39 PM, Jean-Christophe Fillion-Robin
> >> <jchris.fillionr at kitware.com> wrote:
> >> > Hi Daniel,
> >> >
> >> > Just looked at it.
> >> >
> >> > Please consider the following remarks:
> >> >  - Regarding the git commit msg. See
> >> >
> http://www.commontk.org/index.php/Contributing_to_CTK#Git_Commit_Style
> >> >
> >> >  - Regarding the patch:
> >> >      - May be you could just add a property named ErrorTextDisabled to
> >> > ctkWorkflowGroupBox ?
> >> >     - See line 110 of ctkWorkflowGroupBox.cpp
> >> >
> >> > Danielle> What do you think ?
> >> >
> >> > Thanks
> >> > Jc
> >> >
> >> > On Tue, Aug 16, 2011 at 12:35 PM, Daniel Haehn <haehn at bwh.harvard.edu
> >
> >> > wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> did anybody have a chance to look at it yet?
> >> >>
> >> >> Thanks,
> >> >> Daniel
> >> >>
> >> >> On Thu, Aug 11, 2011 at 1:15 PM, Daniel Haehn <haehn at bwh.harvard.edu
> >
> >> >> wrote:
> >> >> > Hi Devels,
> >> >> >
> >> >> > could anybody please review the following topic:
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> https://github.com/haehn/CTK/commits/add-ShowStatusTextUponGoToStepSuccess-workflow-feature
> >> >> >
> >> >> > I added a property to be able to disable the Status Text update on
> >> >> > the
> >> >> > origin step when a GoToStep(..)-call of a ctkWorkflow succeeds.
> >> >> >
> >> >> > Looking forward to your feedback..
> >> >> >
> >> >> > Daniel
> >> >> >
> >> >> _______________________________________________
> >> >> Ctk-developers mailing list
> >> >> Ctk-developers at commontk.org
> >> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >> >
> >> >
> >> >
> >> > --
> >> > +1 919 869 8849
> >> >
> >> >
> >> _______________________________________________
> >> Ctk-developers mailing list
> >> Ctk-developers at commontk.org
> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >
> >
>



-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110817/2d9a1671/attachment.htm>

From haehn at bwh.harvard.edu  Wed Aug 17 19:38:55 2011
From: haehn at bwh.harvard.edu (Daniel Haehn)
Date: Wed, 17 Aug 2011 15:38:55 -0400
Subject: [Ctk-developers] ShowStatusTextUponGoToStepSuccess workflow
 feature, please review
In-Reply-To: <CANLz8R7Oe1-ji8feisf8=KWMChR0LDjx+sf_B7dUyat3dOzWOQ@mail.gmail.com>
References: <CAPDjdmZwuN-RSfRNPz3ZOgwmDTTN-QUrY6X+0VfjDBHoVyOCnQ@mail.gmail.com>
	<CAPDjdmY+3BLQyVCZoBf__Bu6-CEJN=cVASvMRVHvYvrvA+MPrA@mail.gmail.com>
	<CANLz8R5A44TMgDG6UJR+YJF3e=k=N=UynmKXq=RvApv2+zeFyg@mail.gmail.com>
	<CAPDjdma9maaf0812S512LNEDsJWDYgqyD+pSBdSECBX4uuFdNg@mail.gmail.com>
	<CAKoWPPF-AF8xrmW6HFuE++EwsPruL-pYDNbt6vefP8LAw+5LBQ@mail.gmail.com>
	<CAPDjdmbf8Esqpw2-DUO7uAMvJQHjThB7KeuoZkumP9HQXe+Cng@mail.gmail.com>
	<CANLz8R7Oe1-ji8feisf8=KWMChR0LDjx+sf_B7dUyat3dOzWOQ@mail.gmail.com>
Message-ID: <CAPDjdmZB-3Yjr1SBXi=jYs-Ew441WP+Kt1OuaF2PAk=Jocf9eA@mail.gmail.com>

Ok, will do so.

Daniel

On Wed, Aug 17, 2011 at 3:36 PM, Jean-Christophe Fillion-Robin
<jchris.fillionr at kitware.com> wrote:
> You could expose the getter returning workflowGroupBox.. then the property
> ErrorTextDisabled will be accessible.
>
> Jc
>
> On Wed, Aug 17, 2011 at 3:32 PM, Daniel Haehn <haehn at bwh.harvard.edu> wrote:
>>
>> I don't think it is possible to access the groupbox if you created a
>> ctkWorkflowWidget in Python. So would it make sense to expose this one
>> as well?
>>
>> Daniel
>>
>> On Wed, Aug 17, 2011 at 3:26 PM, Julien Finet <julien.finet at kitware.com>
>> wrote:
>> > myWorkflowGroupBox.ErrorTextDisabled = True
>> > no?
>> > j.
>> >
>> > On Wed, Aug 17, 2011 at 3:15 PM, Daniel Haehn <haehn at bwh.harvard.edu>
>> > wrote:
>> >>
>> >> Hi JC,
>> >>
>> >> thanks for the feedback.
>> >>
>> >> If we would add the property ErrorTextDisabled to the
>> >> ctkWorkflowGroupBox, how can it be set from Python?
>> >>
>> >> Cheers,
>> >> Daniel
>> >>
>> >> On Tue, Aug 16, 2011 at 3:39 PM, Jean-Christophe Fillion-Robin
>> >> <jchris.fillionr at kitware.com> wrote:
>> >> > Hi Daniel,
>> >> >
>> >> > Just looked at it.
>> >> >
>> >> > Please consider the following remarks:
>> >> > ?- Regarding the git commit msg. See
>> >> >
>> >> > http://www.commontk.org/index.php/Contributing_to_CTK#Git_Commit_Style
>> >> >
>> >> > ?- Regarding the patch:
>> >> > ???? - May be you could just add a property named ErrorTextDisabled
>> >> > to
>> >> > ctkWorkflowGroupBox ?
>> >> > ??? - See line 110 of ctkWorkflowGroupBox.cpp
>> >> >
>> >> > Danielle> What do you think ?
>> >> >
>> >> > Thanks
>> >> > Jc
>> >> >
>> >> > On Tue, Aug 16, 2011 at 12:35 PM, Daniel Haehn
>> >> > <haehn at bwh.harvard.edu>
>> >> > wrote:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> did anybody have a chance to look at it yet?
>> >> >>
>> >> >> Thanks,
>> >> >> Daniel
>> >> >>
>> >> >> On Thu, Aug 11, 2011 at 1:15 PM, Daniel Haehn
>> >> >> <haehn at bwh.harvard.edu>
>> >> >> wrote:
>> >> >> > Hi Devels,
>> >> >> >
>> >> >> > could anybody please review the following topic:
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > https://github.com/haehn/CTK/commits/add-ShowStatusTextUponGoToStepSuccess-workflow-feature
>> >> >> >
>> >> >> > I added a property to be able to disable the Status Text update on
>> >> >> > the
>> >> >> > origin step when a GoToStep(..)-call of a ctkWorkflow succeeds.
>> >> >> >
>> >> >> > Looking forward to your feedback..
>> >> >> >
>> >> >> > Daniel
>> >> >> >
>> >> >> _______________________________________________
>> >> >> Ctk-developers mailing list
>> >> >> Ctk-developers at commontk.org
>> >> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > +1 919 869 8849
>> >> >
>> >> >
>> >> _______________________________________________
>> >> Ctk-developers mailing list
>> >> Ctk-developers at commontk.org
>> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>> >
>> >
>
>
>
> --
> +1 919 869 8849
>
>


From haehn at bwh.harvard.edu  Wed Aug 17 20:15:25 2011
From: haehn at bwh.harvard.edu (Daniel Haehn)
Date: Wed, 17 Aug 2011 16:15:25 -0400
Subject: [Ctk-developers] ctkMatrixWidget: setValue not invokable from
	Python
In-Reply-To: <CANLz8R4CrEYFb6hg-iiyeSs2eGJM=UYEFw+27nqB+5j-A2fL7g@mail.gmail.com>
References: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>
	<CAKoWPPEkcURxmR_xbqwtQHu8xMRugSLpnmeedYReXzTf-Cfk8Q@mail.gmail.com>
	<CAPDjdmZWXsHtE0PSdq2RtG0wC9U0Dcgn7Q1RedVMSrrWS6JGHg@mail.gmail.com>
	<CAKoWPPHdWoY9k1qMpc2J1gYtNY_kfgCoiP0puufa7ed64Ah52Q@mail.gmail.com>
	<CANLz8R4CrEYFb6hg-iiyeSs2eGJM=UYEFw+27nqB+5j-A2fL7g@mail.gmail.com>
Message-ID: <CAPDjdmYkksDMMx052==YpsLA0kTzC0vY=zfepmmXYrHWQyzx2A@mail.gmail.com>

Hi guys,

could you please review

https://github.com/haehn/CTK/tree/add-SetValuesQPropertyMatrixWidget-feature

Thx,
Daniel

On Tue, Aug 16, 2011 at 3:57 PM, Jean-Christophe Fillion-Robin
<jchris.fillionr at kitware.com> wrote:
> +1 for setValues
> Jc
>
> On Tue, Aug 16, 2011 at 3:11 PM, Julien Finet <julien.finet at kitware.com>
> wrote:
>>
>> Because a "Q_PROPERTY adds features through the meta-object system".
>> Practically in this case, it allows the property to be wrapped with
>> python, and initial values can also be set directly via the Designer.
>> As a more?philosophical?point, the?matrix?"values" are a "property" of the
>> matrix.
>> Julien.
>> On Tue, Aug 16, 2011 at 3:04 PM, Daniel Haehn <haehn at bwh.harvard.edu>
>> wrote:
>>>
>>> Hi Julien,
>>>
>>> why do you think a Q_PROPERTY is better? Anyway, I will give it a shot
>>> and let you know.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On Tue, Aug 16, 2011 at 1:48 PM, Julien Finet <julien.finet at kitware.com>
>>> wrote:
>>> > Either that or we make a?Q_PROPERTY named?"values":
>>> > Q_PROPERTY( QVector<double> values READ values WRITE setValues)
>>> > There is already: ctkMatrixWidget::setVector(QVector<double>), maybe it
>>> > could be renamed into setValues and values() should then also be
>>> > written.
>>> > Julien.
>>> >
>>> > On Tue, Aug 16, 2011 at 12:37 PM, Daniel Haehn <haehn at bwh.harvard.edu>
>>> > wrote:
>>> >>
>>> >> Hi guys,
>>> >>
>>> >> it seems that it is not possible to set a value of a ctkMatrixWidget
>>> >> from Python?
>>> >>
>>> >> Shall we just enable Q_INVOKABLE on the ctkMatrixWidget::setValue
>>> >> method?
>>> >>
>>> >> Thanks,
>>> >> Daniel
>>> >> _______________________________________________
>>> >> Ctk-developers mailing list
>>> >> Ctk-developers at commontk.org
>>> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>> >
>>> >
>>
>>
>> _______________________________________________
>> Ctk-developers mailing list
>> Ctk-developers at commontk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>
>
>
>
> --
> +1 919 869 8849
>
>


From julien.finet at kitware.com  Wed Aug 17 20:48:20 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Wed, 17 Aug 2011 16:48:20 -0400
Subject: [Ctk-developers] ctkMatrixWidget: setValue not invokable from
	Python
In-Reply-To: <CAPDjdmYkksDMMx052==YpsLA0kTzC0vY=zfepmmXYrHWQyzx2A@mail.gmail.com>
References: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>
	<CAKoWPPEkcURxmR_xbqwtQHu8xMRugSLpnmeedYReXzTf-Cfk8Q@mail.gmail.com>
	<CAPDjdmZWXsHtE0PSdq2RtG0wC9U0Dcgn7Q1RedVMSrrWS6JGHg@mail.gmail.com>
	<CAKoWPPHdWoY9k1qMpc2J1gYtNY_kfgCoiP0puufa7ed64Ah52Q@mail.gmail.com>
	<CANLz8R4CrEYFb6hg-iiyeSs2eGJM=UYEFw+27nqB+5j-A2fL7g@mail.gmail.com>
	<CAPDjdmYkksDMMx052==YpsLA0kTzC0vY=zfepmmXYrHWQyzx2A@mail.gmail.com>
Message-ID: <CAKoWPPHisV_2WBuQRwmu=jJo5z0nmDJExDgjqhZJy9bNU6c6mg@mail.gmail.com>

Looks good, except that when populating the values vector
(ctkMatrixWidget::values()), I would call ctkMatrixWidget::value(i,j)
instead of manually querying the data in order to factorize code.

Thanks,
Julien.
p.s.I agree that setValues() would also beneficiate from some
refactorization as well, but it's another story...

On Wed, Aug 17, 2011 at 4:15 PM, Daniel Haehn <haehn at bwh.harvard.edu> wrote:

> Hi guys,
>
> could you please review
>
>
> https://github.com/haehn/CTK/tree/add-SetValuesQPropertyMatrixWidget-feature
>
> Thx,
> Daniel
>
> On Tue, Aug 16, 2011 at 3:57 PM, Jean-Christophe Fillion-Robin
> <jchris.fillionr at kitware.com> wrote:
> > +1 for setValues
> > Jc
> >
> > On Tue, Aug 16, 2011 at 3:11 PM, Julien Finet <julien.finet at kitware.com>
> > wrote:
> >>
> >> Because a "Q_PROPERTY adds features through the meta-object system".
> >> Practically in this case, it allows the property to be wrapped with
> >> python, and initial values can also be set directly via the Designer.
> >> As a more philosophical point, the matrix "values" are a "property" of
> the
> >> matrix.
> >> Julien.
> >> On Tue, Aug 16, 2011 at 3:04 PM, Daniel Haehn <haehn at bwh.harvard.edu>
> >> wrote:
> >>>
> >>> Hi Julien,
> >>>
> >>> why do you think a Q_PROPERTY is better? Anyway, I will give it a shot
> >>> and let you know.
> >>>
> >>> Cheers,
> >>> Daniel
> >>>
> >>> On Tue, Aug 16, 2011 at 1:48 PM, Julien Finet <
> julien.finet at kitware.com>
> >>> wrote:
> >>> > Either that or we make a Q_PROPERTY named "values":
> >>> > Q_PROPERTY( QVector<double> values READ values WRITE setValues)
> >>> > There is already: ctkMatrixWidget::setVector(QVector<double>), maybe
> it
> >>> > could be renamed into setValues and values() should then also be
> >>> > written.
> >>> > Julien.
> >>> >
> >>> > On Tue, Aug 16, 2011 at 12:37 PM, Daniel Haehn <
> haehn at bwh.harvard.edu>
> >>> > wrote:
> >>> >>
> >>> >> Hi guys,
> >>> >>
> >>> >> it seems that it is not possible to set a value of a ctkMatrixWidget
> >>> >> from Python?
> >>> >>
> >>> >> Shall we just enable Q_INVOKABLE on the ctkMatrixWidget::setValue
> >>> >> method?
> >>> >>
> >>> >> Thanks,
> >>> >> Daniel
> >>> >> _______________________________________________
> >>> >> Ctk-developers mailing list
> >>> >> Ctk-developers at commontk.org
> >>> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >>> >
> >>> >
> >>
> >>
> >> _______________________________________________
> >> Ctk-developers mailing list
> >> Ctk-developers at commontk.org
> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >>
> >
> >
> >
> > --
> > +1 919 869 8849
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110817/bc159883/attachment.htm>

From haehn at bwh.harvard.edu  Wed Aug 17 20:51:24 2011
From: haehn at bwh.harvard.edu (Daniel Haehn)
Date: Wed, 17 Aug 2011 16:51:24 -0400
Subject: [Ctk-developers] ShowStatusTextUponGoToStepSuccess workflow
 feature, please review
In-Reply-To: <CAPDjdmZB-3Yjr1SBXi=jYs-Ew441WP+Kt1OuaF2PAk=Jocf9eA@mail.gmail.com>
References: <CAPDjdmZwuN-RSfRNPz3ZOgwmDTTN-QUrY6X+0VfjDBHoVyOCnQ@mail.gmail.com>
	<CAPDjdmY+3BLQyVCZoBf__Bu6-CEJN=cVASvMRVHvYvrvA+MPrA@mail.gmail.com>
	<CANLz8R5A44TMgDG6UJR+YJF3e=k=N=UynmKXq=RvApv2+zeFyg@mail.gmail.com>
	<CAPDjdma9maaf0812S512LNEDsJWDYgqyD+pSBdSECBX4uuFdNg@mail.gmail.com>
	<CAKoWPPF-AF8xrmW6HFuE++EwsPruL-pYDNbt6vefP8LAw+5LBQ@mail.gmail.com>
	<CAPDjdmbf8Esqpw2-DUO7uAMvJQHjThB7KeuoZkumP9HQXe+Cng@mail.gmail.com>
	<CANLz8R7Oe1-ji8feisf8=KWMChR0LDjx+sf_B7dUyat3dOzWOQ@mail.gmail.com>
	<CAPDjdmZB-3Yjr1SBXi=jYs-Ew441WP+Kt1OuaF2PAk=Jocf9eA@mail.gmail.com>
Message-ID: <CAPDjdmafcGhzvfVN4383mz0cYYbmfEybe=hnOi2GrcHEQxF2ZA@mail.gmail.com>

Please review

https://github.com/haehn/CTK/tree/add-ErrorTextEnabledPropertyWorkflowGroupbox-feature

Thanks,
Daniel

On Wed, Aug 17, 2011 at 3:38 PM, Daniel Haehn <haehn at bwh.harvard.edu> wrote:
> Ok, will do so.
>
> Daniel
>
> On Wed, Aug 17, 2011 at 3:36 PM, Jean-Christophe Fillion-Robin
> <jchris.fillionr at kitware.com> wrote:
>> You could expose the getter returning workflowGroupBox.. then the property
>> ErrorTextDisabled will be accessible.
>>
>> Jc
>>
>> On Wed, Aug 17, 2011 at 3:32 PM, Daniel Haehn <haehn at bwh.harvard.edu> wrote:
>>>
>>> I don't think it is possible to access the groupbox if you created a
>>> ctkWorkflowWidget in Python. So would it make sense to expose this one
>>> as well?
>>>
>>> Daniel
>>>
>>> On Wed, Aug 17, 2011 at 3:26 PM, Julien Finet <julien.finet at kitware.com>
>>> wrote:
>>> > myWorkflowGroupBox.ErrorTextDisabled = True
>>> > no?
>>> > j.
>>> >
>>> > On Wed, Aug 17, 2011 at 3:15 PM, Daniel Haehn <haehn at bwh.harvard.edu>
>>> > wrote:
>>> >>
>>> >> Hi JC,
>>> >>
>>> >> thanks for the feedback.
>>> >>
>>> >> If we would add the property ErrorTextDisabled to the
>>> >> ctkWorkflowGroupBox, how can it be set from Python?
>>> >>
>>> >> Cheers,
>>> >> Daniel
>>> >>
>>> >> On Tue, Aug 16, 2011 at 3:39 PM, Jean-Christophe Fillion-Robin
>>> >> <jchris.fillionr at kitware.com> wrote:
>>> >> > Hi Daniel,
>>> >> >
>>> >> > Just looked at it.
>>> >> >
>>> >> > Please consider the following remarks:
>>> >> > ?- Regarding the git commit msg. See
>>> >> >
>>> >> > http://www.commontk.org/index.php/Contributing_to_CTK#Git_Commit_Style
>>> >> >
>>> >> > ?- Regarding the patch:
>>> >> > ???? - May be you could just add a property named ErrorTextDisabled
>>> >> > to
>>> >> > ctkWorkflowGroupBox ?
>>> >> > ??? - See line 110 of ctkWorkflowGroupBox.cpp
>>> >> >
>>> >> > Danielle> What do you think ?
>>> >> >
>>> >> > Thanks
>>> >> > Jc
>>> >> >
>>> >> > On Tue, Aug 16, 2011 at 12:35 PM, Daniel Haehn
>>> >> > <haehn at bwh.harvard.edu>
>>> >> > wrote:
>>> >> >>
>>> >> >> Hi,
>>> >> >>
>>> >> >> did anybody have a chance to look at it yet?
>>> >> >>
>>> >> >> Thanks,
>>> >> >> Daniel
>>> >> >>
>>> >> >> On Thu, Aug 11, 2011 at 1:15 PM, Daniel Haehn
>>> >> >> <haehn at bwh.harvard.edu>
>>> >> >> wrote:
>>> >> >> > Hi Devels,
>>> >> >> >
>>> >> >> > could anybody please review the following topic:
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > https://github.com/haehn/CTK/commits/add-ShowStatusTextUponGoToStepSuccess-workflow-feature
>>> >> >> >
>>> >> >> > I added a property to be able to disable the Status Text update on
>>> >> >> > the
>>> >> >> > origin step when a GoToStep(..)-call of a ctkWorkflow succeeds.
>>> >> >> >
>>> >> >> > Looking forward to your feedback..
>>> >> >> >
>>> >> >> > Daniel
>>> >> >> >
>>> >> >> _______________________________________________
>>> >> >> Ctk-developers mailing list
>>> >> >> Ctk-developers at commontk.org
>>> >> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > +1 919 869 8849
>>> >> >
>>> >> >
>>> >> _______________________________________________
>>> >> Ctk-developers mailing list
>>> >> Ctk-developers at commontk.org
>>> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>> >
>>> >
>>
>>
>>
>> --
>> +1 919 869 8849
>>
>>
>


From haehn at bwh.harvard.edu  Wed Aug 17 20:55:21 2011
From: haehn at bwh.harvard.edu (Daniel Haehn)
Date: Wed, 17 Aug 2011 16:55:21 -0400
Subject: [Ctk-developers] ctkMatrixWidget: setValue not invokable from
	Python
In-Reply-To: <CAKoWPPHisV_2WBuQRwmu=jJo5z0nmDJExDgjqhZJy9bNU6c6mg@mail.gmail.com>
References: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>
	<CAKoWPPEkcURxmR_xbqwtQHu8xMRugSLpnmeedYReXzTf-Cfk8Q@mail.gmail.com>
	<CAPDjdmZWXsHtE0PSdq2RtG0wC9U0Dcgn7Q1RedVMSrrWS6JGHg@mail.gmail.com>
	<CAKoWPPHdWoY9k1qMpc2J1gYtNY_kfgCoiP0puufa7ed64Ah52Q@mail.gmail.com>
	<CANLz8R4CrEYFb6hg-iiyeSs2eGJM=UYEFw+27nqB+5j-A2fL7g@mail.gmail.com>
	<CAPDjdmYkksDMMx052==YpsLA0kTzC0vY=zfepmmXYrHWQyzx2A@mail.gmail.com>
	<CAKoWPPHisV_2WBuQRwmu=jJo5z0nmDJExDgjqhZJy9bNU6c6mg@mail.gmail.com>
Message-ID: <CAPDjdmbD1Huvt9joqvKnF4+X48yCeiJvSU6g22osukdwbcG+2w@mail.gmail.com>

Thanks for the feedback,

I just commited
https://github.com/haehn/CTK/commit/583a229fce5d99f06b78bab1c3a38cfe4255a328

Would be great if we could encounter these changes to upstream and
then to Slicer CTK - the EMSegmenter needs it :)

Thx,
Daniel

On Wed, Aug 17, 2011 at 4:48 PM, Julien Finet <julien.finet at kitware.com> wrote:
> Looks good, except that when populating the values vector
> (ctkMatrixWidget::values()), I would call ctkMatrixWidget::value(i,j)
> instead of manually querying the data in order to factorize code.
> Thanks,
> Julien.
> p.s.I agree that setValues() would also beneficiate from some
> refactorization as well, but it's another story...
>
> On Wed, Aug 17, 2011 at 4:15 PM, Daniel Haehn <haehn at bwh.harvard.edu> wrote:
>>
>> Hi guys,
>>
>> could you please review
>>
>>
>> https://github.com/haehn/CTK/tree/add-SetValuesQPropertyMatrixWidget-feature
>>
>> Thx,
>> Daniel
>>
>> On Tue, Aug 16, 2011 at 3:57 PM, Jean-Christophe Fillion-Robin
>> <jchris.fillionr at kitware.com> wrote:
>> > +1 for setValues
>> > Jc
>> >
>> > On Tue, Aug 16, 2011 at 3:11 PM, Julien Finet <julien.finet at kitware.com>
>> > wrote:
>> >>
>> >> Because a "Q_PROPERTY adds features through the meta-object system".
>> >> Practically in this case, it allows the property to be wrapped with
>> >> python, and initial values can also be set directly via the Designer.
>> >> As a more?philosophical?point, the?matrix?"values" are a "property" of
>> >> the
>> >> matrix.
>> >> Julien.
>> >> On Tue, Aug 16, 2011 at 3:04 PM, Daniel Haehn <haehn at bwh.harvard.edu>
>> >> wrote:
>> >>>
>> >>> Hi Julien,
>> >>>
>> >>> why do you think a Q_PROPERTY is better? Anyway, I will give it a shot
>> >>> and let you know.
>> >>>
>> >>> Cheers,
>> >>> Daniel
>> >>>
>> >>> On Tue, Aug 16, 2011 at 1:48 PM, Julien Finet
>> >>> <julien.finet at kitware.com>
>> >>> wrote:
>> >>> > Either that or we make a?Q_PROPERTY named?"values":
>> >>> > Q_PROPERTY( QVector<double> values READ values WRITE setValues)
>> >>> > There is already: ctkMatrixWidget::setVector(QVector<double>), maybe
>> >>> > it
>> >>> > could be renamed into setValues and values() should then also be
>> >>> > written.
>> >>> > Julien.
>> >>> >
>> >>> > On Tue, Aug 16, 2011 at 12:37 PM, Daniel Haehn
>> >>> > <haehn at bwh.harvard.edu>
>> >>> > wrote:
>> >>> >>
>> >>> >> Hi guys,
>> >>> >>
>> >>> >> it seems that it is not possible to set a value of a
>> >>> >> ctkMatrixWidget
>> >>> >> from Python?
>> >>> >>
>> >>> >> Shall we just enable Q_INVOKABLE on the ctkMatrixWidget::setValue
>> >>> >> method?
>> >>> >>
>> >>> >> Thanks,
>> >>> >> Daniel
>> >>> >> _______________________________________________
>> >>> >> Ctk-developers mailing list
>> >>> >> Ctk-developers at commontk.org
>> >>> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>> >>> >
>> >>> >
>> >>
>> >>
>> >> _______________________________________________
>> >> Ctk-developers mailing list
>> >> Ctk-developers at commontk.org
>> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>> >>
>> >
>> >
>> >
>> > --
>> > +1 919 869 8849
>> >
>> >
>
>


From jchris.fillionr at kitware.com  Wed Aug 17 22:19:56 2011
From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin)
Date: Wed, 17 Aug 2011 18:19:56 -0400
Subject: [Ctk-developers] ctkMatrixWidget: setValue not invokable from
	Python
In-Reply-To: <CAPDjdmbD1Huvt9joqvKnF4+X48yCeiJvSU6g22osukdwbcG+2w@mail.gmail.com>
References: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>
	<CAKoWPPEkcURxmR_xbqwtQHu8xMRugSLpnmeedYReXzTf-Cfk8Q@mail.gmail.com>
	<CAPDjdmZWXsHtE0PSdq2RtG0wC9U0Dcgn7Q1RedVMSrrWS6JGHg@mail.gmail.com>
	<CAKoWPPHdWoY9k1qMpc2J1gYtNY_kfgCoiP0puufa7ed64Ah52Q@mail.gmail.com>
	<CANLz8R4CrEYFb6hg-iiyeSs2eGJM=UYEFw+27nqB+5j-A2fL7g@mail.gmail.com>
	<CAPDjdmYkksDMMx052==YpsLA0kTzC0vY=zfepmmXYrHWQyzx2A@mail.gmail.com>
	<CAKoWPPHisV_2WBuQRwmu=jJo5z0nmDJExDgjqhZJy9bNU6c6mg@mail.gmail.com>
	<CAPDjdmbD1Huvt9joqvKnF4+X48yCeiJvSU6g22osukdwbcG+2w@mail.gmail.com>
Message-ID: <CANLz8R6W1NKeJRB-2wKPfHyzYJq7PkkKXyixL=swNJ1krCoh4g@mail.gmail.com>

Note: When this topic will be integrated. Let's make sure all the commits
are squashed together.
Jc

On Wed, Aug 17, 2011 at 4:55 PM, Daniel Haehn <haehn at bwh.harvard.edu> wrote:

> Thanks for the feedback,
>
> I just commited
>
> https://github.com/haehn/CTK/commit/583a229fce5d99f06b78bab1c3a38cfe4255a328
>
> Would be great if we could encounter these changes to upstream and
> then to Slicer CTK - the EMSegmenter needs it :)
>
> Thx,
> Daniel
>
> On Wed, Aug 17, 2011 at 4:48 PM, Julien Finet <julien.finet at kitware.com>
> wrote:
> > Looks good, except that when populating the values vector
> > (ctkMatrixWidget::values()), I would call ctkMatrixWidget::value(i,j)
> > instead of manually querying the data in order to factorize code.
> > Thanks,
> > Julien.
> > p.s.I agree that setValues() would also beneficiate from some
> > refactorization as well, but it's another story...
> >
> > On Wed, Aug 17, 2011 at 4:15 PM, Daniel Haehn <haehn at bwh.harvard.edu>
> wrote:
> >>
> >> Hi guys,
> >>
> >> could you please review
> >>
> >>
> >>
> https://github.com/haehn/CTK/tree/add-SetValuesQPropertyMatrixWidget-feature
> >>
> >> Thx,
> >> Daniel
> >>
> >> On Tue, Aug 16, 2011 at 3:57 PM, Jean-Christophe Fillion-Robin
> >> <jchris.fillionr at kitware.com> wrote:
> >> > +1 for setValues
> >> > Jc
> >> >
> >> > On Tue, Aug 16, 2011 at 3:11 PM, Julien Finet <
> julien.finet at kitware.com>
> >> > wrote:
> >> >>
> >> >> Because a "Q_PROPERTY adds features through the meta-object system".
> >> >> Practically in this case, it allows the property to be wrapped with
> >> >> python, and initial values can also be set directly via the Designer.
> >> >> As a more philosophical point, the matrix "values" are a "property"
> of
> >> >> the
> >> >> matrix.
> >> >> Julien.
> >> >> On Tue, Aug 16, 2011 at 3:04 PM, Daniel Haehn <haehn at bwh.harvard.edu
> >
> >> >> wrote:
> >> >>>
> >> >>> Hi Julien,
> >> >>>
> >> >>> why do you think a Q_PROPERTY is better? Anyway, I will give it a
> shot
> >> >>> and let you know.
> >> >>>
> >> >>> Cheers,
> >> >>> Daniel
> >> >>>
> >> >>> On Tue, Aug 16, 2011 at 1:48 PM, Julien Finet
> >> >>> <julien.finet at kitware.com>
> >> >>> wrote:
> >> >>> > Either that or we make a Q_PROPERTY named "values":
> >> >>> > Q_PROPERTY( QVector<double> values READ values WRITE setValues)
> >> >>> > There is already: ctkMatrixWidget::setVector(QVector<double>),
> maybe
> >> >>> > it
> >> >>> > could be renamed into setValues and values() should then also be
> >> >>> > written.
> >> >>> > Julien.
> >> >>> >
> >> >>> > On Tue, Aug 16, 2011 at 12:37 PM, Daniel Haehn
> >> >>> > <haehn at bwh.harvard.edu>
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> Hi guys,
> >> >>> >>
> >> >>> >> it seems that it is not possible to set a value of a
> >> >>> >> ctkMatrixWidget
> >> >>> >> from Python?
> >> >>> >>
> >> >>> >> Shall we just enable Q_INVOKABLE on the ctkMatrixWidget::setValue
> >> >>> >> method?
> >> >>> >>
> >> >>> >> Thanks,
> >> >>> >> Daniel
> >> >>> >> _______________________________________________
> >> >>> >> Ctk-developers mailing list
> >> >>> >> Ctk-developers at commontk.org
> >> >>> >>
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >> >>> >
> >> >>> >
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> Ctk-developers mailing list
> >> >> Ctk-developers at commontk.org
> >> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > +1 919 869 8849
> >> >
> >> >
> >
> >
>



-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110817/811879d9/attachment.htm>

From julien.finet at kitware.com  Wed Aug 17 23:46:56 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Wed, 17 Aug 2011 19:46:56 -0400
Subject: [Ctk-developers] ShowStatusTextUponGoToStepSuccess workflow
 feature, please review
In-Reply-To: <CAPDjdmafcGhzvfVN4383mz0cYYbmfEybe=hnOi2GrcHEQxF2ZA@mail.gmail.com>
References: <CAPDjdmZwuN-RSfRNPz3ZOgwmDTTN-QUrY6X+0VfjDBHoVyOCnQ@mail.gmail.com>
	<CAPDjdmY+3BLQyVCZoBf__Bu6-CEJN=cVASvMRVHvYvrvA+MPrA@mail.gmail.com>
	<CANLz8R5A44TMgDG6UJR+YJF3e=k=N=UynmKXq=RvApv2+zeFyg@mail.gmail.com>
	<CAPDjdma9maaf0812S512LNEDsJWDYgqyD+pSBdSECBX4uuFdNg@mail.gmail.com>
	<CAKoWPPF-AF8xrmW6HFuE++EwsPruL-pYDNbt6vefP8LAw+5LBQ@mail.gmail.com>
	<CAPDjdmbf8Esqpw2-DUO7uAMvJQHjThB7KeuoZkumP9HQXe+Cng@mail.gmail.com>
	<CANLz8R7Oe1-ji8feisf8=KWMChR0LDjx+sf_B7dUyat3dOzWOQ@mail.gmail.com>
	<CAPDjdmZB-3Yjr1SBXi=jYs-Ew441WP+Kt1OuaF2PAk=Jocf9eA@mail.gmail.com>
	<CAPDjdmafcGhzvfVN4383mz0cYYbmfEybe=hnOi2GrcHEQxF2ZA@mail.gmail.com>
Message-ID: <CAKoWPPGe0J3cT7nX-3sY3zN2SQWLDYmjCRDu=8o4An_N4cvqOw@mail.gmail.com>

Added in CTK:
https://github.com/commontk/CTK/commit/b6314ac0521de183046ce101d630a43777c5c949

Added in Slicer: r17743
http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=17743

Thanks,
Julien.

On Wed, Aug 17, 2011 at 4:51 PM, Daniel Haehn <haehn at bwh.harvard.edu> wrote:

> Please review
>
>
> https://github.com/haehn/CTK/tree/add-ErrorTextEnabledPropertyWorkflowGroupbox-feature
>
> Thanks,
> Daniel
>
> On Wed, Aug 17, 2011 at 3:38 PM, Daniel Haehn <haehn at bwh.harvard.edu>
> wrote:
> > Ok, will do so.
> >
> > Daniel
> >
> > On Wed, Aug 17, 2011 at 3:36 PM, Jean-Christophe Fillion-Robin
> > <jchris.fillionr at kitware.com> wrote:
> >> You could expose the getter returning workflowGroupBox.. then the
> property
> >> ErrorTextDisabled will be accessible.
> >>
> >> Jc
> >>
> >> On Wed, Aug 17, 2011 at 3:32 PM, Daniel Haehn <haehn at bwh.harvard.edu>
> wrote:
> >>>
> >>> I don't think it is possible to access the groupbox if you created a
> >>> ctkWorkflowWidget in Python. So would it make sense to expose this one
> >>> as well?
> >>>
> >>> Daniel
> >>>
> >>> On Wed, Aug 17, 2011 at 3:26 PM, Julien Finet <
> julien.finet at kitware.com>
> >>> wrote:
> >>> > myWorkflowGroupBox.ErrorTextDisabled = True
> >>> > no?
> >>> > j.
> >>> >
> >>> > On Wed, Aug 17, 2011 at 3:15 PM, Daniel Haehn <haehn at bwh.harvard.edu
> >
> >>> > wrote:
> >>> >>
> >>> >> Hi JC,
> >>> >>
> >>> >> thanks for the feedback.
> >>> >>
> >>> >> If we would add the property ErrorTextDisabled to the
> >>> >> ctkWorkflowGroupBox, how can it be set from Python?
> >>> >>
> >>> >> Cheers,
> >>> >> Daniel
> >>> >>
> >>> >> On Tue, Aug 16, 2011 at 3:39 PM, Jean-Christophe Fillion-Robin
> >>> >> <jchris.fillionr at kitware.com> wrote:
> >>> >> > Hi Daniel,
> >>> >> >
> >>> >> > Just looked at it.
> >>> >> >
> >>> >> > Please consider the following remarks:
> >>> >> >  - Regarding the git commit msg. See
> >>> >> >
> >>> >> >
> http://www.commontk.org/index.php/Contributing_to_CTK#Git_Commit_Style
> >>> >> >
> >>> >> >  - Regarding the patch:
> >>> >> >      - May be you could just add a property named
> ErrorTextDisabled
> >>> >> > to
> >>> >> > ctkWorkflowGroupBox ?
> >>> >> >     - See line 110 of ctkWorkflowGroupBox.cpp
> >>> >> >
> >>> >> > Danielle> What do you think ?
> >>> >> >
> >>> >> > Thanks
> >>> >> > Jc
> >>> >> >
> >>> >> > On Tue, Aug 16, 2011 at 12:35 PM, Daniel Haehn
> >>> >> > <haehn at bwh.harvard.edu>
> >>> >> > wrote:
> >>> >> >>
> >>> >> >> Hi,
> >>> >> >>
> >>> >> >> did anybody have a chance to look at it yet?
> >>> >> >>
> >>> >> >> Thanks,
> >>> >> >> Daniel
> >>> >> >>
> >>> >> >> On Thu, Aug 11, 2011 at 1:15 PM, Daniel Haehn
> >>> >> >> <haehn at bwh.harvard.edu>
> >>> >> >> wrote:
> >>> >> >> > Hi Devels,
> >>> >> >> >
> >>> >> >> > could anybody please review the following topic:
> >>> >> >> >
> >>> >> >> >
> >>> >> >> >
> >>> >> >> >
> >>> >> >> >
> https://github.com/haehn/CTK/commits/add-ShowStatusTextUponGoToStepSuccess-workflow-feature
> >>> >> >> >
> >>> >> >> > I added a property to be able to disable the Status Text update
> on
> >>> >> >> > the
> >>> >> >> > origin step when a GoToStep(..)-call of a ctkWorkflow succeeds.
> >>> >> >> >
> >>> >> >> > Looking forward to your feedback..
> >>> >> >> >
> >>> >> >> > Daniel
> >>> >> >> >
> >>> >> >> _______________________________________________
> >>> >> >> Ctk-developers mailing list
> >>> >> >> Ctk-developers at commontk.org
> >>> >> >>
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > --
> >>> >> > +1 919 869 8849
> >>> >> >
> >>> >> >
> >>> >> _______________________________________________
> >>> >> Ctk-developers mailing list
> >>> >> Ctk-developers at commontk.org
> >>> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >>> >
> >>> >
> >>
> >>
> >>
> >> --
> >> +1 919 869 8849
> >>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110817/77d2c659/attachment.htm>

From julien.finet at kitware.com  Wed Aug 17 23:48:08 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Wed, 17 Aug 2011 19:48:08 -0400
Subject: [Ctk-developers] ctkMatrixWidget: setValue not invokable from
	Python
In-Reply-To: <CAPDjdmbD1Huvt9joqvKnF4+X48yCeiJvSU6g22osukdwbcG+2w@mail.gmail.com>
References: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>
	<CAKoWPPEkcURxmR_xbqwtQHu8xMRugSLpnmeedYReXzTf-Cfk8Q@mail.gmail.com>
	<CAPDjdmZWXsHtE0PSdq2RtG0wC9U0Dcgn7Q1RedVMSrrWS6JGHg@mail.gmail.com>
	<CAKoWPPHdWoY9k1qMpc2J1gYtNY_kfgCoiP0puufa7ed64Ah52Q@mail.gmail.com>
	<CANLz8R4CrEYFb6hg-iiyeSs2eGJM=UYEFw+27nqB+5j-A2fL7g@mail.gmail.com>
	<CAPDjdmYkksDMMx052==YpsLA0kTzC0vY=zfepmmXYrHWQyzx2A@mail.gmail.com>
	<CAKoWPPHisV_2WBuQRwmu=jJo5z0nmDJExDgjqhZJy9bNU6c6mg@mail.gmail.com>
	<CAPDjdmbD1Huvt9joqvKnF4+X48yCeiJvSU6g22osukdwbcG+2w@mail.gmail.com>
Message-ID: <CAKoWPPEovVckSGaAhghjnms6DMPqVJsU5WYVaNrO+2JCbac2cw@mail.gmail.com>

Added in CTK:
https://github.com/commontk/CTK/commit/5ebd60003b230f961bfb5d2c89c17f0ddcb4a151

Added in Slicer: r17743
http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=17743

Thanks,
Julien.

On Wed, Aug 17, 2011 at 4:55 PM, Daniel Haehn <haehn at bwh.harvard.edu> wrote:

> Thanks for the feedback,
>
> I just commited
>
> https://github.com/haehn/CTK/commit/583a229fce5d99f06b78bab1c3a38cfe4255a328
>
> Would be great if we could encounter these changes to upstream and
> then to Slicer CTK - the EMSegmenter needs it :)
>
> Thx,
> Daniel
>
> On Wed, Aug 17, 2011 at 4:48 PM, Julien Finet <julien.finet at kitware.com>
> wrote:
> > Looks good, except that when populating the values vector
> > (ctkMatrixWidget::values()), I would call ctkMatrixWidget::value(i,j)
> > instead of manually querying the data in order to factorize code.
> > Thanks,
> > Julien.
> > p.s.I agree that setValues() would also beneficiate from some
> > refactorization as well, but it's another story...
> >
> > On Wed, Aug 17, 2011 at 4:15 PM, Daniel Haehn <haehn at bwh.harvard.edu>
> wrote:
> >>
> >> Hi guys,
> >>
> >> could you please review
> >>
> >>
> >>
> https://github.com/haehn/CTK/tree/add-SetValuesQPropertyMatrixWidget-feature
> >>
> >> Thx,
> >> Daniel
> >>
> >> On Tue, Aug 16, 2011 at 3:57 PM, Jean-Christophe Fillion-Robin
> >> <jchris.fillionr at kitware.com> wrote:
> >> > +1 for setValues
> >> > Jc
> >> >
> >> > On Tue, Aug 16, 2011 at 3:11 PM, Julien Finet <
> julien.finet at kitware.com>
> >> > wrote:
> >> >>
> >> >> Because a "Q_PROPERTY adds features through the meta-object system".
> >> >> Practically in this case, it allows the property to be wrapped with
> >> >> python, and initial values can also be set directly via the Designer.
> >> >> As a more philosophical point, the matrix "values" are a "property"
> of
> >> >> the
> >> >> matrix.
> >> >> Julien.
> >> >> On Tue, Aug 16, 2011 at 3:04 PM, Daniel Haehn <haehn at bwh.harvard.edu
> >
> >> >> wrote:
> >> >>>
> >> >>> Hi Julien,
> >> >>>
> >> >>> why do you think a Q_PROPERTY is better? Anyway, I will give it a
> shot
> >> >>> and let you know.
> >> >>>
> >> >>> Cheers,
> >> >>> Daniel
> >> >>>
> >> >>> On Tue, Aug 16, 2011 at 1:48 PM, Julien Finet
> >> >>> <julien.finet at kitware.com>
> >> >>> wrote:
> >> >>> > Either that or we make a Q_PROPERTY named "values":
> >> >>> > Q_PROPERTY( QVector<double> values READ values WRITE setValues)
> >> >>> > There is already: ctkMatrixWidget::setVector(QVector<double>),
> maybe
> >> >>> > it
> >> >>> > could be renamed into setValues and values() should then also be
> >> >>> > written.
> >> >>> > Julien.
> >> >>> >
> >> >>> > On Tue, Aug 16, 2011 at 12:37 PM, Daniel Haehn
> >> >>> > <haehn at bwh.harvard.edu>
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> Hi guys,
> >> >>> >>
> >> >>> >> it seems that it is not possible to set a value of a
> >> >>> >> ctkMatrixWidget
> >> >>> >> from Python?
> >> >>> >>
> >> >>> >> Shall we just enable Q_INVOKABLE on the ctkMatrixWidget::setValue
> >> >>> >> method?
> >> >>> >>
> >> >>> >> Thanks,
> >> >>> >> Daniel
> >> >>> >> _______________________________________________
> >> >>> >> Ctk-developers mailing list
> >> >>> >> Ctk-developers at commontk.org
> >> >>> >>
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >> >>> >
> >> >>> >
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> Ctk-developers mailing list
> >> >> Ctk-developers at commontk.org
> >> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > +1 919 869 8849
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110817/984ebb51/attachment.htm>

From haehn at bwh.harvard.edu  Wed Aug 17 23:56:11 2011
From: haehn at bwh.harvard.edu (Daniel Haehn)
Date: Wed, 17 Aug 2011 19:56:11 -0400
Subject: [Ctk-developers] ctkMatrixWidget: setValue not invokable from
	Python
In-Reply-To: <CAKoWPPEovVckSGaAhghjnms6DMPqVJsU5WYVaNrO+2JCbac2cw@mail.gmail.com>
References: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>
	<CAKoWPPEkcURxmR_xbqwtQHu8xMRugSLpnmeedYReXzTf-Cfk8Q@mail.gmail.com>
	<CAPDjdmZWXsHtE0PSdq2RtG0wC9U0Dcgn7Q1RedVMSrrWS6JGHg@mail.gmail.com>
	<CAKoWPPHdWoY9k1qMpc2J1gYtNY_kfgCoiP0puufa7ed64Ah52Q@mail.gmail.com>
	<CANLz8R4CrEYFb6hg-iiyeSs2eGJM=UYEFw+27nqB+5j-A2fL7g@mail.gmail.com>
	<CAPDjdmYkksDMMx052==YpsLA0kTzC0vY=zfepmmXYrHWQyzx2A@mail.gmail.com>
	<CAKoWPPHisV_2WBuQRwmu=jJo5z0nmDJExDgjqhZJy9bNU6c6mg@mail.gmail.com>
	<CAPDjdmbD1Huvt9joqvKnF4+X48yCeiJvSU6g22osukdwbcG+2w@mail.gmail.com>
	<CAKoWPPEovVckSGaAhghjnms6DMPqVJsU5WYVaNrO+2JCbac2cw@mail.gmail.com>
Message-ID: <CAPDjdmZgEnu1iZQzbZ=GShqQxQJkhx99m+ciRctVomc5sKEbRQ@mail.gmail.com>

Great, thank you!

Daniel

On Wed, Aug 17, 2011 at 7:48 PM, Julien Finet <julien.finet at kitware.com> wrote:
> Added in CTK:
> https://github.com/commontk/CTK/commit/5ebd60003b230f961bfb5d2c89c17f0ddcb4a151
> Added in Slicer: r17743
> http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=17743
> Thanks,
> Julien.
>
> On Wed, Aug 17, 2011 at 4:55 PM, Daniel Haehn <haehn at bwh.harvard.edu> wrote:
>>
>> Thanks for the feedback,
>>
>> I just commited
>>
>> https://github.com/haehn/CTK/commit/583a229fce5d99f06b78bab1c3a38cfe4255a328
>>
>> Would be great if we could encounter these changes to upstream and
>> then to Slicer CTK - the EMSegmenter needs it :)
>>
>> Thx,
>> Daniel
>>
>> On Wed, Aug 17, 2011 at 4:48 PM, Julien Finet <julien.finet at kitware.com>
>> wrote:
>> > Looks good, except that when populating the values vector
>> > (ctkMatrixWidget::values()), I would call ctkMatrixWidget::value(i,j)
>> > instead of manually querying the data in order to factorize code.
>> > Thanks,
>> > Julien.
>> > p.s.I agree that setValues() would also beneficiate from some
>> > refactorization as well, but it's another story...
>> >
>> > On Wed, Aug 17, 2011 at 4:15 PM, Daniel Haehn <haehn at bwh.harvard.edu>
>> > wrote:
>> >>
>> >> Hi guys,
>> >>
>> >> could you please review
>> >>
>> >>
>> >>
>> >> https://github.com/haehn/CTK/tree/add-SetValuesQPropertyMatrixWidget-feature
>> >>
>> >> Thx,
>> >> Daniel
>> >>
>> >> On Tue, Aug 16, 2011 at 3:57 PM, Jean-Christophe Fillion-Robin
>> >> <jchris.fillionr at kitware.com> wrote:
>> >> > +1 for setValues
>> >> > Jc
>> >> >
>> >> > On Tue, Aug 16, 2011 at 3:11 PM, Julien Finet
>> >> > <julien.finet at kitware.com>
>> >> > wrote:
>> >> >>
>> >> >> Because a "Q_PROPERTY adds features through the meta-object system".
>> >> >> Practically in this case, it allows the property to be wrapped with
>> >> >> python, and initial values can also be set directly via the
>> >> >> Designer.
>> >> >> As a more?philosophical?point, the?matrix?"values" are a "property"
>> >> >> of
>> >> >> the
>> >> >> matrix.
>> >> >> Julien.
>> >> >> On Tue, Aug 16, 2011 at 3:04 PM, Daniel Haehn
>> >> >> <haehn at bwh.harvard.edu>
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi Julien,
>> >> >>>
>> >> >>> why do you think a Q_PROPERTY is better? Anyway, I will give it a
>> >> >>> shot
>> >> >>> and let you know.
>> >> >>>
>> >> >>> Cheers,
>> >> >>> Daniel
>> >> >>>
>> >> >>> On Tue, Aug 16, 2011 at 1:48 PM, Julien Finet
>> >> >>> <julien.finet at kitware.com>
>> >> >>> wrote:
>> >> >>> > Either that or we make a?Q_PROPERTY named?"values":
>> >> >>> > Q_PROPERTY( QVector<double> values READ values WRITE setValues)
>> >> >>> > There is already: ctkMatrixWidget::setVector(QVector<double>),
>> >> >>> > maybe
>> >> >>> > it
>> >> >>> > could be renamed into setValues and values() should then also be
>> >> >>> > written.
>> >> >>> > Julien.
>> >> >>> >
>> >> >>> > On Tue, Aug 16, 2011 at 12:37 PM, Daniel Haehn
>> >> >>> > <haehn at bwh.harvard.edu>
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> Hi guys,
>> >> >>> >>
>> >> >>> >> it seems that it is not possible to set a value of a
>> >> >>> >> ctkMatrixWidget
>> >> >>> >> from Python?
>> >> >>> >>
>> >> >>> >> Shall we just enable Q_INVOKABLE on the
>> >> >>> >> ctkMatrixWidget::setValue
>> >> >>> >> method?
>> >> >>> >>
>> >> >>> >> Thanks,
>> >> >>> >> Daniel
>> >> >>> >> _______________________________________________
>> >> >>> >> Ctk-developers mailing list
>> >> >>> >> Ctk-developers at commontk.org
>> >> >>> >>
>> >> >>> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>> >> >>> >
>> >> >>> >
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> Ctk-developers mailing list
>> >> >> Ctk-developers at commontk.org
>> >> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > +1 919 869 8849
>> >> >
>> >> >
>> >
>> >
>
>


From haehn at bwh.harvard.edu  Fri Aug 19 15:55:34 2011
From: haehn at bwh.harvard.edu (Daniel Haehn)
Date: Fri, 19 Aug 2011 11:55:34 -0400
Subject: [Ctk-developers] ctkMatrixWidget: setValue not invokable from
	Python
In-Reply-To: <CAPDjdmZgEnu1iZQzbZ=GShqQxQJkhx99m+ciRctVomc5sKEbRQ@mail.gmail.com>
References: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>
	<CAKoWPPEkcURxmR_xbqwtQHu8xMRugSLpnmeedYReXzTf-Cfk8Q@mail.gmail.com>
	<CAPDjdmZWXsHtE0PSdq2RtG0wC9U0Dcgn7Q1RedVMSrrWS6JGHg@mail.gmail.com>
	<CAKoWPPHdWoY9k1qMpc2J1gYtNY_kfgCoiP0puufa7ed64Ah52Q@mail.gmail.com>
	<CANLz8R4CrEYFb6hg-iiyeSs2eGJM=UYEFw+27nqB+5j-A2fL7g@mail.gmail.com>
	<CAPDjdmYkksDMMx052==YpsLA0kTzC0vY=zfepmmXYrHWQyzx2A@mail.gmail.com>
	<CAKoWPPHisV_2WBuQRwmu=jJo5z0nmDJExDgjqhZJy9bNU6c6mg@mail.gmail.com>
	<CAPDjdmbD1Huvt9joqvKnF4+X48yCeiJvSU6g22osukdwbcG+2w@mail.gmail.com>
	<CAKoWPPEovVckSGaAhghjnms6DMPqVJsU5WYVaNrO+2JCbac2cw@mail.gmail.com>
	<CAPDjdmZgEnu1iZQzbZ=GShqQxQJkhx99m+ciRctVomc5sKEbRQ@mail.gmail.com>
Message-ID: <CAPDjdmaSrj8B3_mpN0sWtVNSPVw1EE-JgL-m39g87-wXQP-VmQ@mail.gmail.com>

Hi again,

so it seems that PythonQt has problems to wrap a QVector<double>. The
setValues method is not accesible from python and the values() method
returns:

  QVector<double> (C++ Object 0x14c479690)

rather than a python list. Maybe PythonQt only supports QVector<double*> ?

Maybe it makes more sense to return a QVariantList which maps to
python tuples in PythonQt?

What do you guys think?

Thanks,
Daniel

On Wed, Aug 17, 2011 at 7:56 PM, Daniel Haehn <haehn at bwh.harvard.edu> wrote:
> Great, thank you!
>
> Daniel
>
> On Wed, Aug 17, 2011 at 7:48 PM, Julien Finet <julien.finet at kitware.com> wrote:
>> Added in CTK:
>> https://github.com/commontk/CTK/commit/5ebd60003b230f961bfb5d2c89c17f0ddcb4a151
>> Added in Slicer: r17743
>> http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=17743
>> Thanks,
>> Julien.
>>
>> On Wed, Aug 17, 2011 at 4:55 PM, Daniel Haehn <haehn at bwh.harvard.edu> wrote:
>>>
>>> Thanks for the feedback,
>>>
>>> I just commited
>>>
>>> https://github.com/haehn/CTK/commit/583a229fce5d99f06b78bab1c3a38cfe4255a328
>>>
>>> Would be great if we could encounter these changes to upstream and
>>> then to Slicer CTK - the EMSegmenter needs it :)
>>>
>>> Thx,
>>> Daniel
>>>
>>> On Wed, Aug 17, 2011 at 4:48 PM, Julien Finet <julien.finet at kitware.com>
>>> wrote:
>>> > Looks good, except that when populating the values vector
>>> > (ctkMatrixWidget::values()), I would call ctkMatrixWidget::value(i,j)
>>> > instead of manually querying the data in order to factorize code.
>>> > Thanks,
>>> > Julien.
>>> > p.s.I agree that setValues() would also beneficiate from some
>>> > refactorization as well, but it's another story...
>>> >
>>> > On Wed, Aug 17, 2011 at 4:15 PM, Daniel Haehn <haehn at bwh.harvard.edu>
>>> > wrote:
>>> >>
>>> >> Hi guys,
>>> >>
>>> >> could you please review
>>> >>
>>> >>
>>> >>
>>> >> https://github.com/haehn/CTK/tree/add-SetValuesQPropertyMatrixWidget-feature
>>> >>
>>> >> Thx,
>>> >> Daniel
>>> >>
>>> >> On Tue, Aug 16, 2011 at 3:57 PM, Jean-Christophe Fillion-Robin
>>> >> <jchris.fillionr at kitware.com> wrote:
>>> >> > +1 for setValues
>>> >> > Jc
>>> >> >
>>> >> > On Tue, Aug 16, 2011 at 3:11 PM, Julien Finet
>>> >> > <julien.finet at kitware.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> Because a "Q_PROPERTY adds features through the meta-object system".
>>> >> >> Practically in this case, it allows the property to be wrapped with
>>> >> >> python, and initial values can also be set directly via the
>>> >> >> Designer.
>>> >> >> As a more?philosophical?point, the?matrix?"values" are a "property"
>>> >> >> of
>>> >> >> the
>>> >> >> matrix.
>>> >> >> Julien.
>>> >> >> On Tue, Aug 16, 2011 at 3:04 PM, Daniel Haehn
>>> >> >> <haehn at bwh.harvard.edu>
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> Hi Julien,
>>> >> >>>
>>> >> >>> why do you think a Q_PROPERTY is better? Anyway, I will give it a
>>> >> >>> shot
>>> >> >>> and let you know.
>>> >> >>>
>>> >> >>> Cheers,
>>> >> >>> Daniel
>>> >> >>>
>>> >> >>> On Tue, Aug 16, 2011 at 1:48 PM, Julien Finet
>>> >> >>> <julien.finet at kitware.com>
>>> >> >>> wrote:
>>> >> >>> > Either that or we make a?Q_PROPERTY named?"values":
>>> >> >>> > Q_PROPERTY( QVector<double> values READ values WRITE setValues)
>>> >> >>> > There is already: ctkMatrixWidget::setVector(QVector<double>),
>>> >> >>> > maybe
>>> >> >>> > it
>>> >> >>> > could be renamed into setValues and values() should then also be
>>> >> >>> > written.
>>> >> >>> > Julien.
>>> >> >>> >
>>> >> >>> > On Tue, Aug 16, 2011 at 12:37 PM, Daniel Haehn
>>> >> >>> > <haehn at bwh.harvard.edu>
>>> >> >>> > wrote:
>>> >> >>> >>
>>> >> >>> >> Hi guys,
>>> >> >>> >>
>>> >> >>> >> it seems that it is not possible to set a value of a
>>> >> >>> >> ctkMatrixWidget
>>> >> >>> >> from Python?
>>> >> >>> >>
>>> >> >>> >> Shall we just enable Q_INVOKABLE on the
>>> >> >>> >> ctkMatrixWidget::setValue
>>> >> >>> >> method?
>>> >> >>> >>
>>> >> >>> >> Thanks,
>>> >> >>> >> Daniel
>>> >> >>> >> _______________________________________________
>>> >> >>> >> Ctk-developers mailing list
>>> >> >>> >> Ctk-developers at commontk.org
>>> >> >>> >>
>>> >> >>> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>> >> >>> >
>>> >> >>> >
>>> >> >>
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> Ctk-developers mailing list
>>> >> >> Ctk-developers at commontk.org
>>> >> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > +1 919 869 8849
>>> >> >
>>> >> >
>>> >
>>> >
>>
>>
>


From julien.finet at kitware.com  Fri Aug 19 16:03:42 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Fri, 19 Aug 2011 12:03:42 -0400
Subject: [Ctk-developers] ctkMatrixWidget: setValue not invokable from
	Python
In-Reply-To: <CAPDjdmaSrj8B3_mpN0sWtVNSPVw1EE-JgL-m39g87-wXQP-VmQ@mail.gmail.com>
References: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>
	<CAKoWPPEkcURxmR_xbqwtQHu8xMRugSLpnmeedYReXzTf-Cfk8Q@mail.gmail.com>
	<CAPDjdmZWXsHtE0PSdq2RtG0wC9U0Dcgn7Q1RedVMSrrWS6JGHg@mail.gmail.com>
	<CAKoWPPHdWoY9k1qMpc2J1gYtNY_kfgCoiP0puufa7ed64Ah52Q@mail.gmail.com>
	<CANLz8R4CrEYFb6hg-iiyeSs2eGJM=UYEFw+27nqB+5j-A2fL7g@mail.gmail.com>
	<CAPDjdmYkksDMMx052==YpsLA0kTzC0vY=zfepmmXYrHWQyzx2A@mail.gmail.com>
	<CAKoWPPHisV_2WBuQRwmu=jJo5z0nmDJExDgjqhZJy9bNU6c6mg@mail.gmail.com>
	<CAPDjdmbD1Huvt9joqvKnF4+X48yCeiJvSU6g22osukdwbcG+2w@mail.gmail.com>
	<CAKoWPPEovVckSGaAhghjnms6DMPqVJsU5WYVaNrO+2JCbac2cw@mail.gmail.com>
	<CAPDjdmZgEnu1iZQzbZ=GShqQxQJkhx99m+ciRctVomc5sKEbRQ@mail.gmail.com>
	<CAPDjdmaSrj8B3_mpN0sWtVNSPVw1EE-JgL-m39g87-wXQP-VmQ@mail.gmail.com>
Message-ID: <CAKoWPPGbibowoOce-gwyQgi0ego6ykL68meEWqo569FiLXv_zw@mail.gmail.com>

Maybe QVector<double> needs to be entered in the meta object system.

Can you try adding
qRegisterMetaType<QVector<double> > ("QVector<double>");

in the constructor function of ctkMatrixWidget (better: init() of
ctkMatrixWidgetPrivate if it exists)

j.

On Fri, Aug 19, 2011 at 11:55 AM, Daniel Haehn <haehn at bwh.harvard.edu>wrote:

> Hi again,
>
> so it seems that PythonQt has problems to wrap a QVector<double>. The
> setValues method is not accesible from python and the values() method
> returns:
>
>  QVector<double> (C++ Object 0x14c479690)
>
> rather than a python list. Maybe PythonQt only supports QVector<double*> ?
>
> Maybe it makes more sense to return a QVariantList which maps to
> python tuples in PythonQt?
>
> What do you guys think?
>
> Thanks,
> Daniel
>
> On Wed, Aug 17, 2011 at 7:56 PM, Daniel Haehn <haehn at bwh.harvard.edu>
> wrote:
> > Great, thank you!
> >
> > Daniel
> >
> > On Wed, Aug 17, 2011 at 7:48 PM, Julien Finet <julien.finet at kitware.com>
> wrote:
> >> Added in CTK:
> >>
> https://github.com/commontk/CTK/commit/5ebd60003b230f961bfb5d2c89c17f0ddcb4a151
> >> Added in Slicer: r17743
> >>
> http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=17743
> >> Thanks,
> >> Julien.
> >>
> >> On Wed, Aug 17, 2011 at 4:55 PM, Daniel Haehn <haehn at bwh.harvard.edu>
> wrote:
> >>>
> >>> Thanks for the feedback,
> >>>
> >>> I just commited
> >>>
> >>>
> https://github.com/haehn/CTK/commit/583a229fce5d99f06b78bab1c3a38cfe4255a328
> >>>
> >>> Would be great if we could encounter these changes to upstream and
> >>> then to Slicer CTK - the EMSegmenter needs it :)
> >>>
> >>> Thx,
> >>> Daniel
> >>>
> >>> On Wed, Aug 17, 2011 at 4:48 PM, Julien Finet <
> julien.finet at kitware.com>
> >>> wrote:
> >>> > Looks good, except that when populating the values vector
> >>> > (ctkMatrixWidget::values()), I would call ctkMatrixWidget::value(i,j)
> >>> > instead of manually querying the data in order to factorize code.
> >>> > Thanks,
> >>> > Julien.
> >>> > p.s.I agree that setValues() would also beneficiate from some
> >>> > refactorization as well, but it's another story...
> >>> >
> >>> > On Wed, Aug 17, 2011 at 4:15 PM, Daniel Haehn <haehn at bwh.harvard.edu
> >
> >>> > wrote:
> >>> >>
> >>> >> Hi guys,
> >>> >>
> >>> >> could you please review
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> https://github.com/haehn/CTK/tree/add-SetValuesQPropertyMatrixWidget-feature
> >>> >>
> >>> >> Thx,
> >>> >> Daniel
> >>> >>
> >>> >> On Tue, Aug 16, 2011 at 3:57 PM, Jean-Christophe Fillion-Robin
> >>> >> <jchris.fillionr at kitware.com> wrote:
> >>> >> > +1 for setValues
> >>> >> > Jc
> >>> >> >
> >>> >> > On Tue, Aug 16, 2011 at 3:11 PM, Julien Finet
> >>> >> > <julien.finet at kitware.com>
> >>> >> > wrote:
> >>> >> >>
> >>> >> >> Because a "Q_PROPERTY adds features through the meta-object
> system".
> >>> >> >> Practically in this case, it allows the property to be wrapped
> with
> >>> >> >> python, and initial values can also be set directly via the
> >>> >> >> Designer.
> >>> >> >> As a more philosophical point, the matrix "values" are a
> "property"
> >>> >> >> of
> >>> >> >> the
> >>> >> >> matrix.
> >>> >> >> Julien.
> >>> >> >> On Tue, Aug 16, 2011 at 3:04 PM, Daniel Haehn
> >>> >> >> <haehn at bwh.harvard.edu>
> >>> >> >> wrote:
> >>> >> >>>
> >>> >> >>> Hi Julien,
> >>> >> >>>
> >>> >> >>> why do you think a Q_PROPERTY is better? Anyway, I will give it
> a
> >>> >> >>> shot
> >>> >> >>> and let you know.
> >>> >> >>>
> >>> >> >>> Cheers,
> >>> >> >>> Daniel
> >>> >> >>>
> >>> >> >>> On Tue, Aug 16, 2011 at 1:48 PM, Julien Finet
> >>> >> >>> <julien.finet at kitware.com>
> >>> >> >>> wrote:
> >>> >> >>> > Either that or we make a Q_PROPERTY named "values":
> >>> >> >>> > Q_PROPERTY( QVector<double> values READ values WRITE
> setValues)
> >>> >> >>> > There is already: ctkMatrixWidget::setVector(QVector<double>),
> >>> >> >>> > maybe
> >>> >> >>> > it
> >>> >> >>> > could be renamed into setValues and values() should then also
> be
> >>> >> >>> > written.
> >>> >> >>> > Julien.
> >>> >> >>> >
> >>> >> >>> > On Tue, Aug 16, 2011 at 12:37 PM, Daniel Haehn
> >>> >> >>> > <haehn at bwh.harvard.edu>
> >>> >> >>> > wrote:
> >>> >> >>> >>
> >>> >> >>> >> Hi guys,
> >>> >> >>> >>
> >>> >> >>> >> it seems that it is not possible to set a value of a
> >>> >> >>> >> ctkMatrixWidget
> >>> >> >>> >> from Python?
> >>> >> >>> >>
> >>> >> >>> >> Shall we just enable Q_INVOKABLE on the
> >>> >> >>> >> ctkMatrixWidget::setValue
> >>> >> >>> >> method?
> >>> >> >>> >>
> >>> >> >>> >> Thanks,
> >>> >> >>> >> Daniel
> >>> >> >>> >> _______________________________________________
> >>> >> >>> >> Ctk-developers mailing list
> >>> >> >>> >> Ctk-developers at commontk.org
> >>> >> >>> >>
> >>> >> >>> >>
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >>> >> >>> >
> >>> >> >>> >
> >>> >> >>
> >>> >> >>
> >>> >> >> _______________________________________________
> >>> >> >> Ctk-developers mailing list
> >>> >> >> Ctk-developers at commontk.org
> >>> >> >>
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >>> >> >>
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > --
> >>> >> > +1 919 869 8849
> >>> >> >
> >>> >> >
> >>> >
> >>> >
> >>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110819/ff01892b/attachment.htm>

From haehn at bwh.harvard.edu  Fri Aug 19 16:14:53 2011
From: haehn at bwh.harvard.edu (Daniel Haehn)
Date: Fri, 19 Aug 2011 12:14:53 -0400
Subject: [Ctk-developers] ctkMatrixWidget: setValue not invokable from
	Python
In-Reply-To: <CAKoWPPGbibowoOce-gwyQgi0ego6ykL68meEWqo569FiLXv_zw@mail.gmail.com>
References: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>
	<CAKoWPPEkcURxmR_xbqwtQHu8xMRugSLpnmeedYReXzTf-Cfk8Q@mail.gmail.com>
	<CAPDjdmZWXsHtE0PSdq2RtG0wC9U0Dcgn7Q1RedVMSrrWS6JGHg@mail.gmail.com>
	<CAKoWPPHdWoY9k1qMpc2J1gYtNY_kfgCoiP0puufa7ed64Ah52Q@mail.gmail.com>
	<CANLz8R4CrEYFb6hg-iiyeSs2eGJM=UYEFw+27nqB+5j-A2fL7g@mail.gmail.com>
	<CAPDjdmYkksDMMx052==YpsLA0kTzC0vY=zfepmmXYrHWQyzx2A@mail.gmail.com>
	<CAKoWPPHisV_2WBuQRwmu=jJo5z0nmDJExDgjqhZJy9bNU6c6mg@mail.gmail.com>
	<CAPDjdmbD1Huvt9joqvKnF4+X48yCeiJvSU6g22osukdwbcG+2w@mail.gmail.com>
	<CAKoWPPEovVckSGaAhghjnms6DMPqVJsU5WYVaNrO+2JCbac2cw@mail.gmail.com>
	<CAPDjdmZgEnu1iZQzbZ=GShqQxQJkhx99m+ciRctVomc5sKEbRQ@mail.gmail.com>
	<CAPDjdmaSrj8B3_mpN0sWtVNSPVw1EE-JgL-m39g87-wXQP-VmQ@mail.gmail.com>
	<CAKoWPPGbibowoOce-gwyQgi0ego6ykL68meEWqo569FiLXv_zw@mail.gmail.com>
Message-ID: <CAPDjdmZmBRfkOGhbn7CKMy9GVKR6aFSHgjnYzHZBQFOzqvt3nQ@mail.gmail.com>

Hi Julien,

I tried it but it did not change anything.. :/

Daniel

On Fri, Aug 19, 2011 at 12:03 PM, Julien Finet <julien.finet at kitware.com> wrote:
> Maybe?QVector<double> needs to be entered in the meta object system.
> Can you try adding
>
> qRegisterMetaType<QVector<double> > ("QVector<double>");
>
> in the constructor function of ctkMatrixWidget (better: init() of
> ctkMatrixWidgetPrivate if it exists)
> j.
> On Fri, Aug 19, 2011 at 11:55 AM, Daniel Haehn <haehn at bwh.harvard.edu>
> wrote:
>>
>> Hi again,
>>
>> so it seems that PythonQt has problems to wrap a QVector<double>. The
>> setValues method is not accesible from python and the values() method
>> returns:
>>
>> ?QVector<double> (C++ Object 0x14c479690)
>>
>> rather than a python list. Maybe PythonQt only supports QVector<double*> ?
>>
>> Maybe it makes more sense to return a QVariantList which maps to
>> python tuples in PythonQt?
>>
>> What do you guys think?
>>
>> Thanks,
>> Daniel
>>
>> On Wed, Aug 17, 2011 at 7:56 PM, Daniel Haehn <haehn at bwh.harvard.edu>
>> wrote:
>> > Great, thank you!
>> >
>> > Daniel
>> >
>> > On Wed, Aug 17, 2011 at 7:48 PM, Julien Finet <julien.finet at kitware.com>
>> > wrote:
>> >> Added in CTK:
>> >>
>> >> https://github.com/commontk/CTK/commit/5ebd60003b230f961bfb5d2c89c17f0ddcb4a151
>> >> Added in Slicer: r17743
>> >>
>> >> http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=17743
>> >> Thanks,
>> >> Julien.
>> >>
>> >> On Wed, Aug 17, 2011 at 4:55 PM, Daniel Haehn <haehn at bwh.harvard.edu>
>> >> wrote:
>> >>>
>> >>> Thanks for the feedback,
>> >>>
>> >>> I just commited
>> >>>
>> >>>
>> >>> https://github.com/haehn/CTK/commit/583a229fce5d99f06b78bab1c3a38cfe4255a328
>> >>>
>> >>> Would be great if we could encounter these changes to upstream and
>> >>> then to Slicer CTK - the EMSegmenter needs it :)
>> >>>
>> >>> Thx,
>> >>> Daniel
>> >>>
>> >>> On Wed, Aug 17, 2011 at 4:48 PM, Julien Finet
>> >>> <julien.finet at kitware.com>
>> >>> wrote:
>> >>> > Looks good, except that when populating the values vector
>> >>> > (ctkMatrixWidget::values()), I would call
>> >>> > ctkMatrixWidget::value(i,j)
>> >>> > instead of manually querying the data in order to factorize code.
>> >>> > Thanks,
>> >>> > Julien.
>> >>> > p.s.I agree that setValues() would also beneficiate from some
>> >>> > refactorization as well, but it's another story...
>> >>> >
>> >>> > On Wed, Aug 17, 2011 at 4:15 PM, Daniel Haehn
>> >>> > <haehn at bwh.harvard.edu>
>> >>> > wrote:
>> >>> >>
>> >>> >> Hi guys,
>> >>> >>
>> >>> >> could you please review
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> https://github.com/haehn/CTK/tree/add-SetValuesQPropertyMatrixWidget-feature
>> >>> >>
>> >>> >> Thx,
>> >>> >> Daniel
>> >>> >>
>> >>> >> On Tue, Aug 16, 2011 at 3:57 PM, Jean-Christophe Fillion-Robin
>> >>> >> <jchris.fillionr at kitware.com> wrote:
>> >>> >> > +1 for setValues
>> >>> >> > Jc
>> >>> >> >
>> >>> >> > On Tue, Aug 16, 2011 at 3:11 PM, Julien Finet
>> >>> >> > <julien.finet at kitware.com>
>> >>> >> > wrote:
>> >>> >> >>
>> >>> >> >> Because a "Q_PROPERTY adds features through the meta-object
>> >>> >> >> system".
>> >>> >> >> Practically in this case, it allows the property to be wrapped
>> >>> >> >> with
>> >>> >> >> python, and initial values can also be set directly via the
>> >>> >> >> Designer.
>> >>> >> >> As a more?philosophical?point, the?matrix?"values" are a
>> >>> >> >> "property"
>> >>> >> >> of
>> >>> >> >> the
>> >>> >> >> matrix.
>> >>> >> >> Julien.
>> >>> >> >> On Tue, Aug 16, 2011 at 3:04 PM, Daniel Haehn
>> >>> >> >> <haehn at bwh.harvard.edu>
>> >>> >> >> wrote:
>> >>> >> >>>
>> >>> >> >>> Hi Julien,
>> >>> >> >>>
>> >>> >> >>> why do you think a Q_PROPERTY is better? Anyway, I will give it
>> >>> >> >>> a
>> >>> >> >>> shot
>> >>> >> >>> and let you know.
>> >>> >> >>>
>> >>> >> >>> Cheers,
>> >>> >> >>> Daniel
>> >>> >> >>>
>> >>> >> >>> On Tue, Aug 16, 2011 at 1:48 PM, Julien Finet
>> >>> >> >>> <julien.finet at kitware.com>
>> >>> >> >>> wrote:
>> >>> >> >>> > Either that or we make a?Q_PROPERTY named?"values":
>> >>> >> >>> > Q_PROPERTY( QVector<double> values READ values WRITE
>> >>> >> >>> > setValues)
>> >>> >> >>> > There is already:
>> >>> >> >>> > ctkMatrixWidget::setVector(QVector<double>),
>> >>> >> >>> > maybe
>> >>> >> >>> > it
>> >>> >> >>> > could be renamed into setValues and values() should then also
>> >>> >> >>> > be
>> >>> >> >>> > written.
>> >>> >> >>> > Julien.
>> >>> >> >>> >
>> >>> >> >>> > On Tue, Aug 16, 2011 at 12:37 PM, Daniel Haehn
>> >>> >> >>> > <haehn at bwh.harvard.edu>
>> >>> >> >>> > wrote:
>> >>> >> >>> >>
>> >>> >> >>> >> Hi guys,
>> >>> >> >>> >>
>> >>> >> >>> >> it seems that it is not possible to set a value of a
>> >>> >> >>> >> ctkMatrixWidget
>> >>> >> >>> >> from Python?
>> >>> >> >>> >>
>> >>> >> >>> >> Shall we just enable Q_INVOKABLE on the
>> >>> >> >>> >> ctkMatrixWidget::setValue
>> >>> >> >>> >> method?
>> >>> >> >>> >>
>> >>> >> >>> >> Thanks,
>> >>> >> >>> >> Daniel
>> >>> >> >>> >> _______________________________________________
>> >>> >> >>> >> Ctk-developers mailing list
>> >>> >> >>> >> Ctk-developers at commontk.org
>> >>> >> >>> >>
>> >>> >> >>> >>
>> >>> >> >>> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>> >>> >> >>> >
>> >>> >> >>> >
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> _______________________________________________
>> >>> >> >> Ctk-developers mailing list
>> >>> >> >> Ctk-developers at commontk.org
>> >>> >> >>
>> >>> >> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>> >>> >> >>
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> > --
>> >>> >> > +1 919 869 8849
>> >>> >> >
>> >>> >> >
>> >>> >
>> >>> >
>> >>
>> >>
>> >
>
>


From julien.finet at kitware.com  Fri Aug 19 16:22:16 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Fri, 19 Aug 2011 12:22:16 -0400
Subject: [Ctk-developers] ctkMatrixWidget: setValue not invokable from
	Python
In-Reply-To: <CAPDjdmZmBRfkOGhbn7CKMy9GVKR6aFSHgjnYzHZBQFOzqvt3nQ@mail.gmail.com>
References: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>
	<CAKoWPPEkcURxmR_xbqwtQHu8xMRugSLpnmeedYReXzTf-Cfk8Q@mail.gmail.com>
	<CAPDjdmZWXsHtE0PSdq2RtG0wC9U0Dcgn7Q1RedVMSrrWS6JGHg@mail.gmail.com>
	<CAKoWPPHdWoY9k1qMpc2J1gYtNY_kfgCoiP0puufa7ed64Ah52Q@mail.gmail.com>
	<CANLz8R4CrEYFb6hg-iiyeSs2eGJM=UYEFw+27nqB+5j-A2fL7g@mail.gmail.com>
	<CAPDjdmYkksDMMx052==YpsLA0kTzC0vY=zfepmmXYrHWQyzx2A@mail.gmail.com>
	<CAKoWPPHisV_2WBuQRwmu=jJo5z0nmDJExDgjqhZJy9bNU6c6mg@mail.gmail.com>
	<CAPDjdmbD1Huvt9joqvKnF4+X48yCeiJvSU6g22osukdwbcG+2w@mail.gmail.com>
	<CAKoWPPEovVckSGaAhghjnms6DMPqVJsU5WYVaNrO+2JCbac2cw@mail.gmail.com>
	<CAPDjdmZgEnu1iZQzbZ=GShqQxQJkhx99m+ciRctVomc5sKEbRQ@mail.gmail.com>
	<CAPDjdmaSrj8B3_mpN0sWtVNSPVw1EE-JgL-m39g87-wXQP-VmQ@mail.gmail.com>
	<CAKoWPPGbibowoOce-gwyQgi0ego6ykL68meEWqo569FiLXv_zw@mail.gmail.com>
	<CAPDjdmZmBRfkOGhbn7CKMy9GVKR6aFSHgjnYzHZBQFOzqvt3nQ@mail.gmail.com>
Message-ID: <CAKoWPPHWKJa0Y1EXRZRHSRn8FYHoes4Y4Yun6eUUA8RhXsR3KA@mail.gmail.com>

I'm a bit reluctant to make ctkMatrixWidget's code less readable just to
please scripting.

>From http://pythonqt.sourceforge.net/Features.html: it seems that we need to
add our own "handlers" (whatever it means).
I'm not sure what it implies though.
Julien.

On Fri, Aug 19, 2011 at 12:14 PM, Daniel Haehn <haehn at bwh.harvard.edu>wrote:

> Hi Julien,
>
> I tried it but it did not change anything.. :/
>
> Daniel
>
> On Fri, Aug 19, 2011 at 12:03 PM, Julien Finet <julien.finet at kitware.com>
> wrote:
> > Maybe QVector<double> needs to be entered in the meta object system.
> > Can you try adding
> >
> > qRegisterMetaType<QVector<double> > ("QVector<double>");
> >
> > in the constructor function of ctkMatrixWidget (better: init() of
> > ctkMatrixWidgetPrivate if it exists)
> > j.
> > On Fri, Aug 19, 2011 at 11:55 AM, Daniel Haehn <haehn at bwh.harvard.edu>
> > wrote:
> >>
> >> Hi again,
> >>
> >> so it seems that PythonQt has problems to wrap a QVector<double>. The
> >> setValues method is not accesible from python and the values() method
> >> returns:
> >>
> >>  QVector<double> (C++ Object 0x14c479690)
> >>
> >> rather than a python list. Maybe PythonQt only supports QVector<double*>
> ?
> >>
> >> Maybe it makes more sense to return a QVariantList which maps to
> >> python tuples in PythonQt?
> >>
> >> What do you guys think?
> >>
> >> Thanks,
> >> Daniel
> >>
> >> On Wed, Aug 17, 2011 at 7:56 PM, Daniel Haehn <haehn at bwh.harvard.edu>
> >> wrote:
> >> > Great, thank you!
> >> >
> >> > Daniel
> >> >
> >> > On Wed, Aug 17, 2011 at 7:48 PM, Julien Finet <
> julien.finet at kitware.com>
> >> > wrote:
> >> >> Added in CTK:
> >> >>
> >> >>
> https://github.com/commontk/CTK/commit/5ebd60003b230f961bfb5d2c89c17f0ddcb4a151
> >> >> Added in Slicer: r17743
> >> >>
> >> >>
> http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=17743
> >> >> Thanks,
> >> >> Julien.
> >> >>
> >> >> On Wed, Aug 17, 2011 at 4:55 PM, Daniel Haehn <haehn at bwh.harvard.edu
> >
> >> >> wrote:
> >> >>>
> >> >>> Thanks for the feedback,
> >> >>>
> >> >>> I just commited
> >> >>>
> >> >>>
> >> >>>
> https://github.com/haehn/CTK/commit/583a229fce5d99f06b78bab1c3a38cfe4255a328
> >> >>>
> >> >>> Would be great if we could encounter these changes to upstream and
> >> >>> then to Slicer CTK - the EMSegmenter needs it :)
> >> >>>
> >> >>> Thx,
> >> >>> Daniel
> >> >>>
> >> >>> On Wed, Aug 17, 2011 at 4:48 PM, Julien Finet
> >> >>> <julien.finet at kitware.com>
> >> >>> wrote:
> >> >>> > Looks good, except that when populating the values vector
> >> >>> > (ctkMatrixWidget::values()), I would call
> >> >>> > ctkMatrixWidget::value(i,j)
> >> >>> > instead of manually querying the data in order to factorize code.
> >> >>> > Thanks,
> >> >>> > Julien.
> >> >>> > p.s.I agree that setValues() would also beneficiate from some
> >> >>> > refactorization as well, but it's another story...
> >> >>> >
> >> >>> > On Wed, Aug 17, 2011 at 4:15 PM, Daniel Haehn
> >> >>> > <haehn at bwh.harvard.edu>
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> Hi guys,
> >> >>> >>
> >> >>> >> could you please review
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> https://github.com/haehn/CTK/tree/add-SetValuesQPropertyMatrixWidget-feature
> >> >>> >>
> >> >>> >> Thx,
> >> >>> >> Daniel
> >> >>> >>
> >> >>> >> On Tue, Aug 16, 2011 at 3:57 PM, Jean-Christophe Fillion-Robin
> >> >>> >> <jchris.fillionr at kitware.com> wrote:
> >> >>> >> > +1 for setValues
> >> >>> >> > Jc
> >> >>> >> >
> >> >>> >> > On Tue, Aug 16, 2011 at 3:11 PM, Julien Finet
> >> >>> >> > <julien.finet at kitware.com>
> >> >>> >> > wrote:
> >> >>> >> >>
> >> >>> >> >> Because a "Q_PROPERTY adds features through the meta-object
> >> >>> >> >> system".
> >> >>> >> >> Practically in this case, it allows the property to be wrapped
> >> >>> >> >> with
> >> >>> >> >> python, and initial values can also be set directly via the
> >> >>> >> >> Designer.
> >> >>> >> >> As a more philosophical point, the matrix "values" are a
> >> >>> >> >> "property"
> >> >>> >> >> of
> >> >>> >> >> the
> >> >>> >> >> matrix.
> >> >>> >> >> Julien.
> >> >>> >> >> On Tue, Aug 16, 2011 at 3:04 PM, Daniel Haehn
> >> >>> >> >> <haehn at bwh.harvard.edu>
> >> >>> >> >> wrote:
> >> >>> >> >>>
> >> >>> >> >>> Hi Julien,
> >> >>> >> >>>
> >> >>> >> >>> why do you think a Q_PROPERTY is better? Anyway, I will give
> it
> >> >>> >> >>> a
> >> >>> >> >>> shot
> >> >>> >> >>> and let you know.
> >> >>> >> >>>
> >> >>> >> >>> Cheers,
> >> >>> >> >>> Daniel
> >> >>> >> >>>
> >> >>> >> >>> On Tue, Aug 16, 2011 at 1:48 PM, Julien Finet
> >> >>> >> >>> <julien.finet at kitware.com>
> >> >>> >> >>> wrote:
> >> >>> >> >>> > Either that or we make a Q_PROPERTY named "values":
> >> >>> >> >>> > Q_PROPERTY( QVector<double> values READ values WRITE
> >> >>> >> >>> > setValues)
> >> >>> >> >>> > There is already:
> >> >>> >> >>> > ctkMatrixWidget::setVector(QVector<double>),
> >> >>> >> >>> > maybe
> >> >>> >> >>> > it
> >> >>> >> >>> > could be renamed into setValues and values() should then
> also
> >> >>> >> >>> > be
> >> >>> >> >>> > written.
> >> >>> >> >>> > Julien.
> >> >>> >> >>> >
> >> >>> >> >>> > On Tue, Aug 16, 2011 at 12:37 PM, Daniel Haehn
> >> >>> >> >>> > <haehn at bwh.harvard.edu>
> >> >>> >> >>> > wrote:
> >> >>> >> >>> >>
> >> >>> >> >>> >> Hi guys,
> >> >>> >> >>> >>
> >> >>> >> >>> >> it seems that it is not possible to set a value of a
> >> >>> >> >>> >> ctkMatrixWidget
> >> >>> >> >>> >> from Python?
> >> >>> >> >>> >>
> >> >>> >> >>> >> Shall we just enable Q_INVOKABLE on the
> >> >>> >> >>> >> ctkMatrixWidget::setValue
> >> >>> >> >>> >> method?
> >> >>> >> >>> >>
> >> >>> >> >>> >> Thanks,
> >> >>> >> >>> >> Daniel
> >> >>> >> >>> >> _______________________________________________
> >> >>> >> >>> >> Ctk-developers mailing list
> >> >>> >> >>> >> Ctk-developers at commontk.org
> >> >>> >> >>> >>
> >> >>> >> >>> >>
> >> >>> >> >>> >>
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >> >>> >> >>> >
> >> >>> >> >>> >
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >> _______________________________________________
> >> >>> >> >> Ctk-developers mailing list
> >> >>> >> >> Ctk-developers at commontk.org
> >> >>> >> >>
> >> >>> >> >>
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >> >>> >> >>
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >> > --
> >> >>> >> > +1 919 869 8849
> >> >>> >> >
> >> >>> >> >
> >> >>> >
> >> >>> >
> >> >>
> >> >>
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110819/5115ee2d/attachment.htm>

From jchris.fillionr at kitware.com  Fri Aug 19 16:26:54 2011
From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin)
Date: Fri, 19 Aug 2011 12:26:54 -0400
Subject: [Ctk-developers] ctkMatrixWidget: setValue not invokable from
	Python
In-Reply-To: <CAKoWPPHWKJa0Y1EXRZRHSRn8FYHoes4Y4Yun6eUUA8RhXsR3KA@mail.gmail.com>
References: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>
	<CAKoWPPEkcURxmR_xbqwtQHu8xMRugSLpnmeedYReXzTf-Cfk8Q@mail.gmail.com>
	<CAPDjdmZWXsHtE0PSdq2RtG0wC9U0Dcgn7Q1RedVMSrrWS6JGHg@mail.gmail.com>
	<CAKoWPPHdWoY9k1qMpc2J1gYtNY_kfgCoiP0puufa7ed64Ah52Q@mail.gmail.com>
	<CANLz8R4CrEYFb6hg-iiyeSs2eGJM=UYEFw+27nqB+5j-A2fL7g@mail.gmail.com>
	<CAPDjdmYkksDMMx052==YpsLA0kTzC0vY=zfepmmXYrHWQyzx2A@mail.gmail.com>
	<CAKoWPPHisV_2WBuQRwmu=jJo5z0nmDJExDgjqhZJy9bNU6c6mg@mail.gmail.com>
	<CAPDjdmbD1Huvt9joqvKnF4+X48yCeiJvSU6g22osukdwbcG+2w@mail.gmail.com>
	<CAKoWPPEovVckSGaAhghjnms6DMPqVJsU5WYVaNrO+2JCbac2cw@mail.gmail.com>
	<CAPDjdmZgEnu1iZQzbZ=GShqQxQJkhx99m+ciRctVomc5sKEbRQ@mail.gmail.com>
	<CAPDjdmaSrj8B3_mpN0sWtVNSPVw1EE-JgL-m39g87-wXQP-VmQ@mail.gmail.com>
	<CAKoWPPGbibowoOce-gwyQgi0ego6ykL68meEWqo569FiLXv_zw@mail.gmail.com>
	<CAPDjdmZmBRfkOGhbn7CKMy9GVKR6aFSHgjnYzHZBQFOzqvt3nQ@mail.gmail.com>
	<CAKoWPPHWKJa0Y1EXRZRHSRn8FYHoes4Y4Yun6eUUA8RhXsR3KA@mail.gmail.com>
Message-ID: <CANLz8R4SW8GHymFkaH2zmHGUuJ2Qe957NAGa=DoUKDqH+_NLAA@mail.gmail.com>

Looking into the issue, I am adding a test to
CTK/Apps/ctkSimplePythonShell/Testing

In the mean time, let me know if you find anything else.

Thanks
Jc

On Fri, Aug 19, 2011 at 12:22 PM, Julien Finet <julien.finet at kitware.com>wrote:

> I'm a bit reluctant to make ctkMatrixWidget's code less readable just to
> please scripting.
>
> From http://pythonqt.sourceforge.net/Features.html: it seems that we need
> to add our own "handlers" (whatever it means).
> I'm not sure what it implies though.
> Julien.
>
>
> On Fri, Aug 19, 2011 at 12:14 PM, Daniel Haehn <haehn at bwh.harvard.edu>wrote:
>
>> Hi Julien,
>>
>> I tried it but it did not change anything.. :/
>>
>> Daniel
>>
>> On Fri, Aug 19, 2011 at 12:03 PM, Julien Finet <julien.finet at kitware.com>
>> wrote:
>> > Maybe QVector<double> needs to be entered in the meta object system.
>> > Can you try adding
>> >
>> > qRegisterMetaType<QVector<double> > ("QVector<double>");
>> >
>> > in the constructor function of ctkMatrixWidget (better: init() of
>> > ctkMatrixWidgetPrivate if it exists)
>> > j.
>> > On Fri, Aug 19, 2011 at 11:55 AM, Daniel Haehn <haehn at bwh.harvard.edu>
>> > wrote:
>> >>
>> >> Hi again,
>> >>
>> >> so it seems that PythonQt has problems to wrap a QVector<double>. The
>> >> setValues method is not accesible from python and the values() method
>> >> returns:
>> >>
>> >>  QVector<double> (C++ Object 0x14c479690)
>> >>
>> >> rather than a python list. Maybe PythonQt only supports
>> QVector<double*> ?
>> >>
>> >> Maybe it makes more sense to return a QVariantList which maps to
>> >> python tuples in PythonQt?
>> >>
>> >> What do you guys think?
>> >>
>> >> Thanks,
>> >> Daniel
>> >>
>> >> On Wed, Aug 17, 2011 at 7:56 PM, Daniel Haehn <haehn at bwh.harvard.edu>
>> >> wrote:
>> >> > Great, thank you!
>> >> >
>> >> > Daniel
>> >> >
>> >> > On Wed, Aug 17, 2011 at 7:48 PM, Julien Finet <
>> julien.finet at kitware.com>
>> >> > wrote:
>> >> >> Added in CTK:
>> >> >>
>> >> >>
>> https://github.com/commontk/CTK/commit/5ebd60003b230f961bfb5d2c89c17f0ddcb4a151
>> >> >> Added in Slicer: r17743
>> >> >>
>> >> >>
>> http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=17743
>> >> >> Thanks,
>> >> >> Julien.
>> >> >>
>> >> >> On Wed, Aug 17, 2011 at 4:55 PM, Daniel Haehn <
>> haehn at bwh.harvard.edu>
>> >> >> wrote:
>> >> >>>
>> >> >>> Thanks for the feedback,
>> >> >>>
>> >> >>> I just commited
>> >> >>>
>> >> >>>
>> >> >>>
>> https://github.com/haehn/CTK/commit/583a229fce5d99f06b78bab1c3a38cfe4255a328
>> >> >>>
>> >> >>> Would be great if we could encounter these changes to upstream and
>> >> >>> then to Slicer CTK - the EMSegmenter needs it :)
>> >> >>>
>> >> >>> Thx,
>> >> >>> Daniel
>> >> >>>
>> >> >>> On Wed, Aug 17, 2011 at 4:48 PM, Julien Finet
>> >> >>> <julien.finet at kitware.com>
>> >> >>> wrote:
>> >> >>> > Looks good, except that when populating the values vector
>> >> >>> > (ctkMatrixWidget::values()), I would call
>> >> >>> > ctkMatrixWidget::value(i,j)
>> >> >>> > instead of manually querying the data in order to factorize code.
>> >> >>> > Thanks,
>> >> >>> > Julien.
>> >> >>> > p.s.I agree that setValues() would also beneficiate from some
>> >> >>> > refactorization as well, but it's another story...
>> >> >>> >
>> >> >>> > On Wed, Aug 17, 2011 at 4:15 PM, Daniel Haehn
>> >> >>> > <haehn at bwh.harvard.edu>
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> Hi guys,
>> >> >>> >>
>> >> >>> >> could you please review
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> https://github.com/haehn/CTK/tree/add-SetValuesQPropertyMatrixWidget-feature
>> >> >>> >>
>> >> >>> >> Thx,
>> >> >>> >> Daniel
>> >> >>> >>
>> >> >>> >> On Tue, Aug 16, 2011 at 3:57 PM, Jean-Christophe Fillion-Robin
>> >> >>> >> <jchris.fillionr at kitware.com> wrote:
>> >> >>> >> > +1 for setValues
>> >> >>> >> > Jc
>> >> >>> >> >
>> >> >>> >> > On Tue, Aug 16, 2011 at 3:11 PM, Julien Finet
>> >> >>> >> > <julien.finet at kitware.com>
>> >> >>> >> > wrote:
>> >> >>> >> >>
>> >> >>> >> >> Because a "Q_PROPERTY adds features through the meta-object
>> >> >>> >> >> system".
>> >> >>> >> >> Practically in this case, it allows the property to be
>> wrapped
>> >> >>> >> >> with
>> >> >>> >> >> python, and initial values can also be set directly via the
>> >> >>> >> >> Designer.
>> >> >>> >> >> As a more philosophical point, the matrix "values" are a
>> >> >>> >> >> "property"
>> >> >>> >> >> of
>> >> >>> >> >> the
>> >> >>> >> >> matrix.
>> >> >>> >> >> Julien.
>> >> >>> >> >> On Tue, Aug 16, 2011 at 3:04 PM, Daniel Haehn
>> >> >>> >> >> <haehn at bwh.harvard.edu>
>> >> >>> >> >> wrote:
>> >> >>> >> >>>
>> >> >>> >> >>> Hi Julien,
>> >> >>> >> >>>
>> >> >>> >> >>> why do you think a Q_PROPERTY is better? Anyway, I will give
>> it
>> >> >>> >> >>> a
>> >> >>> >> >>> shot
>> >> >>> >> >>> and let you know.
>> >> >>> >> >>>
>> >> >>> >> >>> Cheers,
>> >> >>> >> >>> Daniel
>> >> >>> >> >>>
>> >> >>> >> >>> On Tue, Aug 16, 2011 at 1:48 PM, Julien Finet
>> >> >>> >> >>> <julien.finet at kitware.com>
>> >> >>> >> >>> wrote:
>> >> >>> >> >>> > Either that or we make a Q_PROPERTY named "values":
>> >> >>> >> >>> > Q_PROPERTY( QVector<double> values READ values WRITE
>> >> >>> >> >>> > setValues)
>> >> >>> >> >>> > There is already:
>> >> >>> >> >>> > ctkMatrixWidget::setVector(QVector<double>),
>> >> >>> >> >>> > maybe
>> >> >>> >> >>> > it
>> >> >>> >> >>> > could be renamed into setValues and values() should then
>> also
>> >> >>> >> >>> > be
>> >> >>> >> >>> > written.
>> >> >>> >> >>> > Julien.
>> >> >>> >> >>> >
>> >> >>> >> >>> > On Tue, Aug 16, 2011 at 12:37 PM, Daniel Haehn
>> >> >>> >> >>> > <haehn at bwh.harvard.edu>
>> >> >>> >> >>> > wrote:
>> >> >>> >> >>> >>
>> >> >>> >> >>> >> Hi guys,
>> >> >>> >> >>> >>
>> >> >>> >> >>> >> it seems that it is not possible to set a value of a
>> >> >>> >> >>> >> ctkMatrixWidget
>> >> >>> >> >>> >> from Python?
>> >> >>> >> >>> >>
>> >> >>> >> >>> >> Shall we just enable Q_INVOKABLE on the
>> >> >>> >> >>> >> ctkMatrixWidget::setValue
>> >> >>> >> >>> >> method?
>> >> >>> >> >>> >>
>> >> >>> >> >>> >> Thanks,
>> >> >>> >> >>> >> Daniel
>> >> >>> >> >>> >> _______________________________________________
>> >> >>> >> >>> >> Ctk-developers mailing list
>> >> >>> >> >>> >> Ctk-developers at commontk.org
>> >> >>> >> >>> >>
>> >> >>> >> >>> >>
>> >> >>> >> >>> >>
>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>> >> >>> >> >>> >
>> >> >>> >> >>> >
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >> >> _______________________________________________
>> >> >>> >> >> Ctk-developers mailing list
>> >> >>> >> >> Ctk-developers at commontk.org
>> >> >>> >> >>
>> >> >>> >> >>
>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>> >> >>> >> >>
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> > --
>> >> >>> >> > +1 919 869 8849
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >
>> >> >>> >
>> >> >>
>> >> >>
>> >> >
>> >
>> >
>>
>
>


-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110819/f9c3b7b3/attachment.htm>

From haehn at bwh.harvard.edu  Fri Aug 19 16:29:51 2011
From: haehn at bwh.harvard.edu (Daniel Haehn)
Date: Fri, 19 Aug 2011 12:29:51 -0400
Subject: [Ctk-developers] ctkMatrixWidget: setValue not invokable from
	Python
In-Reply-To: <CAKoWPPHWKJa0Y1EXRZRHSRn8FYHoes4Y4Yun6eUUA8RhXsR3KA@mail.gmail.com>
References: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>
	<CAKoWPPEkcURxmR_xbqwtQHu8xMRugSLpnmeedYReXzTf-Cfk8Q@mail.gmail.com>
	<CAPDjdmZWXsHtE0PSdq2RtG0wC9U0Dcgn7Q1RedVMSrrWS6JGHg@mail.gmail.com>
	<CAKoWPPHdWoY9k1qMpc2J1gYtNY_kfgCoiP0puufa7ed64Ah52Q@mail.gmail.com>
	<CANLz8R4CrEYFb6hg-iiyeSs2eGJM=UYEFw+27nqB+5j-A2fL7g@mail.gmail.com>
	<CAPDjdmYkksDMMx052==YpsLA0kTzC0vY=zfepmmXYrHWQyzx2A@mail.gmail.com>
	<CAKoWPPHisV_2WBuQRwmu=jJo5z0nmDJExDgjqhZJy9bNU6c6mg@mail.gmail.com>
	<CAPDjdmbD1Huvt9joqvKnF4+X48yCeiJvSU6g22osukdwbcG+2w@mail.gmail.com>
	<CAKoWPPEovVckSGaAhghjnms6DMPqVJsU5WYVaNrO+2JCbac2cw@mail.gmail.com>
	<CAPDjdmZgEnu1iZQzbZ=GShqQxQJkhx99m+ciRctVomc5sKEbRQ@mail.gmail.com>
	<CAPDjdmaSrj8B3_mpN0sWtVNSPVw1EE-JgL-m39g87-wXQP-VmQ@mail.gmail.com>
	<CAKoWPPGbibowoOce-gwyQgi0ego6ykL68meEWqo569FiLXv_zw@mail.gmail.com>
	<CAPDjdmZmBRfkOGhbn7CKMy9GVKR6aFSHgjnYzHZBQFOzqvt3nQ@mail.gmail.com>
	<CAKoWPPHWKJa0Y1EXRZRHSRn8FYHoes4Y4Yun6eUUA8RhXsR3KA@mail.gmail.com>
Message-ID: <CAPDjdmZELicd1isONzJ819JE39-ni=FOAmk23UjHtVy92JcOdQ@mail.gmail.com>

Maybe it would have been easier to make setValue(i,j,value) Q_INVOKABLE :)

Daniel

On Fri, Aug 19, 2011 at 12:22 PM, Julien Finet <julien.finet at kitware.com> wrote:
> I'm a bit reluctant to make ctkMatrixWidget's code less readable just to
> please scripting.
> From?http://pythonqt.sourceforge.net/Features.html: it seems that we need to
> add our own "handlers" (whatever it means).
> I'm not sure what it implies though.
> Julien.
>
> On Fri, Aug 19, 2011 at 12:14 PM, Daniel Haehn <haehn at bwh.harvard.edu>
> wrote:
>>
>> Hi Julien,
>>
>> I tried it but it did not change anything.. :/
>>
>> Daniel
>>
>> On Fri, Aug 19, 2011 at 12:03 PM, Julien Finet <julien.finet at kitware.com>
>> wrote:
>> > Maybe?QVector<double> needs to be entered in the meta object system.
>> > Can you try adding
>> >
>> > qRegisterMetaType<QVector<double> > ("QVector<double>");
>> >
>> > in the constructor function of ctkMatrixWidget (better: init() of
>> > ctkMatrixWidgetPrivate if it exists)
>> > j.
>> > On Fri, Aug 19, 2011 at 11:55 AM, Daniel Haehn <haehn at bwh.harvard.edu>
>> > wrote:
>> >>
>> >> Hi again,
>> >>
>> >> so it seems that PythonQt has problems to wrap a QVector<double>. The
>> >> setValues method is not accesible from python and the values() method
>> >> returns:
>> >>
>> >> ?QVector<double> (C++ Object 0x14c479690)
>> >>
>> >> rather than a python list. Maybe PythonQt only supports
>> >> QVector<double*> ?
>> >>
>> >> Maybe it makes more sense to return a QVariantList which maps to
>> >> python tuples in PythonQt?
>> >>
>> >> What do you guys think?
>> >>
>> >> Thanks,
>> >> Daniel
>> >>
>> >> On Wed, Aug 17, 2011 at 7:56 PM, Daniel Haehn <haehn at bwh.harvard.edu>
>> >> wrote:
>> >> > Great, thank you!
>> >> >
>> >> > Daniel
>> >> >
>> >> > On Wed, Aug 17, 2011 at 7:48 PM, Julien Finet
>> >> > <julien.finet at kitware.com>
>> >> > wrote:
>> >> >> Added in CTK:
>> >> >>
>> >> >>
>> >> >> https://github.com/commontk/CTK/commit/5ebd60003b230f961bfb5d2c89c17f0ddcb4a151
>> >> >> Added in Slicer: r17743
>> >> >>
>> >> >>
>> >> >> http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=17743
>> >> >> Thanks,
>> >> >> Julien.
>> >> >>
>> >> >> On Wed, Aug 17, 2011 at 4:55 PM, Daniel Haehn
>> >> >> <haehn at bwh.harvard.edu>
>> >> >> wrote:
>> >> >>>
>> >> >>> Thanks for the feedback,
>> >> >>>
>> >> >>> I just commited
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> https://github.com/haehn/CTK/commit/583a229fce5d99f06b78bab1c3a38cfe4255a328
>> >> >>>
>> >> >>> Would be great if we could encounter these changes to upstream and
>> >> >>> then to Slicer CTK - the EMSegmenter needs it :)
>> >> >>>
>> >> >>> Thx,
>> >> >>> Daniel
>> >> >>>
>> >> >>> On Wed, Aug 17, 2011 at 4:48 PM, Julien Finet
>> >> >>> <julien.finet at kitware.com>
>> >> >>> wrote:
>> >> >>> > Looks good, except that when populating the values vector
>> >> >>> > (ctkMatrixWidget::values()), I would call
>> >> >>> > ctkMatrixWidget::value(i,j)
>> >> >>> > instead of manually querying the data in order to factorize code.
>> >> >>> > Thanks,
>> >> >>> > Julien.
>> >> >>> > p.s.I agree that setValues() would also beneficiate from some
>> >> >>> > refactorization as well, but it's another story...
>> >> >>> >
>> >> >>> > On Wed, Aug 17, 2011 at 4:15 PM, Daniel Haehn
>> >> >>> > <haehn at bwh.harvard.edu>
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> Hi guys,
>> >> >>> >>
>> >> >>> >> could you please review
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> https://github.com/haehn/CTK/tree/add-SetValuesQPropertyMatrixWidget-feature
>> >> >>> >>
>> >> >>> >> Thx,
>> >> >>> >> Daniel
>> >> >>> >>
>> >> >>> >> On Tue, Aug 16, 2011 at 3:57 PM, Jean-Christophe Fillion-Robin
>> >> >>> >> <jchris.fillionr at kitware.com> wrote:
>> >> >>> >> > +1 for setValues
>> >> >>> >> > Jc
>> >> >>> >> >
>> >> >>> >> > On Tue, Aug 16, 2011 at 3:11 PM, Julien Finet
>> >> >>> >> > <julien.finet at kitware.com>
>> >> >>> >> > wrote:
>> >> >>> >> >>
>> >> >>> >> >> Because a "Q_PROPERTY adds features through the meta-object
>> >> >>> >> >> system".
>> >> >>> >> >> Practically in this case, it allows the property to be
>> >> >>> >> >> wrapped
>> >> >>> >> >> with
>> >> >>> >> >> python, and initial values can also be set directly via the
>> >> >>> >> >> Designer.
>> >> >>> >> >> As a more?philosophical?point, the?matrix?"values" are a
>> >> >>> >> >> "property"
>> >> >>> >> >> of
>> >> >>> >> >> the
>> >> >>> >> >> matrix.
>> >> >>> >> >> Julien.
>> >> >>> >> >> On Tue, Aug 16, 2011 at 3:04 PM, Daniel Haehn
>> >> >>> >> >> <haehn at bwh.harvard.edu>
>> >> >>> >> >> wrote:
>> >> >>> >> >>>
>> >> >>> >> >>> Hi Julien,
>> >> >>> >> >>>
>> >> >>> >> >>> why do you think a Q_PROPERTY is better? Anyway, I will give
>> >> >>> >> >>> it
>> >> >>> >> >>> a
>> >> >>> >> >>> shot
>> >> >>> >> >>> and let you know.
>> >> >>> >> >>>
>> >> >>> >> >>> Cheers,
>> >> >>> >> >>> Daniel
>> >> >>> >> >>>
>> >> >>> >> >>> On Tue, Aug 16, 2011 at 1:48 PM, Julien Finet
>> >> >>> >> >>> <julien.finet at kitware.com>
>> >> >>> >> >>> wrote:
>> >> >>> >> >>> > Either that or we make a?Q_PROPERTY named?"values":
>> >> >>> >> >>> > Q_PROPERTY( QVector<double> values READ values WRITE
>> >> >>> >> >>> > setValues)
>> >> >>> >> >>> > There is already:
>> >> >>> >> >>> > ctkMatrixWidget::setVector(QVector<double>),
>> >> >>> >> >>> > maybe
>> >> >>> >> >>> > it
>> >> >>> >> >>> > could be renamed into setValues and values() should then
>> >> >>> >> >>> > also
>> >> >>> >> >>> > be
>> >> >>> >> >>> > written.
>> >> >>> >> >>> > Julien.
>> >> >>> >> >>> >
>> >> >>> >> >>> > On Tue, Aug 16, 2011 at 12:37 PM, Daniel Haehn
>> >> >>> >> >>> > <haehn at bwh.harvard.edu>
>> >> >>> >> >>> > wrote:
>> >> >>> >> >>> >>
>> >> >>> >> >>> >> Hi guys,
>> >> >>> >> >>> >>
>> >> >>> >> >>> >> it seems that it is not possible to set a value of a
>> >> >>> >> >>> >> ctkMatrixWidget
>> >> >>> >> >>> >> from Python?
>> >> >>> >> >>> >>
>> >> >>> >> >>> >> Shall we just enable Q_INVOKABLE on the
>> >> >>> >> >>> >> ctkMatrixWidget::setValue
>> >> >>> >> >>> >> method?
>> >> >>> >> >>> >>
>> >> >>> >> >>> >> Thanks,
>> >> >>> >> >>> >> Daniel
>> >> >>> >> >>> >> _______________________________________________
>> >> >>> >> >>> >> Ctk-developers mailing list
>> >> >>> >> >>> >> Ctk-developers at commontk.org
>> >> >>> >> >>> >>
>> >> >>> >> >>> >>
>> >> >>> >> >>> >>
>> >> >>> >> >>> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>> >> >>> >> >>> >
>> >> >>> >> >>> >
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >> >> _______________________________________________
>> >> >>> >> >> Ctk-developers mailing list
>> >> >>> >> >> Ctk-developers at commontk.org
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>> >> >>> >> >>
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> > --
>> >> >>> >> > +1 919 869 8849
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >
>> >> >>> >
>> >> >>
>> >> >>
>> >> >
>> >
>> >
>
>


From julien.finet at kitware.com  Fri Aug 19 16:37:02 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Fri, 19 Aug 2011 12:37:02 -0400
Subject: [Ctk-developers] ctkMatrixWidget: setValue not invokable from
	Python
In-Reply-To: <CAPDjdmZELicd1isONzJ819JE39-ni=FOAmk23UjHtVy92JcOdQ@mail.gmail.com>
References: <CAPDjdmagU=w3qC9jizUmBGgNkLhAF1n-qo2bnUXMWJUUf7xV3Q@mail.gmail.com>
	<CAKoWPPEkcURxmR_xbqwtQHu8xMRugSLpnmeedYReXzTf-Cfk8Q@mail.gmail.com>
	<CAPDjdmZWXsHtE0PSdq2RtG0wC9U0Dcgn7Q1RedVMSrrWS6JGHg@mail.gmail.com>
	<CAKoWPPHdWoY9k1qMpc2J1gYtNY_kfgCoiP0puufa7ed64Ah52Q@mail.gmail.com>
	<CANLz8R4CrEYFb6hg-iiyeSs2eGJM=UYEFw+27nqB+5j-A2fL7g@mail.gmail.com>
	<CAPDjdmYkksDMMx052==YpsLA0kTzC0vY=zfepmmXYrHWQyzx2A@mail.gmail.com>
	<CAKoWPPHisV_2WBuQRwmu=jJo5z0nmDJExDgjqhZJy9bNU6c6mg@mail.gmail.com>
	<CAPDjdmbD1Huvt9joqvKnF4+X48yCeiJvSU6g22osukdwbcG+2w@mail.gmail.com>
	<CAKoWPPEovVckSGaAhghjnms6DMPqVJsU5WYVaNrO+2JCbac2cw@mail.gmail.com>
	<CAPDjdmZgEnu1iZQzbZ=GShqQxQJkhx99m+ciRctVomc5sKEbRQ@mail.gmail.com>
	<CAPDjdmaSrj8B3_mpN0sWtVNSPVw1EE-JgL-m39g87-wXQP-VmQ@mail.gmail.com>
	<CAKoWPPGbibowoOce-gwyQgi0ego6ykL68meEWqo569FiLXv_zw@mail.gmail.com>
	<CAPDjdmZmBRfkOGhbn7CKMy9GVKR6aFSHgjnYzHZBQFOzqvt3nQ@mail.gmail.com>
	<CAKoWPPHWKJa0Y1EXRZRHSRn8FYHoes4Y4Yun6eUUA8RhXsR3KA@mail.gmail.com>
	<CAPDjdmZELicd1isONzJ819JE39-ni=FOAmk23UjHtVy92JcOdQ@mail.gmail.com>
Message-ID: <CAKoWPPGGSenPCBs9Y0xGvixbodp8hmDoDEsmzOC-g5+SpGvsvA@mail.gmail.com>

I guess, nothing prevent us from doing that as well.

J.

On Fri, Aug 19, 2011 at 12:29 PM, Daniel Haehn <haehn at bwh.harvard.edu>wrote:

> Maybe it would have been easier to make setValue(i,j,value) Q_INVOKABLE :)
>
> Daniel
>
> On Fri, Aug 19, 2011 at 12:22 PM, Julien Finet <julien.finet at kitware.com>
> wrote:
> > I'm a bit reluctant to make ctkMatrixWidget's code less readable just to
> > please scripting.
> > From http://pythonqt.sourceforge.net/Features.html: it seems that we
> need to
> > add our own "handlers" (whatever it means).
> > I'm not sure what it implies though.
> > Julien.
> >
> > On Fri, Aug 19, 2011 at 12:14 PM, Daniel Haehn <haehn at bwh.harvard.edu>
> > wrote:
> >>
> >> Hi Julien,
> >>
> >> I tried it but it did not change anything.. :/
> >>
> >> Daniel
> >>
> >> On Fri, Aug 19, 2011 at 12:03 PM, Julien Finet <
> julien.finet at kitware.com>
> >> wrote:
> >> > Maybe QVector<double> needs to be entered in the meta object system.
> >> > Can you try adding
> >> >
> >> > qRegisterMetaType<QVector<double> > ("QVector<double>");
> >> >
> >> > in the constructor function of ctkMatrixWidget (better: init() of
> >> > ctkMatrixWidgetPrivate if it exists)
> >> > j.
> >> > On Fri, Aug 19, 2011 at 11:55 AM, Daniel Haehn <haehn at bwh.harvard.edu
> >
> >> > wrote:
> >> >>
> >> >> Hi again,
> >> >>
> >> >> so it seems that PythonQt has problems to wrap a QVector<double>. The
> >> >> setValues method is not accesible from python and the values() method
> >> >> returns:
> >> >>
> >> >>  QVector<double> (C++ Object 0x14c479690)
> >> >>
> >> >> rather than a python list. Maybe PythonQt only supports
> >> >> QVector<double*> ?
> >> >>
> >> >> Maybe it makes more sense to return a QVariantList which maps to
> >> >> python tuples in PythonQt?
> >> >>
> >> >> What do you guys think?
> >> >>
> >> >> Thanks,
> >> >> Daniel
> >> >>
> >> >> On Wed, Aug 17, 2011 at 7:56 PM, Daniel Haehn <haehn at bwh.harvard.edu
> >
> >> >> wrote:
> >> >> > Great, thank you!
> >> >> >
> >> >> > Daniel
> >> >> >
> >> >> > On Wed, Aug 17, 2011 at 7:48 PM, Julien Finet
> >> >> > <julien.finet at kitware.com>
> >> >> > wrote:
> >> >> >> Added in CTK:
> >> >> >>
> >> >> >>
> >> >> >>
> https://github.com/commontk/CTK/commit/5ebd60003b230f961bfb5d2c89c17f0ddcb4a151
> >> >> >> Added in Slicer: r17743
> >> >> >>
> >> >> >>
> >> >> >>
> http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=17743
> >> >> >> Thanks,
> >> >> >> Julien.
> >> >> >>
> >> >> >> On Wed, Aug 17, 2011 at 4:55 PM, Daniel Haehn
> >> >> >> <haehn at bwh.harvard.edu>
> >> >> >> wrote:
> >> >> >>>
> >> >> >>> Thanks for the feedback,
> >> >> >>>
> >> >> >>> I just commited
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> https://github.com/haehn/CTK/commit/583a229fce5d99f06b78bab1c3a38cfe4255a328
> >> >> >>>
> >> >> >>> Would be great if we could encounter these changes to upstream
> and
> >> >> >>> then to Slicer CTK - the EMSegmenter needs it :)
> >> >> >>>
> >> >> >>> Thx,
> >> >> >>> Daniel
> >> >> >>>
> >> >> >>> On Wed, Aug 17, 2011 at 4:48 PM, Julien Finet
> >> >> >>> <julien.finet at kitware.com>
> >> >> >>> wrote:
> >> >> >>> > Looks good, except that when populating the values vector
> >> >> >>> > (ctkMatrixWidget::values()), I would call
> >> >> >>> > ctkMatrixWidget::value(i,j)
> >> >> >>> > instead of manually querying the data in order to factorize
> code.
> >> >> >>> > Thanks,
> >> >> >>> > Julien.
> >> >> >>> > p.s.I agree that setValues() would also beneficiate from some
> >> >> >>> > refactorization as well, but it's another story...
> >> >> >>> >
> >> >> >>> > On Wed, Aug 17, 2011 at 4:15 PM, Daniel Haehn
> >> >> >>> > <haehn at bwh.harvard.edu>
> >> >> >>> > wrote:
> >> >> >>> >>
> >> >> >>> >> Hi guys,
> >> >> >>> >>
> >> >> >>> >> could you please review
> >> >> >>> >>
> >> >> >>> >>
> >> >> >>> >>
> >> >> >>> >>
> >> >> >>> >>
> >> >> >>> >>
> https://github.com/haehn/CTK/tree/add-SetValuesQPropertyMatrixWidget-feature
> >> >> >>> >>
> >> >> >>> >> Thx,
> >> >> >>> >> Daniel
> >> >> >>> >>
> >> >> >>> >> On Tue, Aug 16, 2011 at 3:57 PM, Jean-Christophe Fillion-Robin
> >> >> >>> >> <jchris.fillionr at kitware.com> wrote:
> >> >> >>> >> > +1 for setValues
> >> >> >>> >> > Jc
> >> >> >>> >> >
> >> >> >>> >> > On Tue, Aug 16, 2011 at 3:11 PM, Julien Finet
> >> >> >>> >> > <julien.finet at kitware.com>
> >> >> >>> >> > wrote:
> >> >> >>> >> >>
> >> >> >>> >> >> Because a "Q_PROPERTY adds features through the meta-object
> >> >> >>> >> >> system".
> >> >> >>> >> >> Practically in this case, it allows the property to be
> >> >> >>> >> >> wrapped
> >> >> >>> >> >> with
> >> >> >>> >> >> python, and initial values can also be set directly via the
> >> >> >>> >> >> Designer.
> >> >> >>> >> >> As a more philosophical point, the matrix "values" are a
> >> >> >>> >> >> "property"
> >> >> >>> >> >> of
> >> >> >>> >> >> the
> >> >> >>> >> >> matrix.
> >> >> >>> >> >> Julien.
> >> >> >>> >> >> On Tue, Aug 16, 2011 at 3:04 PM, Daniel Haehn
> >> >> >>> >> >> <haehn at bwh.harvard.edu>
> >> >> >>> >> >> wrote:
> >> >> >>> >> >>>
> >> >> >>> >> >>> Hi Julien,
> >> >> >>> >> >>>
> >> >> >>> >> >>> why do you think a Q_PROPERTY is better? Anyway, I will
> give
> >> >> >>> >> >>> it
> >> >> >>> >> >>> a
> >> >> >>> >> >>> shot
> >> >> >>> >> >>> and let you know.
> >> >> >>> >> >>>
> >> >> >>> >> >>> Cheers,
> >> >> >>> >> >>> Daniel
> >> >> >>> >> >>>
> >> >> >>> >> >>> On Tue, Aug 16, 2011 at 1:48 PM, Julien Finet
> >> >> >>> >> >>> <julien.finet at kitware.com>
> >> >> >>> >> >>> wrote:
> >> >> >>> >> >>> > Either that or we make a Q_PROPERTY named "values":
> >> >> >>> >> >>> > Q_PROPERTY( QVector<double> values READ values WRITE
> >> >> >>> >> >>> > setValues)
> >> >> >>> >> >>> > There is already:
> >> >> >>> >> >>> > ctkMatrixWidget::setVector(QVector<double>),
> >> >> >>> >> >>> > maybe
> >> >> >>> >> >>> > it
> >> >> >>> >> >>> > could be renamed into setValues and values() should then
> >> >> >>> >> >>> > also
> >> >> >>> >> >>> > be
> >> >> >>> >> >>> > written.
> >> >> >>> >> >>> > Julien.
> >> >> >>> >> >>> >
> >> >> >>> >> >>> > On Tue, Aug 16, 2011 at 12:37 PM, Daniel Haehn
> >> >> >>> >> >>> > <haehn at bwh.harvard.edu>
> >> >> >>> >> >>> > wrote:
> >> >> >>> >> >>> >>
> >> >> >>> >> >>> >> Hi guys,
> >> >> >>> >> >>> >>
> >> >> >>> >> >>> >> it seems that it is not possible to set a value of a
> >> >> >>> >> >>> >> ctkMatrixWidget
> >> >> >>> >> >>> >> from Python?
> >> >> >>> >> >>> >>
> >> >> >>> >> >>> >> Shall we just enable Q_INVOKABLE on the
> >> >> >>> >> >>> >> ctkMatrixWidget::setValue
> >> >> >>> >> >>> >> method?
> >> >> >>> >> >>> >>
> >> >> >>> >> >>> >> Thanks,
> >> >> >>> >> >>> >> Daniel
> >> >> >>> >> >>> >> _______________________________________________
> >> >> >>> >> >>> >> Ctk-developers mailing list
> >> >> >>> >> >>> >> Ctk-developers at commontk.org
> >> >> >>> >> >>> >>
> >> >> >>> >> >>> >>
> >> >> >>> >> >>> >>
> >> >> >>> >> >>> >>
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >> >> >>> >> >>> >
> >> >> >>> >> >>> >
> >> >> >>> >> >>
> >> >> >>> >> >>
> >> >> >>> >> >> _______________________________________________
> >> >> >>> >> >> Ctk-developers mailing list
> >> >> >>> >> >> Ctk-developers at commontk.org
> >> >> >>> >> >>
> >> >> >>> >> >>
> >> >> >>> >> >>
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >> >> >>> >> >>
> >> >> >>> >> >
> >> >> >>> >> >
> >> >> >>> >> >
> >> >> >>> >> > --
> >> >> >>> >> > +1 919 869 8849
> >> >> >>> >> >
> >> >> >>> >> >
> >> >> >>> >
> >> >> >>> >
> >> >> >>
> >> >> >>
> >> >> >
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110819/b3f5030a/attachment.htm>

From julien.finet at kitware.com  Fri Aug 26 23:10:27 2011
From: julien.finet at kitware.com (Julien Finet)
Date: Fri, 26 Aug 2011 19:10:27 -0400
Subject: [Ctk-developers] CMake 2.8.6 rc1 is out...
Message-ID: <CAKoWPPErjj+Oq548==+YogvO6b48+YeKzLbfrptQWsdf_uUSXA@mail.gmail.com>

CMake 2.8.6 rc1 is out...
http://www.kitware.com/blog/home/post/158

... and CTK builds fine with it.

For now tested only on Windows XP/7 32b/64b VS 2008/2010.
http://my.cdash.org/index.php?project=CTK&subproject=SuperBuild

Julien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110826/ecc1fdf7/attachment.htm>

From pieper at ibility.net  Mon Aug 29 17:39:09 2011
From: pieper at ibility.net (Steve Pieper)
Date: Mon, 29 Aug 2011 13:39:09 -0400
Subject: [Ctk-developers] Fwd: [slicer-devel] ctk / qMRML build error this
	morning
In-Reply-To: <CA+OFd4wnG=HEvFEwYPcyA_Aogm+XpPaNkuQRNsPcyZwYroEYzw@mail.gmail.com>
References: <CA+OFd4yOAG75bG7vbeUdAO+pJjSdPJNHsxT+J3uM=9O9o4g8og@mail.gmail.com>
	<CAPDjdmZYLf8wNQEA=GKKR9p_3fdj-SZS3NRjc+y=HL1rM3EcDQ@mail.gmail.com>
	<CAKoWPPH3ZeDr8Rgsfii8Ajr+P+d9kLBfDBEvk3whbApTAUUS=g@mail.gmail.com>
	<CADFtqopqf82t9ffsjzZxvLKgfcxZd=Pwuvzg7HNTxHZa_=QASw@mail.gmail.com>
	<CA+OFd4wnG=HEvFEwYPcyA_Aogm+XpPaNkuQRNsPcyZwYroEYzw@mail.gmail.com>
Message-ID: <CA+OFd4xNrG8uAMXHnQmOk_PRjx7FqSHpfPH-ZdVUehDM2DDCXg@mail.gmail.com>

Hi Folks -

I posted an issue about builds:

https://github.com/commontk/CTK/issues/32

Does anyone know what's up with this?

The mail trail below has more info about the slicer side of things.

Thanks in advance,
Steve

---------- Forwarded message ----------
From: Steve Pieper <pieper at ibility.net>
Date: Mon, Aug 29, 2011 at 1:32 PM
Subject: Re: [slicer-devel] ctk / qMRML build error this morning
To: Isaiah Norton <isaiah.norton at gmail.com>
Cc: Julien Finet <julien.finet at kitware.com>, slicer-devel at bwh.harvard.edu


Yes - somehow the dependencies inside CTK's superbuild are not working - if
I do an edit of something, for example in ctkDICOM and then run make at the
CTK-superbuild level ctkDICOM is not rebuilt.  But if I run make inside
CTK-build it does rebuild.  I'll post something to the ctk-developer list.

-Steve

On Mon, Aug 29, 2011 at 12:12 PM, Isaiah Norton <isaiah.norton at gmail.com>wrote:

> I had these errors yesterday; removed qMRMLWidgets and CTK, and rebuilt. It
> worked after rebuild.
> -Isaiah
>
>
> On Mon, Aug 29, 2011 at 12:06 PM, Julien Finet <julien.finet at kitware.com>wrote:
>
>> It should be there already.
>> Can you rebuild CTK ? (remove sources and build and launch superbuild
>> again)
>> There is definitely an issue with the superbuild and CTK.
>> j.
>>
>>
>> On Mon, Aug 29, 2011 at 11:25 AM, Daniel Haehn <haehn at bwh.harvard.edu>wrote:
>>
>>> I have the same error on Mac.
>>>
>>> Thanks,
>>> Daniel
>>>
>>> On Mon, Aug 29, 2011 at 10:59 AM, Steve Pieper <pieper at ibility.net>
>>> wrote:
>>> > Missing push to ctk?
>>> >
>>> > Linking CXX shared library ../../bin/libqMRMLWidgets.so
>>> > CMakeFiles/qMRMLWidgets.dir/qMRMLItemDelegate.cxx.o: In function
>>> > `qMRMLItemDelegate::createEditor(QWidget*, QStyleOptionViewItem const&,
>>> > QModelIndex const&) const':
>>> >
>>> /home/pieper/slicer4/latest/Slicer4/Libs/qMRMLWidgets/qMRMLItemDelegate.cxx:127:
>>> > undefined reference to
>>> > `ctkBasePopupWidget::setAlignment(QFlags<Qt::AlignmentFlag>)'
>>> >
>>> /home/pieper/slicer4/latest/Slicer4/Libs/qMRMLWidgets/qMRMLItemDelegate.cxx:128:
>>> > undefined reference to
>>> > `ctkBasePopupWidget::setOrientation(QFlags<Qt::Orientation>)'
>>> >
>>> /home/pieper/slicer4/latest/Slicer4/Libs/qMRMLWidgets/qMRMLItemDelegate.cxx:129:
>>> > undefined reference to
>>> > `ctkBasePopupWidget::setHorizontalDirection(Qt::LayoutDirection)'
>>> > CMakeFiles/qMRMLWidgets.dir/qMRMLThreeDViewControllerWidget.cxx.o: In
>>> > function `qMRMLThreeDViewControllerWidgetPrivate::setupPopupUi()':
>>> >
>>> /home/pieper/slicer4/latest/Slicer4/Libs/qMRMLWidgets/qMRMLThreeDViewControllerWidget.cxx:73:
>>> > undefined reference to
>>> > `ctkBasePopupWidget::setAlignment(QFlags<Qt::AlignmentFlag>)'
>>> > CMakeFiles/qMRMLWidgets.dir/qMRMLViewControllerBar.cxx.o: In function
>>> > `qMRMLViewControllerBarPrivate::setupPopupUi()':
>>> >
>>> /home/pieper/slicer4/latest/Slicer4/Libs/qMRMLWidgets/qMRMLViewControllerBar.cxx:138:
>>> > undefined reference to
>>> > `ctkBasePopupWidget::setOrientation(QFlags<Qt::Orientation>)'
>>> > collect2: ld returned 1 exit status
>>> > make[2]: *** [bin/libqMRMLWidgets.so] Error 1
>>> > make[1]: *** [Libs/qMRMLWidgets/CMakeFiles/qMRMLWidgets.dir/all] Error
>>> 2
>>> > make: *** [all] Error 2
>>> >
>>> >
>>> > _______________________________________________
>>> > slicer-devel mailing list
>>> > slicer-devel at bwh.harvard.edu
>>> > http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>>> > To unsubscribe: send email to
>>> slicer-devel-request at massmail.spl.harvard.edu
>>> > with unsubscribe as the subject
>>> >
>>> _______________________________________________
>>> slicer-devel mailing list
>>> slicer-devel at bwh.harvard.edu
>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>>> To unsubscribe: send email to
>>> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as the
>>> subject
>>>
>>
>>
>> _______________________________________________
>> slicer-devel mailing list
>> slicer-devel at bwh.harvard.edu
>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>> To unsubscribe: send email to
>> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as the
>> subject
>>
>
>
> _______________________________________________
> slicer-devel mailing list
> slicer-devel at bwh.harvard.edu
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
> To unsubscribe: send email to
> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as the
> subject
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110829/7b9b79ff/attachment.htm>