Native Windows

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Native Windows

Eagle Offshore
I spent the weekend trying to get Ffenestri working in Pharo.   It was  
astonishingly painful, not the least of which because they are stored  
as half a dozen monticello archives and the MC tool merge tool  
requires you to address each conflict individually and the main change  
is that at lot of morphic methods now have comments and _ has been  
replaced with :=.   There must be a better way.

Also, the files have a lot of patches to Delay and Process and really  
scary stuff like that and I was under the impression that those things  
had been reworked since and I didn't want to introduce any sort of  
regression so I didn't load them and focused on just making the plugin  
interface work and patching the event delivery code to deliver window  
events to the host windows (things like activate, iconize, close...).

Debugging would be made a lot easier if I could identify a hook that  
would let me close the native window with the debugger launches, then  
reopen it when it proceeds - but I haven't a clue how that code works.

Anyhow, I have a native window that opens with a sketch morph in it  
and it does pretty much what I expect.  Because of the OS doing window  
image caching and its own damage repair from an offscreen buffer - it  
feels wicked fast and responsive compared to our emulated windows.  I  
would like to push on this and bid farewell to our MDI-like interface  
of windows within a window and finally switch to native windows with a  
top level morph in each.

I have some very mixed feelings about this as the window theming work  
that has been done is really top notch.  Absolutely wonderful - and  
yet I'd like to throw it all away and go with the OS windows because  
they're about a zillion times faster and more responsive (my wicked  
fast 2GHZ Macbook Pro has about a half second delay to drag a window -  
seriously - why?).

It works OK on the Mac OS X.  I'd like to find a windows and linux  
person who would also like to work on this.  I have no idea if it  
works on other platforms.  I also have no idea how I'm going to  
extract my changes and ship them.  I've had to hack  
HandMorph>>processEvents and lord knows what else in the quest to make  
this fly.  I suppose I could file out a change set?

Anyhow - it sort-of works except I think I've exposed a bug in event  
coordinate translation and I don't understand mouseFocus and  
keyboardFocus - how is that suppose to work?  Or does it anymore?  
Perhaps the folks who worked on recent event tweaks could enlighten me?

-Todd Blanchard

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Native Windows

Schwab,Wilhelm K
Todd,

Many thanks for working on this!!!  I suppose I qualify as a Linux person.  Certainly I have interest in having it work well, and I'm completely sick of Microsoft.  I know what you mean about there having to be a better way to do things.  Just saving all of my packages for loading into a new image leaves me wondering why nothing else has been done, or perhaps just what I am missing.

Agreed about Pinesoft's work on Polymorph; it's stunning.  I am glad to hear that you have gotten far enough along to be able to report a speed boost.  I do not necessarily assume that native is faster; emulated widgets have their use too, especially in very large numbers.  So Polymorph might live on in grids for things like spreasheets where a native widget per cell might not scale terribly well.

I have some ideas (not necessarily good ones) on how code should get from one image to another; I have little to no idea how to do that with MC though.  On Dolphin, I built a tool called Migrate that tries to soften the blow, and would be happy to contribute any parts of it that would be of value.  The basic features are to scan packages for a suitable load order[*] and to write a script for loading them into a new image.  Of course, Dolphin packages understand dependencies, which is very helpful.  I also defined a concept of safe and dangerous selectors, e.g. #safe, #dangerous, which could be referenced from any method, and Migrate would file them out and (conditionaly) into the new image.  That allowed me to preserve fixes that I made to the base system, and warned me before applying the fixes to a new version.

Seaside 2.9 defines a class called WADevelopment that helps with saving packages.

[*] Dolphin's package system is quite good, and improved over the years to the point that load order was almost a non-concern, right about the time I started getting it right, maybe.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Eagle Offshore
Sent: Monday, August 17, 2009 4:17 PM
To: [hidden email]
Subject: [Pharo-project] Native Windows

I spent the weekend trying to get Ffenestri working in Pharo.   It was  
astonishingly painful, not the least of which because they are stored as half a dozen monticello archives and the MC tool merge tool requires you to address each conflict individually and the main change is that at lot of morphic methods now have comments and _ has been  
replaced with :=.   There must be a better way.

Also, the files have a lot of patches to Delay and Process and really scary stuff like that and I was under the impression that those things had been reworked since and I didn't want to introduce any sort of regression so I didn't load them and focused on just making the plugin interface work and patching the event delivery code to deliver window events to the host windows (things like activate, iconize, close...).

Debugging would be made a lot easier if I could identify a hook that would let me close the native window with the debugger launches, then reopen it when it proceeds - but I haven't a clue how that code works.

Anyhow, I have a native window that opens with a sketch morph in it and it does pretty much what I expect.  Because of the OS doing window image caching and its own damage repair from an offscreen buffer - it feels wicked fast and responsive compared to our emulated windows.  I would like to push on this and bid farewell to our MDI-like interface of windows within a window and finally switch to native windows with a top level morph in each.

I have some very mixed feelings about this as the window theming work that has been done is really top notch.  Absolutely wonderful - and yet I'd like to throw it all away and go with the OS windows because they're about a zillion times faster and more responsive (my wicked fast 2GHZ Macbook Pro has about a half second delay to drag a window - seriously - why?).

It works OK on the Mac OS X.  I'd like to find a windows and linux person who would also like to work on this.  I have no idea if it works on other platforms.  I also have no idea how I'm going to extract my changes and ship them.  I've had to hack  
HandMorph>>processEvents and lord knows what else in the quest to make
this fly.  I suppose I could file out a change set?

Anyhow - it sort-of works except I think I've exposed a bug in event coordinate translation and I don't understand mouseFocus and keyboardFocus - how is that suppose to work?  Or does it anymore?  
Perhaps the folks who worked on recent event tweaks could enlighten me?

-Todd Blanchard

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Native Windows

Eagle Offshore
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?

On Aug 17, 2009, at 2:48 PM, Schwab,Wilhelm K wrote:

> Todd,
>
> Many thanks for working on this!!!  I suppose I qualify as a Linux  
> person.  Certainly I have interest in having it work well, and I'm  
> completely sick of Microsoft.  I know what you mean about there  
> having to be a better way to do things.  Just saving all of my  
> packages for loading into a new image leaves me wondering why  
> nothing else has been done, or perhaps just what I am missing.
>
> Agreed about Pinesoft's work on Polymorph; it's stunning.  I am glad  
> to hear that you have gotten far enough along to be able to report a  
> speed boost.  I do not necessarily assume that native is faster;  
> emulated widgets have their use too, especially in very large  
> numbers.  So Polymorph might live on in grids for things like  
> spreasheets where a native widget per cell might not scale terribly  
> well.
>
> I have some ideas (not necessarily good ones) on how code should get  
> from one image to another; I have little to no idea how to do that  
> with MC though.  On Dolphin, I built a tool called Migrate that  
> tries to soften the blow, and would be happy to contribute any parts  
> of it that would be of value.  The basic features are to scan  
> packages for a suitable load order[*] and to write a script for  
> loading them into a new image.  Of course, Dolphin packages  
> understand dependencies, which is very helpful.  I also defined a  
> concept of safe and dangerous selectors, e.g. #safe, #dangerous,  
> which could be referenced from any method, and Migrate would file  
> them out and (conditionaly) into the new image.  That allowed me to  
> preserve fixes that I made to the base system, and warned me before  
> applying the fixes to a new version.
>
> Seaside 2.9 defines a class called WADevelopment that helps with  
> saving packages.
>
> [*] Dolphin's package system is quite good, and improved over the  
> years to the point that load order was almost a non-concern, right  
> about the time I started getting it right, maybe.
>
> Bill
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]
> ] On Behalf Of Eagle Offshore
> Sent: Monday, August 17, 2009 4:17 PM
> To: [hidden email]
> Subject: [Pharo-project] Native Windows
>
> I spent the weekend trying to get Ffenestri working in Pharo.   It was
> astonishingly painful, not the least of which because they are  
> stored as half a dozen monticello archives and the MC tool merge  
> tool requires you to address each conflict individually and the main  
> change is that at lot of morphic methods now have comments and _ has  
> been
> replaced with :=.   There must be a better way.
>
> Also, the files have a lot of patches to Delay and Process and  
> really scary stuff like that and I was under the impression that  
> those things had been reworked since and I didn't want to introduce  
> any sort of regression so I didn't load them and focused on just  
> making the plugin interface work and patching the event delivery  
> code to deliver window events to the host windows (things like  
> activate, iconize, close...).
>
> Debugging would be made a lot easier if I could identify a hook that  
> would let me close the native window with the debugger launches,  
> then reopen it when it proceeds - but I haven't a clue how that code  
> works.
>
> Anyhow, I have a native window that opens with a sketch morph in it  
> and it does pretty much what I expect.  Because of the OS doing  
> window image caching and its own damage repair from an offscreen  
> buffer - it feels wicked fast and responsive compared to our  
> emulated windows.  I would like to push on this and bid farewell to  
> our MDI-like interface of windows within a window and finally switch  
> to native windows with a top level morph in each.
>
> I have some very mixed feelings about this as the window theming  
> work that has been done is really top notch.  Absolutely wonderful -  
> and yet I'd like to throw it all away and go with the OS windows  
> because they're about a zillion times faster and more responsive (my  
> wicked fast 2GHZ Macbook Pro has about a half second delay to drag a  
> window - seriously - why?).
>
> It works OK on the Mac OS X.  I'd like to find a windows and linux  
> person who would also like to work on this.  I have no idea if it  
> works on other platforms.  I also have no idea how I'm going to  
> extract my changes and ship them.  I've had to hack
> HandMorph>>processEvents and lord knows what else in the quest to make
> this fly.  I suppose I could file out a change set?
>
> Anyhow - it sort-of works except I think I've exposed a bug in event  
> coordinate translation and I don't understand mouseFocus and  
> keyboardFocus - how is that suppose to work?  Or does it anymore?
> Perhaps the folks who worked on recent event tweaks could enlighten  
> me?
>
> -Todd Blanchard
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Native Windows

Carlos Crosetti-4
In reply to this post by Eagle Offshore
is there a preview or screenshots of this  package?

-----Mensaje original-----
De: [hidden email]
[mailto:[hidden email]]En nombre de Eagle
Offshore
Enviado el: Lunes, 17 de Agosto de 2009 06:17 p.m.
Para: [hidden email]
Asunto: [Pharo-project] Native Windows


I spent the weekend trying to get Ffenestri working in Pharo.   It was
astonishingly painful, not the least of which because they are stored
as half a dozen monticello archives and the MC tool merge tool
requires you to address each conflict individually and the main change
is that at lot of morphic methods now have comments and _ has been
replaced with :=.   There must be a better way.

Also, the files have a lot of patches to Delay and Process and really
scary stuff like that and I was under the impression that those things
had been reworked since and I didn't want to introduce any sort of
regression so I didn't load them and focused on just making the plugin
interface work and patching the event delivery code to deliver window
events to the host windows (things like activate, iconize, close...).

Debugging would be made a lot easier if I could identify a hook that
would let me close the native window with the debugger launches, then
reopen it when it proceeds - but I haven't a clue how that code works.

Anyhow, I have a native window that opens with a sketch morph in it
and it does pretty much what I expect.  Because of the OS doing window
image caching and its own damage repair from an offscreen buffer - it
feels wicked fast and responsive compared to our emulated windows.  I
would like to push on this and bid farewell to our MDI-like interface
of windows within a window and finally switch to native windows with a
top level morph in each.

I have some very mixed feelings about this as the window theming work
that has been done is really top notch.  Absolutely wonderful - and
yet I'd like to throw it all away and go with the OS windows because
they're about a zillion times faster and more responsive (my wicked
fast 2GHZ Macbook Pro has about a half second delay to drag a window -
seriously - why?).

It works OK on the Mac OS X.  I'd like to find a windows and linux
person who would also like to work on this.  I have no idea if it
works on other platforms.  I also have no idea how I'm going to
extract my changes and ship them.  I've had to hack
HandMorph>>processEvents and lord knows what else in the quest to make
this fly.  I suppose I could file out a change set?

Anyhow - it sort-of works except I think I've exposed a bug in event
coordinate translation and I don't understand mouseFocus and
keyboardFocus - how is that suppose to work?  Or does it anymore?
Perhaps the folks who worked on recent event tweaks could enlighten me?

-Todd Blanchard

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



--
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.560 / Virus Database: 269.21.6/1323 - Release Date: 10/03/2008
11:07 a.m.



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Native Windows

johnmci
In reply to this post by Eagle Offshore
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/3862

It'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 <[hidden email]>   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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Native Windows

Eagle Offshore
In reply to this post by Carlos Crosetti-4
Have a look here:

http://wiki.squeak.org/squeak/3862

On Aug 17, 2009, at 5:25 PM, Carlos Crosetti wrote:

> is there a preview or screenshots of this  package?
>
> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]]En nombre de Eagle
> Offshore
> Enviado el: Lunes, 17 de Agosto de 2009 06:17 p.m.
> Para: [hidden email]
> Asunto: [Pharo-project] Native Windows
>
>
> I spent the weekend trying to get Ffenestri working in Pharo.   It was
> astonishingly painful, not the least of which because they are stored
> as half a dozen monticello archives and the MC tool merge tool
> requires you to address each conflict individually and the main change
> is that at lot of morphic methods now have comments and _ has been
> replaced with :=.   There must be a better way.
>
> Also, the files have a lot of patches to Delay and Process and really
> scary stuff like that and I was under the impression that those things
> had been reworked since and I didn't want to introduce any sort of
> regression so I didn't load them and focused on just making the plugin
> interface work and patching the event delivery code to deliver window
> events to the host windows (things like activate, iconize, close...).
>
> Debugging would be made a lot easier if I could identify a hook that
> would let me close the native window with the debugger launches, then
> reopen it when it proceeds - but I haven't a clue how that code works.
>
> Anyhow, I have a native window that opens with a sketch morph in it
> and it does pretty much what I expect.  Because of the OS doing window
> image caching and its own damage repair from an offscreen buffer - it
> feels wicked fast and responsive compared to our emulated windows.  I
> would like to push on this and bid farewell to our MDI-like interface
> of windows within a window and finally switch to native windows with a
> top level morph in each.
>
> I have some very mixed feelings about this as the window theming work
> that has been done is really top notch.  Absolutely wonderful - and
> yet I'd like to throw it all away and go with the OS windows because
> they're about a zillion times faster and more responsive (my wicked
> fast 2GHZ Macbook Pro has about a half second delay to drag a window -
> seriously - why?).
>
> It works OK on the Mac OS X.  I'd like to find a windows and linux
> person who would also like to work on this.  I have no idea if it
> works on other platforms.  I also have no idea how I'm going to
> extract my changes and ship them.  I've had to hack
> HandMorph>>processEvents and lord knows what else in the quest to make
> this fly.  I suppose I could file out a change set?
>
> Anyhow - it sort-of works except I think I've exposed a bug in event
> coordinate translation and I don't understand mouseFocus and
> keyboardFocus - how is that suppose to work?  Or does it anymore?
> Perhaps the folks who worked on recent event tweaks could enlighten  
> me?
>
> -Todd Blanchard
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>
> --
> Internal Virus Database is out-of-date.
> Checked by AVG.
> Version: 7.5.560 / Virus Database: 269.21.6/1323 - Release Date:  
> 10/03/2008
> 11:07 a.m.
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Native Windows

Eagle Offshore
In reply to this post by johnmci
Thanks so much for sharing on this.  

There seems to be a few caches of stuff stashed in various places.  None of it is exactly complete.  I've taken the bulk of it from the http://source.impara.de/HostWindows
and a bit from your experimental directory and looked at the plugins code in the VM tree and then just started trying to fix problems with event delivery.  I'd like to pull it all together and make it coherent on Windows, OS X and Unix.

Its really great that Pharo has integrated the HostMenus stuff - I think it would be cool to do HostWindows too.  Once you eliminate having to emulate the look of the windows - most widget sets look pretty similar and I think morphic widgets inside of real windows would keep things from looking too weird while preserving the benefits of having our widgets in Smalltalk.

Given Pharo's "take no prisoners" attitude, I think getting host windows working would allow a lot of really ugly code in PasteUpMorph and HandMorph to just go away.  Event delivery in Morphic is just totally incomprehensible and I'm finding it is broken when a second window is introduced as the mouse coordinates seem to be delivered window relative.  Its also really hard to work on because I keep junking images by making changes that wreck the UI.

-Todd Blanchard


On Aug 17, 2009, at 6:02 PM, John M McIntosh wrote:

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/3862

It'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 <[hidden email]>   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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Native Windows

johnmci
Before you run too far down the let's change Morphic path you should  
check with Igor I'm sure he was off a year back trying to hack  
Ffenestri into Morphic.

Tim and I gave that thought up when we considered there was 400 or so  
references to EventSenor  & Display many of which had no concept of  
window ownership in mind.


On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote:

> Thanks so much for sharing on this.
>
> There seems to be a few caches of stuff stashed in various places.  
> None of it is exactly complete.  I've taken the bulk of it from the http://source.impara.de/HostWindows
> and a bit from your experimental directory and looked at the plugins  
> code in the VM tree and then just started trying to fix problems  
> with event delivery.  I'd like to pull it all together and make it  
> coherent on Windows, OS X and Unix.
>
> Its really great that Pharo has integrated the HostMenus stuff - I  
> think it would be cool to do HostWindows too.  Once you eliminate  
> having to emulate the look of the windows - most widget sets look  
> pretty similar and I think morphic widgets inside of real windows  
> would keep things from looking too weird while preserving the  
> benefits of having our widgets in Smalltalk.
>
> Given Pharo's "take no prisoners" attitude, I think getting host  
> windows working would allow a lot of really ugly code in  
> PasteUpMorph and HandMorph to just go away.  Event delivery in  
> Morphic is just totally incomprehensible and I'm finding it is  
> broken when a second window is introduced as the mouse coordinates  
> seem to be delivered window relative.  Its also really hard to work  
> on because I keep junking images by making changes that wreck the UI.
>
> -Todd Blanchard
>

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Native Windows

David T. Lewis
In reply to this post by johnmci
On Mon, Aug 17, 2009 at 06:02:58PM -0700, John M McIntosh wrote:

> 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/3862
>
> It'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.

FWIW, I did make a start at getting this working on X11 for unix VMs,
but did not get the project finished.

Background:
  http://lists.squeakfoundation.org/pipermail/vm-dev/2008-July/001977.html

I can dig up the missing attachments if anyone is interested.

Bert may have done some related work since then.

Dave


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Native Windows

Igor Stasenko
In reply to this post by johnmci
2009/8/18 John M McIntosh <[hidden email]>:
> Before you run too far down the let's change Morphic path you should
> check with Igor I'm sure he was off a year back trying to hack
> Ffenestri into Morphic.
>
yes, yes i have an initial implementation of new hostwindows plugin
which moves/separates the windowing stuff from core VM functionality.

It then would be possible to build a VM which having no windowing
support at all, and works as a console application.

The problem with it, that i never did any windowing & event handling
on X windows or MacOS,
so its not so easy. I'm only hoping that my design fits well with
other platforms, not only win32.

I can publish the bits i'm done. Just say.
I am swamped by another projects , so i don't know when i could find a
time to finish it. :(

> Tim and I gave that thought up when we considered there was 400 or so
> references to EventSenor  & Display many of which had no concept of
> window ownership in mind.

Yes, this is a bit of pain.
My thought about it, is to keep sensor global, but
replace all refs to Display to 'self display' message send.
There are only a few methods which assigning new value to Display ,
which should be addressed separately.


>
>
> On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote:
>
>> Thanks so much for sharing on this.
>>
>> There seems to be a few caches of stuff stashed in various places.
>> None of it is exactly complete.  I've taken the bulk of it from the http://source.impara.de/HostWindows
>> and a bit from your experimental directory and looked at the plugins
>> code in the VM tree and then just started trying to fix problems
>> with event delivery.  I'd like to pull it all together and make it
>> coherent on Windows, OS X and Unix.
>>
>> Its really great that Pharo has integrated the HostMenus stuff - I
>> think it would be cool to do HostWindows too.  Once you eliminate
>> having to emulate the look of the windows - most widget sets look
>> pretty similar and I think morphic widgets inside of real windows
>> would keep things from looking too weird while preserving the
>> benefits of having our widgets in Smalltalk.
>>
>> Given Pharo's "take no prisoners" attitude, I think getting host
>> windows working would allow a lot of really ugly code in
>> PasteUpMorph and HandMorph to just go away.  Event delivery in
>> Morphic is just totally incomprehensible and I'm finding it is
>> broken when a second window is introduced as the mouse coordinates
>> seem to be delivered window relative.  Its also really hard to work
>> on because I keep junking images by making changes that wreck the UI.
>>
>> -Todd Blanchard
>>
>
> --
> =
> =
> =
> ========================================================================
> John M. McIntosh <[hidden email]>   Twitter:
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> =
> =
> =
> ========================================================================
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Native Windows

Eagle Offshore
I'm curious why you did a new plugin.   Does the existing one not work  
on windows?

I got the following from Bert on the state of the unix plugin:

"The plugin functions are still stubbed out, so you cannot actually  
open a second window, yet. But at least the hairy part of the work is  
done - I implemented the dispatching between the HostWindow plugin to  
the various display modules. This is more complex than on the other  
platforms, because the unix VM so far supports X11, Quartz,  
FrameBuffer, and Null display devices. But I did that part, now  
someone can simply implement e.g. the X11 functions to have it working  
in Linux. The only function I actually implemented was changing the  
title of the main Squeak window (window index 1).
"

-Todd Blanchard

On Aug 18, 2009, at 6:03 AM, Igor Stasenko wrote:

> 2009/8/18 John M McIntosh <[hidden email]>:
>> Before you run too far down the let's change Morphic path you should
>> check with Igor I'm sure he was off a year back trying to hack
>> Ffenestri into Morphic.
>>
> yes, yes i have an initial implementation of new hostwindows plugin
> which moves/separates the windowing stuff from core VM functionality.
>
> It then would be possible to build a VM which having no windowing
> support at all, and works as a console application.
>
> The problem with it, that i never did any windowing & event handling
> on X windows or MacOS,
> so its not so easy. I'm only hoping that my design fits well with
> other platforms, not only win32.
>
> I can publish the bits i'm done. Just say.
> I am swamped by another projects , so i don't know when i could find a
> time to finish it. :(
>
>> Tim and I gave that thought up when we considered there was 400 or so
>> references to EventSenor  & Display many of which had no concept of
>> window ownership in mind.
>
> Yes, this is a bit of pain.
> My thought about it, is to keep sensor global, but
> replace all refs to Display to 'self display' message send.
> There are only a few methods which assigning new value to Display ,
> which should be addressed separately.
>
>
>>
>>
>> On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote:
>>
>>> Thanks so much for sharing on this.
>>>
>>> There seems to be a few caches of stuff stashed in various places.
>>> None of it is exactly complete.  I've taken the bulk of it from  
>>> the http://source.impara.de/HostWindows
>>> and a bit from your experimental directory and looked at the plugins
>>> code in the VM tree and then just started trying to fix problems
>>> with event delivery.  I'd like to pull it all together and make it
>>> coherent on Windows, OS X and Unix.
>>>
>>> Its really great that Pharo has integrated the HostMenus stuff - I
>>> think it would be cool to do HostWindows too.  Once you eliminate
>>> having to emulate the look of the windows - most widget sets look
>>> pretty similar and I think morphic widgets inside of real windows
>>> would keep things from looking too weird while preserving the
>>> benefits of having our widgets in Smalltalk.
>>>
>>> Given Pharo's "take no prisoners" attitude, I think getting host
>>> windows working would allow a lot of really ugly code in
>>> PasteUpMorph and HandMorph to just go away.  Event delivery in
>>> Morphic is just totally incomprehensible and I'm finding it is
>>> broken when a second window is introduced as the mouse coordinates
>>> seem to be delivered window relative.  Its also really hard to work
>>> on because I keep junking images by making changes that wreck the  
>>> UI.
>>>
>>> -Todd Blanchard
>>>
>>
>> --
>> =
>> =
>> =
>> =
>> =
>> =
>> =====================================================================
>> John M. McIntosh <[hidden email]>   Twitter:
>> squeaker68882
>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>> =
>> =
>> =
>> =
>> =
>> =
>> =====================================================================
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Native Windows

Igor Stasenko
2009/8/18 Eagle Offshore <[hidden email]>:
> I'm curious why you did a new plugin.   Does the existing one not work
> on windows?
>
it works , but it duplicating a functionality which also present in
core platform files:
- creating a window
- processing events

so, the idea is to merge & unify all these bits into a single plugin
and also, make an extended API for
managing host windows.

> I got the following from Bert on the state of the unix plugin:
>
> "The plugin functions are still stubbed out, so you cannot actually
> open a second window, yet. But at least the hairy part of the work is
> done - I implemented the dispatching between the HostWindow plugin to
> the various display modules. This is more complex than on the other
> platforms, because the unix VM so far supports X11, Quartz,
> FrameBuffer, and Null display devices. But I did that part, now
> someone can simply implement e.g. the X11 functions to have it working
> in Linux. The only function I actually implemented was changing the
> title of the main Squeak window (window index 1).
> "
>
> -Todd Blanchard
>
> On Aug 18, 2009, at 6:03 AM, Igor Stasenko wrote:
>
>> 2009/8/18 John M McIntosh <[hidden email]>:
>>> Before you run too far down the let's change Morphic path you should
>>> check with Igor I'm sure he was off a year back trying to hack
>>> Ffenestri into Morphic.
>>>
>> yes, yes i have an initial implementation of new hostwindows plugin
>> which moves/separates the windowing stuff from core VM functionality.
>>
>> It then would be possible to build a VM which having no windowing
>> support at all, and works as a console application.
>>
>> The problem with it, that i never did any windowing & event handling
>> on X windows or MacOS,
>> so its not so easy. I'm only hoping that my design fits well with
>> other platforms, not only win32.
>>
>> I can publish the bits i'm done. Just say.
>> I am swamped by another projects , so i don't know when i could find a
>> time to finish it. :(
>>
>>> Tim and I gave that thought up when we considered there was 400 or so
>>> references to EventSenor  & Display many of which had no concept of
>>> window ownership in mind.
>>
>> Yes, this is a bit of pain.
>> My thought about it, is to keep sensor global, but
>> replace all refs to Display to 'self display' message send.
>> There are only a few methods which assigning new value to Display ,
>> which should be addressed separately.
>>
>>
>>>
>>>
>>> On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote:
>>>
>>>> Thanks so much for sharing on this.
>>>>
>>>> There seems to be a few caches of stuff stashed in various places.
>>>> None of it is exactly complete.  I've taken the bulk of it from
>>>> the http://source.impara.de/HostWindows
>>>> and a bit from your experimental directory and looked at the plugins
>>>> code in the VM tree and then just started trying to fix problems
>>>> with event delivery.  I'd like to pull it all together and make it
>>>> coherent on Windows, OS X and Unix.
>>>>
>>>> Its really great that Pharo has integrated the HostMenus stuff - I
>>>> think it would be cool to do HostWindows too.  Once you eliminate
>>>> having to emulate the look of the windows - most widget sets look
>>>> pretty similar and I think morphic widgets inside of real windows
>>>> would keep things from looking too weird while preserving the
>>>> benefits of having our widgets in Smalltalk.
>>>>
>>>> Given Pharo's "take no prisoners" attitude, I think getting host
>>>> windows working would allow a lot of really ugly code in
>>>> PasteUpMorph and HandMorph to just go away.  Event delivery in
>>>> Morphic is just totally incomprehensible and I'm finding it is
>>>> broken when a second window is introduced as the mouse coordinates
>>>> seem to be delivered window relative.  Its also really hard to work
>>>> on because I keep junking images by making changes that wreck the
>>>> UI.
>>>>
>>>> -Todd Blanchard
>>>>
>>>
>>> --
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =====================================================================
>>> John M. McIntosh <[hidden email]>   Twitter:
>>> squeaker68882
>>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =====================================================================
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Native Windows

Gary Chambers-4
I'll keep checking ,but, let me know when the basics are in and I'll provide
support in Polymorph.

Regards, Gary

----- Original Message -----
From: "Igor Stasenko" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, August 18, 2009 4:11 PM
Subject: Re: [Pharo-project] Native Windows


> 2009/8/18 Eagle Offshore <[hidden email]>:
>> I'm curious why you did a new plugin. Does the existing one not work
>> on windows?
>>
> it works , but it duplicating a functionality which also present in
> core platform files:
> - creating a window
> - processing events
>
> so, the idea is to merge & unify all these bits into a single plugin
> and also, make an extended API for
> managing host windows.
>
>> I got the following from Bert on the state of the unix plugin:
>>
>> "The plugin functions are still stubbed out, so you cannot actually
>> open a second window, yet. But at least the hairy part of the work is
>> done - I implemented the dispatching between the HostWindow plugin to
>> the various display modules. This is more complex than on the other
>> platforms, because the unix VM so far supports X11, Quartz,
>> FrameBuffer, and Null display devices. But I did that part, now
>> someone can simply implement e.g. the X11 functions to have it working
>> in Linux. The only function I actually implemented was changing the
>> title of the main Squeak window (window index 1).
>> "
>>
>> -Todd Blanchard
>>
>> On Aug 18, 2009, at 6:03 AM, Igor Stasenko wrote:
>>
>>> 2009/8/18 John M McIntosh <[hidden email]>:
>>>> Before you run too far down the let's change Morphic path you should
>>>> check with Igor I'm sure he was off a year back trying to hack
>>>> Ffenestri into Morphic.
>>>>
>>> yes, yes i have an initial implementation of new hostwindows plugin
>>> which moves/separates the windowing stuff from core VM functionality.
>>>
>>> It then would be possible to build a VM which having no windowing
>>> support at all, and works as a console application.
>>>
>>> The problem with it, that i never did any windowing & event handling
>>> on X windows or MacOS,
>>> so its not so easy. I'm only hoping that my design fits well with
>>> other platforms, not only win32.
>>>
>>> I can publish the bits i'm done. Just say.
>>> I am swamped by another projects , so i don't know when i could find a
>>> time to finish it. :(
>>>
>>>> Tim and I gave that thought up when we considered there was 400 or so
>>>> references to EventSenor & Display many of which had no concept of
>>>> window ownership in mind.
>>>
>>> Yes, this is a bit of pain.
>>> My thought about it, is to keep sensor global, but
>>> replace all refs to Display to 'self display' message send.
>>> There are only a few methods which assigning new value to Display ,
>>> which should be addressed separately.
>>>
>>>
>>>>
>>>>
>>>> On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote:
>>>>
>>>>> Thanks so much for sharing on this.
>>>>>
>>>>> There seems to be a few caches of stuff stashed in various places.
>>>>> None of it is exactly complete. I've taken the bulk of it from
>>>>> the http://source.impara.de/HostWindows
>>>>> and a bit from your experimental directory and looked at the plugins
>>>>> code in the VM tree and then just started trying to fix problems
>>>>> with event delivery. I'd like to pull it all together and make it
>>>>> coherent on Windows, OS X and Unix.
>>>>>
>>>>> Its really great that Pharo has integrated the HostMenus stuff - I
>>>>> think it would be cool to do HostWindows too. Once you eliminate
>>>>> having to emulate the look of the windows - most widget sets look
>>>>> pretty similar and I think morphic widgets inside of real windows
>>>>> would keep things from looking too weird while preserving the
>>>>> benefits of having our widgets in Smalltalk.
>>>>>
>>>>> Given Pharo's "take no prisoners" attitude, I think getting host
>>>>> windows working would allow a lot of really ugly code in
>>>>> PasteUpMorph and HandMorph to just go away. Event delivery in
>>>>> Morphic is just totally incomprehensible and I'm finding it is
>>>>> broken when a second window is introduced as the mouse coordinates
>>>>> seem to be delivered window relative. Its also really hard to work
>>>>> on because I keep junking images by making changes that wreck the
>>>>> UI.
>>>>>
>>>>> -Todd Blanchard
>>>>>
>>>>
>>>> --
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =====================================================================
>>>> John M. McIntosh <[hidden email]> Twitter:
>>>> squeaker68882
>>>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =====================================================================
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Native Windows

Eagle Offshore
What is the "canonical" window class in Pharo?  I see SystemWindow has  
been subclassed and there's a separate builder for the other window  
that is otherwise a copy of the default builder.  Where was that going?


On Aug 18, 2009, at 10:01 AM, Gary Chambers wrote:

> I'll keep checking ,but, let me know when the basics are in and I'll  
> provide
> support in Polymorph.
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Igor Stasenko" <[hidden email]>
> To: <[hidden email]>
> Sent: Tuesday, August 18, 2009 4:11 PM
> Subject: Re: [Pharo-project] Native Windows
>
>
>> 2009/8/18 Eagle Offshore <[hidden email]>:
>>> I'm curious why you did a new plugin. Does the existing one not work
>>> on windows?
>>>
>> it works , but it duplicating a functionality which also present in
>> core platform files:
>> - creating a window
>> - processing events
>>
>> so, the idea is to merge & unify all these bits into a single plugin
>> and also, make an extended API for
>> managing host windows.
>>
>>> I got the following from Bert on the state of the unix plugin:
>>>
>>> "The plugin functions are still stubbed out, so you cannot actually
>>> open a second window, yet. But at least the hairy part of the work  
>>> is
>>> done - I implemented the dispatching between the HostWindow plugin  
>>> to
>>> the various display modules. This is more complex than on the other
>>> platforms, because the unix VM so far supports X11, Quartz,
>>> FrameBuffer, and Null display devices. But I did that part, now
>>> someone can simply implement e.g. the X11 functions to have it  
>>> working
>>> in Linux. The only function I actually implemented was changing the
>>> title of the main Squeak window (window index 1).
>>> "
>>>
>>> -Todd Blanchard
>>>
>>> On Aug 18, 2009, at 6:03 AM, Igor Stasenko wrote:
>>>
>>>> 2009/8/18 John M McIntosh <[hidden email]>:
>>>>> Before you run too far down the let's change Morphic path you  
>>>>> should
>>>>> check with Igor I'm sure he was off a year back trying to hack
>>>>> Ffenestri into Morphic.
>>>>>
>>>> yes, yes i have an initial implementation of new hostwindows plugin
>>>> which moves/separates the windowing stuff from core VM  
>>>> functionality.
>>>>
>>>> It then would be possible to build a VM which having no windowing
>>>> support at all, and works as a console application.
>>>>
>>>> The problem with it, that i never did any windowing & event  
>>>> handling
>>>> on X windows or MacOS,
>>>> so its not so easy. I'm only hoping that my design fits well with
>>>> other platforms, not only win32.
>>>>
>>>> I can publish the bits i'm done. Just say.
>>>> I am swamped by another projects , so i don't know when i could  
>>>> find a
>>>> time to finish it. :(
>>>>
>>>>> Tim and I gave that thought up when we considered there was 400  
>>>>> or so
>>>>> references to EventSenor & Display many of which had no concept of
>>>>> window ownership in mind.
>>>>
>>>> Yes, this is a bit of pain.
>>>> My thought about it, is to keep sensor global, but
>>>> replace all refs to Display to 'self display' message send.
>>>> There are only a few methods which assigning new value to Display ,
>>>> which should be addressed separately.
>>>>
>>>>
>>>>>
>>>>>
>>>>> On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote:
>>>>>
>>>>>> Thanks so much for sharing on this.
>>>>>>
>>>>>> There seems to be a few caches of stuff stashed in various  
>>>>>> places.
>>>>>> None of it is exactly complete. I've taken the bulk of it from
>>>>>> the http://source.impara.de/HostWindows
>>>>>> and a bit from your experimental directory and looked at the  
>>>>>> plugins
>>>>>> code in the VM tree and then just started trying to fix problems
>>>>>> with event delivery. I'd like to pull it all together and make it
>>>>>> coherent on Windows, OS X and Unix.
>>>>>>
>>>>>> Its really great that Pharo has integrated the HostMenus stuff  
>>>>>> - I
>>>>>> think it would be cool to do HostWindows too. Once you eliminate
>>>>>> having to emulate the look of the windows - most widget sets look
>>>>>> pretty similar and I think morphic widgets inside of real windows
>>>>>> would keep things from looking too weird while preserving the
>>>>>> benefits of having our widgets in Smalltalk.
>>>>>>
>>>>>> Given Pharo's "take no prisoners" attitude, I think getting host
>>>>>> windows working would allow a lot of really ugly code in
>>>>>> PasteUpMorph and HandMorph to just go away. Event delivery in
>>>>>> Morphic is just totally incomprehensible and I'm finding it is
>>>>>> broken when a second window is introduced as the mouse  
>>>>>> coordinates
>>>>>> seem to be delivered window relative. Its also really hard to  
>>>>>> work
>>>>>> on because I keep junking images by making changes that wreck the
>>>>>> UI.
>>>>>>
>>>>>> -Todd Blanchard
>>>>>>
>>>>>
>>>>> --
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> ==================================================================
>>>>> John M. McIntosh <[hidden email]> Twitter:
>>>>> squeaker68882
>>>>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> ==================================================================
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- 
>>>>> project
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko AKA sig.
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Native Windows

Stéphane Ducasse
In reply to this post by Eagle Offshore
Hi todd

this is cool that you work on that. I imagine that it will not be an  
easy task. One of the goal of pharo and effort of mike was to
make sure that we get a better event system so that we can plug  
together different UI.
Now about PasteUpMorph cleaning I do not know. What is clear to me is  
that a registeration for menu is missing.

Keep pushing.
I guess that this is the kind of work that is not fixed in a couple of  
days.

On Aug 18, 2009, at 3:27 AM, Eagle Offshore wrote:

> Thanks so much for sharing on this.
>
> There seems to be a few caches of stuff stashed in various places.  
> None of it is exactly complete.  I've taken the bulk of it from the http://source.impara.de/HostWindows
> and a bit from your experimental directory and looked at the plugins  
> code in the VM tree and then just started trying to fix problems  
> with event delivery.  I'd like to pull it all together and make it  
> coherent on Windows, OS X and Unix.
>
> Its really great that Pharo has integrated the HostMenus stuff - I  
> think it would be cool to do HostWindows too.  Once you eliminate  
> having to emulate the look of the windows - most widget sets look  
> pretty similar and I think morphic widgets inside of real windows  
> would keep things from looking too weird while preserving the  
> benefits of having our widgets in Smalltalk.
>
> Given Pharo's "take no prisoners" attitude, I think getting host  
> windows working would allow a lot of really ugly code in  
> PasteUpMorph and HandMorph to just go away.  Event delivery in  
> Morphic is just totally incomprehensible and I'm finding it is  
> broken when a second window is introduced as the mouse coordinates  
> seem to be delivered window relative.  Its also really hard to work  
> on because I keep junking images by making changes that wreck the UI.
>
> -Todd Blanchard
>
>
> On Aug 17, 2009, at 6:02 PM, John M McIntosh wrote:
>
>> 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/3862
>>
>> It'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 <[hidden email]>   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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Native Windows

Gary Chambers-4
In reply to this post by Eagle Offshore
We use StandardWindow that provides some benefits over SystemWindow.
(ability to open full-screen for deployed applications, prevention of
dragging except via titlebar etc.)

As for builders, I assume you are refering to PluggableStandardWindow (used
via PluggableWindowSpec/PSToolBuilder).

Regards, Gary

----- Original Message -----
From: "Eagle Offshore" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, August 18, 2009 7:33 PM
Subject: Re: [Pharo-project] Native Windows


> What is the "canonical" window class in Pharo?  I see SystemWindow has
> been subclassed and there's a separate builder for the other window
> that is otherwise a copy of the default builder.  Where was that going?
>
>
> On Aug 18, 2009, at 10:01 AM, Gary Chambers wrote:
>
>> I'll keep checking ,but, let me know when the basics are in and I'll
>> provide
>> support in Polymorph.
>>
>> Regards, Gary
>>
>> ----- Original Message -----
>> From: "Igor Stasenko" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Tuesday, August 18, 2009 4:11 PM
>> Subject: Re: [Pharo-project] Native Windows
>>
>>
>>> 2009/8/18 Eagle Offshore <[hidden email]>:
>>>> I'm curious why you did a new plugin. Does the existing one not work
>>>> on windows?
>>>>
>>> it works , but it duplicating a functionality which also present in
>>> core platform files:
>>> - creating a window
>>> - processing events
>>>
>>> so, the idea is to merge & unify all these bits into a single plugin
>>> and also, make an extended API for
>>> managing host windows.
>>>
>>>> I got the following from Bert on the state of the unix plugin:
>>>>
>>>> "The plugin functions are still stubbed out, so you cannot actually
>>>> open a second window, yet. But at least the hairy part of the work
>>>> is
>>>> done - I implemented the dispatching between the HostWindow plugin
>>>> to
>>>> the various display modules. This is more complex than on the other
>>>> platforms, because the unix VM so far supports X11, Quartz,
>>>> FrameBuffer, and Null display devices. But I did that part, now
>>>> someone can simply implement e.g. the X11 functions to have it
>>>> working
>>>> in Linux. The only function I actually implemented was changing the
>>>> title of the main Squeak window (window index 1).
>>>> "
>>>>
>>>> -Todd Blanchard
>>>>
>>>> On Aug 18, 2009, at 6:03 AM, Igor Stasenko wrote:
>>>>
>>>>> 2009/8/18 John M McIntosh <[hidden email]>:
>>>>>> Before you run too far down the let's change Morphic path you
>>>>>> should
>>>>>> check with Igor I'm sure he was off a year back trying to hack
>>>>>> Ffenestri into Morphic.
>>>>>>
>>>>> yes, yes i have an initial implementation of new hostwindows plugin
>>>>> which moves/separates the windowing stuff from core VM
>>>>> functionality.
>>>>>
>>>>> It then would be possible to build a VM which having no windowing
>>>>> support at all, and works as a console application.
>>>>>
>>>>> The problem with it, that i never did any windowing & event
>>>>> handling
>>>>> on X windows or MacOS,
>>>>> so its not so easy. I'm only hoping that my design fits well with
>>>>> other platforms, not only win32.
>>>>>
>>>>> I can publish the bits i'm done. Just say.
>>>>> I am swamped by another projects , so i don't know when i could
>>>>> find a
>>>>> time to finish it. :(
>>>>>
>>>>>> Tim and I gave that thought up when we considered there was 400
>>>>>> or so
>>>>>> references to EventSenor & Display many of which had no concept of
>>>>>> window ownership in mind.
>>>>>
>>>>> Yes, this is a bit of pain.
>>>>> My thought about it, is to keep sensor global, but
>>>>> replace all refs to Display to 'self display' message send.
>>>>> There are only a few methods which assigning new value to Display ,
>>>>> which should be addressed separately.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote:
>>>>>>
>>>>>>> Thanks so much for sharing on this.
>>>>>>>
>>>>>>> There seems to be a few caches of stuff stashed in various
>>>>>>> places.
>>>>>>> None of it is exactly complete. I've taken the bulk of it from
>>>>>>> the http://source.impara.de/HostWindows
>>>>>>> and a bit from your experimental directory and looked at the
>>>>>>> plugins
>>>>>>> code in the VM tree and then just started trying to fix problems
>>>>>>> with event delivery. I'd like to pull it all together and make it
>>>>>>> coherent on Windows, OS X and Unix.
>>>>>>>
>>>>>>> Its really great that Pharo has integrated the HostMenus stuff
>>>>>>> - I
>>>>>>> think it would be cool to do HostWindows too. Once you eliminate
>>>>>>> having to emulate the look of the windows - most widget sets look
>>>>>>> pretty similar and I think morphic widgets inside of real windows
>>>>>>> would keep things from looking too weird while preserving the
>>>>>>> benefits of having our widgets in Smalltalk.
>>>>>>>
>>>>>>> Given Pharo's "take no prisoners" attitude, I think getting host
>>>>>>> windows working would allow a lot of really ugly code in
>>>>>>> PasteUpMorph and HandMorph to just go away. Event delivery in
>>>>>>> Morphic is just totally incomprehensible and I'm finding it is
>>>>>>> broken when a second window is introduced as the mouse
>>>>>>> coordinates
>>>>>>> seem to be delivered window relative. Its also really hard to
>>>>>>> work
>>>>>>> on because I keep junking images by making changes that wreck the
>>>>>>> UI.
>>>>>>>
>>>>>>> -Todd Blanchard
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> ==================================================================
>>>>>> John M. McIntosh <[hidden email]> Twitter:
>>>>>> squeaker68882
>>>>>> Corporate Smalltalk Consulting Ltd.
>>>>>> http://www.smalltalkconsulting.com
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> ==================================================================
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pharo-project mailing list
>>>>>> [hidden email]
>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
>>>>>> project
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Igor Stasenko AKA sig.
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Native Windows

Henrik Sperre Johansen
In reply to this post by Eagle Offshore
Made a small experiment the other week of, sharing in case someone's interested.
It renders an arbitrary SystemWindow in a ffenestri-window (on mac at least) in the simplest way I could think of at least. (not efficient (3MB or so per window), nor exactly pretty), but it makes for a nice demo imo, even though the window is unresponsible to input. 
Render update on resizing works, with a faux render loop instead of real window resize event response :) 
In theory you can do openInWorld on the same window, and manipulate that,  but I wouldn't recommend it, as the faux loop in the workspace is in no way synchronized with World Drawing and you will get DNU's after awhile.

Install the changesets from ftp.smalltalkconsulting.com/experimental/Ffenestri/ first, then the changeset in the attached zip.
Doit'ing the workspace in the .rtf should then open a Hierarchy Browser on HierarchyBrowser, read comments there for more details :) 
Should work on any SystemWindow instance, though actually getting to an instance before it's opened can be surprisingly hard...

Cheers,
Henry
 


On Aug 18, 2009, at 8:33 39PM, Eagle Offshore wrote:

What is the "canonical" window class in Pharo?  I see SystemWindow has  
been subclassed and there's a separate builder for the other window  
that is otherwise a copy of the default builder.  Where was that going?


On Aug 18, 2009, at 10:01 AM, Gary Chambers wrote:

I'll keep checking ,but, let me know when the basics are in and I'll  
provide
support in Polymorph.

Regards, Gary

----- Original Message -----
From: "Igor Stasenko" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, August 18, 2009 4:11 PM
Subject: Re: [Pharo-project] Native Windows


2009/8/18 Eagle Offshore <[hidden email]>:
I'm curious why you did a new plugin. Does the existing one not work
on windows?

it works , but it duplicating a functionality which also present in
core platform files:
- creating a window
- processing events

so, the idea is to merge & unify all these bits into a single plugin
and also, make an extended API for
managing host windows.

I got the following from Bert on the state of the unix plugin:

"The plugin functions are still stubbed out, so you cannot actually
open a second window, yet. But at least the hairy part of the work  
is
done - I implemented the dispatching between the HostWindow plugin  
to
the various display modules. This is more complex than on the other
platforms, because the unix VM so far supports X11, Quartz,
FrameBuffer, and Null display devices. But I did that part, now
someone can simply implement e.g. the X11 functions to have it  
working
in Linux. The only function I actually implemented was changing the
title of the main Squeak window (window index 1).
"

-Todd Blanchard

On Aug 18, 2009, at 6:03 AM, Igor Stasenko wrote:

2009/8/18 John M McIntosh <[hidden email]>:
Before you run too far down the let's change Morphic path you  
should
check with Igor I'm sure he was off a year back trying to hack
Ffenestri into Morphic.

yes, yes i have an initial implementation of new hostwindows plugin
which moves/separates the windowing stuff from core VM  
functionality.

It then would be possible to build a VM which having no windowing
support at all, and works as a console application.

The problem with it, that i never did any windowing & event  
handling
on X windows or MacOS,
so its not so easy. I'm only hoping that my design fits well with
other platforms, not only win32.

I can publish the bits i'm done. Just say.
I am swamped by another projects , so i don't know when i could  
find a
time to finish it. :(

Tim and I gave that thought up when we considered there was 400  
or so
references to EventSenor & Display many of which had no concept of
window ownership in mind.

Yes, this is a bit of pain.
My thought about it, is to keep sensor global, but
replace all refs to Display to 'self display' message send.
There are only a few methods which assigning new value to Display ,
which should be addressed separately.




On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote:

Thanks so much for sharing on this.

There seems to be a few caches of stuff stashed in various  
places.
None of it is exactly complete. I've taken the bulk of it from
the http://source.impara.de/HostWindows
and a bit from your experimental directory and looked at the  
plugins
code in the VM tree and then just started trying to fix problems
with event delivery. I'd like to pull it all together and make it
coherent on Windows, OS X and Unix.

Its really great that Pharo has integrated the HostMenus stuff  
- I
think it would be cool to do HostWindows too. Once you eliminate
having to emulate the look of the windows - most widget sets look
pretty similar and I think morphic widgets inside of real windows
would keep things from looking too weird while preserving the
benefits of having our widgets in Smalltalk.

Given Pharo's "take no prisoners" attitude, I think getting host
windows working would allow a lot of really ugly code in
PasteUpMorph and HandMorph to just go away. Event delivery in
Morphic is just totally incomprehensible and I'm finding it is
broken when a second window is introduced as the mouse  
coordinates
seem to be delivered window relative. Its also really hard to  
work
on because I keep junking images by making changes that wreck the
UI.

-Todd Blanchard


--
=
=
=
=
=
=
=
=
=
==================================================================
John M. McIntosh <[hidden email]> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
=
=
=
=
=
=
==================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
project




--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

FFenestriSystemWindowsExample.zip (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Native Windows

Eagle Offshore
I've gotten a bit further but I'm finding it maddening in that quite often the whole thing will freeze for no apparent reason and with no clue as to what it is doing.

I've just been working with the transcript.  It launches in another window, it resizes properly, you can type into it, select all and delete, etc....

However I cannot get it to update in the background nicely (which is kind of the point for Transcript) although it updates just fine when in the foreground.  

I've implemented enough Morph protocol in DisplayHostWindow to allow it to serve as the root morph (although it actually holds a single morph that it keeps the same size as its window).  The key method seems to be

invalidRect: damageRect from: aMorph
self redrawInBounds: damageRect.
self forceToScreen: damageRect

which, if I implement it, works briefly and then goes slower and slower and eventually hangs.

I tried using CachingMorph as the root morph - this results in fullBounds based infinite recursion.  Somehow I think this is at the root of Morphic's painful inefficiency.  I think the layout/damage management code is trying to do too much.

I've put about 40 hours into trying to track this - I'm taking a little break before diving in again.  My head is quite bruised from banging it on that wall.

-Todd Blanchard

On Aug 25, 2009, at 1:24 AM, Henrik Johansen wrote:

Made a small experiment the other week of, sharing in case someone's interested.
It renders an arbitrary SystemWindow in a ffenestri-window (on mac at least) in the simplest way I could think of at least. (not efficient (3MB or so per window), nor exactly pretty), but it makes for a nice demo imo, even though the window is unresponsible to input. 
Render update on resizing works, with a faux render loop instead of real window resize event response :) 
In theory you can do openInWorld on the same window, and manipulate that,  but I wouldn't recommend it, as the faux loop in the workspace is in no way synchronized with World Drawing and you will get DNU's after awhile.

Install the changesets from ftp.smalltalkconsulting.com/experimental/Ffenestri/ first, then the changeset in the attached zip.
Doit'ing the workspace in the .rtf should then open a Hierarchy Browser on HierarchyBrowser, read comments there for more details :) 
Should work on any SystemWindow instance, though actually getting to an instance before it's opened can be surprisingly hard...

Cheers,
Henry
 
<FFenestriSystemWindowsExample.zip>

On Aug 18, 2009, at 8:33 39PM, Eagle Offshore wrote:

What is the "canonical" window class in Pharo?  I see SystemWindow has  
been subclassed and there's a separate builder for the other window  
that is otherwise a copy of the default builder.  Where was that going?


On Aug 18, 2009, at 10:01 AM, Gary Chambers wrote:

I'll keep checking ,but, let me know when the basics are in and I'll  
provide
support in Polymorph.

Regards, Gary

----- Original Message -----
From: "Igor Stasenko" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, August 18, 2009 4:11 PM
Subject: Re: [Pharo-project] Native Windows


2009/8/18 Eagle Offshore <[hidden email]>:
I'm curious why you did a new plugin. Does the existing one not work
on windows?

it works , but it duplicating a functionality which also present in
core platform files:
- creating a window
- processing events

so, the idea is to merge & unify all these bits into a single plugin
and also, make an extended API for
managing host windows.

I got the following from Bert on the state of the unix plugin:

"The plugin functions are still stubbed out, so you cannot actually
open a second window, yet. But at least the hairy part of the work  
is
done - I implemented the dispatching between the HostWindow plugin  
to
the various display modules. This is more complex than on the other
platforms, because the unix VM so far supports X11, Quartz,
FrameBuffer, and Null display devices. But I did that part, now
someone can simply implement e.g. the X11 functions to have it  
working
in Linux. The only function I actually implemented was changing the
title of the main Squeak window (window index 1).
"

-Todd Blanchard

On Aug 18, 2009, at 6:03 AM, Igor Stasenko wrote:

2009/8/18 John M McIntosh <[hidden email]>:
Before you run too far down the let's change Morphic path you  
should
check with Igor I'm sure he was off a year back trying to hack
Ffenestri into Morphic.

yes, yes i have an initial implementation of new hostwindows plugin
which moves/separates the windowing stuff from core VM  
functionality.

It then would be possible to build a VM which having no windowing
support at all, and works as a console application.

The problem with it, that i never did any windowing & event  
handling
on X windows or MacOS,
so its not so easy. I'm only hoping that my design fits well with
other platforms, not only win32.

I can publish the bits i'm done. Just say.
I am swamped by another projects , so i don't know when i could  
find a
time to finish it. :(

Tim and I gave that thought up when we considered there was 400  
or so
references to EventSenor & Display many of which had no concept of
window ownership in mind.

Yes, this is a bit of pain.
My thought about it, is to keep sensor global, but
replace all refs to Display to 'self display' message send.
There are only a few methods which assigning new value to Display ,
which should be addressed separately.




On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote:

Thanks so much for sharing on this.

There seems to be a few caches of stuff stashed in various  
places.
None of it is exactly complete. I've taken the bulk of it from
the http://source.impara.de/HostWindows
and a bit from your experimental directory and looked at the  
plugins
code in the VM tree and then just started trying to fix problems
with event delivery. I'd like to pull it all together and make it
coherent on Windows, OS X and Unix.

Its really great that Pharo has integrated the HostMenus stuff  
- I
think it would be cool to do HostWindows too. Once you eliminate
having to emulate the look of the windows - most widget sets look
pretty similar and I think morphic widgets inside of real windows
would keep things from looking too weird while preserving the
benefits of having our widgets in Smalltalk.

Given Pharo's "take no prisoners" attitude, I think getting host
windows working would allow a lot of really ugly code in
PasteUpMorph and HandMorph to just go away. Event delivery in
Morphic is just totally incomprehensible and I'm finding it is
broken when a second window is introduced as the mouse  
coordinates
seem to be delivered window relative. Its also really hard to  
work
on because I keep junking images by making changes that wreck the
UI.

-Todd Blanchard


--
=
=
=
=
=
=
=
=
=
==================================================================
John M. McIntosh <[hidden email]> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
=
=
=
=
=
=
==================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
project




--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project