KDE4 and Avogadro

Moin moin

I have got an idea about the “merge”. Currently the plan is that Avo depends
on OpenBabel and other libs, Kalzium (KDE4) depends on libavogadro.
Technically, we are already late in the game, because the first freeze is
already behind us, but I think we could do it in time (some weeks left).

Still, I am sure we all agree that there might be some bigger changes soon
(soon as in “before spring 2008”) which might introduce ABI/API-breakage
problems. If possible I would like Kalzium not to depend on version X of
libavogadro but of any libavogadro which is installed. This impliies a
API/ABI-freeze soon.

There is one very simple solution which of course has other disadvantages: We
could have a local copy of libavogadro in Kalzium
(trunk/kdeedu/kalzium/libavogadro/). Marcus develops features/bugfixes there
and merges it with the “real” libavogadro from time to time. The official
fixes are also going to be merged if possible.

When KDE 4.1 becomes trunk and KDE 4.0 is in branches/KDE/4.0/ we will remove
libavogadro from trunk and use the real avogadro. Until that point of time
(several month in the future) the API/ABI of libavogardo should be not only
better but also more stable so that the problems are (mostly) gone.
In case libavogadro breaks API lets say in January 2008 that is no problem at
all because no Kalzium using it is released. The KDE4.0 Kalzium will ignore
the API-change, the KDE 4.1 one will adopt to it.

The disadvantage is of course the merging which consumes time. Also, we won’t
be able to merge every change.

Another possibility: Technically we could even merge everything and adopt
Kalzium to it… Then the libavogadro in Kalzium would be a 100% copy of the
real one… We just wouldn’t have care about API/ABI breakage.

In short: The only real problem I see is to depend on a released libavogadro
when you still change API/ABI. As I think you should be able to break
API/ABI the local copy, even if it is a 100% copy of libavogadro, might be a
good option for us…

Carsten

Moin

I’d like to clear up some things:

KDE 4.x has to be API/API compatible and we expect the same for our libs. The
real issue is this possible situation:

libavo will have a API/ABI change in november 2007. By then KDE 4.0.0 is out.
With that change Kalzium 4.0.0 no longer works with a relased libavogadro. So
4.0.1 will have to be changed or would depend on an already outdated version.
That would force distros to ship old libraries or simply disable the 3D stuff
in Kalzium.

Another example: Konqeror of KDE 3.0.0 (2002) works on KDE 3.5.7 (2007). If it
doesn’t work that is a bug! Same for KMail 3.0.0 and so on…

Carsten

Moin

One more thought:

Say Kalzium 4.0.x depends on libavogadro 1.0.x
Then libavogadro changes its interface and calls itself 1.1 or 2.0. Then of
course Kalzium 4.1.x can depend on libavogadro 1.1/2.0. No issue. But Kalzium
4.0.x will always depend on 1.0.x.

The thing is there is no such thing as a released libavogadro… That is the
whole point of my discussion here. By having a local copy we circumvent all
problems and fix issues in libavogadro. By spring 2007 there will be a
working and released libavogadro 1.x and Kalzium 4.1.x will remove the local
copy of libavogadro and depend on 1.x.

Carsten

So, after a quick talk with Carsten on IRC, here’s my take:

Having a copy of libavogadro anywhere in /trunk/KDE would mean it’d be frozen
by June 1, so cryos couldn’t work on it anyway.

Having Kalzium 4.0 ported to libavogadro also means that in only 5 weeks, we
must:
– reach API/ABI stability in libavogadro
– complete the porting of Kalzium and finish related new Kalzium features.

If the Kalzium part needs at least 2 weeks, that leaves only 2-3 weeks for the
libavogadro API/ABI stability part. I guess that’s not enough! Especially
that part must not be rushed.

I think that the more reasonable choice is to postpone Kalzium porting to 4.1.

Thus,
– libavogadro can take its time to reach API/ABI stability: actually it has
another 6 monthes to do so,as far as Kalzium is concerned.
– cryos works in the main branch of libavogadro. His improvements will
appear in Kalzium 4.1, not 4.0.
– Kalzium 4.0 as it stands is already pretty good, and I’ll discuss with
Carsten what remains to be done there to give a good impression in 4.0.
– Kalzium 4.1, using libavogadro, will totally rock!!

Cheers,
Benoit

On Tuesday 24 April 2007 08:57:34 Carsten Niehaus wrote:

Moin moin

I have got an idea about the “merge”. Currently the plan is that Avo
depends on OpenBabel and other libs, Kalzium (KDE4) depends on libavogadro.
Technically, we are already late in the game, because the first freeze is
already behind us, but I think we could do it in time (some weeks left).

Still, I am sure we all agree that there might be some bigger changes soon
(soon as in “before spring 2008”) which might introduce ABI/API-breakage
problems. If possible I would like Kalzium not to depend on version X of
libavogadro but of any libavogadro which is installed. This impliies a
API/ABI-freeze soon.

There is one very simple solution which of course has other disadvantages:
We could have a local copy of libavogadro in Kalzium
(trunk/kdeedu/kalzium/libavogadro/). Marcus develops features/bugfixes
there and merges it with the “real” libavogadro from time to time. The
official fixes are also going to be merged if possible.

When KDE 4.1 becomes trunk and KDE 4.0 is in branches/KDE/4.0/ we will
remove libavogadro from trunk and use the real avogadro. Until that point
of time (several month in the future) the API/ABI of libavogardo should be
not only better but also more stable so that the problems are (mostly)
gone. In case libavogadro breaks API lets say in January 2008 that is no
problem at all because no Kalzium using it is released. The KDE4.0 Kalzium
will ignore the API-change, the KDE 4.1 one will adopt to it.

The disadvantage is of course the merging which consumes time. Also, we
won’t be able to merge every change.

Another possibility: Technically we could even merge everything and adopt
Kalzium to it… Then the libavogadro in Kalzium would be a 100% copy of
the real one… We just wouldn’t have care about API/ABI breakage.

In short: The only real problem I see is to depend on a released
libavogadro when you still change API/ABI. As I think you should be able
to break API/ABI the local copy, even if it is a 100% copy of libavogadro,
might be a good option for us…

Carsten

On Apr 24, 2007, at 4:44 AM, Benoît Jacob wrote:

Having a copy of libavogadro anywhere in /trunk/KDE would mean it’d
be frozen
by June 1, so cryos couldn’t work on it anyway.

Having Kalzium 4.0 ported to libavogadro also means that in only 5
weeks, we
must:

No, this is definitely the right approach. Actually, the KDE release
schedule is a little weird since it means a lot of KDE improvements
from the Summer of Code won’t make it into KDE 4.0.

The whole idea of Avogadro is that we should establish a stable API/
ABI relatively soon for the “core” and then most of the work is to
upgrade the plugins, adding new features. But I do agree that I don’t
expect the core API/ABI to be finished in time for the KDE 4.0 freeze.

Cheers,
-Geoff

P.S. Sorry, I was out of town this weekend. Looks like I missed a lot
of e-mail.

I was thinking this morning that I’m not going to have any gripe with
Kalzium using a copy of libavogadro. In fact, worst case, even 4.1 is a
copy of a newer version of libavogadro. The whole reason that we talked
about combining efforts was to share our code. How we share it is
irrelevant to me. However we do decide to do it i think that the SoC
should work on the libavogadro trunk (at sourceforge or if we decide to
move it to kdesupport wherever) and if we’re still not stable with
API/ABI by 4.1 just copy the new version of libavogadro.

I’m cool with waiting til 4.1 to port too.

I want to also say right now that I appreciate that you guys (carsten
and benoit) are working patiently with libavogadro and working with us
to collaborate even though it’s a little more work syncing and such.
Especially considering that we will reap equal benefits from the SoC as
you will because of it.

Out,
Donald

(Tue, Apr 24, 2007 at 10:44:27AM +0200) Benoît Jacob jacob@math.jussieu.fr:

So, after a quick talk with Carsten on IRC, here’s my take:

Having a copy of libavogadro anywhere in /trunk/KDE would mean it’d be frozen
by June 1, so cryos couldn’t work on it anyway.

Having Kalzium 4.0 ported to libavogadro also means that in only 5 weeks, we
must:
– reach API/ABI stability in libavogadro
– complete the porting of Kalzium and finish related new Kalzium features.

If the Kalzium part needs at least 2 weeks, that leaves only 2-3 weeks for the
libavogadro API/ABI stability part. I guess that’s not enough! Especially
that part must not be rushed.

I think that the more reasonable choice is to postpone Kalzium porting to 4.1.

Thus,
– libavogadro can take its time to reach API/ABI stability: actually it has
another 6 monthes to do so,as far as Kalzium is concerned.
– cryos works in the main branch of libavogadro. His improvements will
appear in Kalzium 4.1, not 4.0.
– Kalzium 4.0 as it stands is already pretty good, and I’ll discuss with
Carsten what remains to be done there to give a good impression in 4.0.
– Kalzium 4.1, using libavogadro, will totally rock!!

Cheers,
Benoit

On Tuesday 24 April 2007 08:57:34 Carsten Niehaus wrote:

Moin moin

I have got an idea about the “merge”. Currently the plan is that Avo
depends on OpenBabel and other libs, Kalzium (KDE4) depends on libavogadro.
Technically, we are already late in the game, because the first freeze is
already behind us, but I think we could do it in time (some weeks left).

Still, I am sure we all agree that there might be some bigger changes soon
(soon as in “before spring 2008”) which might introduce ABI/API-breakage
problems. If possible I would like Kalzium not to depend on version X of
libavogadro but of any libavogadro which is installed. This impliies a
API/ABI-freeze soon.

There is one very simple solution which of course has other disadvantages:
We could have a local copy of libavogadro in Kalzium
(trunk/kdeedu/kalzium/libavogadro/). Marcus develops features/bugfixes
there and merges it with the “real” libavogadro from time to time. The
official fixes are also going to be merged if possible.

When KDE 4.1 becomes trunk and KDE 4.0 is in branches/KDE/4.0/ we will
remove libavogadro from trunk and use the real avogadro. Until that point
of time (several month in the future) the API/ABI of libavogardo should be
not only better but also more stable so that the problems are (mostly)
gone. In case libavogadro breaks API lets say in January 2008 that is no
problem at all because no Kalzium using it is released. The KDE4.0 Kalzium
will ignore the API-change, the KDE 4.1 one will adopt to it.

The disadvantage is of course the merging which consumes time. Also, we
won’t be able to merge every change.

Another possibility: Technically we could even merge everything and adopt
Kalzium to it… Then the libavogadro in Kalzium would be a 100% copy of
the real one… We just wouldn’t have care about API/ABI breakage.

In short: The only real problem I see is to depend on a released
libavogadro when you still change API/ABI. As I think you should be able
to break API/ABI the local copy, even if it is a 100% copy of libavogadro,
might be a good option for us…

Carsten


This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

Am Dienstag, 24. April 2007 10:44:27 schrieb Benoît Jacob:

Having Kalzium 4.0 ported to libavogadro also means that in only 5 weeks,
we must:
– reach API/ABI stability in libavogadro

Wrong, that is only needed for kdelibs. As libavo would end up in
trunk/kdeedu/kalzium/avogadro this is not needed at all!

– complete the porting of Kalzium and finish related new Kalzium
features.

Features: yes. Finished porting: no.

Also, by defining features as bugfixes we might be able to “sneak in” some
features…

Carsten

Am Dienstag, 24. April 2007 17:52:43 schrieb Benoit Jacob:

I’m cool with waiting til 4.1 to port too.

So that’s settled, we’ll do the porting for 4.1 not 4.0.

It’s not at all a problem if some features are postponed to 4.1, because
4.0 will only be there for about 6 monthes, and will be regarded as quite
experimental. The 4.0 release schedule is very tight and many features
will have to be postponed to 4.1, so we’re not alone here.

Ok, I am also fine with this if Marcus is.

Carsten

On Tuesday 24 April 2007 19:14:45 Carsten Niehaus wrote:

Am Dienstag, 24. April 2007 17:52:43 schrieb Benoit Jacob:

I’m cool with waiting til 4.1 to port too.

So that’s settled, we’ll do the porting for 4.1 not 4.0.

It’s not at all a problem if some features are postponed to 4.1, because
4.0 will only be there for about 6 monthes, and will be regarded as quite
experimental. The 4.0 release schedule is very tight and many features
will have to be postponed to 4.1, so we’re not alone here.

Ok, I am also fine with this if Marcus is.

After chatting with you guys on IRC and reading all the posts here I totally
agree that this is the right approach. It is a shame the timing means most of
the work will not be visible until 4.1 but I think it will be worth the wait.

I would like to do what I can to help with kalzium in 4.0 too, so that I can
familiarise myself with the code a little more and the release process. That
said my focus will be on implementing the feature set outlined over the
summer and porting kalzium to use it for 4.1.

Marcus

On Apr 25, 2007, at 3:57 AM, Marcus D. Hanwell wrote:

After chatting with you guys on IRC and reading all the posts here
I totally
agree that this is the right approach. It is a shame the timing
means most of
the work will not be visible until 4.1 but I think it will be worth
the wait.

That’s not quite right. The generosity of KDE’s system is that you’re
working on a library which other apps can use (e.g., Avogadro,
maybe KryoMol). So even if the library isn’t in KDE4.0, other
applications may have releases. Who knows, maybe there’s an Avogadro
1.0 release in the fall or winter?

A really visible improvement to both Kalzium and libavogadro would be
the protein ribbon view. Some of your projects, like that, are easily
moved between Kalzium3D and libavogadro. So I think you could still
get in some flashy features into Kalzium 4.0.

Just my $0.02,
-Geoff

Anyway Marcus, Carsten and I chatted earlier today and we agreed on the
following solution, which I hadn’t thought of before:

Import as soon as possible an immature copy of libavogadro directly into
Kalzium, and port Kalzium to using it before the June 1 deadline.

Nobody would work on this copy of libavogadro – in particular, Marcus
would do his SoC on the main trunk of avogadro.

It’s just a way of:

  • bringing nice improvements to Kalzium for 4.0.
  • doing porting work that’ll make it much easier to port to the final
    libavogadro when it’s ready

It only requires us to sort out quickly the last things that have to be
added to libavogadro before it covers all what Kalzium3D used to do:
– global rendering-quality setting (influencing in particular the level
of detail of spheres)
– more rendering engines: sticksengine, vdwengine

Cheers,
Benoit

On Wed, 25 Apr 2007, Geoffrey Hutchison wrote:

On Apr 25, 2007, at 3:57 AM, Marcus D. Hanwell wrote:

After chatting with you guys on IRC and reading all the posts here
I totally
agree that this is the right approach. It is a shame the timing
means most of
the work will not be visible until 4.1 but I think it will be worth
the wait.

That’s not quite right. The generosity of KDE’s system is that you’re
working on a library which other apps can use (e.g., Avogadro,
maybe KryoMol). So even if the library isn’t in KDE4.0, other
applications may have releases. Who knows, maybe there’s an Avogadro
1.0 release in the fall or winter?

A really visible improvement to both Kalzium and libavogadro would be
the protein ribbon view. Some of your projects, like that, are easily
moved between Kalzium3D and libavogadro. So I think you could still
get in some flashy features into Kalzium 4.0.

Just my $0.02,
-Geoff


This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

On Apr 25, 2007, at 10:57 AM, Benoit Jacob wrote:

It only requires us to sort out quickly the last things that have
to be added to libavogadro before it covers all what Kalzium3D used
to do:
– global rendering-quality setting (influencing in particular the
level of detail of spheres)
– more rendering engines: sticksengine, vdwengine

Do we want “global” rendering quality? Maybe we should offer a few
hooks for each engine to set the rendering quality, and maybe a
callback so an engine can display an options window.

The last two are pretty easy. If we’ve decided that the engine
framework has settled down, I can probably “port” my old sticks and
vdw engines in a matter of a few hours. If Marcus wants to “pad” his
SoC resume, I think the code is still in SVN and I’ll focus on other
things.

Really, if you know the OpenGL code for what you want to draw, adding
an engine in Avogadro is great fun.

Cheers,
-Geoff

P.S. Sorry I’m not on IRC today or the rest of the week – I need to
get a grant proposal finished.

On Wednesday 25 April 2007 17:29:41 Geoffrey Hutchison wrote:

On Apr 25, 2007, at 10:57 AM, Benoit Jacob wrote:

It only requires us to sort out quickly the last things that have
to be added to libavogadro before it covers all what Kalzium3D used
to do:
– global rendering-quality setting (influencing in particular the
level of detail of spheres)
– more rendering engines: sticksengine, vdwengine

Do we want “global” rendering quality? Maybe we should offer a few
hooks for each engine to set the rendering quality,

A global quality-setting is what we want to expose in the Kalzium GUI, but I
agree that it’s not necessary to have it in libavogadro – it’d be easy to
let Kalzium offer the user a choice of global quality levels, and then
internally translate that into engine-specific settings to pass to
libavogadro.

and maybe a
callback so an engine can display an options window.

For Kalzium at least, that’s overkill. Then one can discuss whether this is
appropriate in more advanced apps like avogadro. But think of the usability
issues: if the user has to configure n times where n is the number of
engines, he’ll be unhappy. My take is that a global quality setting is enough
as long as we make it so that the settings are coherent across engines. In my
Kalzium experience, what matters is that we make sure that at any given
global quality level, all engines give the same visual quality. That means
that some engines will be slower and some faster. For instance VDW is slow
because the spheres are big, hence have more pixels and need higher
tesselations.

The last two are pretty easy. If we’ve decided that the engine
framework has settled down,

I see one more thing to do before that: include in the Engine API a function
returning the radius of the “enclosing” sphere of a given atom in a given
engine. This is the sphere that’s painted semi-transparent when the atom is
selected; it also can play a role in navigation and camera systems.

Cheers,
Benoit

This brings up an important point about render quality. The more i’ve
been thinking about it (and note that i’d like to get something out by
May 1st, at least something people can use to draw / optimize / output
GAMESS input decks and view simple) and do you think we should be
setting up something so that GLWidget’s actually use a subclases
QPainter?

QPainters rely on QPaintEngines to the do the low level rendering,
namely for each canvas type there are various PaintEngines that do the
actually drawing. We cannot subclass the QT4 QOpenGLPaintEngine as it
is internal. We could however subclass QPainters to allow Sphere and
Cylinder opertaions which bypass the internal QPainter unless it’s a 2d
primitive. I also don’t want to get to the point where Avogadro engines
have to strictly rely on our Painter subclass. We want to allow for
rendering power which means low level access to the GLWidget and also
knowing exactly the environment.

Regardless, in this same direction i think we should move Sphere and
Cylinder to a GLPainter class. Then we can have GLPainter class define
a quality setting. In the GLPainter class we initialize X different
qualities of Spheres and Cylinders based on the user settings. Then we
allow engines to make callse like GLPainter::drawSphere(x,y,z,r,d) where
d=detail level. This will be relative to the GLPainter’s own internal
detail setting. Too complex?

We can’t have our cake and eat it too i suppose. There are lots of
options i have in my head but sorting through them i have a hard time.

-Donald

(Wed, Apr 25, 2007 at 11:29:41AM -0400) Geoffrey Hutchison geoff.hutchison@gmail.com:

On Apr 25, 2007, at 10:57 AM, Benoit Jacob wrote:

It only requires us to sort out quickly the last things that have
to be added to libavogadro before it covers all what Kalzium3D used
to do:
– global rendering-quality setting (influencing in particular the
level of detail of spheres)
– more rendering engines: sticksengine, vdwengine

Do we want “global” rendering quality? Maybe we should offer a few
hooks for each engine to set the rendering quality, and maybe a
callback so an engine can display an options window.

The last two are pretty easy. If we’ve decided that the engine
framework has settled down, I can probably “port” my old sticks and
vdw engines in a matter of a few hours. If Marcus wants to “pad” his
SoC resume, I think the code is still in SVN and I’ll focus on other
things.

Really, if you know the OpenGL code for what you want to draw, adding
an engine in Avogadro is great fun.

Cheers,
-Geoff

P.S. Sorry I’m not on IRC today or the rest of the week – I need to
get a grant proposal finished.


This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

Your idea sounds great; I just have one question. If all we need is to be able
to do
drawSphere(x,y,z,r,d)
in the GLWidget, why not add this method directly to the GLWidget class, and
let the X objects of class Sphere live in GLWidgetPrivate?

I know I must be asking a stupid question, but understanding why it is
stupid will help me understand your idea better :slight_smile:

Also FYI i just computed how much memory the Sphere takes, making the
assumption that each GL command is encoded on 4 bytes in a display list where
it is compiled (in addition to its arguments, so glVertex3f and glNormal3f
would take 16 bytes each). Here’s the result:

  • The sphere of level of detail d takes 640(d^2+d) bytes.

Summing this for d=1,…,N, we see that

  • The spheres of levels of detail 1,…,N take (640/3)*(d^3+3d^2+2d) bytes.

Thus having all spheres of levels 1,…,9 takes 206 kB. I think that this is
very reasonnable for a high-quality mode. The Sphere of level of detail 9
alone takes 56 kB. Having spheres of level of detail 1,2,3,4,6,8 takes 96 kB.

For a low-quality mode, having spheres of levels 1,2,3,4 only takes 25 kB.

Cheers,
Benoit

On Thursday 26 April 2007 22:29:31 Donald Ephraim Curtis wrote:

This brings up an important point about render quality. The more i’ve
been thinking about it (and note that i’d like to get something out by
May 1st, at least something people can use to draw / optimize / output
GAMESS input decks and view simple) and do you think we should be
setting up something so that GLWidget’s actually use a subclases
QPainter?

QPainters rely on QPaintEngines to the do the low level rendering,
namely for each canvas type there are various PaintEngines that do the
actually drawing. We cannot subclass the QT4 QOpenGLPaintEngine as it
is internal. We could however subclass QPainters to allow Sphere and
Cylinder opertaions which bypass the internal QPainter unless it’s a 2d
primitive. I also don’t want to get to the point where Avogadro engines
have to strictly rely on our Painter subclass. We want to allow for
rendering power which means low level access to the GLWidget and also
knowing exactly the environment.

Regardless, in this same direction i think we should move Sphere and
Cylinder to a GLPainter class. Then we can have GLPainter class define
a quality setting. In the GLPainter class we initialize X different
qualities of Spheres and Cylinders based on the user settings. Then we
allow engines to make callse like GLPainter::drawSphere(x,y,z,r,d) where
d=detail level. This will be relative to the GLPainter’s own internal
detail setting. Too complex?

We can’t have our cake and eat it too i suppose. There are lots of
options i have in my head but sorting through them i have a hard time.

-Donald

I made a typo in the formula for spheres of levels 1,…,N. It should read as
follows (just replace d with N):

  • The spheres of levels of detail 1,…,N take (640/3)*(N^3+3N^2+2N) bytes.

On Friday 27 April 2007 08:04:08 Benoît Jacob wrote:

  • The spheres of levels of detail 1,…,N take (640/3)*(d^3+3d^2+2d) bytes.