August 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Preference browser does not load from disk

by csrabak＠bol.com.br

Aug. 18, 2009

Re: [Pharo-project] Native Windows

by Eagle Offshore

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(a)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(a)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(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 18, 2009

Re: [Pharo-project] Native Windows

by John M McIntosh

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(a)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

Aug. 18, 2009

[Pharo-project] Preference browser does not load from disk

by csrabak＠bol.com.br

Aug. 18, 2009

Re: [Pharo-project] Native Windows

by Carlos Crosetti

is there a preview or screenshots of this package? -----Mensaje original----- De: pharo-project-bounces(a)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(a)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(a)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.

Aug. 18, 2009

Re: [Pharo-project] Native Windows

by Eagle Offshore

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(a)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(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2009

Re: [Pharo-project] Getting Javascript in Moose and/or Pharo

by Eagle Offshore

I will go you one better. I want to do a port of webkit basing it on the GTK one because that one has a C api and can run more or less identically on OSX, Windows, and linux. I want web content in Pharo and I don't want to maintain it - I'd rather we adopt it. Then, I want to explore bridging the DOM to smalltalk objects. I've been downloading and building this stuff all weekend. This is very preliminary - its taken all weekend to download all of the required libraries to build gtkwebkit on the mac. I also had the idea some time ago about building an entire UI on top of webkit using bridged smalltalk DOM. This would let you specify your widget layout as HTML/CSS but code in Smalltalk and provide a more or less portable but native UI. Apparently, I'm not the only one with this idea. http://www.advogato.org/article/981.html -Todd Blanchard On Aug 17, 2009, at 2:24 PM, Alexandre Bergel wrote: > Dear List > > Making Pharo interacting with Javascript has been the cup of tea of > the Seaside community. > I am wondering whether there has been an attempt to produce a parser > for Javascript within Pharo. > > We are interested in getting Javascript models within Moose. > > For now, it is likely what we will use the parser of Mozilla to > produce MSE files. > > Cheers, > Alexandre > > NB: Sorry for the cross-posting > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2009

Re: [Pharo-project] Native Windows

by Schwab,Wilhelm K

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(a)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(a)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(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 17, 2009

Re: [Pharo-project] Problem with Author

by csrabak＠bol.com.br

Aug. 17, 2009

Re: [Pharo-project] [ANN] prebuild PharoCore-1.0-10414-BETA

by csrabak＠bol.com.br

Aug. 17, 2009