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