[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
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Eagle Offshore Sent: Monday, August 17, 2009 4:17 PM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Eagle Offshore Sent: Monday, August 17, 2009 4:17 PM To: Pharo-project@lists.gforge.inria.fr 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 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
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 <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== The 3.10 team asked me to build a change set for Ffenestri (multiple host window support), and Mac Host Menus for 3.10. The last change set was build for Tweak in 2004. I've updated my ftp site and my idisk in the Ffenestri folder found in the experimental directory with a number of new change sets that let you load the Ffenestri logic into a 3.10 image, likely also into a 3.9 image. Testing shows that this re-released code works with Mac PowerPC and MacIntel. I did uncover a byte order problem on macintel btw. For the additional Macintosh Host menu support, used by Sophie, and by Scratch I've also pushed out a set of change sets to allow one to load that logic into a 3.10 image, likely also into a 3.9 image too. Testing shows that this re-released code works with Mac PowerPC and MacIntel. I did NOT revisit the Tweak support, there seems to be a LACK of interest. Anyone who wants to explore that should email me and I'll point out the methods of interest they can rework for Tweak. Of course for Tweak you can open a tweak project in a host window and expect everything to work since the display and event queue are instance variables, not globals like in Morphic. -------------------------- Well I note the HostMenu support *is* in Pharo now, so you need to very careful what the HostMenus-Events.1.cs does -------------------------- Ffenestri-b-1-HostWindowPlugin.2.cs This is the plugin for host windows Ffenestri-b-2-WindowProxies.3.cs Setup window proxis Ffenestri-b-3-MultiHostWindows-Sunits.1.cs SUnits to test multiple window support, works on mac powerpc and macIntel Check with Impara about windows changes to enable support on Windows. Ffenestri-b-3-MultiHostWindows.1.cs Add base support for Multiple windows. Ffenestri-b-4-Events-Morphic.1.cs Adds multiple window support for base Morphic, see Sunits for usage. HostMenus-Base.2.cs Add base support for Mac Host Windows. HostMenus-Events.1.cs Add interface to EventSensor for mac host menus, assumes Ffenestri-b-3- MultiHostWindows.1.cs is loaded. HostMenus-Mac-SUnits.1.cs SUnit to test mac host menu support, works on mac powerpc and macIntel. HostMenus-Mac-MacPlugin.1.cs This is the plugin that provides the menu support for os-9/os-x
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 <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
The 3.10 team asked me to build a change set for Ffenestri (multiple host window support), and Mac Host Menus for 3.10. The last change set was build for Tweak in 2004.
I've updated my ftp site and my idisk in the Ffenestri folder found in the experimental directory with a number of new change sets that let you load the Ffenestri logic into a 3.10 image, likely also into a 3.9 image. Testing shows that this re-released code works with Mac PowerPC and MacIntel. I did uncover a byte order problem on macintel btw.
For the additional Macintosh Host menu support, used by Sophie, and by Scratch I've also pushed out a set of change sets to allow one to load that logic into a 3.10 image, likely also into a 3.9 image too. Testing shows that this re-released code works with Mac PowerPC and MacIntel.
I did NOT revisit the Tweak support, there seems to be a LACK of interest. Anyone who wants to explore that should email me and I'll point out the methods of interest they can rework for Tweak. Of course for Tweak you can open a tweak project in a host window and expect everything to work since the display and event queue are instance variables, not globals like in Morphic.
-------------------------- Well I note the HostMenu support *is* in Pharo now, so you need to very careful what the HostMenus-Events.1.cs does --------------------------
Ffenestri-b-1-HostWindowPlugin.2.cs This is the plugin for host windows
Ffenestri-b-2-WindowProxies.3.cs Setup window proxis
Ffenestri-b-3-MultiHostWindows-Sunits.1.cs SUnits to test multiple window support, works on mac powerpc and macIntel Check with Impara about windows changes to enable support on Windows.
Ffenestri-b-3-MultiHostWindows.1.cs Add base support for Multiple windows.
Ffenestri-b-4-Events-Morphic.1.cs Adds multiple window support for base Morphic, see Sunits for usage.
HostMenus-Base.2.cs Add base support for Mac Host Windows.
HostMenus-Events.1.cs Add interface to EventSensor for mac host menus, assumes Ffenestri- b-3- MultiHostWindows.1.cs is loaded.
HostMenus-Mac-SUnits.1.cs SUnit to test mac host menu support, works on mac powerpc and macIntel.
HostMenus-Mac-MacPlugin.1.cs This is the plugin that provides the menu support for os-9/os-x
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
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.
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 <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
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.
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
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
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" <eagleoffshore@mac.com> To: <Pharo-project@lists.gforge.inria.fr> 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" <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
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" <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
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
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 <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = = = = =====================================================================
The 3.10 team asked me to build a change set for Ffenestri (multiple host window support), and Mac Host Menus for 3.10. The last change set was build for Tweak in 2004.
I've updated my ftp site and my idisk in the Ffenestri folder found in the experimental directory with a number of new change sets that let you load the Ffenestri logic into a 3.10 image, likely also into a 3.9 image. Testing shows that this re-released code works with Mac PowerPC and MacIntel. I did uncover a byte order problem on macintel btw.
For the additional Macintosh Host menu support, used by Sophie, and by Scratch I've also pushed out a set of change sets to allow one to load that logic into a 3.10 image, likely also into a 3.9 image too. Testing shows that this re-released code works with Mac PowerPC and MacIntel.
I did NOT revisit the Tweak support, there seems to be a LACK of interest. Anyone who wants to explore that should email me and I'll point out the methods of interest they can rework for Tweak. Of course for Tweak you can open a tweak project in a host window and expect everything to work since the display and event queue are instance variables, not globals like in Morphic.
-------------------------- Well I note the HostMenu support *is* in Pharo now, so you need to very careful what the HostMenus-Events.1.cs does --------------------------
Ffenestri-b-1-HostWindowPlugin.2.cs This is the plugin for host windows
Ffenestri-b-2-WindowProxies.3.cs Setup window proxis
Ffenestri-b-3-MultiHostWindows-Sunits.1.cs SUnits to test multiple window support, works on mac powerpc and macIntel Check with Impara about windows changes to enable support on Windows.
Ffenestri-b-3-MultiHostWindows.1.cs Add base support for Multiple windows.
Ffenestri-b-4-Events-Morphic.1.cs Adds multiple window support for base Morphic, see Sunits for usage.
HostMenus-Base.2.cs Add base support for Mac Host Windows.
HostMenus-Events.1.cs Add interface to EventSensor for mac host menus, assumes Ffenestri- b-3- MultiHostWindows.1.cs is loaded.
HostMenus-Mac-SUnits.1.cs SUnit to test mac host menu support, works on mac powerpc and macIntel.
HostMenus-Mac-MacPlugin.1.cs This is the plugin that provides the menu support for os-9/os-x
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
is there a preview or screenshots of this package? -----Mensaje original----- De: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Eagle Offshore Enviado el: Lunes, 17 de Agosto de 2009 06:17 p.m. Para: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr 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.
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Eagle Offshore Enviado el: Lunes, 17 de Agosto de 2009 06:17 p.m. Para: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (9)
-
Carlos Crosetti -
David T. Lewis -
Eagle Offshore -
Gary Chambers -
Henrik Johansen -
Igor Stasenko -
John M McIntosh -
Schwab,Wilhelm K -
Stéphane Ducasse