|
From: Egon W. <ego...@gm...> - 2014-01-09 14:51:46
|
On Thu, Jan 9, 2014 at 3:29 PM, John May <jo...@eb...> wrote: > As you say a toolkit independent abstraction - however if I were to plug in the > CDK-JChemPaint IUndoRedoable edits into JChemPaint they would not work. Yeah, it does depend on bridges to the various toolkits. Arvid has been doing this for SWT. I do not know what Stefan and Gilleain did for Swing in the JChemPaint applet... I have no insight in what they did in that respect after the fork. > Part of the problem I see is that the granularity ‘ChangeCoordsEdit.java’ > etc isn’t needed - for AtomContainers a more robust approach is to simply > clone the container an push it onto the Undo/Redo stack. That was the original JChemPaint implementation, but was too slow. I would need to dig up more history to see if that was the only reason or not... I do not remember at this moment. Arvid, do you happen to remember the full argumentation for the edit design? > With fewer edit classes it’s now trivial to write the undo/redo manager interaction. That I agree with. > What I really worry about is - > https://github.com/egonw/cdk/tree/13-unsorted-patches/src/main/org/openscience/cdk/controller > and > https://github.com/egonw/cdk/tree/13-unsorted-patches/src/main/org/openscience/cdk/controller/undoredo > > That’s a load much more code to add to an already strained code base. Worst > of all - everything public! and adds to the JavaDoc. I’m really trying to > trim down the bloat and make things more streamlined, efficient and easier > to use. Got it. Maybe with the current CDK just a stack of IChemModel's is now fast enough and the way to go... Egon -- Dr E.L. Willighagen Postdoctoral Researcher Department of Bioinformatics - BiGCaT Maastricht University (http://www.bigcat.unimaas.nl/) Homepage: http://egonw.github.com/ LinkedIn: http://se.linkedin.com/in/egonw Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers ORCID: 0000-0001-7542-0286 |