Thanks Todd, A few vaguely coherent thoughts in line before I rush for my train home ...
2009/11/16 Todd Volkert <[email protected]> > That's sweet, Chris! > What's also cool is that when we get around to writing a full-fledged > SWTApplicationContext, that trick with rendering a BufferedImage to the SWT > graphics context will come in handy. > > I presume it's OK to put the code behind that trick in our code base? It has an IBM copyright, but it states that anyone can do anything with it. > With respect to where to put the code and how to integrate it into the > build, the obvious place would be in the tools package, but since it will > introduce a dependency on the Eclipse libraries, what's the associated > license? If it's not compatible, we'll either have to (a) host it at > Google > Code with the JFreeChart stuff, or (b) just tell the developer who wishes > to > build it to get the required jars somehow and put them on the classpath, > like we do with JUnit. > My preference would of course be to put it in the Pivot code base. My understanding is that Apache License and Eclipse Public License are broadly compatible - perhaps Martjin can comment on this? The main issue in my mind is how to actually build it. I think the Eclipse community would probably recommended PDE which can be executed from the command line. However it requires an appropriate Eclipse environment handy and is dependency hell if the builder does not have the exact right setup. This page is a bit old, but describes how to do it and as far as I'm aware the process hasn't changed much: http://www.eclipse.org/articles/Article-PDE-Automation/automation.html How essential is it that the build script we have is the main mechanism for building the release? Is there scope for any manual process? If we can do it manually using a 'Target Platform' configuration would ensure that the builder has the right plugin dependencies (though doesn't help resolve them) and it is possible to sign the plugins as they are being exported from Eclipse. Also, I have embedded the Pivot libraries in to the plugin - it would probably be desirable to OSGify the jars but that will affect our existing build process as we'll need to generate appropriate MANIFEST.MF files. There are tools to do this (e.g. bnd - http://www.aqute.biz/Code/Bnd ) but I suspect bnd would become an external dependency (like JUnit). Externalising the Pivot JARS as OSGi bundles then makes us have to group them all together in to a 'feature' - not a problem but it is another build artefact we'd need to create and deal with. And that said, it is conceivable we'll have more plugins in the future, and maybe even an entire RCP build. Actually, if we go down the Bnd route then building the Pivot plugin might not be that arduous - we would just need to make sure the Eclipse dependencies are available. Again this can be an 'external' dependency like JUnit but I'm starting to feel things becoming a bit too heavy on the external dependencies. Cheers, Chris > > -T > > On Sun, Nov 15, 2009 at 12:22 PM, Christopher Brind <[email protected] > >wrote: > > > I had an idea ... I'll just use a Graphics2D from a BufferedImage draw in > > to > > it, then copy the image data over to an SWT image and draw that on > > screen... > > then thought, I better check to see if anyone else had done that already > > and > > they had (probably better than I would have as well) : > > > > http://www.java2s.com/Code/Java/SWT-JFace-Eclipse/SWT2DUnicode.htm > > > > > > > > So after lifting that code and tinkering around, for your consideration, > > here is version 0.0.1 of the Pivot WTKX Editor Eclipse plugin: > > > > > > > http://dl.dropbox.com/u/2451973/pivot/plugins/org.apache.pivot.wtkxeditor_0.0.1.jar > > > > It has a new file wizard and associates WTKX files to the WTKX editor. > > > > However, since WTKX's base type is XML (and I needed to use that > > association > > to get the code work) it may open the built in XML Editor. Simply close > > this, right click on the WTKX file and choose Open With -> Pivot WTKX > > Editor > > and it should open an XML editor with 3 pages, the 3rd being 'preview'. > > > > Note that there's very little error checking going and it's basically > > parsing your WTKX as you type. Once you hit preview it renderers your > WTKX > > *if it is valid* (my next task is to report errors). > > > > You will need to use *Eclipse 3.5* and have the *Web Standard Tools* > > feature > > installed (you can get this from the Eclipse update site : Help -> > Install > > Software... ). > > > > For quick installation, just drop it in to your eclipse/dropins folder > and > > restart Eclipse. If that doesn't seem to work, move it in your > > eclipse/plugins folder. > > > > Obviously, there's lots of things still to do and that could be done with > > this - all disclaimers apply! =) > > > > Also, I need to work out where to put the source and how to integrate it > > with the build - if at all. > > > > Feedback, bug reports, suggestions, all welcome. :) > > > > Cheers, > > Chris > > > > > > > > > > 2009/11/15 Christopher Brind <[email protected]> > > > > > Thanks Todd, will give that a whirl later. > > > > > > On 15 Nov 2009 13:09, "Todd Volkert" <[email protected]> wrote: > > > > > > My guess is that it's because Button is an abstract class - try > > <PushButton > > > buttonData="Sumit" />. Also, I think you should be calling > > > window.setContent(c) instead of window.add(c). > > > > > > Give those a shot, and hopefully it'll work - exciting stuff! > > > > > > -T > > > > > > On Sun, Nov 15, 2009 at 7:25 AM, Christopher Brind < > [email protected] > > > >wrote: > > > > > > > Typical - I just hit send and then I realise I can create my own > > Graphics > > > > 2D > sub-class and ju... > > > > > > > > >
