Hi Phil, > My big concern is that in order to get this right so that everything > matches up its a lot more than this, ie to get to where
I'm sure it's a bigger project. Let's do it step by step and not give up because the mountain seems so high ;-) > - fullscreen works This is already abstracted out nicely AFAIR and an implementation detail for the GraphicsEnvironment and friends. > - toolkit images work Dito. > - 2D can render to component graphics Dito. > - fonts are the same Fonts are a problem because there's no interface in place as far as I can see. > - swing works That's the goal ;-) > - printing works I think this is an implementation detail too. > quite a lot of this is about the inter-relationship of the toolkits > and 2D that just isn't neatly factored out. I don't actually know > what all the problems would be, I just know that its not been > considered. Sure. Let's take it step by step. Also, looking at your concerns above, I have the feeling that you misunderstood something. My concern is factoring out the necessary interfaces to be able to plug an alternative implementation in (actually, most of this is already done and only needs some additions in some places). This is not about implementing a fully different toolkit. > So you might need to end up replacing everything via SPIs that don't exist > and haven't been contemplated. Many interfaces actually do exist. There's the stuff in java.awt.peer, java.awt.dnd.peer as well as GraphicsEnvironment, GraphicsConfiguration and GraphicsDevice, plus the Toolkit class. This already covers many many aspects of such an interface. The only big missing thing is fonts. > Also if we expose interfaces here we have to define them - its > a chunk of work to spec out something like that and it constrains > our implementation in the future. > > We have rules (internal to date) that say *any* interface we > expose, not just java api, but right down to commands, command line > args, system properties, env variables which are documented > etc etc is an 'interface' in the general sense and has some > level of support associated with it. I am not sure we want > to take escalations from Oracle because a pluggable interface > doesn't work when it was not designed to be a true pluggable interface. Can't we keep that as something inofficial? I mean, I need it to support a bunch of toolkits and stuff that I already have in place, but there is no need to document that in the specs etc. It's an internal interface, just like the peer interface is now, and it's not recommended for public use. > Hence CCC approval seems required unless someone can > figure out if anything that's discussed on openjdk is not > considered an exposed interface .. but I don't see how that > can be the case. Can you explain what CCC is? Is that a good thing or a bad thing? ;-) > If the AWT group accept this patch then they will need > to get CCC clearance first. Hmm, why? This patch seems pretty small and un-intrusive. > BTW what does Component.printAll() in your current implementation? > Does it print the GTK peers as postscript, as we do for the motif > widgets? Good question. I think it uses some GTK function to print to the graphics object (which is based on Cairo). Yes I think this is also using postscript at some level. Cheers, Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-0 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Geschäftsführer: Dr. James J. Hunt
