On Jan 5, 2012, at 12:20 PM, Roman Kennke <ro...@kennke.org> wrote: > Hi all, > > Thanks Mario for bringing this up. > > First of all let me explain what is Cacio and why we think it's useful. > In essence, it is an (somewhat) abstract implementation of AWT peers. It > implements all the AWT widgets by using Swing for painting and > event/logic processing. This reduces the burden of porting/implementing > the Java graphics stack enourmously. Currently, when one wants to port > the Java graphics stack, the AWT peers need to be implemented as well, > for compatibility. This is a huge effort, and considered rather > pointless by many, because AWT is not that widely used anyway. It is > particularily difficult on platforms that don't have any native widgets > (most embedded platforms). Using Cacio, this effort is reduced to > implementing a Java2D backend and some basic windowing functionality. It > even provides a windowing implementation in Java for platforms that > don't even support windows (e.g. framebuffers).
Funny thing, I believe the Mac OS port uses this same technique. Does anybody know what the differences are between the two? > We also have a somewhat special backend which renders > exclusively into a BufferedImage and can only process events generated > by Robot, which is particularily useful for unit testing GUI > applications without messing around with the user's desktop or without > requiring graphics on a continuous integration server (extremely useful > if you're into this GUI testing thingy). That would be very cool. The SQE team uses robot / image testing heavily for FX and "taking over my computer" is one of the chief problems with it (the other being image tests are finicky).
