- Pharo-dev - lists.pharo.org

Re: [Pharo-project] potential bugfix for orphan OCompletion menus

by Romain Robbes

Thanks! So that would be for the Pharo 1.1 version, I suppose? Romain On Apr 9, 2010, at 7:46 PM, Henrik Sperre Johansen wrote: > On 10.04.2010 01:35, Romain Robbes wrote: >> >> Hi Mariano, >> >> I couldn't find a better way. The model has to be notified that the system window closes, and so far I haven't found where that is done (if at all). >> Of course, I'll be glad to be enlightened on that issue :-). >> >> Cheers, >> Romain >> >> >> > With the Window Announcements Alexandre made, you could. > Those are not in core yet, though, and the fix would not work elsewhere. (Found in Morphic package in PharoTaskForces on squeaksource) > You'd probably want support for weak announcements/variable annoucement args first as well, as unsubscribing whenever an OCompletion morph is closed would be somewhat of an exercise otherwise. > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Romain Robbes http://romain.robb.es rrobbes(a)dcc.uchile.cl

April 10, 2010

Re: [Pharo-project] potential bugfix for orphan OCompletion menus

by Henrik Sperre Johansen

On 10.04.2010 01:46, Henrik Sperre Johansen wrote: > > You'd probably want support for weak announcements/variable > annoucement args first as well, as unsubscribing whenever an > OCompletion morph is closed would be somewhat of an exercise otherwise. > > Cheers, > Henry Err, too many beers... Not much sense in unsubscribing as a result of a window close announcements, the announcer would be gone in a short while anyways :)

April 10, 2010

Re: [Pharo-project] potential bugfix for orphan OCompletion menus

by Henrik Sperre Johansen

On 10.04.2010 01:35, Romain Robbes wrote: > Hi Mariano, > > I couldn't find a better way. The model has to be notified that the > system window closes, and so far I haven't found where that is done > (if at all). > Of course, I'll be glad to be enlightened on that issue :-). > > Cheers, > Romain > > > With the Window Announcements Alexandre made, you could. Those are not in core yet, though, and the fix would not work elsewhere. (Found in Morphic package in PharoTaskForces on squeaksource) You'd probably want support for weak announcements/variable annoucement args first as well, as unsubscribing whenever an OCompletion morph is closed would be somewhat of an exercise otherwise. Cheers, Henry

April 10, 2010

Re: [Pharo-project] potential bugfix for orphan OCompletion menus

by Romain Robbes

Hi Mariano, I couldn't find a better way. The model has to be notified that the system window closes, and so far I haven't found where that is done (if at all). Of course, I'll be glad to be enlightened on that issue :-). Cheers, Romain On Apr 9, 2010, at 6:49 PM, Mariano Martinez Peck wrote: > > > On Thu, Apr 8, 2010 at 7:51 PM, Romain Robbes <romain.robbes(a)gmail.com> wrote: > Dear list, > > I just published a version of OCompletion with a possible fix for the bug in which OCompletion menus would stay on the screen after a browser is closed. > > The issue here is inherited from eCompletion: the menu morph is not a child of the window, but a top-level morph. > To adress this, I implemented a timeout mechanism: if their was no keystroke in the editor which spawned the menu for the last 5 seconds, the menu will close automatically. > > > Thanks, this bug was really annoying :) > Now...I ask completely for ignorance...why you need to wait a timeout ? there is no way to notify from the browser to the oCompletion popup ? so that when it is close, it notifies the rest... > > > You can hence try Ocompletion-RomainRobbes.54 on squeaksource, and tell me what you think of the solution, or of the length of the timeout (I tried to stay conservative, maybe something like 3 seconds would work better). > > Cheers, > Romain > > -- > Romain Robbes > http://romain.robb.es > rrobbes(a)dcc.uchile.cl > > > _______________________________________________ > 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 -- Romain Robbes http://romain.robb.es rrobbes(a)dcc.uchile.cl

April 10, 2010

Re: [Pharo-project] potential bugfix for orphan OCompletion menus

by Mariano Martinez Peck

On Thu, Apr 8, 2010 at 7:51 PM, Romain Robbes <romain.robbes(a)gmail.com>wrote: > Dear list, > > I just published a version of OCompletion with a possible fix for the bug > in which OCompletion menus would stay on the screen after a browser is > closed. > > The issue here is inherited from eCompletion: the menu morph is not a child > of the window, but a top-level morph. > To adress this, I implemented a timeout mechanism: if their was no > keystroke in the editor which spawned the menu for the last 5 seconds, the > menu will close automatically. > Thanks, this bug was really annoying :) Now...I ask completely for ignorance...why you need to wait a timeout ? there is no way to notify from the browser to the oCompletion popup ? so that when it is close, it notifies the rest... > > You can hence try Ocompletion-RomainRobbes.54 on squeaksource, and tell me > what you think of the solution, or of the length of the timeout (I tried to > stay conservative, maybe something like 3 seconds would work better). > > Cheers, > Romain > > -- > Romain Robbes > http://romain.robb.es > rrobbes(a)dcc.uchile.cl > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 10, 2010

Re: [Pharo-project] Canvas transform bug when rendering text?

by Henrik Johansen

Not entirely sure sesong as I write this from a phone with no code nearby, but a hunch would be checking the method in question, and try disabling the shadow drawing, Cheers, Henry Den 9. apr. 2010 kl. 23.42 skrev Chris Muller <asqueaker(a)gmail.com>: > Thank you Henrik, it looks like a huge improvement! The attached > screen shots help explain why I only said "improvement" instead of > "perfect". Look at the color of my translucent morph when it is > upright vs. rotated. The translucency is now preserved, which is > great! However, do you know why the color seems to lose so much > saturation? > > > 2010/4/8 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: >> On 07.04.2010 14:26, Henrik Johansen wrote: >> >> On Apr 7, 2010, at 1:45 49PM, David Harvey wrote: >> >> Hi list, >> I'm writing a little charting morph, and while playing with >> rotating text >> for axis labels came across something which I've noted in Morphs text >> handling a couple of times. >> If I apply a transform in a drawing operation, rotated text >> _appears_ to be >> drawn twice, slightly offset, giving a scrappy bold look. It seems >> only to >> do this when drawing on a form canvas that's backed onto the >> display: if you >> pick and drag the morph, the text is rendered beautifully. >> The test morph attached isolates the problem. The transcript >> logging is an >> attempt to see what might be happening: looking at the output it >> appears >> that there are circumstances in which the during: block is invoked >> twice. >> Any thoughts? >> David >> >> http://n4.nabble.com/Problem-with-TransformationMorph-td1691811.html#a16918… >> Basically, transform doesn't work with depth 32. >> Workarounds are described in the thread. >> Cheers, >> Henry >> >> David, Lukas, whomever else it may concern. >> >> Of course I turned out to be (partly) wrong when looking into it. >> Transform does indeed not work with alpha, but not because of bugs in >> WarpBlt as I assumed, but because FormCanvas always uses the Paint >> rule when >> rotating... >> Try the attached code, and you should get better results. (you >> probably want >> to use smoothing > 1 if displaying text with rotation other than a >> multiple >> of 90 degrees). >> >> This seems to be more of a generic problem though, looking at the >> number of >> places a= 32 ifTrue: [] check is made, I'll try to come up with a >> more >> consistent solution for a system-wide patch. (which amongst other >> things >> would also fix the black border appearing around a window while >> zooming back >> to old position when you drag and drop it outside main window) >> >> Cheers, >> Henry >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > <upright.png> > <rotatedWithFix.png> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 9, 2010

Re: [Pharo-project] [update 1.1] #11310

by Henrik Johansen

Me neither, I just looked at the method changed in the .cs Torsten created based on Squeak changes and checked what was appropriate :) Btw, a "bad" side-effect is you Are no konger able to close a hung image with the close button, since it noe gets sent to the image side for handling. Cheers, Henry Den 9. apr. 2010 kl. 21.54 skrev StÃ©phane Ducass <stephane.ducasse(a)inria.f r>: > > 11310 > ----- > > - Issue 2286: Class definition while compiling method > - Issue 2131: Handling Window events. Thanks Henrik - I looked at > the code and I would not be able to fix that. > again some stuff to learn. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 9, 2010

Re: [Pharo-project] Canvas transform bug when rendering text?

by Chris Muller

Thank you Henrik, it looks like a huge improvement! The attached screen shots help explain why I only said "improvement" instead of "perfect". Look at the color of my translucent morph when it is upright vs. rotated. The translucency is now preserved, which is great! However, do you know why the color seems to lose so much saturation? 2010/4/8 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: > On 07.04.2010 14:26, Henrik Johansen wrote: > > On Apr 7, 2010, at 1:45 49PM, David Harvey wrote: > > Hi list, > I'm writing a little charting morph, and while playing with rotating text > for axis labels came across something which I've noted in Morphs text > handling a couple of times. > If I apply a transform in a drawing operation, rotated text _appears_ to be > drawn twice, slightly offset, giving a scrappy bold look. It seems only to > do this when drawing on a form canvas that's backed onto the display: if you > pick and drag the morph, the text is rendered beautifully. > The test morph attached isolates the problem. The transcript logging is an > attempt to see what might be happening: looking at the output it appears > that there are circumstances in which the during: block is invoked twice. > Any thoughts? > David > > http://n4.nabble.com/Problem-with-TransformationMorph-td1691811.html#a16918… > Basically, transform doesn't work with depth 32. > Workarounds are described in the thread. > Cheers, > Henry > > David, Lukas, whomever else it may concern. > > Of course I turned out to be (partly) wrong when looking into it. > Transform does indeed not work with alpha, but not because of bugs in > WarpBlt as I assumed, but because FormCanvas always uses the Paint rule when > rotating... > Try the attached code, and you should get better results. (you probably want > to use smoothing > 1 if displaying text with rotation other than a multiple > of 90 degrees). > > This seems to be more of a generic problem though, looking at the number of > places a= 32 ifTrue: [] check is made, I'll try to come up with a more > consistent solution for a system-wide patch. (which amongst other things > would also fix the black border appearing around a window while zooming back > to old position when you drag and drop it outside main window) > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 9, 2010

Re: [Pharo-project] Initial experience coming from Squeak

by Chris Muller

> * what is with the workflow of the default browser? Â When you click on a > protocol, the method template appears in the bottom pane, all highlighted > and ready to be replaced. Â But because hovering over the pane doesn't give > it the keyboard focus (like Squeak), you have to click in it, which > unselects the template, which you then have to reselect manuallyâ¦ Â Certainly > not a big deal, but weird. Â I though of a few possible fixes: > Â - automatically give the bottom pane the keyboard focus when working in > the protocol column (which doesn't seem to need it (I like this one - fewest > steps for the user) > Â - don't have the template pre-selected, so that clicking in the pane below > the template selects it (easiest fix, requires one more user click) Ha, the "click-for-focus" mosquito finally bit someone besides me. Sean, to live happily ever after, in Preferences, just enable mouseOverForKeyboardFocus. It solves all of the problems you mentioned above, reduces the overall effort needed to use the system because merely "pointing" at an object endows it with 100+ "mouse buttons" (left, middle, right, + the whole keyboard). It is more becoming of an object-oriented system, and if you can keep it on long enough to get used to it, I'll bet you'll never want to go back..

April 9, 2010

[Pharo-project] [update 1.1] #11310

by StÃ©phane Ducasse

11310 ----- - Issue 2286: Class definition while compiling method - Issue 2131: Handling Window events. Thanks Henrik - I looked at the code and I would not be able to fix that. again some stuff to learn. Stef

April 9, 2010