From: gilleain t. <gil...@gm...> - 2010-07-28 12:06:57
|
Hi Mark, Developers; The CDK-export code is interesting, and could be another part of JChemPaint that is pushed down into the CDK. The use-case would be any CDK application that wants to export images, or molfiles, through a single interface. Here is a sketch of my impression of the architecture : http://jump.fm/AFLKX (ugh! I would have preferred tumblr, but it made it too small to read...) So, it seems like the CDKExport class is acting as a builder for Renderers (or IRenderers, or whatever) and the CDKExportFormat is configuring the RendererModel by stuffing in the appropriate parameters. The whole process starts with parsing the format string into an ExportFormat. I hadn't seen the FreeHEP libraries before - they look good, but I'm not sure about introducing them as dependencies. The other thing is that there are many more molfile formats that could be handled by the MolfileExportFormatHandler ... er.. sorry, that should be "MoleculeFileExport..." - well anyway. gilleain |
From: gilleain t. <gil...@gm...> - 2010-07-28 14:52:18
|
Hi Grrr. Sorry about the 2Shared link. I used them on a whim, but as far as I can see they are a legal hair's width from a scam - prominent "Download" button that leads to an ad, for example. Fair enough, they have a business model, but don't trick the user... Anyway. Here is free hosting of another sort: http://gilleain.blogspot.com/2010/07/cdk-export.html where click for bigger should really mean that (perhaps 2shared works on IE or something, I don't know). Seems like I got most things right, then. I agree that the FreeHEP and servlet could be in a separate project. Hmmm.. a CDK servlet project, perhaps. It's always little tricky to work out the right boundaries for carving up projects into packages (and modules, in the case of the CDK). Apart from narrowing some things, there are others that could be generalised perhaps. Without making the whole thing overly complex, it does seem like the string format is a bit like a stylesheet. There was an idea floating around (can't remember who suggested it) of chemical stylesheets. Or 'CheSS' for those that like fancy names for things :) Ah, wait, I found a blog post by Rajarshi where I mention this: http://blog.rguha.net/?p=113 - but I'm sure I got it from someone else. Of course, the best thing would be to integrate CDKExport as a first step, then possibly expand it if there is time to so and if anyone wants to do it. gilleain On Wed, Jul 28, 2010 at 3:22 PM, Mark Southern <sou...@sc...> wrote: > Hi Gilleain, > > Glad you find it interesting. Unfortunately the sketch is still too small to read for me. I cannot see nor save it at a size more than a postage stamp! > > The CDKExport class is the builder and the CDKExportFormat configures and parses custom properties and IGeneratorParameters from an IRenderer into a String representation and back again. This last part currently having a dependency on the ConvertUtils class from commons-beanutils. > > The ExportFormatHandler instances are designed to be added to the CDKExport instance. So in the case of the FreeHEPExportFormatHandler I would envision keeping it in a separate project and jar file. > > The CDKExportServlet (along with CDKFiles and ChemicalMIME) may also be useful to people but kept as a standalone project. > > Molfile -> MoleculeFileExportFormatHandler absolutely! I just took care of my usual use cases for now! It's supposed to be an extensible mechanism :-) > > Best, > ~Mark. > > -----Original Message----- > From: gilleain torrance [mailto:gil...@gm...] > Sent: Wednesday, July 28, 2010 8:07 AM > To: Developers forum for discussion about the Chemistry Development Kit (CDK); Mark Southern > Subject: CDK-Export > > Hi Mark, Developers; > > The CDK-export code is interesting, and could be another part of > JChemPaint that is pushed down into the CDK. The use-case would be any > CDK application that wants to export images, or molfiles, through a > single interface. > > Here is a sketch of my impression of the architecture : > http://jump.fm/AFLKX (ugh! I would have preferred tumblr, but it made > it too small to read...) > > So, it seems like the CDKExport class is acting as a builder for > Renderers (or IRenderers, or whatever) and the CDKExportFormat is > configuring the RendererModel by stuffing in the appropriate > parameters. The whole process starts with parsing the format string > into an ExportFormat. > > I hadn't seen the FreeHEP libraries before - they look good, but I'm > not sure about introducing them as dependencies. The other thing is > that there are many more molfile formats that could be handled by the > MolfileExportFormatHandler ... er.. sorry, that should be > "MoleculeFileExport..." - well anyway. > > gilleain > |
From: Rajarshi G. <raj...@gm...> - 2010-07-28 16:12:35
|
I think the idea was originally proposed by Rich http://depth-first.com/articles/2007/07/13/making-your-2d-structures-look-good-firefly-styles-and-stylesheets On Wed, Jul 28, 2010 at 10:52 AM, gilleain torrance <gil...@gm...> wrote: > Hi > > Grrr. Sorry about the 2Shared link. I used them on a whim, but as far > as I can see they are a legal hair's width from a scam - prominent > "Download" button that leads to an ad, for example. Fair enough, they > have a business model, but don't trick the user... > > Anyway. Here is free hosting of another sort: > > http://gilleain.blogspot.com/2010/07/cdk-export.html > > where click for bigger should really mean that (perhaps 2shared works > on IE or something, I don't know). > > Seems like I got most things right, then. I agree that the FreeHEP and > servlet could be in a separate project. Hmmm.. a CDK servlet project, > perhaps. It's always little tricky to work out the right boundaries > for carving up projects into packages (and modules, in the case of the > CDK). > > Apart from narrowing some things, there are others that could be > generalised perhaps. Without making the whole thing overly complex, it > does seem like the string format is a bit like a stylesheet. There was > an idea floating around (can't remember who suggested it) of chemical > stylesheets. Or 'CheSS' for those that like fancy names for things :) > > Ah, wait, I found a blog post by Rajarshi where I mention this: > http://blog.rguha.net/?p=113 - but I'm sure I got it from someone > else. Of course, the best thing would be to integrate CDKExport as a > first step, then possibly expand it if there is time to so and if > anyone wants to do it. > > gilleain > > On Wed, Jul 28, 2010 at 3:22 PM, Mark Southern <sou...@sc...> wrote: >> Hi Gilleain, >> >> Glad you find it interesting. Unfortunately the sketch is still too small to read for me. I cannot see nor save it at a size more than a postage stamp! >> >> The CDKExport class is the builder and the CDKExportFormat configures and parses custom properties and IGeneratorParameters from an IRenderer into a String representation and back again. This last part currently having a dependency on the ConvertUtils class from commons-beanutils. >> >> The ExportFormatHandler instances are designed to be added to the CDKExport instance. So in the case of the FreeHEPExportFormatHandler I would envision keeping it in a separate project and jar file. >> >> The CDKExportServlet (along with CDKFiles and ChemicalMIME) may also be useful to people but kept as a standalone project. >> >> Molfile -> MoleculeFileExportFormatHandler absolutely! I just took care of my usual use cases for now! It's supposed to be an extensible mechanism :-) >> >> Best, >> ~Mark. >> >> -----Original Message----- >> From: gilleain torrance [mailto:gil...@gm...] >> Sent: Wednesday, July 28, 2010 8:07 AM >> To: Developers forum for discussion about the Chemistry Development Kit (CDK); Mark Southern >> Subject: CDK-Export >> >> Hi Mark, Developers; >> >> The CDK-export code is interesting, and could be another part of >> JChemPaint that is pushed down into the CDK. The use-case would be any >> CDK application that wants to export images, or molfiles, through a >> single interface. >> >> Here is a sketch of my impression of the architecture : >> http://jump.fm/AFLKX (ugh! I would have preferred tumblr, but it made >> it too small to read...) >> >> So, it seems like the CDKExport class is acting as a builder for >> Renderers (or IRenderers, or whatever) and the CDKExportFormat is >> configuring the RendererModel by stuffing in the appropriate >> parameters. The whole process starts with parsing the format string >> into an ExportFormat. >> >> I hadn't seen the FreeHEP libraries before - they look good, but I'm >> not sure about introducing them as dependencies. The other thing is >> that there are many more molfile formats that could be handled by the >> MolfileExportFormatHandler ... er.. sorry, that should be >> "MoleculeFileExport..." - well anyway. >> >> gilleain >> > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel > -- Rajarshi Guha NIH Chemical Genomics Center |
From: gilleain t. <gil...@gm...> - 2010-07-28 16:16:52
|
Perhaps, but it has also been done for SVG (this is not quite the same, I suppose) : http://www.ch.ic.ac.uk/svg/ or http://www.ch.ic.ac.uk/rzepa/chimeral/ I admit that "chimeral" is also a nice name. It was mentioned in 2001: http://cml.sourceforge.net/historical/position.html So there's nothing new under the sun :) gilleain On Wed, Jul 28, 2010 at 5:12 PM, Rajarshi Guha <raj...@gm...> wrote: > I think the idea was originally proposed by Rich > > http://depth-first.com/articles/2007/07/13/making-your-2d-structures-look-good-firefly-styles-and-stylesheets > > On Wed, Jul 28, 2010 at 10:52 AM, gilleain torrance > <gil...@gm...> wrote: >> Hi >> >> Grrr. Sorry about the 2Shared link. I used them on a whim, but as far >> as I can see they are a legal hair's width from a scam - prominent >> "Download" button that leads to an ad, for example. Fair enough, they >> have a business model, but don't trick the user... >> >> Anyway. Here is free hosting of another sort: >> >> http://gilleain.blogspot.com/2010/07/cdk-export.html >> >> where click for bigger should really mean that (perhaps 2shared works >> on IE or something, I don't know). >> >> Seems like I got most things right, then. I agree that the FreeHEP and >> servlet could be in a separate project. Hmmm.. a CDK servlet project, >> perhaps. It's always little tricky to work out the right boundaries >> for carving up projects into packages (and modules, in the case of the >> CDK). >> >> Apart from narrowing some things, there are others that could be >> generalised perhaps. Without making the whole thing overly complex, it >> does seem like the string format is a bit like a stylesheet. There was >> an idea floating around (can't remember who suggested it) of chemical >> stylesheets. Or 'CheSS' for those that like fancy names for things :) >> >> Ah, wait, I found a blog post by Rajarshi where I mention this: >> http://blog.rguha.net/?p=113 - but I'm sure I got it from someone >> else. Of course, the best thing would be to integrate CDKExport as a >> first step, then possibly expand it if there is time to so and if >> anyone wants to do it. >> >> gilleain >> >> On Wed, Jul 28, 2010 at 3:22 PM, Mark Southern <sou...@sc...> wrote: >>> Hi Gilleain, >>> >>> Glad you find it interesting. Unfortunately the sketch is still too small to read for me. I cannot see nor save it at a size more than a postage stamp! >>> >>> The CDKExport class is the builder and the CDKExportFormat configures and parses custom properties and IGeneratorParameters from an IRenderer into a String representation and back again. This last part currently having a dependency on the ConvertUtils class from commons-beanutils. >>> >>> The ExportFormatHandler instances are designed to be added to the CDKExport instance. So in the case of the FreeHEPExportFormatHandler I would envision keeping it in a separate project and jar file. >>> >>> The CDKExportServlet (along with CDKFiles and ChemicalMIME) may also be useful to people but kept as a standalone project. >>> >>> Molfile -> MoleculeFileExportFormatHandler absolutely! I just took care of my usual use cases for now! It's supposed to be an extensible mechanism :-) >>> >>> Best, >>> ~Mark. >>> >>> -----Original Message----- >>> From: gilleain torrance [mailto:gil...@gm...] >>> Sent: Wednesday, July 28, 2010 8:07 AM >>> To: Developers forum for discussion about the Chemistry Development Kit (CDK); Mark Southern >>> Subject: CDK-Export >>> >>> Hi Mark, Developers; >>> >>> The CDK-export code is interesting, and could be another part of >>> JChemPaint that is pushed down into the CDK. The use-case would be any >>> CDK application that wants to export images, or molfiles, through a >>> single interface. >>> >>> Here is a sketch of my impression of the architecture : >>> http://jump.fm/AFLKX (ugh! I would have preferred tumblr, but it made >>> it too small to read...) >>> >>> So, it seems like the CDKExport class is acting as a builder for >>> Renderers (or IRenderers, or whatever) and the CDKExportFormat is >>> configuring the RendererModel by stuffing in the appropriate >>> parameters. The whole process starts with parsing the format string >>> into an ExportFormat. >>> >>> I hadn't seen the FreeHEP libraries before - they look good, but I'm >>> not sure about introducing them as dependencies. The other thing is >>> that there are many more molfile formats that could be handled by the >>> MolfileExportFormatHandler ... er.. sorry, that should be >>> "MoleculeFileExport..." - well anyway. >>> >>> gilleain >>> >> >> ------------------------------------------------------------------------------ >> The Palm PDK Hot Apps Program offers developers who use the >> Plug-In Development Kit to bring their C/C++ apps to Palm for a share >> of $1 Million in cash or HP Products. Visit us here for more details: >> http://p.sf.net/sfu/dev2dev-palm >> _______________________________________________ >> Cdk-devel mailing list >> Cdk...@li... >> https://lists.sourceforge.net/lists/listinfo/cdk-devel >> > > > > -- > Rajarshi Guha > NIH Chemical Genomics Center > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel > |
From: Mark S. <sou...@sc...> - 2010-07-28 14:23:31
|
Hi Gilleain, Glad you find it interesting. Unfortunately the sketch is still too small to read for me. I cannot see nor save it at a size more than a postage stamp! The CDKExport class is the builder and the CDKExportFormat configures and parses custom properties and IGeneratorParameters from an IRenderer into a String representation and back again. This last part currently having a dependency on the ConvertUtils class from commons-beanutils. The ExportFormatHandler instances are designed to be added to the CDKExport instance. So in the case of the FreeHEPExportFormatHandler I would envision keeping it in a separate project and jar file. The CDKExportServlet (along with CDKFiles and ChemicalMIME) may also be useful to people but kept as a standalone project. Molfile -> MoleculeFileExportFormatHandler absolutely! I just took care of my usual use cases for now! It's supposed to be an extensible mechanism :-) Best, ~Mark. -----Original Message----- From: gilleain torrance [mailto:gil...@gm...] Sent: Wednesday, July 28, 2010 8:07 AM To: Developers forum for discussion about the Chemistry Development Kit (CDK); Mark Southern Subject: CDK-Export Hi Mark, Developers; The CDK-export code is interesting, and could be another part of JChemPaint that is pushed down into the CDK. The use-case would be any CDK application that wants to export images, or molfiles, through a single interface. Here is a sketch of my impression of the architecture : http://jump.fm/AFLKX (ugh! I would have preferred tumblr, but it made it too small to read...) So, it seems like the CDKExport class is acting as a builder for Renderers (or IRenderers, or whatever) and the CDKExportFormat is configuring the RendererModel by stuffing in the appropriate parameters. The whole process starts with parsing the format string into an ExportFormat. I hadn't seen the FreeHEP libraries before - they look good, but I'm not sure about introducing them as dependencies. The other thing is that there are many more molfile formats that could be handled by the MolfileExportFormatHandler ... er.. sorry, that should be "MoleculeFileExport..." - well anyway. gilleain |
From: Mark S. <sou...@sc...> - 2010-07-31 14:26:53
|
Hi Gilleain, I updated the MoleculeFileExportFormatHandler to export using all 14 of the Writers in the cdk.io package, one after the other. I then started to think that there might be a better way to do it. Could I use the cdk.io.FormatFactory class to obtain the Writers and their extensions? i.e. FormatFactory factory = new FormatFactory(); for(IChemFormatMatcher matcher: factory.getFormats()) { if( matcher instanceof IChemFormat ) { IChemFormat format = (IChemFormat) matcher; if ( null != format.getWriterClassName() ) { // instantiate Writer and add to map with preferredNameExtension as the "type" for the CDKExportFormat } } } However, when I run this code, only 9 of the 14 Writers in cdk.io get listed. Is this simply unfinished functionality in the CDK? Best, ~Mark. URL: http://code.google.com/p/cdk-export/ |
From: gilleain t. <gil...@gm...> - 2010-07-31 14:40:59
|
Hi, Hmmm. I'm not very familiar with how cdk.io works. I've only used it, not developed any of the code. It seems like a lot of the formats in cdk.io.formats return null for the "getWriterClassName", but there are 14 that do: CDKSourceCodeFormat.java CMLFormat.java CMLRSSFormat.java CrystClustFormat.java GaussianInputFormat.java HINFormat.java MDLV2000Format.java Mol2Format.java PDBFormat.java RGroupQueryFormat.java SDFFormat.java ShelXFormat.java SMILESFormat.java XYZFormat.java and I guess that these correspond to the 14 writers? It's strange, because IChemFormatMatcher extends IChemFormat, so they should all pass the instanceof. gilleain On Sat, Jul 31, 2010 at 3:10 PM, Mark Southern <sou...@sc...> wrote: > Hi Gilleain, > > I updated the MoleculeFileExportFormatHandler to export using all 14 of the Writers in the cdk.io package, one after the other. > > I then started to think that there might be a better way to do it. Could I use the cdk.io.FormatFactory class to obtain the Writers and their extensions? i.e. > > FormatFactory factory = new FormatFactory(); > for(IChemFormatMatcher matcher: factory.getFormats()) { > if( matcher instanceof IChemFormat ) { > IChemFormat format = (IChemFormat) matcher; > if ( null != format.getWriterClassName() ) { > // instantiate Writer and add to map with preferredNameExtension as the "type" for the CDKExportFormat > } > } > } > > However, when I run this code, only 9 of the 14 Writers in cdk.io get listed. Is this simply unfinished functionality in the CDK? > > Best, > ~Mark. > URL: http://code.google.com/p/cdk-export/ > |
From: Egon W. <ego...@gm...> - 2010-07-31 15:10:35
|
Hi Mark, On Sat, Jul 31, 2010 at 4:10 PM, Mark Southern <sou...@sc...> wrote: > However, when I run this code, only 9 of the 14 Writers in cdk.io get listed. Is this simply unfinished functionality in the CDK? Which are the 5 missing ones? I'll explore the issue then. Egon -- Post-doc @ Uppsala University Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Egon W. <ego...@gm...> - 2010-09-08 19:14:33
|
Mark, On Sat, Jul 31, 2010 at 5:10 PM, Egon Willighagen <ego...@gm...> wrote: > On Sat, Jul 31, 2010 at 4:10 PM, Mark Southern <sou...@sc...> wrote: >> However, when I run this code, only 9 of the 14 Writers in cdk.io get listed. Is this simply unfinished functionality in the CDK? > > Which are the 5 missing ones? I'll explore the issue then. is this issue still open? Egon -- Dr E.L. Willighagen Post-doc @ Uppsala University (only until 2010-09-30) Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg 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 |