I think it's a good idea but I'm not sure how this would differentiate pivot--unless you think it's a checklist to be in the set of choices by architects and developers. SWT already is cross-platform and includes a web-enabled version (called RAP) and e4 already includes XWT which has a "renderer" model that can be replaced by any rendering technology so that there are actually two levels of replacement on the UI side (SWT and the rendering layer). Soyatec's eface (straight-up XAML for java) has 3 backends for rendering (soyatec's main architect contributed the renderer layer in XWT to eclipse).
I think some more thought is needed on whether a pure skin layer can handle rendering they way you think. If its just the capability to render, it probably could, but if you are trying to be more cross-platform from the same codebase especially including a certain level of styling attributes, then typical "skin" attributes such as colors and other things may need to migrate back to the model instead of the skin to ensure that they are available in all "rendered" versions of the skin or an entire skin superclass layer is then needed. Food for thought. -----Original Message----- From: Greg Brown [mailto:[email protected]] Sent: Sunday, September 12, 2010 7:40 PM To: Pivot Dev Subject: SWT theme? Someone on a java.net thread was asking if Pivot supported native L&F. I explained that we intentionally don't support that because it is too much of a moving target, etc. But it got me thinking that we (or someone, anyways) could theoretically create a theme that is backed by native components (for example, via SWT). The fact that we pass a Graphics2D object to our paint() method doesn't really matter in that case since those components are painted by the native peer anyways. We wouldn't be able to use decorators since those rely on Java2D, but there are ways around that (such as providing our own graphics abstraction, which is something we have talked about in the past). Basically, every skin would have a native peer. Layout containers could simply use an empty container peer and just perform layout on the native children. Navigation containers could just use the native equivalent. If a native equivalent doesn't exist, that component just wouldn't be supported (or could be emulated, if a Pivot-native graphics API existed). I think it is an interesting idea. This would allow developers to use Pivot to build applications that could be deployed via Eclipse RCP as well as our existing application contexts. It would work on Android and iPhone as well, assuming that Java can be made to run there (which, based on some recent announcements, seems possible). I'm curious to know what others think about this idea. G
