<Swing Dev> Project proposal: fbtoolkit

[Phil Race]

Hi Steph,


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.

I don't think we know either. But I'd err on the side of more is better.

> 
> 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 :-)

FYI. If you look at openjdk linux/solaris sources, you'll see that
XAWT's TextField and TextArea (ie the editable text widgets) use Swing's
Motif emulation.

> 
>> 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.
> 

What I was getting at is how are you drawing geometry, images, text etc?
Are you expecting to still use JDK for this (onto a bufferedimage?)

> 
> 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.

Whilst I maybe understand this and your motivations a little better
I'm wondering how is this existing code plugged into a JDK?

the awt.Toolkit property was never intended as a 'pluggable SPI'.
Its a way for the JDK to select between its built-in toolkit options.

If you are drawing your text etc by calling back into JDK to do
such rendering for you I'm not sure that this will work reliably
or perhaps even at all, if one of the built in toolkits was not activated.

-phil.