On Fri, Mar 4, 2011 at 9:57 AM, Konstantin Tokarev annulen@yandex.ru wrote:
04.03.2011, 17:49, “Marcus D. Hanwell” mhanwell@gmail.com:
On Fri, Mar 4, 2011 at 9:43 AM, Konstantin Tokarev annulen@yandex.ru; wrote:
04.03.2011, 17:23, “Marcus D. Hanwell” mhanwell@gmail.com;:
On Wed, Mar 2, 2011 at 12:19 PM, Mickaël Gadroy
mickael.gadroy@gmail.com;; wrote:
Hi,
I would like to use the Avogadro plugin path in /home/[user]/.avogadro/ .
But I do not find them. They do not create by default (except for the
python plugins). I currently realize my test in /user/local/lib/avogadro.
What are the paths for each plugin ?
This is simply a location we scan for valid plugins. I will see about
adding the option to use user locations to the CMake code. I have
never used the avopkg stuff, and you can certainly do everything you
need by building a dependent project (like the simple wire engine or
the VTK extension) and placing the resultant .so in the right
location.
You just do
make manifest
make package
make package_install
and .so will be placed to right directory.
I would rather just do,
make
make install
Avopkg allows you to install plugins to $HOME when run as user
and to Avogadro plugin directory when run as root.
Avopkg allow you to distinguish plugin types and install them into
proper places.
Avopkg allows you to package and install Python plugins properly
Sounds like CMake can do all but distinguish between user and root.
Like I said, there is more than one way to do this. I was pointing out
the method I use which I find to be very efficient and have used
successfully since well before this was added.
Does it even work on Windows? I develop on all three platforms, and so
expect my tools to work on all three.
Marcus
Sounds like CMake can do all but distinguish between user and root.
Like I said, there is more than one way to do this. I was pointing out
the method I use which I find to be very efficient and have used
successfully since well before this was added.
Does it even work on Windows? I develop on all three platforms, and so
expect my tools to work on all three.
No, it does not (at least out of the box, because it needs POSIX shell).
But Windows have simpler layout of plugin directories - we don’t load
anything from user’s “home”. So plugin installation is easier and could
be done e.g. with installer reading Avogadro location from registry.
Of course, it’s not too difficult to rewrite avopkg in CMake, Qt, or Python.
I’ve chosen sh because when it had only basic features its implementation
was very straightforward (you may find it in 1.0 branch), probably more
straightforward than with other possible tools. But when more features
creeped in it became much more complicated.
–
Regards,
Konstantin
Hi Mickaël,
Sorry for confusion, you need to run “make install” to get your plugin
working, just as Marcus advised.
–
Regards,
Konstantin
I don’t understand where/when to realise “make install”.
Currently, I have a cmake file which build a plugin (“cmake” then “make”, no
“make install”) (independent of the Avogadro installation process), then I
copy it in the plugin directory.
So when you speak to do “make install”, I don’t see if it is in the use of
avopkg or the avogadro installation process ?
Regards,
Mickaël Gadroy
2011/3/4 Konstantin Tokarev annulen@yandex.ru
Hi Mickaël,
Sorry for confusion, you need to run “make install” to get your plugin
working, just as Marcus advised.
–
Regards,
Konstantin
Hi,
On Wed, May 30, 2012 at 05:46:32AM -0700, SourceForge.net wrote:
One idea: If you run from the build directory, the extension won’t work
because it expects the crystal database to be in its installed location.
Well, it /will/ work - just not like intended. I get dropped to the
current working directory from where I started avogadro (same for the
fragment inserter I guess).
I think in this case, the treeview should be either empty (possibly
displaying some helpful message that the relevant data files could not
be found instead), or the menu item should be greyed out/not exist at
all.
Michael
On Wed, May 30, 2012 at 9:19 AM, Michael Banck mbanck@gmx.net wrote:
On Wed, May 30, 2012 at 05:46:32AM -0700, SourceForge.net wrote:
One idea: If you run from the build directory, the extension won’t work
because it expects the crystal database to be in its installed location.
Well, it /will/ work - just not like intended. I get dropped to the
current working directory from where I started avogadro (same for the
fragment inserter I guess).
I think in this case, the treeview should be either empty (possibly
displaying some helpful message that the relevant data files could not
be found instead), or the menu item should be greyed out/not exist at
all.
Or, it wouldn’t be to hard to add a variable to a configured header so that
the extension could look in the source tree if the installed location
doesn’t exist. Geoff would know more about the extension, lets see what he
thinks.
Dave
On Wed, May 30, 2012 at 09:24:39AM -0400, David Lonie wrote:
On Wed, May 30, 2012 at 9:19 AM, Michael Banck mbanck@gmx.net wrote:
On Wed, May 30, 2012 at 05:46:32AM -0700, SourceForge.net wrote:
One idea: If you run from the build directory, the extension won’t work
because it expects the crystal database to be in its installed location.
Well, it /will/ work - just not like intended. I get dropped to the
current working directory from where I started avogadro (same for the
fragment inserter I guess).
I think in this case, the treeview should be either empty (possibly
displaying some helpful message that the relevant data files could not
be found instead), or the menu item should be greyed out/not exist at
all.
Or, it wouldn’t be to hard to add a variable to a configured header so that
the extension could look in the source tree if the installed location
doesn’t exist. Geoff would know more about the extension, lets see what he
thinks.
Sure, though in my case, I just didn’t know of the new functionality and
forgot to add the crystals/ directory to the avogadro-data package - I
didn’t actually test avogadro on the same box I had the source tree on,
but with test packages.
Michael
(replying here again cause I think it is a more fundamental issue)
On Wed, May 30, 2012 at 06:26:40AM -0700, SourceForge.net wrote:
You’re right – it’s a dead menu item, the extension launches itself
automatically, as needed.
I think the menu item is useful, in case the user closes the MO dockwidget
and wants to bring it back, but it should be disabled otherwise. I’ll put
this on my TODO list.
Note that right now, closing the dock widget and activating the
Extensions menu item does not bring back the dock widget, either.
A similar problem exists for the “Vibrations” dock widgets, though there
is no menu item in the Extensions menu for it at all.
Even worse, closing the dock widgets and adding them again via
Settings->Toolbars just yields empty dock widgets. So I guess currently
the user has to close and reopen Avogadro (or the QC output file) to get
back the dialogs, unless I am missing something.
Michael
On Wed, May 30, 2012 at 9:57 AM, Michael Banck mbanck@gmx.net wrote:
(replying here again cause I think it is a more fundamental issue)
On Wed, May 30, 2012 at 06:26:40AM -0700, SourceForge.net wrote:
You’re right – it’s a dead menu item, the extension launches itself
automatically, as needed.
I think the menu item is useful, in case the user closes the MO
dockwidget
and wants to bring it back, but it should be disabled otherwise. I’ll put
this on my TODO list.
Note that right now, closing the dock widget and activating the
Extensions menu item does not bring back the dock widget, either.
A similar problem exists for the “Vibrations” dock widgets, though there
is no menu item in the Extensions menu for it at all.
Even worse, closing the dock widgets and adding them again via
Settings->Toolbars just yields empty dock widgets. So I guess currently
the user has to close and reopen Avogadro (or the QC output file) to get
back the dialogs, unless I am missing something.
I think your observations are correct. I’ll look into cleaning this up when
I have some time.
On May 30, 2012, at 9:24 AM, David Lonie wrote:
I think in this case, the treeview should be either empty (possibly
displaying some helpful message that the relevant data files could not
be found instead), or the menu item should be greyed out/not exist at
all.
I’ll look into this. Naturally, there’s a similar issue with the fragments code, and shortly the polymer builder as well.
Or, it wouldn’t be to hard to add a variable to a configured header so that the extension could look in the source tree if the installed location doesn’t exist. Geoff would know more about the extension, lets see what he thinks.
I think both things are important – disable the menu item when no files are available. My concern about the source tree is knowing where that is. I’m not sure I want to compile-in the source directory. Should I know that it was compiled by /home/mbanck/avogadro/… ?
-Geoff
On Wed, May 30, 2012 at 10:40 AM, Geoffrey Hutchison <
geoff.hutchison@gmail.com> wrote:
On May 30, 2012, at 9:24 AM, David Lonie wrote:
Or, it wouldn’t be to hard to add a variable to a configured header so
that the extension could look in the source tree if the installed location
doesn’t exist. Geoff would know more about the extension, lets see what he
thinks.
I think both things are important – disable the menu item when no files
are available. My concern about the source tree is knowing where that is.
I’m not sure I want to compile-in the source directory. Should I know that
it was compiled by /home/mbanck/avogadro/… ?
I don’t think it would hurt. In my case, I rarely install avogadro and only
run it from my build directory. It would be nice to be able to use these
extensions without additional work, but I know this is also an unusual use
case 
Dave
On Wed, May 30, 2012 at 10:40:31AM -0400, Geoffrey Hutchison wrote:
I think both things are important – disable the menu item when no
files are available. My concern about the source tree is knowing where
that is. I’m not sure I want to compile-in the source directory.
Should I know that it was compiled by /home/mbanck/avogadro/… ?
I guess it wouldn’t hurt, so long as it is just a fall-back that is
used if the data directory is not available and the source tree is
present, but it should not be exposed to GUI in any way otherwise.
Michael
On Wed, May 30, 2012 at 10:52 AM, Michael Banck mbanck@gmx.net wrote:
On Wed, May 30, 2012 at 10:40:31AM -0400, Geoffrey Hutchison wrote:
I think both things are important – disable the menu item when no
files are available. My concern about the source tree is knowing where
that is. I’m not sure I want to compile-in the source directory.
Should I know that it was compiled by /home/mbanck/avogadro/… ?
I guess it wouldn’t hurt, so long as it is just a fall-back that is
used if the data directory is not available and the source tree is
present, but it should not be exposed to GUI in any way otherwise.
We do this for the plugins etc already. I would like to find a way to
remove some of the burden from the developer of the plugin. We might
just want to add one function that gives a prefix for data directories
that can have a second entry for the build tree. We would have one
place to disable that second entry then for distros etc if they were
concerned about searching additional paths.
Marcus