Well let me comment
For years the squeak community complained about the fact there was
just one window and morphic, and no way
to offer native widgets or have more than one window.
The folks providing funding for Sophie complained about this same fact
too.
So years ago, Tim and I spent a summer working out how to provide the
multiple window support for Squeak
aka Areithfa Ffenestri
http://wiki.squeak.org/squeak/3862It's quite simple, the HostWindowProxy proxy lets you manipulate the
window and draw to it.
The VM was changed so that Events *should* tag UI events with a window
index number.
EventSensor then brings up the events and hands them to who ever is
interested.
It's all fully explained on the web page.
We built it on the macintosh first, with *pending* support for the
other platforms. I'm sure Bert did a Linux variation.
mmm I'm sure windowIndex 0 refers to the main squeak window btw.
The original source code without complexity should sit in the
ftp.smalltalkconsulting.com/experimental/Ffenestri/changes sets
Ffenestri-b-1 thru b-4
You should be able to load it into a Squeak image from Jan 2007,
infact I rebuilt the change sets and tested them in a January 2007 image
for a pending Squeak release let's see, oh yes the email for that is
attached at the end.
We alter event sensor, as you know that was all changed in Pharo
It also alters Moprhic a bit so it understands windowIndex logic.
Now about implementation, part of the problem is where does the events
go and where does the drawing go.
Lots of this is done in globals with no reference to the windowIndex.
We had two implementations
(a) We alter Project, when you enter project it then set the Display,
so we could make a Project Window and drawing and mouse events would
go to it, I'm not sure
about todays version of Morphic but in the past you could have
multiple Projects open, but only one would be active, then others
would be *stopped*
(b) We altered Tweak, Tweak at the time being the future vision of
Morphic and UI on Squeak. Tweak actually built an environment and
stuck the UI input queue and display information in an instance
variable associated with the Tweak world. So it was *trivial* to hook
up the host window proxy display logic and dispatch the events to the
proper Tweak world.
(c) I lie, I believe Michael Rueger built a subset of morphic (or
something) that is Ffenestri aware, but I don't think it was ever
published.
Out of this, there was a dull thud as the folks wanting multiple host
windows just failed to produce code using it.
The powers that be that directed Sophie decided in fact one window was
enough, so we never implemented things with multiple windows.
The version of Tweak we were using in Sophie was grave-yarded.
Maybe you could send me the details of your trail of MC loading since
I don't recall an Process or Delay overrides. We had lots of that in
Sophie via changes from Tweak/Qwaq to fix evil semaphore and process
bugs plus Tweak did process priority escalation to solve event
ordering/semaphore issues.
On 17-Aug-09, at 3:05 PM, Eagle Offshore wrote:
Well, I may have spoken too soon. Digging into the platform specific
window proxies - I see proxies for MacOS 9, OS X, Win32, and Acorn???,
but nothing for linux. OTOH, I find source code for a HostWindows
plugin in the Unix VM source tree.
Anybody with more knowledge of why we have a plugin without a proxy?
--
=
=
=
========================================================================
John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================
The 3.10 team asked me to build a change set for Ffenestri (multiple
host window support), and Mac Host Menus for 3.10.
The last change set was build for Tweak in 2004.
I've updated my ftp site and my idisk in the Ffenestri folder found in
the experimental directory with a number of new
change sets that let you load the Ffenestri logic into a 3.10 image,
likely also into a 3.9 image. Testing shows that this re-released code
works with Mac PowerPC and MacIntel. I did uncover a byte order
problem on macintel btw.
For the additional Macintosh Host menu support, used by Sophie, and by
Scratch I've also pushed out a set of change sets
to allow one to load that logic into a 3.10 image, likely also into a
3.9 image too. Testing shows that this re-released code works with Mac
PowerPC and MacIntel.
I did NOT revisit the Tweak support, there seems to be a LACK of
interest. Anyone who wants to explore that should email me and I'll
point out the methods of interest they can rework for Tweak. Of
course for Tweak you can open a tweak project in a host window and
expect everything to work since the display and event queue are
instance variables, not globals like in Morphic.
--------------------------
Well I note the HostMenu support *is* in Pharo now, so you need to
very careful what the HostMenus-Events.1.cs does
--------------------------
Ffenestri-b-1-HostWindowPlugin.2.cs
This is the plugin for host windows
Ffenestri-b-2-WindowProxies.3.cs
Setup window proxis
Ffenestri-b-3-MultiHostWindows-Sunits.1.cs
SUnits to test multiple window support, works on mac powerpc and
macIntel
Check with Impara about windows changes to enable support on Windows.
Ffenestri-b-3-MultiHostWindows.1.cs
Add base support for Multiple windows.
Ffenestri-b-4-Events-Morphic.1.cs
Adds multiple window support for base Morphic, see Sunits for usage.
HostMenus-Base.2.cs
Add base support for Mac Host Windows.
HostMenus-Events.1.cs
Add interface to EventSensor for mac host menus, assumes Ffenestri-b-3-
MultiHostWindows.1.cs is loaded.
HostMenus-Mac-SUnits.1.cs
SUnit to test mac host menu support, works on mac powerpc and macIntel.
HostMenus-Mac-MacPlugin.1.cs
This is the plugin that provides the menu support for os-9/os-x
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project