Preparing for the Avogadro 1.0 release

Development
1

Hi,

As many of you already know, we are hoping to push out a 1.0 release
this Spring. I would like to solicit feedback on our to do page for 1.0
[1]. I would like you all to consider issues in this order of priority
for tasks that must be completed before a 1.0 release,

  • Stabilize the API so that people can develop against the Avogadro
    library.
  • Stabilize the ABI [2], i.e. no new virtuals, no new non-static data
    members etc.
  • Big interface changes - will break documentation efforts.
  • Staying as close to KDE library policy in our libs as possible [3].

There are a few things I need to work on. I was planning on renaming all
private headers to header_p.h to signify that they are private and
should not be exported/are not part of our API. Any classes that should
be exported should be included in the header list and their declaration
preceded by A_EXPORT, which ensures the right thing is done on various
platforms.

I have been doing some work with a GLSL painter and will be making some
changes to the Painter (and derived) class. I will also be adding some
stub virtual functions intended for future use. Remember, only exported
classes/symbols that form part of our API/ABI need this attention. That
means that none of the plugins are affected, but the Plugin, Engine,
Tool, Color and Extension classes are for example. Also derived classes
where we extensively call the base class such as Primitive, Painter,
PainterDevice…

I would like to prioritize all work that needs to be completed before we
freeze our API/ABI. Large interface changes, such as the changes Geoff
has planned for the tools, will also need to be completed before 1.0. I
am most of the way through porting Kalzium to use the latest Avogadro
library, along with finishing off the Kompound application. These should
both exercise our API a little to ensure it copes well with being used
as a library. I will try to add Kompound to the playground KDE repo as
soon as I can so others can take a look at that too.

Any other thoughts as we push toward the release of 1.0? I think we are
in good shape, although there are a few things I would like to figure
out before committing to some parts of our API/ABI.

Thanks,

Marcus

[1] http://avogadro.openmolecules.net/wiki/To_Do_For_1.0
[2]
http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
[3] http://techbase.kde.org/Policies/Library_Code_Policy

2

Hi Marcus.

First of all, I would like to know if you are definitively moving to
Qt4.5. I have been unable to build from github for over a week
and finally moved to 4.5 last night. Build smooth and a quick tour
revealed nothing odd. But.

Before 1.0 release, it would be nice to correct Supercell Builder
and/or Cartesian editor to correct a misbehavior I have already
mentioned: coordinates are incorrect after, for instance, doubling
the unit cell on some direction : three molecules appear in
the editor, two of them identical; there seems to be a coordinate
update problem somewhere.

At present, my whish list is very short: there seems to be no
atom renumbering function in Draw tool. Simple to use (Molden
like). This is in my opinion important for some QM input file
setup. It would also be nice to be able to generate enantiomers
for molecules (perhaps by simply changing the sign of the
z coordinate in Cartesian editor?).
The last point is already on the TODO list: add a dummy atom
in the periodic table.

Very impressive advances so far!

Cheers,

Louis

Le 14 avr. 09 à 20:33, Marcus D. Hanwell a écrit :

Hi,

As many of you already know, we are hoping to push out a 1.0 release
this Spring. I would like to solicit feedback on our to do page for
1.0
[1]. I would like you all to consider issues in this order of priority
for tasks that must be completed before a 1.0 release,

  • Stabilize the API so that people can develop against the Avogadro
    library.
  • Stabilize the ABI [2], i.e. no new virtuals, no new non-static data
    members etc.
  • Big interface changes - will break documentation efforts.
  • Staying as close to KDE library policy in our libs as possible [3].

There are a few things I need to work on. I was planning on renaming
all
private headers to header_p.h to signify that they are private and
should not be exported/are not part of our API. Any classes that
should
be exported should be included in the header list and their
declaration
preceded by A_EXPORT, which ensures the right thing is done on various
platforms.

I have been doing some work with a GLSL painter and will be making
some
changes to the Painter (and derived) class. I will also be adding some
stub virtual functions intended for future use. Remember, only
exported
classes/symbols that form part of our API/ABI need this attention.
That
means that none of the plugins are affected, but the Plugin, Engine,
Tool, Color and Extension classes are for example. Also derived
classes
where we extensively call the base class such as Primitive, Painter,
PainterDevice…

I would like to prioritize all work that needs to be completed
before we
freeze our API/ABI. Large interface changes, such as the changes Geoff
has planned for the tools, will also need to be completed before
1.0. I
am most of the way through porting Kalzium to use the latest Avogadro
library, along with finishing off the Kompound application. These
should
both exercise our API a little to ensure it copes well with being used
as a library. I will try to add Kompound to the playground KDE repo as
soon as I can so others can take a look at that too.

Any other thoughts as we push toward the release of 1.0? I think we
are
in good shape, although there are a few things I would like to figure
out before committing to some parts of our API/ABI.

Thanks,

Marcus

[1] http://avogadro.openmolecules.net/wiki/To_Do_For_1.0
[2]
Policies/Binary Compatibility Issues With C++ - KDE TechBase
[3] Policies/Library Code Policy - KDE TechBase

This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com

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

3

Louis Ricard wrote:

Hi Marcus.

First of all, I would like to know if you are definitively moving to
Qt4.5. I have been unable to build from github for over a week
and finally moved to 4.5 last night. Build smooth and a quick tour
revealed nothing odd. But.

As far as I was aware some code was committed that used a new part of
the Qt API. That was worked around though and so 4.4 should still be OK.
Admittedly all my work is done using Qt 4.5 and we do intend to move to
it. Avogadro 1.0 will certainly depend upon Qt 4.5 but trunk should work
with 4.4 right now and through to the next release on 1 May.

Before 1.0 release, it would be nice to correct Supercell Builder
and/or Cartesian editor to correct a misbehavior I have already
mentioned: coordinates are incorrect after, for instance, doubling
the unit cell on some direction : three molecules appear in
the editor, two of them identical; there seems to be a coordinate
update problem somewhere.

I will look into that, I must have missed the report. I have been
working on the supercell code quite a bit and thought it was in good
shape. I have been working on really big systems though, and neglected
testing very small systems.

At present, my whish list is very short: there seems to be no
atom renumbering function in Draw tool. Simple to use (Molden
like). This is in my opinion important for some QM input file
setup. It would also be nice to be able to generate enantiomers
for molecules (perhaps by simply changing the sign of the
z coordinate in Cartesian editor?).
The last point is already on the TODO list: add a dummy atom
in the periodic table.

I was going to look at the periodic table, adding a dummy atom is no
problem and can already be done programatically. Enantiomers have not
been on my radar, seems very specific. Is it reasonable to make a
generic tool for something this specific? I can see how atom renumbering
is necessary for quite a few quantum codes, not sure on the best way to
accomplish this. I will think about it.

These things are much more on the side of interface rather that API/ABI.
I am far more concerned about API/ABI at this stage as we will be
committing to it for a considerable amount of time. If there are
problems with it we would have the choice of breaking it, working on a
2.0 much sooner than we would like, or working around it.

I will be working on polishing features and squashing bugs, so all bug
reports are appreciated. We should start marking blockers for 1.0 in
there somewhere too, along with prioritizing. In my opinion API/ABI must
be highest priority, crashers, interface and general bugs. It is far
easier to polish individual tools after 1.0 than to break API/ABI.

Very impressive advances so far!

Thanks. I hope that we can make an impressive 1.0 release in the near
future. In related news I have completed porting Kalzium to use the
latest Avogadro library in KDE trunk (will be released as part of KDE 4.3).

Thanks,

Marcus

4

Louis Ricard wrote:

Before 1.0 release, it would be nice to correct Supercell Builder
and/or Cartesian editor to correct a misbehavior I have already
mentioned: coordinates are incorrect after, for instance, doubling
the unit cell on some direction : three molecules appear in
the editor, two of them identical; there seems to be a coordinate
update problem somewhere.

I have corrected the duplicate atom problem and pushed it at least. I
could not find the bug report, and so have not closed anything. I will
look at the cartesian editor - probably listening to the wrong thing. So
at least this paragraph I should have fixed in another ten minutes :wink:

5

Hi.

Nice! I will give this more attention tomorrow, but looks OK.
By the way, I did not open a bug report, but adressed the list
directly. Should remember to avoid that in such intances.
Copy of previous mail, dated 04/08:
"Hi all.

Following the latest merge of “spectra extension”, I can no longer
build the trunk version. On MacosX and on Fedora (virtual machine).
I am quite puzzled. Changed dependencies?

I get the following error under both OS’s:
“[ 68%] Building CXX object libavogadro/src/extensions/CMakeFiles/
spectraextension.dir/spectradialog.cpp.o
/Users/ricard/git/avogadro/libavogadro/src/extensions/
spectradialog.cpp: In member function ‘void
Avogadro::SpectraDialog::writeSettings() const’:
/Users/ricard/git/avogadro/libavogadro/src/extensions/
spectradialog.cpp:331: error: no matching function for call to
‘QSettings::setValue(const char [7], const QHash<QString, QVariant>&)’
/Library/Frameworks/QtCore.framework/Headers/qsettings.h:159: note:
candidates are: void QSettings::setValue(const QString&, const
QVariant&)
/Users/ricard/git/avogadro/libavogadro/src/extensions/
spectradialog.cpp: In member function ‘void
Avogadro::SpectraDialog::readSettings()’:
/Users/ricard/git/avogadro/libavogadro/src/extensions/
spectradialog.cpp:350: error: ‘class QVariant’ has no member named
‘toHash’
make[2]: *** [libavogadro/src/extensions/CMakeFiles/
spectraextension.dir/spectradialog.cpp.o] Error 1
make[1]: *** [libavogadro/src/extensions/CMakeFiles/
spectraextension.dir/all] Error 2”

Any idea?

Cheers,

Louis"

Concerning enantiomers, not diastereomers, I agree this would be
a convenience function. Specefic need.

Louis

Le 16 avr. 09 à 19:15, Marcus D. Hanwell a écrit :

Louis Ricard wrote:

Before 1.0 release, it would be nice to correct Supercell Builder
and/or Cartesian editor to correct a misbehavior I have already
mentioned: coordinates are incorrect after, for instance, doubling
the unit cell on some direction : three molecules appear in
the editor, two of them identical; there seems to be a coordinate
update problem somewhere.

I have corrected the duplicate atom problem and pushed it at least. I
could not find the bug report, and so have not closed anything. I will
look at the cartesian editor - probably listening to the wrong
thing. So
at least this paragraph I should have fixed in another ten minutes :wink:

Stay on top of everything new and different, both inside and
around Java ™ technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p

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

6

On Thursday 16 April 2009 13:24:03 Louis Ricard wrote:

Copy of previous mail, dated 04/08:
"Hi all.

Following the latest merge of “spectra extension”, I can no longer
build the trunk version. On MacosX and on Fedora (virtual machine).
I am quite puzzled. Changed dependencies?"

Hrm, I thought I fixed that a few hours after you mailed that report. Can someone who still has Qt 4.4 confirm that the extension still won’t build? All the Qt 4.5 code should be gone…

Dave

7

On Thu, Apr 16, 2009 at 9:55 PM, David Lonie loniedavid@gmail.com wrote:

On Thursday 16 April 2009 13:24:03 Louis Ricard wrote:

Copy of previous mail, dated 04/08:
"Hi all.

Following the latest merge of “spectra extension”, I can no longer
build the trunk version. On MacosX and on Fedora (virtual machine).
I am quite puzzled. Changed dependencies?"

Hrm, I thought I fixed that a few hours after you mailed that report. Can someone who still has Qt 4.4 confirm that the extension still won’t build? All the Qt 4.5 code should be gone…

I still have 4.4 here and just pushed some minor changes to cryos’
repository make it compile again.

Dave

Stay on top of everything new and different, both inside and
around Java ™ technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p

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

8

On Tue, Apr 14, 2009 at 02:33:02PM -0400, Marcus D. Hanwell wrote:

As many of you already know, we are hoping to push out a 1.0 release
this Spring. I would like to solicit feedback on our to do page for 1.0
[1].

OK, so here is my feedback.

  1. I think the Avogadro GUI exposes too many implementation details.
    Libavogadro has tools, engines and extensions, and those are still very
    visable on the GUI (even though they might not be explicitely labelled
    like that). I think this is problematic due to the below reasons:

  2. Combination of Tools.

Tools are (apparently?) very destinct, each tool does its job, with the
notable exception of 3D rotation for some tools, e.g. when the user
drags on a position of the GL window in which the current tool has no
business.

It would maybe be good to rethink the Tools and group them into some
modes, like “select/navigate”, “measure/navigate” and “manipulate”.

I understand the Avogadro basically does not use modifier keys and that
this is probably a concious design choice (bad discoverability for
users?).

E.g. one could combine the navigate, select and measure tools by no
longer rotating around atoms if they are clicked, but selecting them and
maybe diverting the measure tool to a dialog which gets updated when
atoms get (de)selected.

Manipulate and Bond Centric Manipulate could maybe merged into one tool,
the former acts on atoms, the latter mostly on bonds.

  1. Screen Real Estate.

Most tools or engines have no options (or at least have sensible default
options few users might want to change), yet the Tools widget takes
quite some screen real-estate. Just undocking or hiding the Tools
widgets does not help. If I start with a clean avogadro config, the
Tools and Display Types widgets take more than a third of the Avogadro
window.

The Toolbar just repeats the File menu and takes more screen space, I
almost never use it compared to its size.

If you combine the two above paragraphs, the easy solution would be:
Move the most important Tools into the Toolbar, move their configuration
to some configuration dialog and the more obscure tools into some menu
entries and remove the Tools widget entirely.

Important options (like which atom to draw, or which selection type)
could maybe be implemented as pop-up selectors next to the toolbar icon
(like zoom factor or font type in word processors)

Other options (like all the AutoOpt options) e.g. could be moved to some
preferences.

Then there will be things like AutoRotate or Align left, which, while
certainly worthwhile to have, could have their own menu entry and maybe
dialog window.

  1. Engines

Why can I add/remove engines? Why can I duplicate engines? What is the
Objects tab in the Settings supposed to do?

I never used (or felt I should use) any of the above, so maybe their
functionality should either be better explained, or be moved away from
the main GUI.

Note that due to the Add/Duplicate/Remove buttons, one cannot shrink the
Engines widget so that no empty is behind the engine names.

  1. Work-Flow.

Due to the split between extensions and engines, currently displaying
molecular orbitals is quite difficult.

You have to select and calculate the MO in the Cube tab, then calculate
the mesh in the Isosurface dialog, and then possibly switch between
different orbitals in the Orbital engine’s settings.

On the other hand, vibrations are currently directly visualized via the
vibration extension, and the Forces engine is just an on/off switch.

These are my comments, I am aware that most of them might not be
feasable to have due to early design decisions and/or differing
opinions,but I wanted to share them anyway because Avogadro is such an
awesome project.

cheers,

Michael

9

On Apr 21, 2009, at 1:54 PM, Michael Banck wrote:

It would maybe be good to rethink the Tools and group them into some
modes, like “select/navigate”, “measure/navigate” and “manipulate”.

I think there’s already interest, if not implementation, to do that.
As you mentioned, navigate features showed up in other tools.

I also have a student here, who wanted to have the manipulate tool add
an option to select a whole molecule or residue to move at once –
much like the select tool.

I understand the Avogadro basically does not use modifier keys and
that this is probably a concious design choice (bad discoverability
for users?)

It is a conscious design decision. Partly it’s discoverability. Partly
it’s being able to use Avogadro on a laptop or Mac with one button.

I think if you can figure out good ways to merge tools, people will be
receptive. I know Marcus and Tim have been focusing on adding
features, not necessarily improving UI. I like to improve the
interface, but haven’t had much time to code.

If you combine the two above paragraphs, the easy solution would be:
Move the most important Tools into the Toolbar, move their
configuration
to some configuration dialog and the more obscure tools into some menu
entries and remove the Tools widget entirely.

This is exactly something we’ve been discussing. But personally, I’d
let the user set which tools are in the toolbar via the Plugin
Manager. All loaded tools will be available into menu entries. And
then you can pull up the configuration dialog via menu command.

Important options (like which atom to draw, or which selection type)
could maybe be implemented as pop-up selectors next to the toolbar
icon
(like zoom factor or font type in word processors)

Interesting idea… It might be helpful to see a graphic mockup of
that feature. But pulling from a word processor is a nice idea. I know
Photoshop has moved towards having key tools available, plus a little
button to “drop down” the tool options widget.

Why can I add/remove engines? Why can I duplicate engines? What is
the
Objects tab in the Settings supposed to do?

These let you customize the rendering. For example, I can set the VdW
engine to only render the Fe atom in a Heme protein. Or I can pick
some atoms and render them with a “cloned” Balls and Sticks engine and
different settings.

Yes, this is a documentation issue. But if you have some good ideas
for the interface, they would be greatly appreciated. The underlying
rendering code is very flexible – but we haven’t known the best way
to expose that to the user!

Actually, if we move to a “drop down the settings widget” idea for the
toolbar, the engine settings can be moved there too – very much like
setting font styles in a word processor.

You have to select and calculate the MO in the Cube tab, then
calculate
the mesh in the Isosurface dialog, and then possibly switch between
different orbitals in the Orbital engine’s settings.

This UI is bad and we know it. Marcus and I have discussed a better
idea, but feedback is welcome. The orbitals extension now controls all
surfaces, so it’s also mis-named. But the point so far has been to get
the feature done, not make it pretty. That needs to happen now, before
1.0.

The extension should bring up a list dialog with a list of current
computed surfaces. You can add new surfaces, remove them from display,
or edit their options. Adding a surface will create the cube and
calculate the mesh in one dialog. Editing a surface will re-create the
mesh from the existing cube.

See the attached graphic and Designer idea for a quick mock-up.

Anyway Michael, you have hit upon the same interface areas which also
annoy me. Please continue to make suggestions!

Cheers,
-Geoff

10

Geoffrey Hutchison wrote:

On Apr 21, 2009, at 1:54 PM, Michael Banck wrote:

It would maybe be good to rethink the Tools and group them into some
modes, like “select/navigate”, “measure/navigate” and “manipulate”.

I think there’s already interest, if not implementation, to do that.
As you mentioned, navigate features showed up in other tools.

I also have a student here, who wanted to have the manipulate tool add
an option to select a whole molecule or residue to move at once –
much like the select tool.

I am certainly very interested in this area, but currently do not have
the time to spend on it.

I understand the Avogadro basically does not use modifier keys and
that this is probably a concious design choice (bad discoverability
for users?)

It is a conscious design decision. Partly it’s discoverability. Partly
it’s being able to use Avogadro on a laptop or Mac with one button.

I think if you can figure out good ways to merge tools, people will be
receptive. I know Marcus and Tim have been focusing on adding
features, not necessarily improving UI. I like to improve the
interface, but haven’t had much time to code.

I have been working much more under the hood recently, as well as some
work on Kalzium and the API. I have some ideas, and I think the
improvements I implemented where unused mouse clicks go to the navigate
tool both improved code reuse and the UI to some degree. This could be
taken further, but in many cases the tools themselves should possibly be
improved to become more diverse.

If you combine the two above paragraphs, the easy solution would be:
Move the most important Tools into the Toolbar, move their configuration
to some configuration dialog and the more obscure tools into some menu
entries and remove the Tools widget entirely.

This is exactly something we’ve been discussing. But personally, I’d
let the user set which tools are in the toolbar via the Plugin
Manager. All loaded tools will be available into menu entries. And
then you can pull up the configuration dialog via menu command.

I have had the opinion for a long time that some tools should be in the
menu, rather than constantly taking up screen space. It just does not
scale well as we add more tools. Some are specialized and rarely used
such as the align tool.

Why can I add/remove engines? Why can I duplicate engines? What is the
Objects tab in the Settings supposed to do?

These let you customize the rendering. For example, I can set the VdW
engine to only render the Fe atom in a Heme protein. Or I can pick
some atoms and render them with a “cloned” Balls and Sticks engine and
different settings.

Yes, this is a documentation issue. But if you have some good ideas
for the interface, they would be greatly appreciated. The underlying
rendering code is very flexible – but we haven’t known the best way
to expose that to the user!

Actually, if we move to a “drop down the settings widget” idea for the
toolbar, the engine settings can be moved there too – very much like
setting font styles in a word processor.

I wonder if this functionality is something that should be hidden away a
little more in an advanced engine configuration tool. Most users do not
use this feature, I have been exploring some alternate ways to present
these options to users in Kalzium. It is a great feature, and some
powerful renders can result from it. For most casual users it is
possibly overkill. Hence a move to an advanced extension/dialog might
help to improve our UI - opinions?

You have to select and calculate the MO in the Cube tab, then calculate
the mesh in the Isosurface dialog, and then possibly switch between
different orbitals in the Orbital engine’s settings.

This UI is bad and we know it. Marcus and I have discussed a better
idea, but feedback is welcome. The orbitals extension now controls all
surfaces, so it’s also mis-named. But the point so far has been to get
the feature done, not make it pretty. That needs to happen now, before
1.0.

I have been playing around with this, and it is on my pre-1.0 to do
list. I think the improved dialog I have in mind will be much
quicker/simpler to use and should be all 95% of people need. I was
planning on keeping some of the other features in an advanced pop up
dialog for the times we need it. I will try to get this out of the door
in the near future to solicit wider feedback. It is relatively simple
compared to the work that went into adding these features.

This grew as I coded it, and is actually worse than what we had in the
beginning in many ways. Although the underlying architecture is much
nicer. Watch this space :wink:

Thanks,

Marcus

11

On Tue, Apr 14, 2009 at 1:33 PM, Marcus D. Hanwell marcus@cryos.org wrote:

Hi,

As many of you already know, we are hoping to push out a 1.0 release
this Spring. I would like to solicit feedback on our to do page for 1.0
[1]. I would like you all to consider issues in this order of priority
for tasks that must be completed before a 1.0 release,

  • Stabilize the API so that people can develop against the Avogadro
    library.
  • Stabilize the ABI [2], i.e. no new virtuals, no new non-static data
    members etc.
  • Big interface changes - will break documentation efforts.
  • Staying as close to KDE library policy in our libs as possible [3].

I have a suggestion for another priority issue before the release that
is more of a documentation concern.

IMHO, I believe the windows compilation instructions should be
completely rewritten by someone who has successfully compiled on the
platform. As has been mentioned, we should expect a lot more testing,
feedback, bugs reports, etc. when 1.0 is released, and the reporters
will want to see results, and the devs will want the reporters to test
the changes quickly so bugs aren’t forgotten. Let’s face it: most
users will be on windows and can’t test changes using the current
instructions. If we are going to support Windows at all, it is
important that we do so fully, making things as easy as can be for
them.

I’ve tried using the installation instructions on the wiki to build in
windows several times and failed. I have no trouble in linux, and
while I don’t claim to be an expert, I would consider myself to be
representative of most linux devs, in terms of comfort level building
on windows. The problem here is that there are two main groups who
will be looking at the wiki:

  1. Linux users/devs who want to test their changes in windows, and
  2. Windows users who don’t have much (if any) experience or
    understanding of what is needed to compile a program.

Neither of the above groups is familiar with the windows workflow of
building, and especially the latter would need much clear instructions
then are presently given.

This is a frustrating matter, as I have committed code that was fine
in linux, but failed when the time came for a windows release due to
differences in compiler tolerance. This slows Marcus down when he’s
trying to get a release out the door by having to stop and debug my
code, when I could have tested the changes much sooner and fixed them
myself.

Another frustration is that if I want feedback from a windows user
between releases, I either have to tell them to wait a few weeks until
then next release (which makes for very slow fixes, especially when
the user loses interest during that time), or bother Marcus to make me
a new installer. While he’s generally willing and able to do it, I’d
like to have the ability to build a windows version myself without
taking time away from another dev’s work.

I believe that these are very good reasons to rewrite to instructions
so that they work with no confusion, no issues, etc. I’d be nice if a
dev who has been successful in compiling would sit down with a fresh
vm/install of windows, and go through things step by step, documenting
verbosely what they’re doing. Think gentoo installation handbook :slight_smile: It
shouldn’t take more than an afternoon, and would speed up workflow
when fielding bugs from windows users immensely. Many of the helper
scripts in avogadro/scripts need updating as well.

Another thought I’ve had would be to set up a box to build windows
installers nightly, although this would be frustrating when it breaks,
since bugs couldn’t be fixed right away…

Thoughts?

Dave

12

David Lonie wrote:

On Tue, Apr 14, 2009 at 1:33 PM, Marcus D. Hanwell marcus@cryos.org wrote:

Hi,

As many of you already know, we are hoping to push out a 1.0 release
this Spring. I would like to solicit feedback on our to do page for 1.0
[1]. I would like you all to consider issues in this order of priority
for tasks that must be completed before a 1.0 release,

  • Stabilize the API so that people can develop against the Avogadro
    library.
  • Stabilize the ABI [2], i.e. no new virtuals, no new non-static data
    members etc.
  • Big interface changes - will break documentation efforts.
  • Staying as close to KDE library policy in our libs as possible [3].

I have a suggestion for another priority issue before the release that
is more of a documentation concern.

IMHO, I believe the windows compilation instructions should be
completely rewritten by someone who has successfully compiled on the
platform. As has been mentioned, we should expect a lot more testing,
feedback, bugs reports, etc. when 1.0 is released, and the reporters
will want to see results, and the devs will want the reporters to test
the changes quickly so bugs aren’t forgotten. Let’s face it: most
users will be on windows and can’t test changes using the current
instructions. If we are going to support Windows at all, it is
important that we do so fully, making things as easy as can be for
them.

I honestly think our time would be better spent making nightly Windows
builds that interested users can try. Certainly improve the Windows
build documentation. This was rewritten by me and then Tim added in some
of the Python stuff. So it was recently rewritten by people who worked
on the build, but it could probably do with being revisited and made as
consistent as possible.

I do not think many users will ever compile Avogadro on Windows. They
will likely try a new binary if we make them available in some way. We
could also ensure that they have debug symbols once I read up on the
Windows C++ compiler a little more…

I’ve tried using the installation instructions on the wiki to build in
windows several times and failed. I have no trouble in linux, and
while I don’t claim to be an expert, I would consider myself to be
representative of most linux devs, in terms of comfort level building
on windows. The problem here is that there are two main groups who
will be looking at the wiki:

I think the better solution is getting regular CDash submissions for our
various architectures. We cannot expect all developers to test on
Windows, Windows x86_64, Linux, Linux x86_64 (random architecture), Mac
PPC, Mac x86 etc… The Git support is not there in CDash yet, but we
could cron it and at least run a git pull and CTest run with CDash
submission. I set a CDash page up for Avogadro. We just have not been
using it.

I can assure you that Windows was something that likely caused me some
hair loss when I took the time to improve our build system there. I am
still not done, just taking a break and regrouping!

Thanks,

Marcus

13

Hi all.

This is just a nightly thought, but I think Marcus is absolutely wright.
Only exceptionnally knowledgeable and motivated users will care to
compile under Windows. The drawback is that if they are really deceived
by crashes, lack of functionalities and so forth, they will never come
back.

So, taking time to polish a few issues may be more beneficial than lots
of more or less well describred issues from anonimous users and a
precipiticous 1.0 release.

This is a user point of view!

Cheers?

Louis

Le 22 avr. 09 à 19:00, Marcus D. Hanwell a écrit :

I do not think many users will ever compile Avogadro on Windows. They
will likely try a new binary if we make them available in some way. We
could also ensure that they have debug symbols once I read up on the
Windows C++ compiler a little more…

14

I honestly think our time would be better spent making nightly Windows
builds that interested users can try. Certainly improve the Windows
build documentation. This was rewritten by me and then Tim added in some
of the Python stuff. So it was recently rewritten by people who worked
on the build, but it could probably do with being revisited and made as
consistent as possible.
What would be necessary to facilitate that? Do we need a native Windows
box running somewhere or would be some cross compilation enough (I think
Fedore planned something afaik)?

Thanks,
Simon

15
  • Stabilize the API so that people can develop against the Avogadro
    library.
  • Stabilize the ABI [2], i.e. no new virtuals, no new non-static data
    members etc.
    …
    I have been doing some work with a GLSL painter and will be making
    some
    changes to the Painter (and derived) class. I will also be adding some
    stub virtual functions intended for future use.
    …
    [1] http://avogadro.openmolecules.net/wiki/To_Do_For_1.0

I think it would be good Marcus if you took a few minutes and pasted
in your “outline” for the 1.0 release into the wiki. Similarly, anyone
(Michael?) who has ideas they’d like to see in 1.0 should add them soon.

Then it’s easy to check off the items and know we’re done. :slight_smile:

As far as the API/ABI, I was talking with Marcus that the Painter is
something I see as really important. We need to add virtual functions
if we want to draw ellipsoids, planes, etc. So it’s good if we add
some “stubs” so we can implement these in 1.1 or 1.2 and not break
everyone’s binaries.

Another good question might be for Tim – can someone use libavogadro
in a purely Python/PyQt program? It would be good to have several
Python examples – not just plugins embedded into Avogadro, but
libavogadro embedded into Python.

Just my $0.02 – I need to get my To Do items done.
-Geoff

16

On Thu, Apr 23, 2009 at 4:39 PM, Geoffrey Hutchison
geoff.hutchison@gmail.com wrote:

  • Stabilize the API so that people can develop against the Avogadro
    library.
  • Stabilize the ABI [2], i.e. no new virtuals, no new non-static data
    members etc.

…

I have been doing some work with a GLSL painter and will be making some
changes to the Painter (and derived) class. I will also be adding some
stub virtual functions intended for future use.

…

[1] http://avogadro.openmolecules.net/wiki/To_Do_For_1.0

I think it would be good Marcus if you took a few minutes and pasted in your
“outline” for the 1.0 release into the wiki. Similarly, anyone (Michael?)
who has ideas they’d like to see in 1.0 should add them soon.

Then it’s easy to check off the items and know we’re done. :slight_smile:

As far as the API/ABI, I was talking with Marcus that the Painter is
something I see as really important. We need to add virtual functions if we
want to draw ellipsoids, planes, etc. So it’s good if we add some “stubs” so
we can implement these in 1.1 or 1.2 and not break everyone’s binaries.

Another good question might be for Tim – can someone use libavogadro in a
purely Python/PyQt program?

Yes, this is possible (on linux at least), I have examples of this.
I’m still compiling Qt 4.5 in my win XP VM but keep running out of
disk space :frowning: Does anyone have experience running VMWare with a VM
on an external USB2 HD? Is it fast enough?

It would be good to have several Python examples
– not just plugins embedded into Avogadro, but libavogadro embedded into
Python.

My first priority is to get the python build more automated. After
this I’ll look into making some more examples.

Just my $0.02 – I need to get my To Do items done.

I’ll add/update my items.

Tim

17

Simon Ochsenreither wrote:

I honestly think our time would be better spent making nightly Windows
builds that interested users can try. Certainly improve the Windows
build documentation. This was rewritten by me and then Tim added in some
of the Python stuff. So it was recently rewritten by people who worked
on the build, but it could probably do with being revisited and made as
consistent as possible.

What would be necessary to facilitate that? Do we need a native Windows
box running somewhere or would be some cross compilation enough (I think
Fedore planned something afaik)?

We need an instance of Windows with a development environment set up. A
VMWare or similar would be fine. Cross compilation wouldn’t really cut
it if we wanted to run the automated tests for the dash board too - need
a real Windows environment. I am looking at getting the environment set
up to automate this kind of thing - I am a little outside of my normal
environment but should be able to get something up and running.