Changes in Avogadro master break linking in Kalzium

Development
41

The Mac dashboard is failing

Maybe something is wrong on build host (e.g., fresh clone is needed)?
Successful build of master on Mac was reported recently

That was a minor point, and I am not sure why, after taking the time to
reply to you at length, you chose to answer this one minor point and
ignore the rest.

The split you have done should be in a branch at best, destined for a 2.0
release. It is clear that you do not appreciate many of the points I have
made, or understand the API/ABI concerns raised multiple times. What
exactly does the split get Avogadro as a project? Is it worth the cost. I
will be clear and state that I do not think it is in isolation.

It is clear that you prefer the layout, but beyond that. Does it make
Avogadro scale to much larger molecules? Does it extend our feature set?
Does it make Avogadro easier to use? Does it introduce inconsistency? Does
it increase compilation time? Does it add extra complexity to the build
system? Does it break the build on Windows?

While I am not claiming that everything we did for 1.0 was perfect, it is
what it is. For you to come in after the release, and move everything
around with questionable gains is quite arrogant. Splitting Avogadro into
smaller pieces on its own is not worth breaking backwards compatibility. A
lack of response to a few emails in hundreds sent to the list does not
indicate acceptance.

The main Avogadro project should stick with the layout it had. This
refactoring should be moved to 2.0, but in all honesty I want to see some
bigger gains than this in a 2.0 release. Maintaining both layouts is not
reasonable in my honest opinion. If you want to do so, you should in a
branch. As you have already demonstrated, you can still build these mini
libraries and link to other Avogadro applications.

As a project we should be more careful about what gets merged. I have been
absent for some time, but I am not willing to squander all of our hard
work. The whole point of working towards a 1.0 release was to invest in
something we would stick with for a few years. We did that, and unless you
can demonstrate enormous gains then we should stick with it.

The KDE project invested in two Google Summer of Code projects for this,
Geoff and I worked together for two years. We have spoken at various
conferences, worked with others from academia and industry. Constant
refactoring is a distraction that does not have a big enough payout.

For a 2.0 this would be a reasonable change, it might have been for a 1.0.
Although even there I would have done it in a branch until the approach
proved worthwhile. We should be spending our time working on new features,
instead of needless refactoring because each of us wants things the way we
want them.

I intend to restore the previous structure. I hope you can respect that.
You can base a branch off of the current point in your repo. I will be
working in topic branches so that things are easier to merge, should you
choose to.

Thanks,

Marcus

42

The split you have done should be in a branch at best, destined for a 2.0
release. It is clear that you do not appreciate many of the points I have
made, or understand the API/ABI concerns raised multiple times. What
exactly does the split get Avogadro as a project? Is it worth the cost. I
will be clear and state that I do not think it is in isolation.

It will be more useful for developers who want to use widgets, provided by Avogadro, it their applications.
For example, look at qperiodictable application in bin. It looks very simple, but it is a bit more convenient than gelemental, because I don’t need to open/close windows with element properties to get them copied. I hope this library could be used by such projects as Molsketch, there’s no need to copy code from project to project

Next, go to plot widget. There’s nothing chemical in it, and much more people could use it (especially if it would be released under LGPL). It’s a bit better than original KPlotWidget, but still has a room for improvements, if more developers use it, maybe omebody else could contribute

If somebody tries to use GLWidget in his project, he will get feeling of bloatware. It’s unlikely that periodic table and plot widget are mandatory parts of GLWidget. But while library is monolithic, they will go to memory anyway

Another example: I want to make a standalone application of spectra extension with minimum extra effort. It could use libavogadro, but all it actually needs is AvogadroCore. And if I decide to add widget later (e.g., for interactive solving of spectra, but with widget layout very different from Avogadro’s), it will be loaded only if user presses certain button, thus keeping startup time and average memory usage smaller.

I cannot put here example of console application which could need AvogadroCore, but maybe somebody will be interested in it (it’s a bit more convenient than direct use of OB). Maybe somebody will be interested in use of AvogadroCore in application using another GUI toolkit than Qt, or in framebuffer application

So, while libavogadro layout maybe good for development “for Avogadro”, it’s far from perfect for development “with Avogadro”. 3rd party developer seeing name and size of libavogadro may think that it’s library containing everything needed for Avogadro. But he doesn’t want to re-create Avogadro, he want to build his own app, so development tools should be more function-oriented, e.g. AvogadroWidget. I think this new layout will be useful for Kalzium too (it’s single case I know which relates to development “with Avogadro”

While I am not claiming that everything we did for 1.0 was perfect, it is
what it is. For you to come in after the release, and move everything
around with questionable gains is quite arrogant. Splitting Avogadro into
smaller pieces on its own is not worth breaking backwards compatibility. A
lack of response to a few emails in hundreds sent to the list does not
indicate acceptance.

I also thought about it. If Avogadro was widely used, I think I would have already got several angry letters from developers

The main Avogadro project should stick with the layout it had. This
refactoring should be moved to 2.0, but in all honesty I want to see some
bigger gains than this in a 2.0 release. Maintaining both layouts is not
reasonable in my honest opinion.

As you wish. I think it would be reasonable to make possible building of plotwidget and periodictable in addition to monolithic libavogadro on request

As a project we should be more careful about what gets merged.

Note, that I didn’t merged anything to cryos/master, nor even insisted on it

I have been
absent for some time, but I am not willing to squander all of our hard
work. The whole point of working towards a 1.0 release was to invest in
something we would stick with for a few years. We did that, and unless you
can demonstrate enormous gains then we should stick with it.

The KDE project invested in two Google Summer of Code projects for this,
Geoff and I worked together for two years. We have spoken at various
conferences, worked with others from academia and industry. Constant
refactoring is a distraction that does not have a big enough payout.

Who talks about constant refactoring? I’m strictly against it

For a 2.0 this would be a reasonable change, it might have been for a 1.0.
Although even there I would have done it in a branch until the approach
proved worthwhile. We should be spending our time working on new features,
instead of needless refactoring because each of us wants things the way we
want them.

I intend to restore the previous structure. I hope you can respect that.

Ok. Are you sure keeping swith like ENABLE_MODULAR_LIBRARY is unreasonable?

–
Regards,
Konstantin

43

P.S. Rock solid ABI stable library is usually expected to be useful for development “with it”, not “for it”

44

That was a minor point, and I am not sure why, after taking the time to
reply to you at length, you chose to answer this one minor point and
ignore the rest.

Because the rest was already discussed

–
Regards,
Konstantin

45

It is clear that you do not appreciate many of the points I have
made, or understand the API/ABI concerns raised multiple times.

Of course, I cannot be right anywhere :slight_smile: You’re programmer, and I’m a dabbler :slight_smile:

–
Regards,
Konstantin

46

Kalzium is not yet released, so I could make some changes to help it
link. I don’t think it is acceptable to move existing symbols/API out
of the Avogadro library in general.

How Kalzium finds Avogadro? If it uses AvogadroUse.cmake, it could be
changed to link all modules by default. In combination with preserved
header structure it will provide both successful compilation and
linking, won’t it?

It’s not an advocacy of split in 1.x, but general thoughts. Correct me
if I’m wrong

Similar changes could be done in pkg-config and qmake integrations I’ve
added recently, so only those people who use another build system or
raw Makefile will need to take care of changes. Yes, symbols gone from
one library to another but it’s not actually visible in average case.

–
Regards,
Konstantin

47

For KDE I can maintain a 1.y line, with minimal releases for bug
fixes and occasional backported features.

I think it won’t be difficult to backport extensions from 2.y to 1.y,
escpecially those that don’t do any rendering. If we’ll release stable
1.2.x, it could live fairly long with backports, if KDE will require it.

Also, some kind of backporting is possible right now - if new extension
doesn’t require OB trunk, it could be compiled against 1.0.x and
released as avopkg package or as self-installer for Windows

At some point we bump the
KDE requirement, and port the code to use 2.y. So Kalzium is not a
blocker, but that community helped us a lot early on, and I want to
make sure their interests are also taken care of.

Thanks,

Marcus

–
Regards,
Konstantin

48

OK, I didn’t really check e-mail this weekend.

I’d like to see if we can wrap up this discussion and come to some consensus. As far as I can tell, it seems there’s two possible solutions.

  • One, a CMake option that will build the 1.0-style libavogadro. (This will likely require some namespace fixes.)
  • A long-lived Git branch for Konstantin with the modular libraries, which can be merged for 2.0.

It will be more useful for developers who want to use widgets, provided by Avogadro, it their applications.

I think what Marcus is saying here is “that’s fine, they can take the code – it’s open source.” But we also aim to be a “big time project” and allow developers to use our widgets and libraries. Keeping stable libraries is HARD. I can tell you from experience. OB has a constant API and while it’s far from perfect, at least people know they can rely on it not breaking for 8 years or whatever it’s been. I shudder every time OB breaks ABI for other projects.

So this takes discipline as a project. OB sometimes has to hold off on good changes because they’ll break other people’s code. That’s definitely one goal we’ve had for Avogadro – that the API and ABI can be fairly solid.

For example, look at qperiodictable application in bin. It looks very simple, but it is a bit more convenient than gelemental, because I don’t need to open/close windows with element properties to get them copied. I hope this library could be used by such projects as Molsketch, there’s no need to copy code from project to project

True, and this is good. But there’s also nothing which says Avogadro 1.x needs to host that particular repository. It could also live in its own Git repo and Molsketch, Avogadro, and Kalzium (or others) can pull from it.

As a project we should be more careful about what gets merged.
Note, that I didn’t merged anything to cryos/master, nor even insisted on it

No, that’s my fault. See, on Mac, I don’t care about API or ABI breaks, because either people compile from source, or use the pre-built binary, where everything is encapsulated.

There have also been a lot of good commits from you, and these are clearly worth merging. Obviously, you’ve been pushing the project forward, which is a good goal.

In summary… Let’s work out the libavogadro issue and get back to more pressing issues – like getting some 1.1 releases going again!

-Geoff

49

On Mon, May 24, 2010 at 11:12 AM, Geoffrey Hutchison
geoff.hutchison@gmail.com wrote:

In summary… Let’s work out the libavogadro issue and get back to more pressing issues – like getting some 1.1 releases going again!

I want to chime in and share my thoughts on this as well. I think
Marcus’s suggestion of topic branches would make things much easier.
Konstantin has been using his github fork as a “sandbox”, and that’s
absolutely ok. As he mentioned, he never put the changes into
cryos/master – that was either Geoff’s or my own fault:

It is difficult to go through and cherry-pick dozens of commits that I
didn’t make in order to bring in a new feature from someone else’s
branch. I get a pull request with a list of new features, and when I
compare histories there are lots and lots of commits – I really don’t
know which are ok and which aren’t, so I either scan the changes just
to make sure there is nothing crazy going on and pull everything, or
(more likely) put it off for a “later time” that never comes. Even if
I had a specific list of the commits to pull – this would be a marked
improvement, but still a PITA – git only lets me cherry-pick one at a
time. It would simplify things and avoid problems by developing in
branches. And with git’s cheap branching, why not? :slight_smile:

I think there are some major misunderstandings here – Konstantin has
some good ideas and is willing to do the work to implement them, and I
don’t want to discourage his work. Marcus did spend a lot of time and
effort into creating and mantaining a stable API/ABI. These should
NEVER break between major releases, end of story – I’d really like to
stop hearing arguments about that. It may not seem a big deal, but
nobody likes trying to code against a moving target. Marcus packaged
for Gentoo for years, and Jordan has worked with Kubuntu for a long
time – as a result both are very familiar with bad upstream practices
and how much time it wastes. However, Konstantin does not have write
access to cryos/master AFAIK, so anything of his that breaks Kalzium
etc is certainly not his doing. I agree that developing in topic
branches and mantaining long-term development/legacy branches would be
the best solution to most of these problems.

BTW, there was a lot of effort put into making 1.0 stable – why is
Kalzium using master?

Dave

50

On Mon, May 24, 2010 at 11:12 AM, Geoffrey Hutchison
geoff.hutchison@gmail.com wrote:

In summary… Let’s work out the libavogadro issue and get back to more
pressing issues – like getting some 1.1 releases going again!

I want to chime in and share my thoughts on this as well. I think
Marcus’s suggestion of topic branches would make things much easier.
Konstantin has been using his github fork as a “sandbox”, and that’s
absolutely ok. As he mentioned, he never put the changes into
cryos/master – that was either Geoff’s or my own fault:

It is difficult to go through and cherry-pick dozens of commits that I
didn’t make in order to bring in a new feature from someone else’s
branch. I get a pull request with a list of new features, and when I
compare histories there are lots and lots of commits – I really don’t
know which are ok and which aren’t, so I either scan the changes just
to make sure there is nothing crazy going on and pull everything, or
(more likely) put it off for a “later time” that never comes. Even if
I had a specific list of the commits to pull – this would be a marked
improvement, but still a PITA – git only lets me cherry-pick one at a
time. It would simplify things and avoid problems by developing in
branches. And with git’s cheap branching, why not? :slight_smile:

Read man gitworkflows, think about it and then hopefully see the power
there. It is the workflow used by many projects, and makes maintaining
stable releases that land features when ready possible. I think, among
others, the Linux kernel follow something like this too. It would allow me
and others to merge in specific topic branches when they are ready,
rather than dragging in multiple fixes (some good, some not).

I think there are some major misunderstandings here – Konstantin has
some good ideas and is willing to do the work to implement them, and I
don’t want to discourage his work. Marcus did spend a lot of time and
effort into creating and mantaining a stable API/ABI. These should
NEVER break between major releases, end of story – I’d really like to
stop hearing arguments about that. It may not seem a big deal, but
nobody likes trying to code against a moving target. Marcus packaged
for Gentoo for years, and Jordan has worked with Kubuntu for a long
time – as a result both are very familiar with bad upstream practices
and how much time it wastes. However, Konstantin does not have write
access to cryos/master AFAIK, so anything of his that breaks Kalzium
etc is certainly not his doing. I agree that developing in topic
branches and mantaining long-term development/legacy branches would be
the best solution to most of these problems.

I never intended to demotivate Konstantin, he has some great energy and
the time to implement the ideas. I have spent a significant amount of time
trying to explain some of these issues, and have explained them multiple
times in multiple ways. After talking with Benoit and Jordan privately, it
became clear that this was not productive.

Konstantin has some great ideas. I am with him on splitting the Avogadro
library, at the right time. I think it is the right way to go, but it
would be a net negative to do it now. It is not worth doing 2.0 right now
just for that improvement. We can host the separated widgets in a separate
repo, offering them as standalone components.

BTW, there was a lot of effort put into making 1.0 stable – why is
Kalzium using master?

It isn’t using master, it compiles against the system copy. Someone tried
compiling against master, and then I began looking into it. Part of this
has been a lack of time on my part, but in all honesty I would rather be
spending my time fixing bugs and developing new features than answering
emails on the list - the volume of mail from Konstantin can be tough to
keep up with. It is even more frustrating when I have to keep repeating
myself.

I do want to remain positive. We are not about to support people building
Kalzium against Avogadro master, but that should work. May be I can add
a fancy dashboard to confirm that is the case. I am passionate about
Avogadro, and about maintaining a library with a minimum of API stability.
There are some really big changes I hope to get time to work on that would
be worth a 2.0 in my opinion (I will ask you guys first), more on that
later…

I can be stubborn at times, I want us as a project to stand by our
promises. I think Avogadro has a great future, but it does require
discipline. I will try posting a brief run down of topic branch based
development, may be we can start using it (they are easier than they first
sound).

I would like to avoid such enormous threads in the future. May be a little
time outlining core policies, and getting them in the wiki would be time
well spent. We do need to start getting some releases out, rather than
going around in circles.

Thanks,

Marcus

51

On Mon, May 24, 2010 at 12:42 PM, Marcus D. Hanwell marcus@cryos.org wrote:

I would like to avoid such enormous threads in the future. May be a little
time outlining core policies, and getting them in the wiki would be time
well spent. We do need to start getting some releases out, rather than
going around in circles.

Agreed. Is everyone ok with a 2.0 branch, moving API breakers to it,
and getting back to real work? :wink: This seems to be the most popular
decision.

If there is a policy wiki going up, lets make sure it clearly states
what each branch is for. I was under the assumption that API breaks
were ok in master, but yes, a 1.1 branch and a 2.0 branch would be
much clearer.

Dave

52

Read man gitworkflows

Thanks for hint! I’ve missed this very manual, and it’s my fault

–
Regards,
Konstantin

53

On Mon, 24 May 2010 13:08:17 -0400
David Lonie loniedavid@gmail.com wrote:

On Mon, May 24, 2010 at 12:42 PM, Marcus D. Hanwell
marcus@cryos.org wrote:

I would like to avoid such enormous threads in the future. May be a
little time outlining core policies, and getting them in the wiki
would be time well spent. We do need to start getting some releases
out, rather than going around in circles.

Agreed. Is everyone ok with a 2.0 branch, moving API breakers to it,
and getting back to real work? :wink: This seems to be the most popular
decision.

I agree. But I’m not sure that 3rd party developers will follow changes
on “next”, so I propose to make some previews of 2.0 from time to time

I also propose to exclude plotwidget and periodictable from next, they
should be put into separate repositories

If there is a policy wiki going up, lets make sure it clearly states
what each branch is for. I was under the assumption that API breaks
were ok in master, but yes, a 1.1 branch and a 2.0 branch would be
much clearer.

Surely

–
Regards,
Konstantin

54

Our GLWidget has grown into a bit of a god class, I have been meaning
to move more of the code into the painters. Doing something about
that would be good. Definitely 2.0 material.

Is it possible to completely remove all OpenGL-related stuff from
GLWidget? If yes, my proposal about additional backend-agnostic
RenderWidget class is useless, and GLWidget could become RenderWidget
without additional complexity

–
Regards,
Konstantin

55

On Tuesday 25 May 2010 16:18:04 Konstantin Tokarev wrote:

Our GLWidget has grown into a bit of a god class, I have been meaning
to move more of the code into the painters. Doing something about
that would be good. Definitely 2.0 material.

Is it possible to completely remove all OpenGL-related stuff from
GLWidget? If yes, my proposal about additional backend-agnostic
RenderWidget class is useless, and GLWidget could become RenderWidget
without additional complexity

It would no longer be a GLWidget then…I am not sure I see the approach you
are taking here, but a more general widget should have a different name. I
could see using an abstract base class, then inheriting to make more
specialized widgets, or are you pushing for something else?

If it were me, I would have an abstract base with common API, then specialize
for each rendering type. A lot of the work was already done by me when
abstracting rendering using the painter API, but more is required.

Does that answer your query?

Marcus

56

It would no longer be a GLWidget then…

Yes, it will be RenderWidget or even AvogadroWidget

I am not sure I see the approach you
are taking here, but a more general widget should have a different name.

Surely

I
could see using an abstract base class, then inheriting to make more
specialized widgets, or are you pushing for something else?

If it were me, I would have an abstract base with common API, then specialize
for each rendering type. A lot of the work was already done by me when
abstracting rendering using the painter API, but more is required.

There’s a problem - base class should inherit QObject, and specialized should also inherit QGLWidget. But I couldn’t manage to solve a problem with virtual inheritance of QObject

–
Regards,
Konstantin

Яндекс.Почта. Письма есть. Спама - нет. http://mail.yandex.ru/nospam/sign

57

On May 27, 2010, at 4:43 AM, Konstantin Tokarev wrote:

There’s a problem - base class should inherit QObject, and specialized should also inherit QGLWidget. But I couldn’t manage to solve a problem with virtual inheritance of QObject

No, such a RenderWidget would probably inherit QGraphicsView:
http://doc.trolltech.com/4.7-snapshot/graphicsview.html#opengl-rendering

Then the GL version would create a QGLWidget and set the viewport. The framework is also set up nicely to allow embedded widgets and multiple views of the same scene. We could use the widgets to handle painter text, for example, or a full-screen view with a pop-up toolbar.

Hope that helps,
-Geoff