PROJECT PROPOSAL - "Squeak Fenestra"

This is a proposal of a project i would like to do as my bachelor's 
dissertation - a framework for handling host OS windows. I know there 
are two kind of similar works in progress by now ("Ffenestri" and 
"wxSqueak"), but I'd like to this with a bit different approach (though 
i find a lot of inspiration and possible solutions in this projects).
Before i begin, I'd like to know the opinions of the community members, 
cause this is mostly to make Squeak much more useful for the general 
public and i have no reason working on this kind of project if it would 
end up as my personal toy.

 >> The Idea: Make Squeak applications work outside of the 
"morphic-world". The OS-window should be attached to their "owner" 
(aMorph, Tweak "costume" or any other GUI-element), taking-over all its 
actions (creation, closing, resizing, movement, minimalization,...) and 
providing their actions (... + I/O) transparently back to the owner.

   ->Background: A *lot* of applications has only one or a few os 
windows, managed (drawing, event handling) by itself (Winamp, almost all 
games, most of skinnable apps) - i find this approach a lot "better" 
than making a Squeak binding to a third-party graphic toolkit, adding an 
external dependency and losing a lot of Smalltalks' flexibility and GUI 
elegance or extending the Display-plugin and letting the VM to do the 
work and hold the state.

   ->To-do:
	->Modification of BitBlt to make it work with multiple (maybe a *lot* 
of) windows (the solution should be easily found in "wxSqueak").
	->Platform-dependent wrappers - this would be the actual binding to the 
OS (WinAPI, X.org) and window management, focusing on doing as much as 
possible from within the image - I'd like to make this all via FFI, but 
i will need callbacks and input event handling, so there are obviously 
two approaches possible: extending FFI to support callbacks or rewriting 
the display-plugin to fit my needs. There should be at least as possible 
of the real functionality.
	->"Fenestra-API", providing all the basic functionality (window 
creation, management and callbacks) in a platform-independent manner. 
There should be an "extension interface" available, to provide some 
enhanced and very host-OS-dependent functions, like systray or os-menu 
handling.
	->A global "Window Registry" to hold the models/state of all managed 
windows and encapsulate all their startUp/shutDown registering, 
initialization and finalization in-image only.
	->"HostWindow" class, to provide an 
abstraction/wrapper/model/stateholder of the 'real' os-window completely 
encapsulating it (*all* handling of the host-os windows should be made 
through this wrappers).
	->Morphic extensions (as much low-level as possible, maybe implemented 
as real morph-extensions) to make the morphs able to transparently 
interact with their attached windows (if any) with no further 
modifications to specialized morph-classes (with some exceptions like 
SystemWindow and MenuMorph, which shall be "externalized" by default).

   ->Some random thoughts:
	->Halos may be still used (the os-window can be transparent and provide 
enough place for them) or completely replaced by the halo-menu.
	->*every* morph should have the possibility to freely change its' state 
between "externalized" and "being a part of the morphic-world" at 
runtime by users' decision (extensions to the halo-menu).
	->More kinds of os-windows should be accessible: application window, 
dialog, child-window (without taskbar interaction),... depending on the 
underlying OS.
	->Every os-window should have the possibility to manage/change it's 
kind, taskbar entry, systray icon & menus at runtime (a lot of these 
operations involve the destruction of the window and a creation of 
another one - this may include the re-registration of event hooks and 
this is what should be transparently managed by the HostWindow model).
	->Make even the main window independent from the VM and managed 
in-image & externalize VM state as much as possible (a little step to a 
re-entrant VM).
	->Find a way to make more complicated UI constructions possible 
(Connectors,...).


I hope i didn't get lost in my ideas somewhere and this post makes some 
sense...
Now, i would be glad to hear your opinions regarding the sanity, 
real-word usefulness and possible caveats of this project... :)

Viktor Svub


PS: Excuse my english, ... and i you don't like the project name (maybe 
being too close to Ffenestri), just suggest a better one ;)