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

[Jeannette Hung]

Hey Stuart,
    As you probably know, we had been working feverishly to get our code 
in a state that we could put it out for JavaOne.  The amount of software 
in the JDK is huge, and the amount of work that we've had to do to get 
it to where we currently have it has taken a lot of people and many, 
many hours.  Because of all of that work, we haven't had much time to 
work out all of the rules for interim governance, and even less to 
communicate what's going on so some of what you are seeing is growing 
pains as we all build a common understanding of how this community will 
develop.
    The kinds of questions being asked by the engineers are typical ones 
asked internally when Sun engineers propose projects that they would 
like to be accepted.  This is certainly necessary for us because we have 
to make sure that we are properly using our limited internal resources. 
  This type of scrutiny may make less sense for projects that are 
staffed by non-Sun engineers.
    I apologize if you are feeling beleaguered -- that was not our 
intention.  This is just the first proposal that we had seen in our 
groups and we hadn't heard of the notion of sponsorship before this 
discussion started so you caught us unawares.

jeannette

Stuart McCulloch wrote:
> On 25/05/07, Oleg Sukhodolsky <Oleg.Sukhodolsky at sun.com> wrote:
>> 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?
> 
> perhaps better use of memory/resources?
> 
> sometimes a bit of (re)invention can uncover new and interesting paths...
> 
> On 24/05/07, Phil Race <Phil.Race at sun.com> wrote:
>> I don't think we have a clue what sponsorship means.  It certainly can't
>> mean in  this case any work from Sun engineers ( wish we had time for
>> such ideas ourselves), or taking it back into openjdk in any time in the
>> forseeable future.
> 
> I guess the question I have about this discussion is whether openjdk
> is just a place to grab the JDK source, or whether it's a place where
> people can really take part, innovate and contribute back?
> 
>>
>> 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/
>> >
>>
>