On Wed, Apr 6, 2016 at 2:02 PM, Semyon Sadetsky <semyon.sadet...@oracle.com> wrote:
> Not compile time switch but run-time. I would introduce a new system > property, for example "-Dawt.robot.gtk=true". Just in case if your solution > will stop to work on some platforms or WMs. GTK may be the working > alternative there. All right, makes totally sense. I'll prepare a patch and follow up here as soon as it's ready. >> In the long run, we will need to cleanup also the XPeer and all the >> Xlib code and abstract it away or simply replace with GTK or something >> else that hides the Wayland/X11 details, the screenshots are just the >> tip of the iceberg... So overall, I don't know what's best here :) > > I agree. It would be nice to introduce another layer to abstract the native > toolkit. But it will be really huge refactoring. Don't know how realistic > this could be. Yes, indeed. Another option could be to have a totally clean room gtk3/wayland peer (not just the laf, I mean the total swing/awt backend[1]), pretty much like the OSX port. This will also take a lot of time, but being isolated could give us an advantage and be done at a later time not necessarily in sync with the release. It would be interesting to discuss this further, perhaps we could even try to do a presentation together at Java One to analyse the state of things in the Toolkit stack. Cheers, Mario [1] Or perhaps we could finally obsolete AWT in JDK10? :) We already have a solid Swing only peer to use in this case.
