Hey all (again).
Disregard this. I've made a lot of changes and I'll post an improved
version shortly (with working code).
/Sven
On Sun, 2006-07-23 at 19:23 +0200, Sven de Marothy wrote:
> Hey all,
> So it seems AWT in 1.6 will include support for splash-screens.
> This will require a little (optional) VM support, so here's a proposal
> and some prototype code for this I'd like feedback on.
>
> This is done by either:
> 1) Giving the VM a command line option and filename (JPEG/GIF/PNG is
> supported)
> 2) Including such an image in a JAR and using an option in the manifest.
> (In the case of both, the former has precedence.)
>
> The idea is that the splashscreen should be loaded and shown as quickly
> as possible. Once the first AWT window is opened by the app, the
> splashscreen is closed. But once user code is running the program can
> update the splashscreen prior to that, using a new SplashScreen class.
>
> * For VM implementors:
> Ok, so I've got a proposal for how to do this. For the VM part,
> see splashscreen.h. There are two native functions to call:
> int cp_awt_splashscreen_load_file( char *filename );
> int cp_awt_splashscreen_load_data( char *url, char *imagedata );
>
> Corresponding to loading from the command line and from a jar,
> respectively. These methods should load the file, create a frameless
> window, display it, and return as fast as they can, using the
> native toolkit instead of java.
>
> Strictly speaking we only need one function, but since the
> command-line option takes precedence we can use that to show
> the splash earlier. On failure, the VM can display a message
> or silently ignore it.
>
> * For peer implementors:
> A new ClasspathToolkit method:
> public abstract SplashWindow getSplashWindow();
>
> The public SplashScreen class is implemented on top
> of our SplashWindow class. This is more or less an ordinary
> Window. But more on this later, first the native side of things:
>
> The native methods above set a global variable (cp_splashscreen) which
> is a struct splashscreenhandle
> {
> void *nativeWindowHandle;
> void *nativeImageHandle;
> }
> If set (the variable is null if no splashscreen is available
> or if loading failed), the structure should be populated with
> platform-specific values for the window handle and image data.
> On X/GTK/Qt, this should be understood to mean XIDs for the
> window and a pixmap, respectively. NOT a toolkit-specific
> structure (See below). On Windows (athough we don't have peers
> for that yet) it'd be a HWND and HBITMAP, and so on.
>
> The reason why we want to use X structures here is this:
> We cannot know from the start which set of peers the user
> is using, and therefore we don't know which peers will want
> to create the SplashWindow instance.
>
> The idea here is that the native splashscreen code should be compiled
> to use the default toolkit (or none). If the user has chosen a
> different toolkit at runtime, the thing should still work.
>
> Q and A..
>
> Q: What does the peer need to do, then?
> A: Implement getSplashWindow. What this should do, is retrive
> the cp_splashscreen structure and use the X handles to wrap it
> in the native toolit (e.g. gdk_window_foreign_new on GTK). This
> object should then be wrapped with a WindowPeer from which a
> SplashWindow implementation can be created. (This is a lot less
> code than it sounds like)
>
> Q: What does the VM need to do, then?
> A: Nothing. But if it wants splashscreens it should. Call
> cp_awt_splashscreen_load_file or cp_awt_splashscreen_load_data,
> and do so as soon as it can (after parsing the command line and reading
> the jar manifest, respectively).
>
> Q: Native toolkit?! But what about JNode/IKVM/Other pure-java peers?
> A: In those cases the VM is already loaded, or will need to be. In which
> case displaying a splash-screen during VM loading is rather pointless.
> However, a pure-java implementation which the VM can show at some point
> of its choice is simple to do, and should be done.
>
> /Sven
