I’m curious if we can allow some python scrips to have arbitrary
menuPath()s. This would make the scripts full equivalents to extensions.
Is there anything else I’m forgetting? Undo/redo for scripts?
I’m asking most for the 1.0 and post-1.1 todo list. I don’t think we’d
need any API change for this – it’s all inside the
pythonextension.cpp code.
-Geoff
Hi Geoff,
On Sun, Dec 21, 2008 at 11:49 PM, Geoffrey Hutchison
geoff.hutchison@gmail.com wrote:
I’m curious if we can allow some python scrips to have arbitrary
menuPath()s. This would make the scripts full equivalents to extensions.
Yes, this is on my todo list. I’ll probably split the current
pythonextension into a pythonextension with full Extension interface
and a python terminal extension.
Is there anything else I’m forgetting? Undo/redo for scripts?
Don’t think so…
I’m asking most for the 1.0 and post-1.1 todo list. I don’t think we’d need
any API change for this – it’s all inside the pythonextension.cpp code.
I’d like to have full python support for the next release and hope to
get this done tonight or tommorow. Once we have full python support we
could also provide extra features without having to build on all
platforms etc. For 1.x, we could also have a dialog where users can
download new python plugins from a repository. It might also be nice
to provide a way for users to share their python plugins…
Cheers,
Tim
I’m already impressed with how far you’ve taken the Python code. I
think it’s already really useful – for example, it’d be easy to write
a variety of extensions linking to GaussSum, QMForge, PyMol, MMTK,
Cinfony, etc. (A lot of Python chemistry tools!)
could also provide extra features without having to build on all
platforms etc. For 1.x, we could also have a dialog where users can
download new python plugins from a repository. It might also be nice
to provide a way for users to share their python plugins…
One way is to add a section to the SVN repository for plugins.
I’ve also seen a GitHub solution. The Mac text editor TextMate will
search GitHub for particular names (i.e., any GitHub project which
ends in tmbundle)
http://github.com/search?q=tmbundle&x=0&y=0
The nice thing about GitHub is that you can easily download a Zip or
Tar:
http://github.com/ghutchis/avogadro/zipball/master
Honestly, I’d lean towards the GitHub solution. It’s much more open,
since anyone can create an account and upload some code. I’d suggest
we go for requiring names which include something like:
Then each project should include description file we can download,
e.g. description.xml:
http://github.com/ghutchis/avogadro/raw/master/authors.xml
If this doesn’t make sense, I’ll just go create a simple avoextension
project to illustrate.
Cheers,
-Geoff
On Sunday 21 December 2008 20:12:53 Geoffrey Hutchison wrote:
I’m already impressed with how far you’ve taken the Python code. I
think it’s already really useful – for example, it’d be easy to write
a variety of extensions linking to GaussSum, QMForge, PyMol, MMTK,
Cinfony, etc. (A lot of Python chemistry tools!)
I would like to second that. I never imagined that you would get the Python
bindings into such great shape so quickly. I have a few things I have been
playing with locally that are looking pretty good. Also, the work you have
been doing pushing the Windows build forward with all the extra Python deps is
great.
could also provide extra features without having to build on all
platforms etc. For 1.x, we could also have a dialog where users can
download new python plugins from a repository. It might also be nice
to provide a way for users to share their python plugins…One way is to add a section to the SVN repository for plugins.
I’ve also seen a GitHub solution. The Mac text editor TextMate will
search GitHub for particular names (i.e., any GitHub project which
ends in tmbundle)
Repository search results · GitHubThe nice thing about GitHub is that you can easily download a Zip or
Tar:
http://github.com/ghutchis/avogadro/zipball/masterHonestly, I’d lean towards the GitHub solution. It’s much more open,
since anyone can create an account and upload some code. I’d suggest
we go for requiring names which include something like:
- avoextension
- avotool
- avoengine
- avocolor
etc.
I think that GitHub would be a great way to encourage new developers to get
involved. As Tim said I see nothing in our API stopping Python extensions
setting whatever menu path they want. So Python integration would be seamless,
to the point where you would probably need to check what was being loaded to
tell if it was a Python plugin or a native C++ plugin.
Python obviously has the great advantage of not needing compilation. Are there
security concerns with auto adding these things though? They effectively have
full access to your file system etc, and so it might be better to have some
kind of vetting before we add them to a list of plugins that are automatically
downloaded.
Still - great potential.
Thanks,
Marcus
On Dec 21, 2008, at 10:46 PM, Marcus D. Hanwell wrote:
Are there security concerns with auto adding these things though?
They effectively have full access to your file system etc, and so it
might be better to have some kind of vetting before we add them to a
list of plugins that are automatically downloaded.
I think we do need to talk with some security gurus about sandboxing.
IMHO, the way to go forward is to first start a “vetted” SVN
repository. In the meantime, we can investigate ways of securing
arbitrary scripts. I’ve seen enough programs that offer similar
features that there must be a reasonable way.
-Geoff