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" <siguctua@gmail.com>
To: <Pharo-project@lists.gforge.inria.fr>
Sent: Tuesday, August 18, 2009 4:11 PM
Subject: Re: [Pharo-project] Native Windows


2009/8/18 Eagle Offshore <eagleoffshore@mac.com>:
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 <johnmci@smalltalkconsulting.com>:
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 <johnmci@smalltalkconsulting.com> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
=
=
=
=
=
=
==================================================================





_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
project




--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project