<AWT Dev> <Swing Dev> Project proposal: fbtoolkit

[Oleg Sukhodolsky]

imho all functionality suggested could be achieved by fb-based XServer, 
why do you need to reinvent the wheel and develop a toolkit which will 
implement some functionality of XServer, some functionality of Window 
Manager, and AWT toolkit.

What is the advantage of the approach you suggest?

Thanks, Oleg.

Steph Meslin-Weber wrote:
> Hi Phil,
> 
> Thanks for your comments, I wasn't certain how verbose the initial
> proposal was supposed to be so we left out the details from the
> usecases.
> 
> In order to keep this thread in one list (it's starting to confuse
> Gmail a bit) we could continue this conversation in discuss for now.
> I have Bcc'd the other lists (including 2d following Mark's use) to
> let everyone on those lists know to check discuss for followups:
>  Bcc: awt-dev at openjdk.java.net
>  Bcc: 2d-dev at openjdk.java.net
>  Bcc: swing-dev at openjdk.java.net
> As the discussion moves on we can move it to the one group that seems
> most appropriate.
> 
> On 23/05/07, Phil Race <Phil.Race at sun.com> wrote:
>> I don't follow what this has to do with Swing. 2D would be more 
>> affected ..
>> Swing is ignorant of whether the Motif or X toolkit is specified
>> and even works with the headless toolkit.
> 
> Agreed, Swing shouldn't use knowledge of the underlying
> implementation. The reasoning behind including Swing in the discussion
> is the SwingAWT work by Roman Kennke. In his project, he implemented
> AWT peers using Swing [1]. Now, whether the Swing implementation is
> native is another topic of discussion :-)
> 
>> Also the existing toolkits can still leverage all of the
>> same internal 2D native code for rendering. I don't see where
>> you are going to get that from unless if its going to be
>> a pure Java solution.
> 
> I think here we tried to show that the example implementation would be
> written in pure Java, with extension points to break to native code as
> needed:
> 
> "This example implementation will prefer pure-Java solutions, with
> public extension points available to enter native resources as
> necessary."
> 
> Starting with pure Java means we have a baseline that is easier to
> understand than one that jumps back and forth to native code, this
> also incidentally makes it an ideal example for those wishing to write
> their own set of peers. It's a given that without those jumps certain
> optimisations aren't practical to implement, but that's why we'd like
> to do this in the open so those situations can be discussed and
> planned for.
> 
> 
> Before going on to a few usecases, I'd like to mention that I already
> have a fair amount of code in support of this proof of concept, including
> providers for raw linux fb, VNC and (as of 2 hours ago, thanks Guillaume!)
> a pure Java X11 provider; there is also embryonic work on an SDL provider
> to ensure we cover as many platforms as possible.
> 
>> > Examples of usage include: implementation debugging, device
>> > emulation, multiple-head clone outputs/inputs, simultaneous
>> > multiple-peer output, etc.
> 
> Example usecases:
> 
> 1) Implementation debugging is one that is fairly simple to explain,
>   it becomes a tool for us to track down AWT/Swing issues by excluding
>   native resources as a possible error source. (Yes it introduces
>   another factor, but at least it's independent). This also allows for
>   some device emulation, screen sizes, pixel encoding, etc.
> 
> 2) Realtime output/input on a device (say an N800 [2]) with
>   simultaneous output/input of the exact same screen contents on an
>   attached PC. This is in effect multiplexing two different devices onto
>   a single Java stack. Control of the device from the PC. Useful when
>   your touchscreen driver isn't written yet.
> 
> 3) Distributed remote software agents exposing a VNC or X11 capable
>   UI. Easier to secure and to use than a fullblown VNC or X11 server on
>   a dedicated host. Easier to deploy too. This is in effect a
>   kernel+jvm+libc on any hardware. Including headless ones like a
>   router.
> 
> 4) Point of Sale, The network is the machine, etc... lightweight PXE
>   images booting a rich Swing UI direct to their framebuffer. Small PXE
>   image, few external dependencies. For bonus points, let the client
>   decide which provider to load from a Jini cloud depending on need.
> 
> 5) Multicast a single UI via VNC, kiosk-type advertising or
>   interaction: one window per terminal.
> 
> Please let me know if I've left a few out.
> 
> Thanks,
> Steph
> 
> [1] awtswing, http://kennke.org/~roman/swing-based-awt.png
> [2] N800, http://www.nseries.com/n800
> [3] Maemo, http://maemo.org/
>