Ffenestri (multiple host window support), and Mac Host Menus

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

Ffenestri (multiple host window support), and Mac Host Menus

johnmci
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.

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



Reply | Threaded
Open this post in threaded view
|

Re: Ffenestri (multiple host window support), and Mac Host Menus

David T. Lewis
On Mon, Jan 15, 2007 at 02:48:02PM -0800, John M McIntosh wrote:

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

Dumb question: There does not seem to be a HostWindowPlugin implementation
in platforms/unix. If such a thing existed, would it be a useful thing?

I don't have either a Mac or a RiscOS box, so I'm not entirely clear
as to whether Areithfa Ffenestri does something useful now, or if
it's more of an R&D exercise awaiting future development work.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Ffenestri (multiple host window support), and Mac Host Menus

timrowledge

On 15-Jan-07, at 5:24 PM, David T. Lewis wrote:

>
> Dumb question: There does not seem to be a HostWindowPlugin  
> implementation
> in platforms/unix. If such a thing existed, would it be a useful  
> thing?

It would; and I can't find anything in my mailfiles to suggest that  
it has been done yet.
>
> I don't have either a Mac or a RiscOS box, so I'm not entirely clear
> as to whether Areithfa Ffenestri does something useful now, or if
> it's more of an R&D exercise awaiting future development work.

Right now it is a bit of both. The low-level stuff seems to me to be  
complete but we need the higher level stuff to actually make sensible  
use of it.
You can:-
   create
   decorate
   show
   hide
   delete
   move
   query state
   display on
   get event info from
host windows. John did some hacks to map Squeak projects to windows  
as a proof of concept but I don't think that is the way to go. I'd  
rather see it having any morph in a separate host window, including  
allowing pasteupmorphs (I think that's the chap) so that you can do  
something MDI-like if you really want to. John also did host menu  
stuff and it appears to work ok on Windows as well. I'd recommend  
having a pesudo-platform that provides sorta-host popup menus by  
using an undecorated window to display a Squeak menu as well - since  
Mac and Windows host menus are so utterly f**%#ed up. In my opinion.  
Which is, of course, The Truth.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: LB: connect Line-voltage to BITNET



Reply | Threaded
Open this post in threaded view
|

Re: Ffenestri (multiple host window support), and Mac Host Menus

johnmci

On Jan 15, 2007, at 5:44 PM, tim Rowledge wrote:

> host windows. John did some hacks to map Squeak projects to windows  
> as a proof of concept but I don't think that is the way to go.

Well actually it was to map tweak projects to a window because a  
tweak world has a display surface and an event queue. So when the VM  
flows the events
we dispatch the event to the proper tweak world event queue based on  
which host window the weak world thinks it is managing and possibly  
alter the coordinates.
  And when the tweak world draws to the tweak surface we ensure it  
draws to the proper host window surface.

Normally the tweak project's event queue would just be filled with  
events based on focus, and the surface used would be Display.

Worked quite nicely, not a HACK....

What was a hack was the Morphic project integration I did. On a  
morphic project switch I would switch out what the Display was, and  
of course on
window activation ensure the correct Morphic project was switched to  
and the events for the proper window would flow. Because the logic in  
2004, perhaps today, assumes only one morphic project was running  
that was reasonable.

In all of this, if one looks at the SUnit you'll see how to interact  
with a window and draw to it without any regard to what Morphic thinks.

Sadly looking for Sensor and or Display usage will cause one's blood  
to run thin... The fun part is that in *lots* of usage there is no  
context to decide which
drawing surface we are dealing with...

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



Reply | Threaded
Open this post in threaded view
|

Re: Ffenestri (multiple host window support), and Mac Host Menus

Edgar J. De Cleene-2
In reply to this post by johnmci



El 1/15/07 7:48 PM, "John M McIntosh" <[hidden email]>
escribió:

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

I have the John files.
It's 5.36 here and just reading all.
Later I report any relevant issues.

Again I said you John  are not a master, you are one indispensable Squeaker.

Edgar



       

       
               
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas


Reply | Threaded
Open this post in threaded view
|

Re: Ffenestri (multiple host window support), and Mac Host Menus

Edgar J. De Cleene-2
In reply to this post by johnmci

All SUnit test are green.
The quit command of new menu do not works. Ask for save or no , but no
quits.
The usual World menu is working, if this helps you

Host Windows are nice !!!!

Edgar



       

       
               
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas 


Reply | Threaded
Open this post in threaded view
|

Re: Ffenestri (multiple host window support), and Mac Host Menus

stephane ducasse
In reply to this post by johnmci
Hi guys

Do you think that this is reasonable to rescue this project. Because  
after reading your comment I have the impression that
I was wrong suggesting to have a look at what you did.

Stef

On 16 janv. 07, at 03:16, John M McIntosh wrote:

>
> On Jan 15, 2007, at 5:44 PM, tim Rowledge wrote:
>
>> host windows. John did some hacks to map Squeak projects to  
>> windows as a proof of concept but I don't think that is the way to  
>> go.
>
> Well actually it was to map tweak projects to a window because a  
> tweak world has a display surface and an event queue. So when the  
> VM flows the events
> we dispatch the event to the proper tweak world event queue based  
> on which host window the weak world thinks it is managing and  
> possibly alter the coordinates.
>  And when the tweak world draws to the tweak surface we ensure it  
> draws to the proper host window surface.
>
> Normally the tweak project's event queue would just be filled with  
> events based on focus, and the surface used would be Display.
>
> Worked quite nicely, not a HACK....
>
> What was a hack was the Morphic project integration I did. On a  
> morphic project switch I would switch out what the Display was, and  
> of course on
> window activation ensure the correct Morphic project was switched  
> to and the events for the proper window would flow. Because the  
> logic in 2004, perhaps today, assumes only one morphic project was  
> running that was reasonable.
>
> In all of this, if one looks at the SUnit you'll see how to  
> interact with a window and draw to it without any regard to what  
> Morphic thinks.
>
> Sadly looking for Sensor and or Display usage will cause one's  
> blood to run thin... The fun part is that in *lots* of usage there  
> is no context to decide which
> drawing surface we are dealing with...
>
> --
> ======================================================================
> =====
> John M. McIntosh <[hidden email]>
> Corporate Smalltalk Consulting Ltd.  http://
> www.smalltalkconsulting.com
> ======================================================================
> =====
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Ffenestri (multiple host window support), and Mac Host Menus

Bert Freudenberg
In reply to this post by timrowledge
On Jan 16, 2007, at 2:44 , tim Rowledge wrote:

> On 15-Jan-07, at 5:24 PM, David T. Lewis wrote:
>
>>
>> Dumb question: There does not seem to be a HostWindowPlugin  
>> implementation
>> in platforms/unix. If such a thing existed, would it be a useful  
>> thing?
>
> It would; and I can't find anything in my mailfiles to suggest that  
> it has been done yet.

Has never been implemented to my knowledge. I'd *very* much like to  
see this working on unix! With all major platforms supported and a  
Morphic refactoring underway (which hopefully would get rid of the  
global Display and Sensor access) we would get one major complaint  
about Squeak's "real-world" usefulness out of the way ...

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Ffenestri (multiple host window support), and Mac Host Menus

johnmci
In reply to this post by Edgar J. De Cleene-2
Well the host menu quit command does is


        applicationQuit ifNotNil: [applicationQuit handler:
                [:evt | Smalltalk snapshot:
                        (self confirm: 'Save changes before quitting?'
                                orCancel: [^ self])
                                andQuit: true]].

mmm well that is wrong, SmalltalkImage current...
and the error handler in the menu  handler code traps the error so  
you don't see it.

I've posted a fix to my ftp site and idisk.

HostMenus-Fixes-1.1.cs



On Jan 16, 2007, at 1:14 AM, ---- ---- wrote:

>
> All SUnit test are green.
> The quit command of new menu do not works. Ask for save or no , but no
> quits.
> The usual World menu is working, if this helps you
>
> Host Windows are nice !!!!
>
> Edgar
>

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



Reply | Threaded
Open this post in threaded view
|

Re: Ffenestri (multiple host window support), and Mac Host Menus

stephane ducasse
In reply to this post by Bert Freudenberg
>>> Dumb question: There does not seem to be a HostWindowPlugin  
>>> implementation
>>> in platforms/unix. If such a thing existed, would it be a useful  
>>> thing?
>>
>> It would; and I can't find anything in my mailfiles to suggest  
>> that it has been done yet.
>
> Has never been implemented to my knowledge. I'd *very* much like to  
> see this working on unix! With all major platforms supported and a  
> Morphic refactoring underway (which hopefully would get rid of the  
> global Display and Sensor access) we would get one major complaint  
> about Squeak's "real-world" usefulness out of the way ...

Yes this is why I was mentioning it for 3.10 but if this is not ready  
what should be done? May be some people
may join and do something.

Stef

Reply | Threaded
Open this post in threaded view
|

Re: Ffenestri (multiple host window support), and Mac Host Menus

johnmci
Ok, well all I did was spend some time to confirm that the host  
window and mac menu support works in a 3.10 image, plus works for  
macintosh
powerpc and macintel. I believe Impara has a windows VM for the host  
window plugin but I'm not sure where.  Having one for unix would be  
great too.

Both Sophie and Scratch use the mac menu logic, so that is in actual  
use. However no-one I know is using the multiple window support.

On Jan 16, 2007, at 12:08 PM, stephane ducasse wrote:

>>>> Dumb question: There does not seem to be a HostWindowPlugin  
>>>> implementation
>>>> in platforms/unix. If such a thing existed, would it be a useful  
>>>> thing?
>>>
>>> It would; and I can't find anything in my mailfiles to suggest  
>>> that it has been done yet.
>>
>> Has never been implemented to my knowledge. I'd *very* much like  
>> to see this working on unix! With all major platforms supported  
>> and a Morphic refactoring underway (which hopefully would get rid  
>> of the global Display and Sensor access) we would get one major  
>> complaint about Squeak's "real-world" usefulness out of the way ...
>
> Yes this is why I was mentioning it for 3.10 but if this is not  
> ready what should be done? May be some people
> may join and do something.
>
> Stef
>

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



Reply | Threaded
Open this post in threaded view
|

Re: Ffenestri (multiple host window support), and Mac Host Menus

Bert Freudenberg
On Jan 16, 2007, at 21:38 , John M McIntosh wrote:

> I believe Impara has a windows VM for the host window plugin but  
> I'm not sure where.

Actually, if I am not mistaken, the regular Windows VM has had host  
window support built-in for quite some time.

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Ffenestri (multiple host window support), and Mac Host Menus

Edgar J. De Cleene-2
In reply to this post by johnmci
El 1/16/07 5:38 PM, "John M McIntosh" <[hidden email]>
escribió:

> However no-one I know is using the multiple window support.

All what John send works fine, he is working a lot with this.

I ask he and repeat for all what have Mac and knowledge of Quartz Composer
if some kind of Squeak drive is possible.

I mean some like the attached file could be generated inside Squeak (not in
Quarz Composer) but performed into a host window.

Maybe I again ask stupid things :=)

Edgar




Blob.qtz (43K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ffenestri (multiple host window support), and Mac Host Menus

johnmci
In reply to this post by Bert Freudenberg
Ah, well could someone could load the Ffenestri change sets I posted  
into an image and try running the Sunits on a windows machine?

On Jan 16, 2007, at 12:57 PM, Bert Freudenberg wrote:

> On Jan 16, 2007, at 21:38 , John M McIntosh wrote:
>
>> I believe Impara has a windows VM for the host window plugin but  
>> I'm not sure where.
>
> Actually, if I am not mistaken, the regular Windows VM has had host  
> window support built-in for quite some time.
>
> - Bert -
>
>
>

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



Reply | Threaded
Open this post in threaded view
|

re: Ffenestri (multiple host window support), and Mac Host Menus

ccrraaiigg
In reply to this post by johnmci

> Both Sophie and Scratch use the mac menu logic, so that is in actual
> use. However no-one I know is using the multiple window support.

     For what it's worth, as I mentioned in a Spoon progress report[1],
I'm building the Spoon display support from the Ffenestri work.


     thanks again!

-C

[1] http://tinyurl.com/y6u9qc

--
Craig Latta
http://netjam.org/resume


Reply | Threaded
Open this post in threaded view
|

Re: Ffenestri (multiple host window support), and Mac Host Menus

johnmci
In reply to this post by Edgar J. De Cleene-2
mmm.

Well in Sophie we set things up to allow quicktime to draw to a  
surface.  What we do is setup a GWorld via FFI and call our
quicktime plugin to setup a squeak surface that points to the the  
GWorld. Then we tell Quicktime to draw to the GWorld, the
plugin is setup to signal a semaphore when quicktime has finished  
drawing a frame. So we wait on the semaphore, and when
fired we flush the form to Display.

For the browser plugin I use this to create a CGBitmapContext

SharedBrowserBitMapContextRef = CGBitmapContextCreate  
(SharedMemoryBlock,width,height,
8,rowBytes,colorspace,kCGImageAlphaNoneSkipFirst);

then later do
                CGContextDrawImage(SharedBrowserBitMapContextRef, clip, image);    
to draw to this bitmap
or
                CGContextDrawImage(targetWindowBlock->context, clip, image); to  
draw to the window context.

image is a CGImageCreate using a CGDataProviderCreateDirectAccess  
which points to the squeak form, usually the Display.

With I think the right parms the CGBitmapContextCreate could write  
bits to a Squeak Surface.

I can't say how you would interface to Quartz Composer, first it  
would look like you need the Obj-C interface logic, then follow the
instruction on how to use the QCRenderer class to draw to an openGL  
context. Which at this point you have exhausted my knowledge of
how to continue.

Evil things, I note the  copybits logic grabs an extra word off the  
end of a form. That can cause a VM memory protection depending on
how the bitmap storage area was created. In Sophie we tried to use  
the Cairo png reader but found this copybits bug was an issue.



On Jan 16, 2007, at 12:58 PM, Edgar J. De Cleene wrote:

> El 1/16/07 5:38 PM, "John M McIntosh"  
> <[hidden email]>
> escribió:
>
>> However no-one I know is using the multiple window support.
>
> All what John send works fine, he is working a lot with this.
>
> I ask he and repeat for all what have Mac and knowledge of Quartz  
> Composer
> if some kind of Squeak drive is possible.
>
> I mean some like the attached file could be generated inside Squeak  
> (not in
> Quarz Composer) but performed into a host window.
>
> Maybe I again ask stupid things :=)
>
> Edgar
>
> <Blob.qtz>
>

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



Reply | Threaded
Open this post in threaded view
|

Re: Ffenestri (multiple host window support), and Mac Host Menus

Edgar J. De Cleene-2



El 1/17/07 4:14 AM, "John M McIntosh" <[hidden email]>
escribió:

>
> Well in Sophie we set things up to allow quicktime to draw to a
> surface.  What we do is setup a GWorld via FFI and call our
> quicktime plugin to setup a squeak surface that points to the the
> GWorld. Then we tell Quicktime to draw to the GWorld, the
> plugin is setup to signal a semaphore when quicktime has finished
> drawing a frame. So we wait on the semaphore, and when
> fired we flush the form to Display.
>
> For the browser plugin I use this to create a CGBitmapContext
>
> SharedBrowserBitMapContextRef = CGBitmapContextCreate
> (SharedMemoryBlock,width,height,
> 8,rowBytes,colorspace,kCGImageAlphaNoneSkipFirst);
>
> then later do
> CGContextDrawImage(SharedBrowserBitMapContextRef, clip, image);
> to draw to this bitmap
> or
> CGContextDrawImage(targetWindowBlock->context, clip, image); to
> draw to the window context.
>
> image is a CGImageCreate using a CGDataProviderCreateDirectAccess
> which points to the squeak form, usually the Display.
>
> With I think the right parms the CGBitmapContextCreate could write
> bits to a Squeak Surface.
>
> I can't say how you would interface to Quartz Composer, first it
> would look like you need the Obj-C interface logic, then follow the
> instruction on how to use the QCRenderer class to draw to an openGL
> context. Which at this point you have exhausted my knowledge of
> how to continue.
>
> Evil things, I note the  copybits logic grabs an extra word off the
> end of a form. That can cause a VM memory protection depending on
> how the bitmap storage area was created. In Sophie we tried to use
> the Cairo png reader but found this copybits bug was an issue.


Very thanks. I read carefully. Maybe in a few years more could do something
:=)

Edgar



       

       
               
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas