[PROJECT PROPOSAL] - "Squeak Fenestra"

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] 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 ;)
>

>> PROJECT PROPOSAL - "Squeak Fenestra"
>>
>> This is a proposal of a project i would like to do
> My advice - *use* the stuff John & I did and instead of repeating a  
> lot of rather tedious work enjoy doing something new and  
> productive. The Areithfa Ffenestri code provides all (we think)  
> that you need to create, display, manipulate and manage host  
> windows. What is still needed is a good hookup to Morphic to make  
> it useful in the general case.
>
> You don't need to alter BitBlt, just the users of it. A lot of bits  
> of code simply end up blitting to 'Display' and you would want to  
> make them use 'theCurrentWindowIAmDisplayingIn' instead.
>
> You don't need platform dependent wrappers and strange FFI stuff.  
> Ffenestri does it all in a portable manner, which is good for  
> platforms that don't have FFI.
>
> etc.
>
> If you want to do something that you have a chance of finishing,  
> please don't waste time repeating work already done and known to  
> function reasonably well. It may not be a case of "standing on the  
> shoulders of giants" but at least you can try to benefit from a  
> "piggyback ride from quite reasonable engineers" !
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: RLBMI: Ruin Logic Board Multiple Indexed
>
>
>

> I would be good to build on top of Areithfa Ffenestri so that after a  
> while we could get the Areithfa Ffenestri
> really stable and include in Squeak .
>
> Stef
>
>>> PROJECT PROPOSAL - "Squeak Fenestra"
>>>
>>> This is a proposal of a project i would like to do
>>
>> My advice - *use* the stuff John & I did and instead of repeating a  
>> lot of rather tedious work enjoy doing something new and  productive.
>> The Areithfa Ffenestri code provides all (we think)  that you need to
>> create, display, manipulate and manage host  windows. What is still
>> needed is a good hookup to Morphic to make  it useful in the general
>> case.
>>
>> You don't need to alter BitBlt, just the users of it. A lot of bits  
>> of code simply end up blitting to 'Display' and you would want to  
>> make them use 'theCurrentWindowIAmDisplayingIn' instead.
>>
>> You don't need platform dependent wrappers and strange FFI stuff.  
>> Ffenestri does it all in a portable manner, which is good for  
>> platforms that don't have FFI.
>>
>> etc.
>>
>> If you want to do something that you have a chance of finishing,  
>> please don't waste time repeating work already done and known to  
>> function reasonably well. It may not be a case of "standing on the  
>> shoulders of giants" but at least you can try to benefit from a  
>> "piggyback ride from quite reasonable engineers" !
>>
>> tim
>> --
>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>> Strange OpCodes: RLBMI: Ruin Logic Board Multiple Indexed
>>
>>
>>
>
>
>

> Andreas Raab wrote:
>> And Unix (X11) shouldn't be all that hard either. BTW, the only  
>> reason why it isn't bundled by default with the Win32 VM is that  
>> apparently the license hasn't been quite set yet and I don't want  
>> to ship stuff with unclear license terms in the VM (nudge, nudge,  
>> Tim, get your Sophie licensing terms in place, please? ;-)
>
> Sophie stuff is licensed under the new BSD.
>
> Which brings up the interesting problem on how to make that  
> visible. We don't want to put the license on every class.
> We thought that having license information on package level would  
> be sufficient, but then "someone" would need to add that to  
> Monticello, the source server etc.
>
> Michael
>