- Pharo-dev - lists.pharo.org

Re: [Pharo-project] HostWindows rewrite

by Igor Stasenko

2008/11/9 David T. Lewis <lewis(a)mail.msen.com>: > On Sun, Nov 09, 2008 at 01:47:26PM +0200, Igor Stasenko wrote: >> Hello list, >> >> i started design of new plugin, which is conceptually based on >> HostWindows, but will be more integral & flexible. > ... > >> Awaiting for your comments or suggestions. > > I tried implementing HostWindowPlugin for X11 a couple of years ago > but did not complete it. IIRC, one area of difficulty was the encoding > of X-Y coordinates in the plugin parameters, which put the X and Y > values into the high and low order 16 bits of a 32 bit int. On X11, > the coordinates are (32 bit) signed ints, and I recall that negative > screen positions causes problems. Sorry I can't recall the exact details, > but if you do reimplement the plugin, I would suggest encoding screen > position parameters as separate X and Y ints rather than the hi and lo > 16 bit scheme used in the current plugin. > Oh, that's the bits i'm missing. I found the sources of HostWindowPlugin for win and mac, but was unable to find anything for X11. Can you please send me a sources of it, or link for downloads? Concerning 16/32 bit - forget it :) Internally, all attribute declarations having a type. Currently it will support only most commonly used types: - int - boolean - string but of course, in case of need, more types can be added later. A plugin will coerce values back and forth without any problems. And of course, i don't see a need in packing X and Y into a single 32 bit int as its currently done in HostWindowPlugin. Partly, because there will be no #setXY or #setSizeXY , but instead you'll have only an attributeAt: #attributeName put: value and setAttributes: { #name1 -> value1. #name2-> value2 ... } primitives for setting multiple attributes in single batch. > 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. 9, 2008

Re: [Pharo-project] HostWindows rewrite

by David T. Lewis

On Sun, Nov 09, 2008 at 01:47:26PM +0200, Igor Stasenko wrote: > Hello list, > > i started design of new plugin, which is conceptually based on > HostWindows, but will be more integral & flexible. ... > Awaiting for your comments or suggestions. I tried implementing HostWindowPlugin for X11 a couple of years ago but did not complete it. IIRC, one area of difficulty was the encoding of X-Y coordinates in the plugin parameters, which put the X and Y values into the high and low order 16 bits of a 32 bit int. On X11, the coordinates are (32 bit) signed ints, and I recall that negative screen positions causes problems. Sorry I can't recall the exact details, but if you do reimplement the plugin, I would suggest encoding screen position parameters as separate X and Y ints rather than the hi and lo 16 bit scheme used in the current plugin. Dave

Nov. 9, 2008

Re: [Pharo-project] Repaint does not work

by StÃ©phane Ducasse

Adrian I did from a 10107 image I did Utilities updateFromServerThroughUpdateNumber: 10115 and the repaint is working well. So I guess that you cleaned too much :) Stef On Nov 9, 2008, at 3:15 PM, StÃ©phane Ducasse wrote: > It worked in 10112 > but does not in 10116 > > On Nov 9, 2008, at 3:03 PM, StÃ©phane Ducasse wrote: > >> Hi adrian >> >> do you remember if you did something with the SketchEditorMorph >> when you optimise memory, >> because now I cannot repaint a form, I get a plainCursor error >> since the palette is nil. >> >> To reproduce >> bring halos on the pharo logo >> click on repaint >> you get one DNU because Prototype classVariable is nil and not a >> PaintBoxMorph >> then if you bring again the halos and move the mouse over the area >> we get >> a plainCursor DNU. >> >> I was not working on this area so I imagine that it may be your >> cleans. >> >> was working 10107 >> >> but not in 10133 >> >> >> Sytef >> >> _______________________________________________ >> 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. 9, 2008

Re: [Pharo-project] About etoy cleaning

by StÃ©phane Ducasse

> I'm appreciate your efforts. Keep going! > > Just one question. > You seem planning to remove Project from system, as part of Etoys. > I'm not really sure about it. A removal of Projects will lead to > model, which having only a single World (a PasteUpMorph instance), > what i fear of, because i want to make a plugin which supports > multiple windows, and therefore each window can have own PasteUpMorph > instance. I do not know. now each time I look at Project and its impact everywhere. May be it would be better to reimplement a clean multiple world abstraction. For now I'm removing player and etoy support from Project when I see them. > And it seems like its least painful way to get multiple windows > support. > > Of course, it would require rethinking the role of Display & World > globals, because there will be more than a single window and this will > require to do something with code, which assuming that there is always > a Display/World where everyone can put his dirty hands on :) > For instance, i have no idea, what to do with commonly used (and quite > convenient, in fact) message , like #openInWorld. > When you have multiple worlds, its a big question, where new morph > should appear. > > Maybe, as solution, a World/Display globals can stay, but they will > track the currently active window. In this way, all new morphs will > appear in currently active window. The problem is, that its not really > necessary for window to be associated with PasteUpMorph - it can be a > window which only having a Form for drawing and nothing more, or > window which may use different UI framework and therefore > creating/keeping an instance of PasteUpMorph for it is not an option. Probably but I do not really know. Now I'm trying not to break Morphic while removing etoys. I think that once this is done we will have to think about it. May be rebuilding another solution on the side and switching is the best when I see the current state of the code. Not a really optimistic answer but I'm getting burned by etoy > > > -- > 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

Nov. 9, 2008

Re: [Pharo-project] Repaint does not work

by Adrian Lienhard

Yes, I removed this morph as it used a lot of memory. I thought it was only used from within EToys but I didn't realize it was accessible from elsewhere. Now, the question is whether we still want to have the drawing tool in Pharo? To see my cleanup check out #cleanUpForRelease. Adrian On Nov 9, 2008, at 15:15 , StÃ©phane Ducasse wrote: > It worked in 10112 > but does not in 10116 > > On Nov 9, 2008, at 3:03 PM, StÃ©phane Ducasse wrote: > >> Hi adrian >> >> do you remember if you did something with the SketchEditorMorph >> when you optimise memory, >> because now I cannot repaint a form, I get a plainCursor error >> since the palette is nil. >> >> To reproduce >> bring halos on the pharo logo >> click on repaint >> you get one DNU because Prototype classVariable is nil and not a >> PaintBoxMorph >> then if you bring again the halos and move the mouse over the area >> we get >> a plainCursor DNU. >> >> I was not working on this area so I imagine that it may be your >> cleans. >> >> was working 10107 >> >> but not in 10133 >> >> >> Sytef >> >> _______________________________________________ >> 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. 9, 2008

Re: [Pharo-project] About etoy cleaning

by Igor Stasenko

2008/11/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I can tell you that removing etoy is really really boring/difficult/ even if > you think that this is > **just** removing some methods. I really hope that I will not break too much > but really this is a so huge mess. > I'm appreciate your efforts. Keep going! Just one question. You seem planning to remove Project from system, as part of Etoys. I'm not really sure about it. A removal of Projects will lead to model, which having only a single World (a PasteUpMorph instance), what i fear of, because i want to make a plugin which supports multiple windows, and therefore each window can have own PasteUpMorph instance. And it seems like its least painful way to get multiple windows support. Of course, it would require rethinking the role of Display & World globals, because there will be more than a single window and this will require to do something with code, which assuming that there is always a Display/World where everyone can put his dirty hands on :) For instance, i have no idea, what to do with commonly used (and quite convenient, in fact) message , like #openInWorld. When you have multiple worlds, its a big question, where new morph should appear. Maybe, as solution, a World/Display globals can stay, but they will track the currently active window. In this way, all new morphs will appear in currently active window. The problem is, that its not really necessary for window to be associated with PasteUpMorph - it can be a window which only having a Form for drawing and nothing more, or window which may use different UI framework and therefore creating/keeping an instance of PasteUpMorph for it is not an option. -- Best regards, Igor Stasenko AKA sig.

Nov. 9, 2008

Re: [Pharo-project] Repaint does not work

by StÃ©phane Ducasse

It worked in 10112 but does not in 10116 On Nov 9, 2008, at 3:03 PM, StÃ©phane Ducasse wrote: > Hi adrian > > do you remember if you did something with the SketchEditorMorph when > you optimise memory, > because now I cannot repaint a form, I get a plainCursor error > since the palette is nil. > > To reproduce > bring halos on the pharo logo > click on repaint > you get one DNU because Prototype classVariable is nil and not a > PaintBoxMorph > then if you bring again the halos and move the mouse over the area > we get > a plainCursor DNU. > > I was not working on this area so I imagine that it may be your > cleans. > > was working 10107 > > but not in 10133 > > > Sytef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 9, 2008

[Pharo-project] Repaint does not work

by StÃ©phane Ducasse

Hi adrian do you remember if you did something with the SketchEditorMorph when you optimise memory, because now I cannot repaint a form, I get a plainCursor error since the palette is nil. To reproduce bring halos on the pharo logo click on repaint you get one DNU because Prototype classVariable is nil and not a PaintBoxMorph then if you bring again the halos and move the mouse over the area we get a plainCursor DNU. I was not working on this area so I imagine that it may be your cleans. was working 10107 but not in 10133 Sytef

Nov. 9, 2008

Re: [Pharo-project] About etoy cleaning

by StÃ©phane Ducasse

I can tell you that removing etoy is really really boring/difficult/ even if you think that this is **just** removing some methods. I really hope that I will not break too much but really this is a so huge mess. Stef On Nov 8, 2008, at 10:04 PM, StÃ©phane Ducasse wrote: > Hi guys > > I just wanted to let you know that I'm working on etoy cleaning from > Object, Morph and friends. > And I will probably do some mistakes (because this is complex). I'm > trying to do that concentrated > but still this is serious beast. > > Now I'm keeping a list of my progress at this page > http://code.google.com/p/pharo/w/edit/CurrentlyWorkingOn > so that you can follow my progression and that I'm not lost either. > > I'm using gary etoy removal and going over his list and checking > senders of senders .... and verifying when I have doubts. > and I'm finding missed points from time to time and this is normal > when we see the complexity of etoy and morphic together. > So gary may be at the end I would appreciate that you have a look at > the stuff I'm removing. > May be by doing a "changes" comparison. > Right now I'm cleaning object and I will keep a list of the > difficult methods I did not fixed yet. > May be these ones will be easier to treat when etoy will be removed. > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 9, 2008

Re: [Pharo-project] HostWindows rewrite

by Michael Rueger

Igor Stasenko wrote: > 2008/11/9 Michael Rueger <m.rueger(a)acm.org>: >> Igor Stasenko wrote: >>> Hello list, >>> >>> i started design of new plugin, which is conceptually based on >>> HostWindows, but will be more integral & flexible. >> What about ffenestri? > > i currently taking parts from it as well as parts from core VM > functionality, like event handling. Not blindly , of course. :) > The idea is to make an integral plugin with clean design, which will > allow us to clean a lot of things in VM & language side both as well > as finer control of different windowing operations. Sound good :-) Just wanted to make sure that no unnecessary re-inventing of wheels takes place ;-) Michael

Nov. 9, 2008