Ions in Avogadro

On Nov 4, 2009, at 11:04 AM, mhanwell@gmail.com wrote:

New extensions introduce new strings, and break any notion of a string
freeze to improve translation coverage.

The string freeze for 1.0 is definitely more like a “slush.” Well
beyond the date of the string freeze, there were any number of changes
which broke strings. And many of the bug-fixes for translations have
made minor breaks in the strings as well. Case in point, several UI
files were not properly translated, resulting in “untranslatable”
strings.

translators get time to work on it. There are numerous examples of
projects that support i18n and freeze their strings.

That’s true. But as a project, we have not been good about such things
for 1.0. I’m sure we’ll get better over time, but there were ~20 new
strings right before the release. So as the person handling
translations, I don’t see the level of commitment you suggest. Adding
plugins doesn’t affect the core code or the library.

There seems to be consensus behind a policy of 1.0.x introduces
nothing new. That’s fine, although I suggest we then remove the z-
matrix editor, since it is currently disabled by default and broken.
I’m happy to let Cryos strike the cartesian editor from the 1.0.x
branch for now, in favor of trunk.

Again, what is wrong with an unstable release series or nightly builds
that track head development.

I have nothing against it. I’d be happy to have nightly builds of both
stable and development trees. I’m already doing 1.0.x builds for Mac.
I would hope we could get some nightly Windows builds going.

But in all the previous discussions about releases and stable
branches, there was also no mention of a timeline. I think it’s
important that we can say “OK, the new cartesian editor will be
available in 1.2, which should be released in the Spring.” Otherwise,
it’s very frustrating – we’ve been in a development model where new
features are added each release, and now suddenly that appears to stop.

So I think it’s really important to make some timelines:

  • We’re going to focus hard on bug-fixes and documentation for the
    near future, for 1.0.1 and 1.0.2. New contributions will go into trunk.
  • We’ll open up a 1.1 development series in December, with an estimate
    on a new stable 1.2 release sometime in the summer of 2010.
  • Contributed plugins should go here for people to find and/or install.

Again, if you look at projects like KDE or even GCC, there’s a clear
timeline for contributors.

Just my $0.02.
-Geoff

Killer feature of new editor is a possibility to paste coordinates
from external source.

Do you think we could include this into the Paste command in
mainwindow.cpp? Right now the code is simply:
} else if ( mimeData->hasText() ) {
pasteFormat = conv.FindFormat( “xyz” );

   text = mimeData->text().toAscii();
 }

But couldn’t we add some code here to guess the type of coordinates
from the text? This way, we could fix a bug – paste only works on
“true” XYZ coordinates with an atomic symbol in the first column. (I
imagine this confuses many users.) I think your parseText method would
be perfect.

No new extension needed. No new strings needed. :slight_smile:

Right now, “Copy” in mainWindow adds the XYZ molecule format to the
text buffer. Do you think this works OK?

Cheers,
-Geoff

Do you think we could include this into the Paste command in
mainwindow.cpp? Right now the code is simply:
} else if ( mimeData->hasText() ) {
pasteFormat = conv.FindFormat( “xyz” );
text = mimeData->text().toAscii();
}
But couldn’t we add some code here to guess the type of coordinates
from the text? This way, we could fix a bug – paste only works on
“true” XYZ coordinates with an atomic symbol in the first column. (I
imagine this confuses many users.) I think your parseText method would
be perfect.

You will make Avogadro even more powerful, if pass clipboard content through OpenBabel before my function. This will greatly improve interoperability with other chemical software. For example, JChemPaint stores MDL MOL in text clipboard, MarvinSketch - 2D or 3D CML (readable in Avogadro from file).


Regards,
Konstantin

What method should be used to determine if Avogadro was linked with OpenBabel trunk? I’ve tried to do it BABEL_VERSION, but #if construction can’t compare version numbers such as 2.2.99. I’ve locally defined BABEL23, but it isn’t a good solution

Regards,
Konstantin

On Sun, Nov 22, 2009 at 11:52:44AM -0500, David C. Lonie wrote:

From: Konstantin Tokarev annulen@yandex.ru
Subject: [Avogadro-devel] Using OpenBabel trunk
Date: Sun, 22 Nov 2009 19:40:07 +0300

What method should be used to determine if Avogadro was linked with
OpenBabel trunk? I’ve tried to do it BABEL_VERSION, but #if
construction can’t compare version numbers such as 2.2.99. I’ve
locally defined BABEL23, but it isn’t a good solution

It should be possible to compare in the cmake file and then define
USING_OPENBABEL_TRUNK or similar, e.g.

if(OPENBABEL2_VERSION STREQUAL “2.2.99”)
add_definitions( -DUSING_OPENBABEL_TRUNK )
endif(OPENBABEL2_VERSION STREQUAL “2.2.99”)

Not sure how we want to handle this when trunk becomes 2.3.99,
though. I have some code to commit that needs trunk, too, so I’m quite
interested in how this plays out…

In the old days of autoconf, you would define a feature like
-DHAVE_FF_FOO, and then test for the precense of that feature/symbol in
the library to figure out whether you can use it or not.

Michael

On Nov 22, 2009, at 5:34 PM, Michael Banck wrote:

Not sure how we want to handle this when trunk becomes 2.3.99,
though. I have some code to commit that needs trunk, too, so I’m quite
interested in how this plays out…

In the old days of autoconf, you would define a feature like
-DHAVE_FF_FOO, and then test for the precense of that feature/symbol in
the library to figure out whether you can use it or not.

For now, it’s probably reasonable for Open Babel to output an “BABEL_API_VERSION” string.

But yes. CMake can test installed headers for particular features too. You could test, for example:

HAVE_OPENBABEL_UNIT_CELL

Cheers,
-Geoff

Hi,

On Sun, Nov 22, 2009 at 11:45 PM, David Lonie loniedavid@gmail.com wrote:

From: Konstantin Tokarev annulen@yandex.ru
Subject: Re: [Avogadro-devel] Using OpenBabel trunk
Date: Sun, 22 Nov 2009 21:24:05 +0300

Thanks for hint about cmake!

in CMakeLists.txt macro_ensure_version() is used to determine GCC version. So, for OB it should be used the next way:
macro_ensure_version(“2.2.99” “${OPENBABEL2_VERSION}” OPENBABEL_IS_NEWER_THAN_2_2_99)
but i’m not shure about existence of OPENBABEL2_VERSION
Or use pkg_check_modules?

All of that is set already in cmake/modules/FindOpenBabel2.cmake. I
just committed code that will set OPENBABEL_IS_NEWER_THAN_2_2_99 for
use with ifdefs – go ahead and pull either cryos or my master to get
this.

You could also check to make sure if some newly added header exists.
For example, here is the cmake code used in molsketch:

Check if we are using openbabel trunk… (graphsym.h is not in 2.2.x)

if (EXISTS {OPENBABEL2_INCLUDE_DIR}/openbabel/graphsym.h) message(STATUS "Found OpenBabel Trunk with graphsym.h") set(OPENBABEL2_TRUNK TRUE) # for use in cmake add_definitions(-DOPENBABEL2_TRUNK) # for use in code endif (EXISTS {OPENBABEL2_INCLUDE_DIR}/openbabel/graphsym.h)

Cheers,
Tim

I guess I can go ahead and port over my UV, CD, and DOS plotting now :smiley:

Dave


Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what’s new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

Bugs item #3000080, was opened at 2010-05-11 17:12
Message generated for change (Tracker Item Submitted) made by mr_grieves
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=835077&aid=3000080&group_id=165310

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mr_Grieves (mr_grieves)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fragment extension broken on windows

Initial Comment:
It seems that the path to fragments isn’t working as expected in windows. Rather than pointing to QCoreApplication::applicationDirPath() + “/…/share/avogadro/fragments”, it is showing QCoreApplication::applicationDirPath() + “/…/”.

This is with both the 1.0.0 and 1.0.1 releases.


You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=835077&aid=3000080&group_id=165310

Bugs item #3033154, was opened at 2010-07-22 17:21
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=835077&aid=3033154&group_id=165310

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash when creating surfaces

Initial Comment:
OS: Windows xp

I opened an output file of Qchem, using B3LYP-6-31++G*. When trying to create surfaces under the menu “extensions”, the program crashes. It happens to another output file generated using higher level calculation B3LYP 6-311++G*. But when I tried on an output file calculated using B3LYP-3-21G, I have no problem creating surfaces


You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=835077&aid=3033154&group_id=165310

Bugs item #3174124, was opened at 2011-02-06 08:40
Message generated for change (Tracker Item Submitted) made by littleboboy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=835077&aid=3174124&group_id=165310

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Balcaen John (littleboboy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Avogadro crash on start

Initial Comment:
Avogadro 1.0.1 is crashing on every start on a x86_64 arch when it’s build with thoses options passed on cmake:
cmake -DLIB_SUFFIX=64 -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_INSTALL_LIBDIR:PATH=/usr/lib64 -DCMAKE_MODULE_LINKER_FLAGS=“-Wl,–as-needed -Wl,-z,relro -Wl,-O1 -Wl,–build-id” -DDBUS_SERVICES_DIR=/usr/share/dbus-1/services -DDBUS_INTERFACES_DIR=/usr/share/dbus-1/interfaces %{?ENABLE_TESTS} -DENABLE_GLSL:BOOL=ON -DENABLE_PYTHON:BOOL=ON …/
except for the 3 last options others are used in the macro available for building avogadro on mandriva.
Removing the -DLIB_SUFFIX=64 allow me to launch the application without problem but in this case the library are not placed in /usr/lib64 as expected on x86_64

Attached is the backtrace of the crash

From the console i can read :
mikala@hatmehyt [~] % avogadro
QStackedLayout::setCurrentWidget: Widget 0x2b25630 not contained in stack
QGLTempContext: No GL capable X visuals available.
Erreur de segmentation
I’m using Qt 4.7.1, python 2.6.5, glew is 1.5.2, openbabel is 2.2.3 ,python-sip is 4.10.5, python-numpy is 1.4.1 & eigen is 2.0.9


You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=835077&aid=3174124&group_id=165310

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 ?
I also notice that each plugin path are not mentioned in the debug mode in
the launch of Avogadro :
"
[…]
Loading plugins: "/usr/local/bin/…/lib/avogadro/1_1"
Searching for plugins in "/usr/local/lib/avogadro/1_1"
Searching for plugins in "/usr/local/lib/avogadro/1_1/colors"
Searching for plugins in "/usr/local/lib/avogadro/1_1/engines"
Searching for plugins in "/usr/local/lib/avogadro/1_1/extensions"
Searching for plugins in “/usr/local/lib/avogadro/1_1/tools”

Loading plugins: “/home/myck/.avogadro/1_1/plugins”
[ Here, no noticed path ]
QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: Aucun
espace disponible sur le périphérique

QFileSystemWatcher: failed to add paths: /usr/local/share/avogadro/fragments
QStackedLayout::setCurrentWidget: Widget 0x2eaf6b0 not contained in stack
[…]
"

Regards,
Mickaël Gadroy

02.03.2011, 20:19, “Mickaël Gadroy” mickael.gadroy@gmail.com:

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 ?
I also notice that each plugin path are not mentioned in the debug mode in the launch of Avogadro :
"
[…]
Loading plugins: “/usr/local/bin/…/lib/avogadro/1_1”
Searching for plugins in “/usr/local/lib/avogadro/1_1”
Searching for plugins in “/usr/local/lib/avogadro/1_1/colors”
Searching for plugins in “/usr/local/lib/avogadro/1_1/engines”
Searching for plugins in “/usr/local/lib/avogadro/1_1/extensions”
Searching for plugins in “/usr/local/lib/avogadro/1_1/tools”

Loading plugins: “/home/myck/.avogadro/1_1/plugins”
[ Here, no noticed path ]
QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: Aucun espace disponible sur le périphérique

QFileSystemWatcher: failed to add paths: /usr/local/share/avogadro/fragments
QStackedLayout::setCurrentWidget: Widget 0x2eaf6b0 not contained in stack
[…]

You need to mkdir $HOME/.avogadro/1_1/plugins/ yourself and create directory
“colors”, “engines”, “extensions”, or “tools”, depending what kind of plugin you want
to install

BTW, you can use Avopkg [1] to automate this process. It is integrated into build system
for 3rd party plugins


Regards,
Konstantin

03.03.2011, 11:58, “Konstantin Tokarev” annulen@yandex.ru:

02.03.2011, 20:19, “Mickaël Gadroy” mickael.gadroy@gmail.com;:

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 ?
I also notice that each plugin path are not mentioned in the debug mode in the launch of Avogadro :
"
[…]
Loading plugins: “/usr/local/bin/…/lib/avogadro/1_1”
Searching for plugins in “/usr/local/lib/avogadro/1_1”
Searching for plugins in “/usr/local/lib/avogadro/1_1/colors”
Searching for plugins in “/usr/local/lib/avogadro/1_1/engines”
Searching for plugins in “/usr/local/lib/avogadro/1_1/extensions”
Searching for plugins in “/usr/local/lib/avogadro/1_1/tools”

Loading plugins: “/home/myck/.avogadro/1_1/plugins”
[ Here, no noticed path ]
QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: Aucun espace disponible sur le périphérique

QFileSystemWatcher: failed to add paths: /usr/local/share/avogadro/fragments
QStackedLayout::setCurrentWidget: Widget 0x2eaf6b0 not contained in stack
[…]

You need to mkdir $HOME/.avogadro/1_1/plugins/ yourself and create directory
“colors”, “engines”, “extensions”, or “tools”, depending what kind of plugin you want
to install

BTW, you can use Avopkg [1] to automate this process. It is integrated into build system
for 3rd party plugins

Sorry, I’ve forgotten the link:

[1] http://avogadro.openmolecules.net/wiki/Avopkg


Regards,
Konstantin

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.

Hope that helps.

Marcus

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.


Regards,
Konstantin

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

It is not necessary in my workflow, and I was pointing out the one I
employ. CMake can easily target the correct location, and for plugins
I am actively working on I have no need of any kind of packaging. I
usually don’t even do make install and simply run from the build
directory, but this is not currently possible with externally built
plugins.

Marcus

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” marcus.hanwell@kitware.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


Regards,
Konstantin