Does Kalzium use Python API of libavogadro?
–
Regards,
Konstantin
Am 02.05.2010 12:49, schrieb Константин Токарев:
Does Kalzium use Python API of libavogadro?
No, the c++ Version.
Carsten
Am 02.05.2010 12:49, schrieb Константин Токарев:
Does Kalzium use Python API of libavogadro?
No, the c++ Version.
To be sure: no C++ header with word ‘python’ is used?
–
Regards,
Konstantin
Am 02.05.2010 17:20, schrieb Konstantin Tokarev:
Am 02.05.2010 12:49, schrieb Константин Токарев:
Does Kalzium use Python API of libavogadro?
No, the c++ Version.
To be sure: no C++ header with word ‘python’ is used?
To be extra sure I grepped with “grep -iR python *” in the directory and
nothing showed up.
Carsten
Am 02.05.2010 12:49, schrieb Константин Токарев:
Does Kalzium use Python API of libavogadro?
Would this even be possible (to use Python from within a c+±KDE-App?)
If so: can I mix Python and c+±code somehow? I don’t like to code in
c++ but really like Python. I would like to add new features in Kalzium
using Python and not c++…
Carsten
Am 02.05.2010 18:08, schrieb Tim Vandermeersch:
On Sun, May 2, 2010 at 5:28 PM, Carsten Niehaus cniehaus@gmx.de wrote:
Am 02.05.2010 12:49, schrieb Константин Токарев:
Does Kalzium use Python API of libavogadro?
Would this even be possible (to use Python from within a c+±KDE-App?)
If so: can I mix Python and c+±code somehow? I don’t like to code in
c++ but really like Python. I would like to add new features in Kalzium
using Python and not c++…This is possible. It does require some (boost python) C++ code though.
To start, you need to write python bindings for the C++ code you will
be accessing from python.
Is that what PyQt and/or PyKDE are for?
Carsten
On Sun, May 2, 2010 at 5:28 PM, Carsten Niehaus cniehaus@gmx.de wrote:
Am 02.05.2010 12:49, schrieb Константин Токарев:
Does Kalzium use Python API of libavogadro?
Would this even be possible (to use Python from within a c+±KDE-App?)
If so: can I mix Python and c+±code somehow? I don’t like to code in
c++ but really like Python. I would like to add new features in Kalzium
using Python and not c++…
This is possible. It does require some (boost python) C++ code though.
To start, you need to write python bindings for the C++ code you will
be accessing from python. Next, you need some C++ code to call your
python code. For example, in avogadro we have a C++ PythonExtension
class which wraps an extension written in python.
Tim
Carsten
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options
//Disclaimer: my notion about Python and Python bindings of Avogadro is
somewhat vague, you’d better ask Tim about it.
Would this even be possible (to use Python from within a c+±KDE-App?)
If so: can I mix Python and c+±code somehow?
As far as I can see in sources of libavogadro/src/python (it is
pluggable python module which installs to site-packages directory of
python interpreter and than is used to run Python scripts inside
Avogadro), it’s possible to use Python-like constructions in C++ code
using Boost.Python library
I don’t like to code in
c++ but really like Python. I would like to add new features in
Kalzium using Python and not c++…
What about real python coding, it’s possible to write plugins for
Avogadro which can be tools, engines or extensions. See Avogadro
website for more information. However, if you want to use Python in
some action which are not directly related to GLWidget, python API of
Avogadro will not help you (learn PyQt4, Kross, Boost.Python or
something else)
Why I asked you about Python. I do some work on changing of
binding-related API of Avogadro (branch python_separation) to make it
language-independent (I hope it’ll allow to add Kross interface and
maybe other language bindings in future). There are some other
benefits: if you don’t need Python in your application and only need
fast lightweight Qt widget to display molecule, your application won’t
depend on python-related libraries anyway.
If suddenly this change would be accepted by others, existing Python
scripts will not be affected, but clients (applications which uses
GLWidget) will have to use “script*” headers instead of “python*” ones
to handle script-related signals. Don’t worry about 1.0.x branch
though, it’ll not change API and ABI anyway
–
Regards,
Konstantin