April 2010 - Pharo-dev - lists.pharo.org

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

by Henrik Sperre Johansen

On 10.04.2010 02:21, Alexandre Bergel wrote: > Yes, the window announcements are in 1.1 > > Alexandre Doh, I didn't notice they'd been integrated! :D

April 10, 2010

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

by Henrik Sperre Johansen

On 10.04.2010 01:51, Romain Robbes wrote: > Thanks! > > So that would be for the Pharo 1.1 version, I suppose? > > Romain Hopefully, yes :) Personally I find it the most annoying things in rc4 to be: 1 it doesn't close immediately when a) I mouseclick another location in the text (only when I type something) b) change focus to another window 2 It does not update the list location when a) I've mouse-clicked another place in the morph and started typing again. b) I've moved/resized the editor 3) It takes ~ 0.5 -1 second to update if I press down, and on each character typed thereafter with items still in list (Te - down - s - t, s and t take some time to input) 4) Mouse-click on a list item does not select it. 1 is somewhat remedied by the patch I guess, for the rest I guess 2 and 4 should solvable by additional logic, and 3 would require some profiling. 1b and 2a in combination is quite annoying, as the list will be below the morph when you refocus, and in many cases you will be able to see suggestions for the new location. (1/2 b would also be easy to solve with window announcements) In essence, I feel it still could use some improvement with regards to awareness of mouse activity and multiple editors. Cheers, Henry

April 10, 2010

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

by Alexandre Bergel

Yes, the window announcements are in 1.1 Alexandre On 9 Apr 2010, at 19:51, Romain Robbes wrote: > 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 > > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 10, 2010

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

by Alexandre Bergel

I was about to say this. Alexandre On 9 Apr 2010, at 19:46, 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 10, 2010

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 9, 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 9, 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 9, 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 9, 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 9, 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