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 ======================================================================== === |
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 |
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 |
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 ======================================================================== === |
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 |
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 |
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 > ====================================================================== > ===== > > > > |
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 - |
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 ======================================================================== === |
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 |
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 ======================================================================== === |
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 - |
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 |
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 ======================================================================== === |
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 |
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 ======================================================================== === |
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 |
Free forum by Nabble | Edit this page |