[Kalzium] [Avogadro-devel] Fwd: Final Reminder: KDE 4.2 Feature Plan Closing Tonight

[Marcus D. Hanwell]

On Sunday 16 November 2008 00:35:50 Benoît Jacob wrote:
> Here's the latest episode of this comedy...

So you are saying we can't port any kalzium stuff now due to local fixes in 
KDE? I was working on a port locally but if that is not feasible then I will 
continue to work on getting Avogadro into a state where the API should be 
something we can stabilise. I have some local changes but if this would cause 
more issues then I can leave this.
>
> I realized that our libavogadro snapshot contains fixes (especially by the
> kde-windows guys) that would be lost if we updated it from avo trunk, and
> that can't be easily forwardported to avo trunk anymore since we didn't do
> it in time.

I thought the hard freeze was on Monday? Are you saying changes like this 
require more time? I thought Monday was the day all new features must be in 
and then they were stabilised after that? I certainly don't want to cause 
headaches for people.
>
> So what I finally did, was to put a eigen1 snapshot inside kalzium's libavo
> snapshot. I then removed eigen1 from /trunk/kdesupport (there is
> now /tags/eigen/1.0.5).
>
> Notice that the size of eigen1 is small anyway compared to the size of
> libavo.
>
> That allows kalzium 4.2 's molecular editor to work like in 4.1, without
> forcing /trunk/kdesupport to keep eigen1, and without forcing the user to
> grab another dependency.
>
> Of course that's a completely unsustainable thing to do in the long term,
> and the fact that our libavo snapshot contains changes that now are
> difficult to forwardport is another proof that it is more than time to get
> rid of any snapshot, so in 4.3, I really really hope that libavogadro 1.0
> is out, otherwise we will have to remove the molecular editor from
> /trunk/KDE (playground would then be a good temporary home for it).

Personally, I think that it would probably be better for several reasons to 
split of the molecular editor into a separate app. That way bugs/regressions 
in that can be looked at in isolation. If you look in the Primitive branch I 
have been doing a lot of work to give us an API that we can stabilise. I am 
working towards merging this branch into trunk once I have ported the 
extensions.

I am right there with you on having a stable API but I don't think our core 
data classes were really up to the task and so I have put a lot of time into 
improving them.This has the side benefit that the API is much more C++/Qt in 
style too and so should hopefully be easier to use.

I have been traveling, then ill and busy catching up and so this has delayed 
my progress. To be honest I thought I was free to work on stuff this weekend 
and commit it too. May be just working in a git branch during the freeze would 
be the best policy?

I want to ensure Kalzium has really nice features in it and am committed to 
ensuring that is the case. If I can't commit updates I won't. I hadn't thought 
of having people commit local changes to our snapshot of libavogadro without 
emailing upstream/sending patches on. This is certainly not a good situation 
and ideally we would have integrated these patches. After the freeze is over I 
will see about removing the snapshot and depending on an external libavogadro.

Thanks,

Marcus