Native Windows
Locked
 
|
I spent the weekend trying to get Ffenestri working in Pharo. It was
astonishingly painful, not the least of which because they are stored as half a dozen monticello archives and the MC tool merge tool requires you to address each conflict individually and the main change is that at lot of morphic methods now have comments and _ has been replaced with :=. There must be a better way. Also, the files have a lot of patches to Delay and Process and really scary stuff like that and I was under the impression that those things had been reworked since and I didn't want to introduce any sort of regression so I didn't load them and focused on just making the plugin interface work and patching the event delivery code to deliver window events to the host windows (things like activate, iconize, close...). Debugging would be made a lot easier if I could identify a hook that would let me close the native window with the debugger launches, then reopen it when it proceeds - but I haven't a clue how that code works. Anyhow, I have a native window that opens with a sketch morph in it and it does pretty much what I expect. Because of the OS doing window image caching and its own damage repair from an offscreen buffer - it feels wicked fast and responsive compared to our emulated windows. I would like to push on this and bid farewell to our MDI-like interface of windows within a window and finally switch to native windows with a top level morph in each. I have some very mixed feelings about this as the window theming work that has been done is really top notch. Absolutely wonderful - and yet I'd like to throw it all away and go with the OS windows because they're about a zillion times faster and more responsive (my wicked fast 2GHZ Macbook Pro has about a half second delay to drag a window - seriously - why?). It works OK on the Mac OS X. I'd like to find a windows and linux person who would also like to work on this. I have no idea if it works on other platforms. I also have no idea how I'm going to extract my changes and ship them. I've had to hack HandMorph>>processEvents and lord knows what else in the quest to make this fly. I suppose I could file out a change set? Anyhow - it sort-of works except I think I've exposed a bug in event coordinate translation and I don't understand mouseFocus and keyboardFocus - how is that suppose to work? Or does it anymore? Perhaps the folks who worked on recent event tweaks could enlighten me? -Todd Blanchard _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Todd,
Many thanks for working on this!!! I suppose I qualify as a Linux person. Certainly I have interest in having it work well, and I'm completely sick of Microsoft. I know what you mean about there having to be a better way to do things. Just saving all of my packages for loading into a new image leaves me wondering why nothing else has been done, or perhaps just what I am missing. Agreed about Pinesoft's work on Polymorph; it's stunning. I am glad to hear that you have gotten far enough along to be able to report a speed boost. I do not necessarily assume that native is faster; emulated widgets have their use too, especially in very large numbers. So Polymorph might live on in grids for things like spreasheets where a native widget per cell might not scale terribly well. I have some ideas (not necessarily good ones) on how code should get from one image to another; I have little to no idea how to do that with MC though. On Dolphin, I built a tool called Migrate that tries to soften the blow, and would be happy to contribute any parts of it that would be of value. The basic features are to scan packages for a suitable load order[*] and to write a script for loading them into a new image. Of course, Dolphin packages understand dependencies, which is very helpful. I also defined a concept of safe and dangerous selectors, e.g. #safe, #dangerous, which could be referenced from any method, and Migrate would file them out and (conditionaly) into the new image. That allowed me to preserve fixes that I made to the base system, and warned me before applying the fixes to a new version. Seaside 2.9 defines a class called WADevelopment that helps with saving packages. [*] Dolphin's package system is quite good, and improved over the years to the point that load order was almost a non-concern, right about the time I started getting it right, maybe. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Eagle Offshore Sent: Monday, August 17, 2009 4:17 PM To: [hidden email] Subject: [Pharo-project] Native Windows I spent the weekend trying to get Ffenestri working in Pharo. It was astonishingly painful, not the least of which because they are stored as half a dozen monticello archives and the MC tool merge tool requires you to address each conflict individually and the main change is that at lot of morphic methods now have comments and _ has been replaced with :=. There must be a better way. Also, the files have a lot of patches to Delay and Process and really scary stuff like that and I was under the impression that those things had been reworked since and I didn't want to introduce any sort of regression so I didn't load them and focused on just making the plugin interface work and patching the event delivery code to deliver window events to the host windows (things like activate, iconize, close...). Debugging would be made a lot easier if I could identify a hook that would let me close the native window with the debugger launches, then reopen it when it proceeds - but I haven't a clue how that code works. Anyhow, I have a native window that opens with a sketch morph in it and it does pretty much what I expect. Because of the OS doing window image caching and its own damage repair from an offscreen buffer - it feels wicked fast and responsive compared to our emulated windows. I would like to push on this and bid farewell to our MDI-like interface of windows within a window and finally switch to native windows with a top level morph in each. I have some very mixed feelings about this as the window theming work that has been done is really top notch. Absolutely wonderful - and yet I'd like to throw it all away and go with the OS windows because they're about a zillion times faster and more responsive (my wicked fast 2GHZ Macbook Pro has about a half second delay to drag a window - seriously - why?). It works OK on the Mac OS X. I'd like to find a windows and linux person who would also like to work on this. I have no idea if it works on other platforms. I also have no idea how I'm going to extract my changes and ship them. I've had to hack HandMorph>>processEvents and lord knows what else in the quest to make this fly. I suppose I could file out a change set? Anyhow - it sort-of works except I think I've exposed a bug in event coordinate translation and I don't understand mouseFocus and keyboardFocus - how is that suppose to work? Or does it anymore? Perhaps the folks who worked on recent event tweaks could enlighten me? -Todd Blanchard _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Well, I may have spoken too soon. Digging into the platform specific
window proxies - I see proxies for MacOS 9, OS X, Win32, and Acorn???, but nothing for linux. OTOH, I find source code for a HostWindows plugin in the Unix VM source tree. Anybody with more knowledge of why we have a plugin without a proxy? On Aug 17, 2009, at 2:48 PM, Schwab,Wilhelm K wrote: > Todd, > > Many thanks for working on this!!! I suppose I qualify as a Linux > person. Certainly I have interest in having it work well, and I'm > completely sick of Microsoft. I know what you mean about there > having to be a better way to do things. Just saving all of my > packages for loading into a new image leaves me wondering why > nothing else has been done, or perhaps just what I am missing. > > Agreed about Pinesoft's work on Polymorph; it's stunning. I am glad > to hear that you have gotten far enough along to be able to report a > speed boost. I do not necessarily assume that native is faster; > emulated widgets have their use too, especially in very large > numbers. So Polymorph might live on in grids for things like > spreasheets where a native widget per cell might not scale terribly > well. > > I have some ideas (not necessarily good ones) on how code should get > from one image to another; I have little to no idea how to do that > with MC though. On Dolphin, I built a tool called Migrate that > tries to soften the blow, and would be happy to contribute any parts > of it that would be of value. The basic features are to scan > packages for a suitable load order[*] and to write a script for > loading them into a new image. Of course, Dolphin packages > understand dependencies, which is very helpful. I also defined a > concept of safe and dangerous selectors, e.g. #safe, #dangerous, > which could be referenced from any method, and Migrate would file > them out and (conditionaly) into the new image. That allowed me to > preserve fixes that I made to the base system, and warned me before > applying the fixes to a new version. > > Seaside 2.9 defines a class called WADevelopment that helps with > saving packages. > > [*] Dolphin's package system is quite good, and improved over the > years to the point that load order was almost a non-concern, right > about the time I started getting it right, maybe. > > Bill > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email] > ] On Behalf Of Eagle Offshore > Sent: Monday, August 17, 2009 4:17 PM > To: [hidden email] > Subject: [Pharo-project] Native Windows > > I spent the weekend trying to get Ffenestri working in Pharo. It was > astonishingly painful, not the least of which because they are > stored as half a dozen monticello archives and the MC tool merge > tool requires you to address each conflict individually and the main > change is that at lot of morphic methods now have comments and _ has > been > replaced with :=. There must be a better way. > > Also, the files have a lot of patches to Delay and Process and > really scary stuff like that and I was under the impression that > those things had been reworked since and I didn't want to introduce > any sort of regression so I didn't load them and focused on just > making the plugin interface work and patching the event delivery > code to deliver window events to the host windows (things like > activate, iconize, close...). > > Debugging would be made a lot easier if I could identify a hook that > would let me close the native window with the debugger launches, > then reopen it when it proceeds - but I haven't a clue how that code > works. > > Anyhow, I have a native window that opens with a sketch morph in it > and it does pretty much what I expect. Because of the OS doing > window image caching and its own damage repair from an offscreen > buffer - it feels wicked fast and responsive compared to our > emulated windows. I would like to push on this and bid farewell to > our MDI-like interface of windows within a window and finally switch > to native windows with a top level morph in each. > > I have some very mixed feelings about this as the window theming > work that has been done is really top notch. Absolutely wonderful - > and yet I'd like to throw it all away and go with the OS windows > because they're about a zillion times faster and more responsive (my > wicked fast 2GHZ Macbook Pro has about a half second delay to drag a > window - seriously - why?). > > It works OK on the Mac OS X. I'd like to find a windows and linux > person who would also like to work on this. I have no idea if it > works on other platforms. I also have no idea how I'm going to > extract my changes and ship them. I've had to hack > HandMorph>>processEvents and lord knows what else in the quest to make > this fly. I suppose I could file out a change set? > > Anyhow - it sort-of works except I think I've exposed a bug in event > coordinate translation and I don't understand mouseFocus and > keyboardFocus - how is that suppose to work? Or does it anymore? > Perhaps the folks who worked on recent event tweaks could enlighten > me? > > -Todd Blanchard > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Eagle Offshore
is there a preview or screenshots of this package?
-----Mensaje original----- De: [hidden email] [mailto:[hidden email]]En nombre de Eagle Offshore Enviado el: Lunes, 17 de Agosto de 2009 06:17 p.m. Para: [hidden email] Asunto: [Pharo-project] Native Windows I spent the weekend trying to get Ffenestri working in Pharo. It was astonishingly painful, not the least of which because they are stored as half a dozen monticello archives and the MC tool merge tool requires you to address each conflict individually and the main change is that at lot of morphic methods now have comments and _ has been replaced with :=. There must be a better way. Also, the files have a lot of patches to Delay and Process and really scary stuff like that and I was under the impression that those things had been reworked since and I didn't want to introduce any sort of regression so I didn't load them and focused on just making the plugin interface work and patching the event delivery code to deliver window events to the host windows (things like activate, iconize, close...). Debugging would be made a lot easier if I could identify a hook that would let me close the native window with the debugger launches, then reopen it when it proceeds - but I haven't a clue how that code works. Anyhow, I have a native window that opens with a sketch morph in it and it does pretty much what I expect. Because of the OS doing window image caching and its own damage repair from an offscreen buffer - it feels wicked fast and responsive compared to our emulated windows. I would like to push on this and bid farewell to our MDI-like interface of windows within a window and finally switch to native windows with a top level morph in each. I have some very mixed feelings about this as the window theming work that has been done is really top notch. Absolutely wonderful - and yet I'd like to throw it all away and go with the OS windows because they're about a zillion times faster and more responsive (my wicked fast 2GHZ Macbook Pro has about a half second delay to drag a window - seriously - why?). It works OK on the Mac OS X. I'd like to find a windows and linux person who would also like to work on this. I have no idea if it works on other platforms. I also have no idea how I'm going to extract my changes and ship them. I've had to hack HandMorph>>processEvents and lord knows what else in the quest to make this fly. I suppose I could file out a change set? Anyhow - it sort-of works except I think I've exposed a bug in event coordinate translation and I don't understand mouseFocus and keyboardFocus - how is that suppose to work? Or does it anymore? Perhaps the folks who worked on recent event tweaks could enlighten me? -Todd Blanchard _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Internal Virus Database is out-of-date. Checked by AVG. Version: 7.5.560 / Virus Database: 269.21.6/1323 - Release Date: 10/03/2008 11:07 a.m. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Eagle Offshore
Well let me comment
For years the squeak community complained about the fact there was just one window and morphic, and no way to offer native widgets or have more than one window. The folks providing funding for Sophie complained about this same fact too. So years ago, Tim and I spent a summer working out how to provide the multiple window support for Squeak aka Areithfa Ffenestri http://wiki.squeak.org/squeak/3862 It's quite simple, the HostWindowProxy proxy lets you manipulate the window and draw to it. The VM was changed so that Events *should* tag UI events with a window index number. EventSensor then brings up the events and hands them to who ever is interested. It's all fully explained on the web page. We built it on the macintosh first, with *pending* support for the other platforms. I'm sure Bert did a Linux variation. mmm I'm sure windowIndex 0 refers to the main squeak window btw. The original source code without complexity should sit in the ftp.smalltalkconsulting.com/experimental/Ffenestri/ changes sets Ffenestri-b-1 thru b-4 You should be able to load it into a Squeak image from Jan 2007, infact I rebuilt the change sets and tested them in a January 2007 image for a pending Squeak release let's see, oh yes the email for that is attached at the end. We alter event sensor, as you know that was all changed in Pharo It also alters Moprhic a bit so it understands windowIndex logic. Now about implementation, part of the problem is where does the events go and where does the drawing go. Lots of this is done in globals with no reference to the windowIndex. We had two implementations (a) We alter Project, when you enter project it then set the Display, so we could make a Project Window and drawing and mouse events would go to it, I'm not sure about todays version of Morphic but in the past you could have multiple Projects open, but only one would be active, then others would be *stopped* (b) We altered Tweak, Tweak at the time being the future vision of Morphic and UI on Squeak. Tweak actually built an environment and stuck the UI input queue and display information in an instance variable associated with the Tweak world. So it was *trivial* to hook up the host window proxy display logic and dispatch the events to the proper Tweak world. (c) I lie, I believe Michael Rueger built a subset of morphic (or something) that is Ffenestri aware, but I don't think it was ever published. Out of this, there was a dull thud as the folks wanting multiple host windows just failed to produce code using it. The powers that be that directed Sophie decided in fact one window was enough, so we never implemented things with multiple windows. The version of Tweak we were using in Sophie was grave-yarded. Maybe you could send me the details of your trail of MC loading since I don't recall an Process or Delay overrides. We had lots of that in Sophie via changes from Tweak/Qwaq to fix evil semaphore and process bugs plus Tweak did process priority escalation to solve event ordering/semaphore issues. On 17-Aug-09, at 3:05 PM, Eagle Offshore wrote: > Well, I may have spoken too soon. Digging into the platform specific > window proxies - I see proxies for MacOS 9, OS X, Win32, and Acorn???, > but nothing for linux. OTOH, I find source code for a HostWindows > plugin in the Unix VM source tree. > > Anybody with more knowledge of why we have a plugin without a proxy? > -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== The 3.10 team asked me to build a change set for Ffenestri (multiple host window support), and Mac Host Menus for 3.10. The last change set was build for Tweak in 2004. I've updated my ftp site and my idisk in the Ffenestri folder found in the experimental directory with a number of new change sets that let you load the Ffenestri logic into a 3.10 image, likely also into a 3.9 image. Testing shows that this re-released code works with Mac PowerPC and MacIntel. I did uncover a byte order problem on macintel btw. For the additional Macintosh Host menu support, used by Sophie, and by Scratch I've also pushed out a set of change sets to allow one to load that logic into a 3.10 image, likely also into a 3.9 image too. Testing shows that this re-released code works with Mac PowerPC and MacIntel. I did NOT revisit the Tweak support, there seems to be a LACK of interest. Anyone who wants to explore that should email me and I'll point out the methods of interest they can rework for Tweak. Of course for Tweak you can open a tweak project in a host window and expect everything to work since the display and event queue are instance variables, not globals like in Morphic. -------------------------- Well I note the HostMenu support *is* in Pharo now, so you need to very careful what the HostMenus-Events.1.cs does -------------------------- Ffenestri-b-1-HostWindowPlugin.2.cs This is the plugin for host windows Ffenestri-b-2-WindowProxies.3.cs Setup window proxis Ffenestri-b-3-MultiHostWindows-Sunits.1.cs SUnits to test multiple window support, works on mac powerpc and macIntel Check with Impara about windows changes to enable support on Windows. Ffenestri-b-3-MultiHostWindows.1.cs Add base support for Multiple windows. Ffenestri-b-4-Events-Morphic.1.cs Adds multiple window support for base Morphic, see Sunits for usage. HostMenus-Base.2.cs Add base support for Mac Host Windows. HostMenus-Events.1.cs Add interface to EventSensor for mac host menus, assumes Ffenestri-b-3- MultiHostWindows.1.cs is loaded. HostMenus-Mac-SUnits.1.cs SUnit to test mac host menu support, works on mac powerpc and macIntel. HostMenus-Mac-MacPlugin.1.cs This is the plugin that provides the menu support for os-9/os-x _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Carlos Crosetti-4
Have a look here:
http://wiki.squeak.org/squeak/3862 On Aug 17, 2009, at 5:25 PM, Carlos Crosetti wrote: > is there a preview or screenshots of this package? > > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]]En nombre de Eagle > Offshore > Enviado el: Lunes, 17 de Agosto de 2009 06:17 p.m. > Para: [hidden email] > Asunto: [Pharo-project] Native Windows > > > I spent the weekend trying to get Ffenestri working in Pharo. It was > astonishingly painful, not the least of which because they are stored > as half a dozen monticello archives and the MC tool merge tool > requires you to address each conflict individually and the main change > is that at lot of morphic methods now have comments and _ has been > replaced with :=. There must be a better way. > > Also, the files have a lot of patches to Delay and Process and really > scary stuff like that and I was under the impression that those things > had been reworked since and I didn't want to introduce any sort of > regression so I didn't load them and focused on just making the plugin > interface work and patching the event delivery code to deliver window > events to the host windows (things like activate, iconize, close...). > > Debugging would be made a lot easier if I could identify a hook that > would let me close the native window with the debugger launches, then > reopen it when it proceeds - but I haven't a clue how that code works. > > Anyhow, I have a native window that opens with a sketch morph in it > and it does pretty much what I expect. Because of the OS doing window > image caching and its own damage repair from an offscreen buffer - it > feels wicked fast and responsive compared to our emulated windows. I > would like to push on this and bid farewell to our MDI-like interface > of windows within a window and finally switch to native windows with a > top level morph in each. > > I have some very mixed feelings about this as the window theming work > that has been done is really top notch. Absolutely wonderful - and > yet I'd like to throw it all away and go with the OS windows because > they're about a zillion times faster and more responsive (my wicked > fast 2GHZ Macbook Pro has about a half second delay to drag a window - > seriously - why?). > > It works OK on the Mac OS X. I'd like to find a windows and linux > person who would also like to work on this. I have no idea if it > works on other platforms. I also have no idea how I'm going to > extract my changes and ship them. I've had to hack > HandMorph>>processEvents and lord knows what else in the quest to make > this fly. I suppose I could file out a change set? > > Anyhow - it sort-of works except I think I've exposed a bug in event > coordinate translation and I don't understand mouseFocus and > keyboardFocus - how is that suppose to work? Or does it anymore? > Perhaps the folks who worked on recent event tweaks could enlighten > me? > > -Todd Blanchard > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Internal Virus Database is out-of-date. > Checked by AVG. > Version: 7.5.560 / Virus Database: 269.21.6/1323 - Release Date: > 10/03/2008 > 11:07 a.m. > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by johnmci
Thanks so much for sharing on this. 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:
_______________________________________________ Pharo-project mailing list [hidden email] 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 <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by johnmci
On Mon, Aug 17, 2009 at 06:02:58PM -0700, John M McIntosh wrote:
> Well let me comment > > For years the squeak community complained about the fact there was > just one window and morphic, and no way > to offer native widgets or have more than one window. > > The folks providing funding for Sophie complained about this same fact > too. > > So years ago, Tim and I spent a summer working out how to provide the > multiple window support for Squeak > aka Areithfa Ffenestri http://wiki.squeak.org/squeak/3862 > > It's quite simple, the HostWindowProxy proxy lets you manipulate the > window and draw to it. > The VM was changed so that Events *should* tag UI events with a window > index number. > EventSensor then brings up the events and hands them to who ever is > interested. > > It's all fully explained on the web page. > > We built it on the macintosh first, with *pending* support for the > other platforms. I'm sure Bert did a Linux variation. > mmm I'm sure windowIndex 0 refers to the main squeak window btw. FWIW, I did make a start at getting this working on X11 for unix VMs, but did not get the project finished. Background: http://lists.squeakfoundation.org/pipermail/vm-dev/2008-July/001977.html I can dig up the missing attachments if anyone is interested. Bert may have done some related work since then. Dave _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by johnmci
2009/8/18 John M McIntosh <[hidden email]>:
> Before you run too far down the let's change Morphic path you should > check with Igor I'm sure he was off a year back trying to hack > Ffenestri into Morphic. > yes, yes i have an initial implementation of new hostwindows plugin which moves/separates the windowing stuff from core VM functionality. It then would be possible to build a VM which having no windowing support at all, and works as a console application. The problem with it, that i never did any windowing & event handling on X windows or MacOS, so its not so easy. I'm only hoping that my design fits well with other platforms, not only win32. I can publish the bits i'm done. Just say. I am swamped by another projects , so i don't know when i could find a time to finish it. :( > Tim and I gave that thought up when we considered there was 400 or so > references to EventSenor  & Display many of which had no concept of > window ownership in mind. Yes, this is a bit of pain. My thought about it, is to keep sensor global, but replace all refs to Display to 'self display' message send. There are only a few methods which assigning new value to Display , which should be addressed separately. > > > On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote: > >> Thanks so much for sharing on this. >> >> There seems to be a few caches of stuff stashed in various places. >> None of it is exactly complete.  I've taken the bulk of it from the http://source.impara.de/HostWindows >> and a bit from your experimental directory and looked at the plugins >> code in the VM tree and then just started trying to fix problems >> with event delivery.  I'd like to pull it all together and make it >> coherent on Windows, OS X and Unix. >> >> Its really great that Pharo has integrated the HostMenus stuff - I >> think it would be cool to do HostWindows too.  Once you eliminate >> having to emulate the look of the windows - most widget sets look >> pretty similar and I think morphic widgets inside of real windows >> would keep things from looking too weird while preserving the >> benefits of having our widgets in Smalltalk. >> >> Given Pharo's "take no prisoners" attitude, I think getting host >> windows working would allow a lot of really ugly code in >> PasteUpMorph and HandMorph to just go away.  Event delivery in >> Morphic is just totally incomprehensible and I'm finding it is >> broken when a second window is introduced as the mouse coordinates >> seem to be delivered window relative.  Its also really hard to work >> on because I keep junking images by making changes that wreck the UI. >> >> -Todd Blanchard >> > > -- > = > = > = > ======================================================================== > John M. McIntosh <[hidden email]>  Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com > = > = > = > ======================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I'm curious why you did a new plugin. Does the existing one not work
on windows? I got the following from Bert on the state of the unix plugin: "The plugin functions are still stubbed out, so you cannot actually open a second window, yet. But at least the hairy part of the work is done - I implemented the dispatching between the HostWindow plugin to the various display modules. This is more complex than on the other platforms, because the unix VM so far supports X11, Quartz, FrameBuffer, and Null display devices. But I did that part, now someone can simply implement e.g. the X11 functions to have it working in Linux. The only function I actually implemented was changing the title of the main Squeak window (window index 1). " -Todd Blanchard On Aug 18, 2009, at 6:03 AM, Igor Stasenko wrote: > 2009/8/18 John M McIntosh <[hidden email]>: >> Before you run too far down the let's change Morphic path you should >> check with Igor I'm sure he was off a year back trying to hack >> Ffenestri into Morphic. >> > yes, yes i have an initial implementation of new hostwindows plugin > which moves/separates the windowing stuff from core VM functionality. > > It then would be possible to build a VM which having no windowing > support at all, and works as a console application. > > The problem with it, that i never did any windowing & event handling > on X windows or MacOS, > so its not so easy. I'm only hoping that my design fits well with > other platforms, not only win32. > > I can publish the bits i'm done. Just say. > I am swamped by another projects , so i don't know when i could find a > time to finish it. :( > >> Tim and I gave that thought up when we considered there was 400 or so >> references to EventSenor & Display many of which had no concept of >> window ownership in mind. > > Yes, this is a bit of pain. > My thought about it, is to keep sensor global, but > replace all refs to Display to 'self display' message send. > There are only a few methods which assigning new value to Display , > which should be addressed separately. > > >> >> >> On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote: >> >>> Thanks so much for sharing on this. >>> >>> There seems to be a few caches of stuff stashed in various places. >>> None of it is exactly complete. I've taken the bulk of it from >>> the http://source.impara.de/HostWindows >>> and a bit from your experimental directory and looked at the plugins >>> code in the VM tree and then just started trying to fix problems >>> with event delivery. I'd like to pull it all together and make it >>> coherent on Windows, OS X and Unix. >>> >>> Its really great that Pharo has integrated the HostMenus stuff - I >>> think it would be cool to do HostWindows too. Once you eliminate >>> having to emulate the look of the windows - most widget sets look >>> pretty similar and I think morphic widgets inside of real windows >>> would keep things from looking too weird while preserving the >>> benefits of having our widgets in Smalltalk. >>> >>> Given Pharo's "take no prisoners" attitude, I think getting host >>> windows working would allow a lot of really ugly code in >>> PasteUpMorph and HandMorph to just go away. Event delivery in >>> Morphic is just totally incomprehensible and I'm finding it is >>> broken when a second window is introduced as the mouse coordinates >>> seem to be delivered window relative. Its also really hard to work >>> on because I keep junking images by making changes that wreck the >>> UI. >>> >>> -Todd Blanchard >>> >> >> -- >> = >> = >> = >> = >> = >> = >> ===================================================================== >> John M. McIntosh <[hidden email]> Twitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> = >> = >> = >> = >> = >> = >> ===================================================================== >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2009/8/18 Eagle Offshore <[hidden email]>:
> I'm curious why you did a new plugin.  Does the existing one not work > on windows? > it works , but it duplicating a functionality which also present in core platform files: - creating a window - processing events so, the idea is to merge & unify all these bits into a single plugin and also, make an extended API for managing host windows. > I got the following from Bert on the state of the unix plugin: > > "The plugin functions are still stubbed out, so you cannot actually > open a second window, yet. But at least the hairy part of the work is > done - I implemented the dispatching between the HostWindow plugin to > the various display modules. This is more complex than on the other > platforms, because the unix VM so far supports X11, Quartz, > FrameBuffer, and Null display devices. But I did that part, now > someone can simply implement e.g. the X11 functions to have it working > in Linux. The only function I actually implemented was changing the > title of the main Squeak window (window index 1). > " > > -Todd Blanchard > > On Aug 18, 2009, at 6:03 AM, Igor Stasenko wrote: > >> 2009/8/18 John M McIntosh <[hidden email]>: >>> Before you run too far down the let's change Morphic path you should >>> check with Igor I'm sure he was off a year back trying to hack >>> Ffenestri into Morphic. >>> >> yes, yes i have an initial implementation of new hostwindows plugin >> which moves/separates the windowing stuff from core VM functionality. >> >> It then would be possible to build a VM which having no windowing >> support at all, and works as a console application. >> >> The problem with it, that i never did any windowing & event handling >> on X windows or MacOS, >> so its not so easy. I'm only hoping that my design fits well with >> other platforms, not only win32. >> >> I can publish the bits i'm done. Just say. >> I am swamped by another projects , so i don't know when i could find a >> time to finish it. :( >> >>> Tim and I gave that thought up when we considered there was 400 or so >>> references to EventSenor  & Display many of which had no concept of >>> window ownership in mind. >> >> Yes, this is a bit of pain. >> My thought about it, is to keep sensor global, but >> replace all refs to Display to 'self display' message send. >> There are only a few methods which assigning new value to Display , >> which should be addressed separately. >> >> >>> >>> >>> On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote: >>> >>>> Thanks so much for sharing on this. >>>> >>>> There seems to be a few caches of stuff stashed in various places. >>>> None of it is exactly complete.  I've taken the bulk of it from >>>> the http://source.impara.de/HostWindows >>>> and a bit from your experimental directory and looked at the plugins >>>> code in the VM tree and then just started trying to fix problems >>>> with event delivery.  I'd like to pull it all together and make it >>>> coherent on Windows, OS X and Unix. >>>> >>>> Its really great that Pharo has integrated the HostMenus stuff - I >>>> think it would be cool to do HostWindows too.  Once you eliminate >>>> having to emulate the look of the windows - most widget sets look >>>> pretty similar and I think morphic widgets inside of real windows >>>> would keep things from looking too weird while preserving the >>>> benefits of having our widgets in Smalltalk. >>>> >>>> Given Pharo's "take no prisoners" attitude, I think getting host >>>> windows working would allow a lot of really ugly code in >>>> PasteUpMorph and HandMorph to just go away.  Event delivery in >>>> Morphic is just totally incomprehensible and I'm finding it is >>>> broken when a second window is introduced as the mouse coordinates >>>> seem to be delivered window relative.  Its also really hard to work >>>> on because I keep junking images by making changes that wreck the >>>> UI. >>>> >>>> -Todd Blanchard >>>> >>> >>> -- >>> = >>> = >>> = >>> = >>> = >>> = >>> ===================================================================== >>> John M. McIntosh <[hidden email]>  Twitter: >>> squeaker68882 >>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com >>> = >>> = >>> = >>> = >>> = >>> = >>> ===================================================================== >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I'll keep checking ,but, let me know when the basics are in and I'll provide
support in Polymorph. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <[hidden email]> To: <[hidden email]> Sent: Tuesday, August 18, 2009 4:11 PM Subject: Re: [Pharo-project] Native Windows > 2009/8/18 Eagle Offshore <[hidden email]>: >> I'm curious why you did a new plugin. Does the existing one not work >> on windows? >> > it works , but it duplicating a functionality which also present in > core platform files: > - creating a window > - processing events > > so, the idea is to merge & unify all these bits into a single plugin > and also, make an extended API for > managing host windows. > >> I got the following from Bert on the state of the unix plugin: >> >> "The plugin functions are still stubbed out, so you cannot actually >> open a second window, yet. But at least the hairy part of the work is >> done - I implemented the dispatching between the HostWindow plugin to >> the various display modules. This is more complex than on the other >> platforms, because the unix VM so far supports X11, Quartz, >> FrameBuffer, and Null display devices. But I did that part, now >> someone can simply implement e.g. the X11 functions to have it working >> in Linux. The only function I actually implemented was changing the >> title of the main Squeak window (window index 1). >> " >> >> -Todd Blanchard >> >> On Aug 18, 2009, at 6:03 AM, Igor Stasenko wrote: >> >>> 2009/8/18 John M McIntosh <[hidden email]>: >>>> Before you run too far down the let's change Morphic path you should >>>> check with Igor I'm sure he was off a year back trying to hack >>>> Ffenestri into Morphic. >>>> >>> yes, yes i have an initial implementation of new hostwindows plugin >>> which moves/separates the windowing stuff from core VM functionality. >>> >>> It then would be possible to build a VM which having no windowing >>> support at all, and works as a console application. >>> >>> The problem with it, that i never did any windowing & event handling >>> on X windows or MacOS, >>> so its not so easy. I'm only hoping that my design fits well with >>> other platforms, not only win32. >>> >>> I can publish the bits i'm done. Just say. >>> I am swamped by another projects , so i don't know when i could find a >>> time to finish it. :( >>> >>>> Tim and I gave that thought up when we considered there was 400 or so >>>> references to EventSenor & Display many of which had no concept of >>>> window ownership in mind. >>> >>> Yes, this is a bit of pain. >>> My thought about it, is to keep sensor global, but >>> replace all refs to Display to 'self display' message send. >>> There are only a few methods which assigning new value to Display , >>> which should be addressed separately. >>> >>> >>>> >>>> >>>> On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote: >>>> >>>>> Thanks so much for sharing on this. >>>>> >>>>> There seems to be a few caches of stuff stashed in various places. >>>>> None of it is exactly complete. I've taken the bulk of it from >>>>> the http://source.impara.de/HostWindows >>>>> and a bit from your experimental directory and looked at the plugins >>>>> code in the VM tree and then just started trying to fix problems >>>>> with event delivery. I'd like to pull it all together and make it >>>>> coherent on Windows, OS X and Unix. >>>>> >>>>> Its really great that Pharo has integrated the HostMenus stuff - I >>>>> think it would be cool to do HostWindows too. Once you eliminate >>>>> having to emulate the look of the windows - most widget sets look >>>>> pretty similar and I think morphic widgets inside of real windows >>>>> would keep things from looking too weird while preserving the >>>>> benefits of having our widgets in Smalltalk. >>>>> >>>>> Given Pharo's "take no prisoners" attitude, I think getting host >>>>> windows working would allow a lot of really ugly code in >>>>> PasteUpMorph and HandMorph to just go away. Event delivery in >>>>> Morphic is just totally incomprehensible and I'm finding it is >>>>> broken when a second window is introduced as the mouse coordinates >>>>> seem to be delivered window relative. Its also really hard to work >>>>> on because I keep junking images by making changes that wreck the >>>>> UI. >>>>> >>>>> -Todd Blanchard >>>>> >>>> >>>> -- >>>> = >>>> = >>>> = >>>> = >>>> = >>>> = >>>> ===================================================================== >>>> John M. McIntosh <[hidden email]> Twitter: >>>> squeaker68882 >>>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>>> = >>>> = >>>> = >>>> = >>>> = >>>> = >>>> ===================================================================== >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
What is the "canonical" window class in Pharo? I see SystemWindow has
been subclassed and there's a separate builder for the other window that is otherwise a copy of the default builder. Where was that going? On Aug 18, 2009, at 10:01 AM, Gary Chambers wrote: > I'll keep checking ,but, let me know when the basics are in and I'll > provide > support in Polymorph. > > Regards, Gary > > ----- Original Message ----- > From: "Igor Stasenko" <[hidden email]> > To: <[hidden email]> > Sent: Tuesday, August 18, 2009 4:11 PM > Subject: Re: [Pharo-project] Native Windows > > >> 2009/8/18 Eagle Offshore <[hidden email]>: >>> I'm curious why you did a new plugin. Does the existing one not work >>> on windows? >>> >> it works , but it duplicating a functionality which also present in >> core platform files: >> - creating a window >> - processing events >> >> so, the idea is to merge & unify all these bits into a single plugin >> and also, make an extended API for >> managing host windows. >> >>> I got the following from Bert on the state of the unix plugin: >>> >>> "The plugin functions are still stubbed out, so you cannot actually >>> open a second window, yet. But at least the hairy part of the work >>> is >>> done - I implemented the dispatching between the HostWindow plugin >>> to >>> the various display modules. This is more complex than on the other >>> platforms, because the unix VM so far supports X11, Quartz, >>> FrameBuffer, and Null display devices. But I did that part, now >>> someone can simply implement e.g. the X11 functions to have it >>> working >>> in Linux. The only function I actually implemented was changing the >>> title of the main Squeak window (window index 1). >>> " >>> >>> -Todd Blanchard >>> >>> On Aug 18, 2009, at 6:03 AM, Igor Stasenko wrote: >>> >>>> 2009/8/18 John M McIntosh <[hidden email]>: >>>>> Before you run too far down the let's change Morphic path you >>>>> should >>>>> check with Igor I'm sure he was off a year back trying to hack >>>>> Ffenestri into Morphic. >>>>> >>>> yes, yes i have an initial implementation of new hostwindows plugin >>>> which moves/separates the windowing stuff from core VM >>>> functionality. >>>> >>>> It then would be possible to build a VM which having no windowing >>>> support at all, and works as a console application. >>>> >>>> The problem with it, that i never did any windowing & event >>>> handling >>>> on X windows or MacOS, >>>> so its not so easy. I'm only hoping that my design fits well with >>>> other platforms, not only win32. >>>> >>>> I can publish the bits i'm done. Just say. >>>> I am swamped by another projects , so i don't know when i could >>>> find a >>>> time to finish it. :( >>>> >>>>> Tim and I gave that thought up when we considered there was 400 >>>>> or so >>>>> references to EventSenor & Display many of which had no concept of >>>>> window ownership in mind. >>>> >>>> Yes, this is a bit of pain. >>>> My thought about it, is to keep sensor global, but >>>> replace all refs to Display to 'self display' message send. >>>> There are only a few methods which assigning new value to Display , >>>> which should be addressed separately. >>>> >>>> >>>>> >>>>> >>>>> On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote: >>>>> >>>>>> Thanks so much for sharing on this. >>>>>> >>>>>> There seems to be a few caches of stuff stashed in various >>>>>> places. >>>>>> None of it is exactly complete. I've taken the bulk of it from >>>>>> the http://source.impara.de/HostWindows >>>>>> and a bit from your experimental directory and looked at the >>>>>> plugins >>>>>> code in the VM tree and then just started trying to fix problems >>>>>> with event delivery. I'd like to pull it all together and make it >>>>>> coherent on Windows, OS X and Unix. >>>>>> >>>>>> Its really great that Pharo has integrated the HostMenus stuff >>>>>> - I >>>>>> think it would be cool to do HostWindows too. Once you eliminate >>>>>> having to emulate the look of the windows - most widget sets look >>>>>> pretty similar and I think morphic widgets inside of real windows >>>>>> would keep things from looking too weird while preserving the >>>>>> benefits of having our widgets in Smalltalk. >>>>>> >>>>>> Given Pharo's "take no prisoners" attitude, I think getting host >>>>>> windows working would allow a lot of really ugly code in >>>>>> PasteUpMorph and HandMorph to just go away. Event delivery in >>>>>> Morphic is just totally incomprehensible and I'm finding it is >>>>>> broken when a second window is introduced as the mouse >>>>>> coordinates >>>>>> seem to be delivered window relative. Its also really hard to >>>>>> work >>>>>> on because I keep junking images by making changes that wreck the >>>>>> UI. >>>>>> >>>>>> -Todd Blanchard >>>>>> >>>>> >>>>> -- >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> ================================================================== >>>>> John M. McIntosh <[hidden email]> Twitter: >>>>> squeaker68882 >>>>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> ================================================================== >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Eagle Offshore
Hi todd
this is cool that you work on that. I imagine that it will not be an easy task. One of the goal of pharo and effort of mike was to make sure that we get a better event system so that we can plug together different UI. Now about PasteUpMorph cleaning I do not know. What is clear to me is that a registeration for menu is missing. Keep pushing. I guess that this is the kind of work that is not fixed in a couple of days. On Aug 18, 2009, at 3:27 AM, Eagle Offshore wrote: > Thanks so much for sharing on this. > > There seems to be a few caches of stuff stashed in various places. > None of it is exactly complete. I've taken the bulk of it from the http://source.impara.de/HostWindows > and a bit from your experimental directory and looked at the plugins > code in the VM tree and then just started trying to fix problems > with event delivery. I'd like to pull it all together and make it > coherent on Windows, OS X and Unix. > > Its really great that Pharo has integrated the HostMenus stuff - I > think it would be cool to do HostWindows too. Once you eliminate > having to emulate the look of the windows - most widget sets look > pretty similar and I think morphic widgets inside of real windows > would keep things from looking too weird while preserving the > benefits of having our widgets in Smalltalk. > > Given Pharo's "take no prisoners" attitude, I think getting host > windows working would allow a lot of really ugly code in > PasteUpMorph and HandMorph to just go away. Event delivery in > Morphic is just totally incomprehensible and I'm finding it is > broken when a second window is introduced as the mouse coordinates > seem to be delivered window relative. Its also really hard to work > on because I keep junking images by making changes that wreck the UI. > > -Todd Blanchard > > > On Aug 17, 2009, at 6:02 PM, John M McIntosh wrote: > >> Well let me comment >> >> For years the squeak community complained about the fact there was >> just one window and morphic, and no way >> to offer native widgets or have more than one window. >> >> The folks providing funding for Sophie complained about this same >> fact >> too. >> >> So years ago, Tim and I spent a summer working out how to provide the >> multiple window support for Squeak >> aka Areithfa Ffenestri http://wiki.squeak.org/squeak/3862 >> >> It's quite simple, the HostWindowProxy proxy lets you manipulate the >> window and draw to it. >> The VM was changed so that Events *should* tag UI events with a >> window >> index number. >> EventSensor then brings up the events and hands them to who ever is >> interested. >> >> It's all fully explained on the web page. >> >> We built it on the macintosh first, with *pending* support for the >> other platforms. I'm sure Bert did a Linux variation. >> mmm I'm sure windowIndex 0 refers to the main squeak window btw. >> >> The original source code without complexity should sit in the >> ftp.smalltalkconsulting.com/experimental/Ffenestri/ >> changes sets >> Ffenestri-b-1 thru b-4 >> >> You should be able to load it into a Squeak image from Jan 2007, >> infact I rebuilt the change sets and tested them in a January 2007 >> image >> for a pending Squeak release let's see, oh yes the email for that is >> attached at the end. >> >> We alter event sensor, as you know that was all changed in Pharo >> It also alters Moprhic a bit so it understands windowIndex logic. >> >> Now about implementation, part of the problem is where does the >> events >> go and where does the drawing go. >> Lots of this is done in globals with no reference to the windowIndex. >> >> We had two implementations >> (a) We alter Project, when you enter project it then set the Display, >> so we could make a Project Window and drawing and mouse events would >> go to it, I'm not sure >> about todays version of Morphic but in the past you could have >> multiple Projects open, but only one would be active, then others >> would be *stopped* >> >> (b) We altered Tweak, Tweak at the time being the future vision of >> Morphic and UI on Squeak. Tweak actually built an environment and >> stuck the UI input queue and display information in an instance >> variable associated with the Tweak world. So it was *trivial* to >> hook >> up the host window proxy display logic and dispatch the events to the >> proper Tweak world. >> >> (c) I lie, I believe Michael Rueger built a subset of morphic (or >> something) that is Ffenestri aware, but I don't think it was ever >> published. >> >> Out of this, there was a dull thud as the folks wanting multiple host >> windows just failed to produce code using it. >> The powers that be that directed Sophie decided in fact one window >> was >> enough, so we never implemented things with multiple windows. >> The version of Tweak we were using in Sophie was grave-yarded. >> >> >> Maybe you could send me the details of your trail of MC loading since >> I don't recall an Process or Delay overrides. We had lots of that in >> Sophie via changes from Tweak/Qwaq to fix evil semaphore and process >> bugs plus Tweak did process priority escalation to solve event >> ordering/semaphore issues. >> >> On 17-Aug-09, at 3:05 PM, Eagle Offshore wrote: >> >>> Well, I may have spoken too soon. Digging into the platform >>> specific >>> window proxies - I see proxies for MacOS 9, OS X, Win32, and >>> Acorn???, >>> but nothing for linux. OTOH, I find source code for a HostWindows >>> plugin in the Unix VM source tree. >>> >>> Anybody with more knowledge of why we have a plugin without a proxy? >>> >> >> -- >> = >> = >> = >> = >> = >> = >> ===================================================================== >> John M. McIntosh <[hidden email]> Twitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> = >> = >> = >> = >> = >> = >> ===================================================================== >> >> >> >> >> >> The 3.10 team asked me to build a change set for Ffenestri (multiple >> host window support), and Mac Host Menus for 3.10. >> The last change set was build for Tweak in 2004. >> >> I've updated my ftp site and my idisk in the Ffenestri folder found >> in >> the experimental directory with a number of new >> change sets that let you load the Ffenestri logic into a 3.10 image, >> likely also into a 3.9 image. Testing shows that this re-released >> code >> works with Mac PowerPC and MacIntel. I did uncover a byte order >> problem on macintel btw. >> >> For the additional Macintosh Host menu support, used by Sophie, and >> by >> Scratch I've also pushed out a set of change sets >> to allow one to load that logic into a 3.10 image, likely also into a >> 3.9 image too. Testing shows that this re-released code works with >> Mac >> PowerPC and MacIntel. >> >> I did NOT revisit the Tweak support, there seems to be a LACK of >> interest. Anyone who wants to explore that should email me and I'll >> point out the methods of interest they can rework for Tweak. Of >> course for Tweak you can open a tweak project in a host window and >> expect everything to work since the display and event queue are >> instance variables, not globals like in Morphic. >> >> >> -------------------------- >> Well I note the HostMenu support *is* in Pharo now, so you need to >> very careful what the HostMenus-Events.1.cs does >> -------------------------- >> >> >> Ffenestri-b-1-HostWindowPlugin.2.cs >> This is the plugin for host windows >> >> Ffenestri-b-2-WindowProxies.3.cs >> Setup window proxis >> >> Ffenestri-b-3-MultiHostWindows-Sunits.1.cs >> SUnits to test multiple window support, works on mac powerpc and >> macIntel >> Check with Impara about windows changes to enable support on Windows. >> >> Ffenestri-b-3-MultiHostWindows.1.cs >> Add base support for Multiple windows. >> >> Ffenestri-b-4-Events-Morphic.1.cs >> Adds multiple window support for base Morphic, see Sunits for usage. >> >> HostMenus-Base.2.cs >> Add base support for Mac Host Windows. >> >> HostMenus-Events.1.cs >> Add interface to EventSensor for mac host menus, assumes Ffenestri- >> b-3- >> MultiHostWindows.1.cs is loaded. >> >> HostMenus-Mac-SUnits.1.cs >> SUnit to test mac host menu support, works on mac powerpc and >> macIntel. >> >> HostMenus-Mac-MacPlugin.1.cs >> This is the plugin that provides the menu support for os-9/os-x >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Eagle Offshore
We use StandardWindow that provides some benefits over SystemWindow.
(ability to open full-screen for deployed applications, prevention of dragging except via titlebar etc.) As for builders, I assume you are refering to PluggableStandardWindow (used via PluggableWindowSpec/PSToolBuilder). Regards, Gary ----- Original Message ----- From: "Eagle Offshore" <[hidden email]> To: <[hidden email]> Sent: Tuesday, August 18, 2009 7:33 PM Subject: Re: [Pharo-project] Native Windows > What is the "canonical" window class in Pharo? I see SystemWindow has > been subclassed and there's a separate builder for the other window > that is otherwise a copy of the default builder. Where was that going? > > > On Aug 18, 2009, at 10:01 AM, Gary Chambers wrote: > >> I'll keep checking ,but, let me know when the basics are in and I'll >> provide >> support in Polymorph. >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Igor Stasenko" <[hidden email]> >> To: <[hidden email]> >> Sent: Tuesday, August 18, 2009 4:11 PM >> Subject: Re: [Pharo-project] Native Windows >> >> >>> 2009/8/18 Eagle Offshore <[hidden email]>: >>>> I'm curious why you did a new plugin. Does the existing one not work >>>> on windows? >>>> >>> it works , but it duplicating a functionality which also present in >>> core platform files: >>> - creating a window >>> - processing events >>> >>> so, the idea is to merge & unify all these bits into a single plugin >>> and also, make an extended API for >>> managing host windows. >>> >>>> I got the following from Bert on the state of the unix plugin: >>>> >>>> "The plugin functions are still stubbed out, so you cannot actually >>>> open a second window, yet. But at least the hairy part of the work >>>> is >>>> done - I implemented the dispatching between the HostWindow plugin >>>> to >>>> the various display modules. This is more complex than on the other >>>> platforms, because the unix VM so far supports X11, Quartz, >>>> FrameBuffer, and Null display devices. But I did that part, now >>>> someone can simply implement e.g. the X11 functions to have it >>>> working >>>> in Linux. The only function I actually implemented was changing the >>>> title of the main Squeak window (window index 1). >>>> " >>>> >>>> -Todd Blanchard >>>> >>>> On Aug 18, 2009, at 6:03 AM, Igor Stasenko wrote: >>>> >>>>> 2009/8/18 John M McIntosh <[hidden email]>: >>>>>> Before you run too far down the let's change Morphic path you >>>>>> should >>>>>> check with Igor I'm sure he was off a year back trying to hack >>>>>> Ffenestri into Morphic. >>>>>> >>>>> yes, yes i have an initial implementation of new hostwindows plugin >>>>> which moves/separates the windowing stuff from core VM >>>>> functionality. >>>>> >>>>> It then would be possible to build a VM which having no windowing >>>>> support at all, and works as a console application. >>>>> >>>>> The problem with it, that i never did any windowing & event >>>>> handling >>>>> on X windows or MacOS, >>>>> so its not so easy. I'm only hoping that my design fits well with >>>>> other platforms, not only win32. >>>>> >>>>> I can publish the bits i'm done. Just say. >>>>> I am swamped by another projects , so i don't know when i could >>>>> find a >>>>> time to finish it. :( >>>>> >>>>>> Tim and I gave that thought up when we considered there was 400 >>>>>> or so >>>>>> references to EventSenor & Display many of which had no concept of >>>>>> window ownership in mind. >>>>> >>>>> Yes, this is a bit of pain. >>>>> My thought about it, is to keep sensor global, but >>>>> replace all refs to Display to 'self display' message send. >>>>> There are only a few methods which assigning new value to Display , >>>>> which should be addressed separately. >>>>> >>>>> >>>>>> >>>>>> >>>>>> On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote: >>>>>> >>>>>>> Thanks so much for sharing on this. >>>>>>> >>>>>>> There seems to be a few caches of stuff stashed in various >>>>>>> places. >>>>>>> None of it is exactly complete. I've taken the bulk of it from >>>>>>> the http://source.impara.de/HostWindows >>>>>>> and a bit from your experimental directory and looked at the >>>>>>> plugins >>>>>>> code in the VM tree and then just started trying to fix problems >>>>>>> with event delivery. I'd like to pull it all together and make it >>>>>>> coherent on Windows, OS X and Unix. >>>>>>> >>>>>>> Its really great that Pharo has integrated the HostMenus stuff >>>>>>> - I >>>>>>> think it would be cool to do HostWindows too. Once you eliminate >>>>>>> having to emulate the look of the windows - most widget sets look >>>>>>> pretty similar and I think morphic widgets inside of real windows >>>>>>> would keep things from looking too weird while preserving the >>>>>>> benefits of having our widgets in Smalltalk. >>>>>>> >>>>>>> Given Pharo's "take no prisoners" attitude, I think getting host >>>>>>> windows working would allow a lot of really ugly code in >>>>>>> PasteUpMorph and HandMorph to just go away. Event delivery in >>>>>>> Morphic is just totally incomprehensible and I'm finding it is >>>>>>> broken when a second window is introduced as the mouse >>>>>>> coordinates >>>>>>> seem to be delivered window relative. Its also really hard to >>>>>>> work >>>>>>> on because I keep junking images by making changes that wreck the >>>>>>> UI. >>>>>>> >>>>>>> -Todd Blanchard >>>>>>> >>>>>> >>>>>> -- >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> ================================================================== >>>>>> John M. McIntosh <[hidden email]> Twitter: >>>>>> squeaker68882 >>>>>> Corporate Smalltalk Consulting Ltd. >>>>>> http://www.smalltalkconsulting.com >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> ================================================================== >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> [hidden email] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>>> project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Eagle Offshore
Made a small experiment the other week of, sharing in case someone's interested.
It renders an arbitrary SystemWindow in a ffenestri-window (on mac at least) in the simplest way I could think of at least. (not efficient (3MB or so per window), nor exactly pretty), but it makes for a nice demo imo, even though the window is unresponsible to input. Render update on resizing works, with a faux render loop instead of real window resize event response :) In theory you can do openInWorld on the same window, and manipulate that, but I wouldn't recommend it, as the faux loop in the workspace is in no way synchronized with World Drawing and you will get DNU's after awhile. Install the changesets from ftp.smalltalkconsulting.com/experimental/Ffenestri/ first, then the changeset in the attached zip. Doit'ing the workspace in the .rtf should then open a Hierarchy Browser on HierarchyBrowser, read comments there for more details :) Should work on any SystemWindow instance, though actually getting to an instance before it's opened can be surprisingly hard... Cheers, Henry On Aug 18, 2009, at 8:33 39PM, Eagle Offshore wrote:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
FFenestriSystemWindowsExample.zip (4K) |
|
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:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |