November 2008 - Pharo-dev - lists.pharo.org

Re: Unix host windows. (Was: Re: [Pharo-project] HostWindows rewrite)

by Igor Stasenko

2008/11/21 David T. Lewis <lewis(a)mail.msen.com>: > On Thu, Nov 20, 2008 at 09:14:51PM +0200, Igor Stasenko wrote: >> Hello David, >> >> Today i took a look at the unix port of squeak, where it deals with >> host windows.. ouch!! >> >> The main file - sqUnixX11.c is a big bloat of C code , which tries to >> deal with anything at once. ouch!! > > The design intent (not mine of course) was to allow Squeak to be > an X11 client with the entire world of Squeak living inside an X11 > window. For sure some reorganization will be needed in order to do > this differently. > Yup >> I'm slowly reading it, trying to understand how it works. >> The Xlib window management is quite different from what i used to see >> in windoze. >> As i understand, it using two windows - one for decoration and to be >> managed by window managers, and second is for actual squeak content. > > Yes. This is because of the distiction between top-level windows > and other windows on X11. X window managers treat top-level windows > differently, and Squeak is running in an X window that is the child > of a top-level window. > > Loosely speaking, the top-level window corresponds to an "application" > which might have a hierarchy of windows inside it. Inside only, or just have a child-parent relation? I mean, does a child-parent implies, that child window should live inside rect designated by parent and parent always acts as background window, or its free to be placed anywhere? > In the case of > Squeak, only one child window is needed because Squeak takes over > from there and everything else is "inside of" Squeak itself. > >> The number of flags, settings, startup options to set-up a host window >> is overwhelming. The docs, as for everything in unixes, is quite >> obscure and often don't tell anything about purpose of option/function >> - just what it does and what it expects as input. > > Yes, it's enough to make your head spin. Note however that this is > not really a Unix thing. X11 was developed for VMS and DECNet as > well as Unix, and proprietary DEC systems used X11 for many years. > It runs on other operating systems and network transports also. But > the Unix flavors seem to have outlived the other better-documented > proprietary operating systems ;) > > Also I have to say that when you see the size of the bookshelf > required to document X11, it really makes you appreciate something > like Squeak where everything from top to bottom is visible and you > can figure the whole thing out on your own. > >> As i see in sqUnixEvent.c , the windowIndex member of events is >> ignored and set to 0. So at first stage it would require to change >> functions there to honor a window index. > > I think that's right. > >> I found some analogies with my windoze code - you are also keep own >> private registry for host windows and operating with 1-based window >> handles (i'm using 0-based index). > > Yes. The VM needs to keep track of host windows, because there is > no good way to ask the window manager to do it for you. > >> There is a couple of interesting things which i discovered: >> any action, like window move & size can be completely ignored by window manager. > > This is fundamental to X window. Squeak is the client. It can ask > the server to do things, but the window manager and the X server > are in control. > > An important aspect of this (that I thought about but did not implement) > is to figure out how many connections there should be to the X server, > and how the X events should be routed to Squeak. Traditionally (in > Ian's implementation), there is one top-level X window being managed > by the X window manager, a child window in which Squeak lives, and > a single communication channel between the client application (the > Squeak VM) and the X server. Any X event that arrives on this channel > can just be delivered to "all of Squeak" and there is no need to > figure out which X window it refers to. > Of course, because there is a single window. But once you have many... > In order to expand this to work for multiple host windows, you want > to figure out if each host window should live inside an X window > within its own top-level X window (that is how I was doing it), or > should each host window be a child of a single Squeak window (this > might make sense if the intent of the host windows was to implement > widgets such as buttons and text boxes for example). > I think i will support both options. You should be able to create a top-level windows as well as childs of existing top-level window. I'm not sure however how things play well with coordinate system & events in latter case. I'm also concerned a bit with a window manager communication. How to tell window manager that window should have different decoration, like having static border, or can't be closed (don't show close button) , or having no decoration at all - only area for painting etc. I want (at least try) to support a set of generic assets throughout all platforms. > Also, you need to decide if each top-level host window should have > its own separate communication session to the X server such that X > events are naturally delivered to that window, or if there should be > one connection with code to dispatch the events to the right destination. > Either way, the X events need to get back to the VM in such a way > that the correct X windows are refreshed, and the correct semaphore > or process gets alerted in the Squeak image. > I don't see the need in having multiple comm channels. Squeak VM having single event queue, that's makes no sense to use multiple queues inside X11 backend. Of couse if X11 allows to manage everything through single channel. > I'm writing this from memory so I probable have messed up some of > the details, but that is the general idea. As I said, I never did > finish an implementation. It can certainly be done, but it will > require some more thinking about the design, as well as some > reorganization of the current Unix X11 support code. > Thanks for explanation anyway. Since i never did anything for X11, so any bit of information is wellcome :) > Dave > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 21, 2008

Re: Unix host windows. (Was: Re: [Pharo-project] HostWindows rewrite)

by David T. Lewis

On Thu, Nov 20, 2008 at 09:14:51PM +0200, Igor Stasenko wrote: > Hello David, > > Today i took a look at the unix port of squeak, where it deals with > host windows.. ouch!! > > The main file - sqUnixX11.c is a big bloat of C code , which tries to > deal with anything at once. ouch!! The design intent (not mine of course) was to allow Squeak to be an X11 client with the entire world of Squeak living inside an X11 window. For sure some reorganization will be needed in order to do this differently. > I'm slowly reading it, trying to understand how it works. > The Xlib window management is quite different from what i used to see > in windoze. > As i understand, it using two windows - one for decoration and to be > managed by window managers, and second is for actual squeak content. Yes. This is because of the distiction between top-level windows and other windows on X11. X window managers treat top-level windows differently, and Squeak is running in an X window that is the child of a top-level window. Loosely speaking, the top-level window corresponds to an "application" which might have a hierarchy of windows inside it. In the case of Squeak, only one child window is needed because Squeak takes over from there and everything else is "inside of" Squeak itself. > The number of flags, settings, startup options to set-up a host window > is overwhelming. The docs, as for everything in unixes, is quite > obscure and often don't tell anything about purpose of option/function > - just what it does and what it expects as input. Yes, it's enough to make your head spin. Note however that this is not really a Unix thing. X11 was developed for VMS and DECNet as well as Unix, and proprietary DEC systems used X11 for many years. It runs on other operating systems and network transports also. But the Unix flavors seem to have outlived the other better-documented proprietary operating systems ;) Also I have to say that when you see the size of the bookshelf required to document X11, it really makes you appreciate something like Squeak where everything from top to bottom is visible and you can figure the whole thing out on your own. > As i see in sqUnixEvent.c , the windowIndex member of events is > ignored and set to 0. So at first stage it would require to change > functions there to honor a window index. I think that's right. > I found some analogies with my windoze code - you are also keep own > private registry for host windows and operating with 1-based window > handles (i'm using 0-based index). Yes. The VM needs to keep track of host windows, because there is no good way to ask the window manager to do it for you. > There is a couple of interesting things which i discovered: > any action, like window move & size can be completely ignored by window manager. This is fundamental to X window. Squeak is the client. It can ask the server to do things, but the window manager and the X server are in control. An important aspect of this (that I thought about but did not implement) is to figure out how many connections there should be to the X server, and how the X events should be routed to Squeak. Traditionally (in Ian's implementation), there is one top-level X window being managed by the X window manager, a child window in which Squeak lives, and a single communication channel between the client application (the Squeak VM) and the X server. Any X event that arrives on this channel can just be delivered to "all of Squeak" and there is no need to figure out which X window it refers to. In order to expand this to work for multiple host windows, you want to figure out if each host window should live inside an X window within its own top-level X window (that is how I was doing it), or should each host window be a child of a single Squeak window (this might make sense if the intent of the host windows was to implement widgets such as buttons and text boxes for example). Also, you need to decide if each top-level host window should have its own separate communication session to the X server such that X events are naturally delivered to that window, or if there should be one connection with code to dispatch the events to the right destination. Either way, the X events need to get back to the VM in such a way that the correct X windows are refreshed, and the correct semaphore or process gets alerted in the Squeak image. I'm writing this from memory so I probable have messed up some of the details, but that is the general idea. As I said, I never did finish an implementation. It can certainly be done, but it will require some more thinking about the design, as well as some reorganization of the current Unix X11 support code. Dave

Nov. 21, 2008

Re: [Pharo-project] Polymorph in Pharo

by Marcus Denker

On 20.11.2008, at 21:02, Igor Stasenko wrote: > hmm.. i trying to install polymorph-widgets from universes on 10156- > dev image > and it fails with DNU: > BottomLeftGripMorph>>shouldDraw > in emergency evaluator. > Ups. I wonder why it was removed... was it categorized as "etoys"? Maybe we should really add TT and Polymorph into the base soon. This way we make sure it works... Marcus > 2008/11/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> tx torsten :) >> >> Stef >> >> On Nov 20, 2008, at 5:31 PM, Torsten Bergmann wrote: >> >>> The ScriptLoader 665 MCZ in the pharo inbox (which is based on 664 >>> from >>> Marcus) >>> adds a simple load script to load the Polymorph UI framework into >>> pharo. >>> >>> There is no need to patch MC as described in >>> http://wiki.squeak.org/squeak/6005 >>> sine an exception handler is used to surpress the progress bar. >>> >>> It's best to close most windows before evaluating the script but >>> in most >>> cases >>> it just works. >>> >>> Thanks to Gary for the nice UI! When to expect an XP like look ;) >> >> I would ask when a pharo look :) >> >> Stef >> >>> >>> >>> Have fun, >>> Torsten >>> -- >>> Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + >>> DSL >>> fÃ¼r nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Nov. 20, 2008

Re: [Pharo-project] About browsers

by David RÃ¶thlisberger

> why are we forced to click on a method category to define one? > We could click on the class and paste a method body > then select a category... yep, that would be something... > right now apple-F is linked to look for a class in the class category. > but this would be great to have it working anywhere. I found a way to make apple-F search for classes in text panels too. Adding it to the other columns besides class cat was easy too. > I went over the shortcut list and lot of them are not working and it > would be good to check and rethink them. yes, we need to do this. Would be good if we could agree on a list of shortcuts we want to have everywhere in our tools. Because for apple-F I had to overwrite the behavior this shortcut normally has in a text editor, namely searching for a pattern in this text. So some people used to this behavior might be confused now and start to complain... ;) > PS: David the inheritance pane is now working extremely well. It is > really cool to be able to double click > on it to see the new inheritance tree and the switch between the smart > group selection and the package > view is really great. Thanks, I'm happy to hear that. :)) David

Nov. 20, 2008

Re: [Pharo-project] SUnit: history support and OB icons

by David RÃ¶thlisberger

> this is strange that the system is asking me twice to enter my password. indeed. I will check this. David > > stef > > On Nov 20, 2008, at 8:45 PM, StÃ©phane Ducasse wrote: > >> Apparently my tests were wrong. >> Now I do not understand since when I run the tests the icons do not >> change. >> >> Stef >> >> On Nov 20, 2008, at 8:17 PM, David RÃ¶thlisberger wrote: >> >>> >>>> I loaded the fix of John for the menu >>>> and the changes for SUnit icons and my image freshes when I open >>>> the Package browser and run the tests >>>> in 10162 >>> >>> which tests? All tests? >>> >>> David >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 20, 2008

Re: [Pharo-project] SUnit: history support and OB icons

by David RÃ¶thlisberger

> Now I do not understand since when I run the tests the icons do not > change. Strange. So you always get the not run icon (circle with green and red)? For me this is not the case, the icons do change. Can you check whether it saved a history in the class variable of TestCase? david > Stef > > On Nov 20, 2008, at 8:17 PM, David RÃ¶thlisberger wrote: > >> >>> I loaded the fix of John for the menu >>> and the changes for SUnit icons and my image freshes when I open the >>> Package browser and run the tests >>> in 10162 >> >> which tests? All tests? >> >> David >> >> _______________________________________________ >> 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

Nov. 20, 2008

Re: [Pharo-project] tx...

by Tudor Girba

Indeed, even from outside I can sense how things are improving with every release. I must admit it's something I was not used to since I got hooked with Smalltalk :). Cheers, Doru On Nov 20, 2008, at 9:12 PM, StÃ©phane Ducasse wrote: > Hi guys > > I just wanted to tell you that I really like what we are doing. I > was so sad in the past. I find really important > that our (marcus and me) little flame inside did not die after 3.9. > > I would really pharo to be able to move forward even Smalltalk > (first class slots for example)! > I still have the idea that the system should be beautiful and that > one person can understand it. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com www.tudorgirba.com/blog "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Nov. 20, 2008

Re: [Pharo-project] Process stuck in 10156+OB?

by StÃ©phane Ducasse

john do you have a new version of the package since the method calculateShouldBeFrom:using: is missing On Nov 20, 2008, at 12:03 AM, John M McIntosh wrote: > testCharacterChanging > | testString item shouldBe resultingString where | > #(';' '^' '!' '<' '/' '(' ) > do: [:c | #('*' '* ' '* ' '**' '** ' '** ' > ')' '*)' '* )' '* )' '**)' '** )' '** )' > ')' '*)' '*X)' '*XX)' '**)' '**X)' '**XX)' > '))' '*))' '*X))' '*XX))' '**))' '**X))' '**XX))' > '(' '*(' '*X(' '*XX(' '**)' '**X(' '**XX(' > '((' '*((' '*X((' '*XX((' '**((' '**X((' '**XX((' > ) > do: [:template | > testString := template copyReplaceAll: '*' with: c. > testString > permutationsDo: [:mixedUp | > item := mixedUp copy. > shouldBe := self calculateShouldBeFrom: item using: c. > resultingString := self modifySqueakMenu: item copy. > self should: [shouldBe = resultingString]. > (where := resultingString indexOf: $/) > 0 > ifTrue: [self should: [(mixedUp at: where) = $(]. > self should: [(mixedUp at: where+2) = $)]. > self should: [(mixedUp at: where+1) asUppercase = > (resultingString at: where+1)]]]]]

Nov. 20, 2008

Re: [Pharo-project] List of Type entry

by StÃ©phane Ducasse

no but exclusive in the tool which is boring :) Stef On Nov 20, 2008, at 9:43 PM, Alexandre Bergel wrote: > Are these types sound ? :-) > > Alexandre > > > On 20 Nov 2008, at 17:34, StÃ©phane Ducasse wrote: > >> Hi guys >> >> I added two type entries >> >> Type-Defect = Report of a software defect >> Type-Enhancement = Request for enhancement >> Type-Task = Work item that doesn't change the code or docs >> Type-Patch = Source code patch for review >> Type-Mantis = Ticket on bugs.squeak.org to integrate >> Type-Squeak = Squeak version to integrate >> Type-Other = Some other kind of issue >> Type-ToDo = To list some todo for the coming versions >> Type-NextMilestone = To remember some actions for the next >> milestones >> >> I would like that we used them to sort well the items >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 >

Nov. 20, 2008

Re: [Pharo-project] Polymorph in Pharo

by Henrik Johansen

Might want to take a peek at issue 337 before trying to switch to the Vistary look ;) Turns out the errors I reported earlier weren't really related to changes in Pharo between 101 and 144, but new version of Polymorph being released meanwhile making the Vistary window buttons nicer, but using methods no longer in Pharo. Henry StÃ©phane Ducasse wrote: > tx torsten :) > > Stef > > On Nov 20, 2008, at 5:31 PM, Torsten Bergmann wrote: > >> The ScriptLoader 665 MCZ in the pharo inbox (which is based on 664 >> from Marcus) >> adds a simple load script to load the Polymorph UI framework into pharo. >> >> There is no need to patch MC as described in >> http://wiki.squeak.org/squeak/6005 >> sine an exception handler is used to surpress the progress bar. >> >> It's best to close most windows before evaluating the script but in >> most cases >> it just works. >> >> Thanks to Gary for the nice UI! When to expect an XP like look ;) > > I would ask when a pharo look :) > > Stef > >> >> >> Have fun, >> Torsten >> -- >> Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL >> fÃ¼r nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a >> >> _______________________________________________ >> 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 > >

Nov. 20, 2008