[PROJECT PROPOSAL] - "Squeak Fenestra"

Sebastián Sastre ssastre at seaswork.com.ar
Mon May 22 15:35:44 UTC 2006


Viktor,

	as to any project, my suggestion would be to make and expose a table
of pros and cons of the project and a conclusion to better appreciate why
squeak could/should have a project.

	regards,

Sebastian
PD: "Fenestra" is very cacophonic in spanish. A cacophony that nobody
deserves. So I also would suggest you other name for a project.

> -----Mensaje original-----
> De: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] En 
> nombre de Viktor Svub
> Enviado el: Lunes, 22 de Mayo de 2006 10:49
> Para: The general-purpose Squeak developers list
> Asunto: [PROJECT PROPOSAL] - "Squeak Fenestra"
> 
> 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 ;)
> 




More information about the Squeak-dev mailing list