search

commontk / CTK

A set of common support code for medical imaging, surgical navigation, and related purposes.
https://commontk.org
Apache License 2.0
867 stars 492 forks source link

PyCTK: Python bindings for CTK #599

Open jazzycamel opened 9 years ago

jazzycamel commented 9 years ago

Hi CTK Folks,

I just wanted to let any interested parties know that we (that is to say I) are in the process of producing some python/PyQt bindings to some of the code in CTK. We have reached a point of a very tentative development release of the Core and Widgets submodules (our only interest for now) and have published the project on our GitHub: https://github.com/lamondlab/pyctk. Our activities are now switching towards writing some tests and/or examples that use these bindings to prove them before integrating them into our own application(s). I just wanted to let the CTK community know what we were up to in case our work could be useful to others and obviously we are always open to suggestions, (constructive) criticism and help.

Thanks very much, Rob Kent https://github.com/jazzycamel

PS. Sorry for raising this as an 'issue', I wasn't sure where else to send/post this. If there is a better method or forum them please let me know.

jcfr commented 9 years ago

Hi @jazzycamel,

I just wanted to let the CTK community know what we were up to in case our work could be useful to others

Thanks for the note :+1: and thanks for sharing your work. It is always good to know when things works out.

Would also be great to learn more about the type of application you are creating. Are you using it to build part of the DataShop application ?

Either way, it is great to see it is useful :)

If there is a better method or forum them please let me know.

Earlier today, I updated the wiki to clarify things. See http://commontk.org/index.php/Getting_Started Registering on the mailing list is also an option, it will allow you to discuss and ask questions .

and obviously we are always open to suggestions, (constructive) criticism and help.

Here are few suggestions / comments:

Tracking a specific version

Browsing through the code, I noticed you copied the source files. I wonder if we could improve things on the CTK side to facilitate the "PyQt-ification" of a given version.

Here are few idea:

The idea is to clearly track which version of CTK is used within a given version of the bindings. This is particularly when building scientific application.

Simplifying the maintenance of sip files

I also noticed that you did a lot of work to create the sip files. Is there anything we could do within CTK to facilitate the creation of these sip files ?

I am wondering if these files could be automatically generated by using the output of a tool like castxml

common testing

Since we already wrap the CTK objects to make them usable with PythonQt. I am wondering if we could keep the python testing code (or part of it) in one location. The python code in common would be wrapper independent (not specific to either PyQt or PythonQt) and would be stored within the CTK source tree.

Best, Jc

jazzycamel commented 9 years ago

Hi @jcfr,

So, yes: I am the creator and sole developer of DataShop, I'm surprised you found it BTW! The application is part of a suite of tools (PepTracker) designed and implemented by us to support the work going on in our laboratory which is concerned mostly with large-scale Proteomics data. DataShop was conceived to overcome a particular issue in this field which is that the tools that are normally used for data visualisation and analysis (e.g. Excel) can't cope efficiently with the volume of our data and the tools that can are too complicated or have too steep a learning curve for our typical user to take advantage of. Thus we designed DataShop to be able to handle large datasets, visualise them and perform powerful analyses all efficiently as possible whilst providing the simplest and most comfortable user experience possible. The project has been ongoing for ~3 years now and we reached a stable release 1.2 for Mac OSX and Windows last year. Since then I have been working on release 2.0 which consists of a complete re-evaluation and re-implementation of the UI to make leveraging the power of DataShop even easier, and this is where CTK comes in. Many of the widgets contained within CTK just make interacting with a UI simpler, more obvious and, frankly, prettier and thats why I decided to wrap/bind some of the functionality into PyQt to allow us to access it. So, thats 'who' I am and 'why' I'm doing this, sorry for the essay!

Thanks very much for your reply and for your comments @jcfr, I have signed up to the mailing list today and will communicate via this in future. As to your suggestions/comments:

Tracking a specific version You're absolutely right: we should track a specific CTK version. The reason I copied the source initially was actually to learn how to build it without CMake and incorporate it into the SIP build chain. I actually started with only a couple of simple classes (ctkPopupWidget) and it kind of spiralled from there. I have actually modified all of the headers (with a python script) and created my own ctkExport.h (rather than ctkCoreExport.h and ctkWidgetsExport.h), but this in unnecessary and will be removed/reverted. I think that using a git submodule or subtree is probably the right way to go and then specifying a particular CTK commit/tag/release for each version of the python bindings.

Simplifying the maintenance of sip files You're right here too! A lot, if not most, of the work has gone in to generating the sip files. I have got a python script which parses the C++ header files and generates a skeleton sip file but it usually only gets me ~80-90% of the way and then I have to hand tweak them. This is possibly because I'm still learning how to SIPify things as I go along and it may become easier/more generic with experience and as I close some of my own issues. I will have a look at castxml as it may well do a better job of parsing the C++ than my hand cranked script, so thank for the suggestion.

Common Testing I think this is an excellent idea. Once I have got something more formal completed (and thats actually worth testing properly!) I would like to look into this, as I agree that using the same testing code is the most logical way to go.

Thanks very much again for your response, your suggestions and your support. I very much look forward to being part of this community and hopefully contributing something useful.

Regards, Rob (@jazzycamel)

pieper commented 9 years ago

Thanks for working on this @jazzycamel ! We have a lot of other ctk derived code and i hope we'll be able to someday use your work to generalize the ways it can be used.