On 13 February 2012 16:58, Stéphane Ducasse <[email protected]> wrote: > > On Feb 13, 2012, at 3:49 AM, S Krish wrote: > >> Will come up with a cs for the issues in Morphic widgets shortly after I >> test them more thoroughly.. >> >> I am kind of convinced that putting a breakpoint in a method with "Toggle >> Breakpoint" and then stepping through the morphic code base is causing the >> UI instability of rendering glitches and other concomittant issues. It does >> not occur, if we do normal "debugIt" and then step through, so it should not >> be much to do with Morphic stepping thru logic of events et all.. but >> something intrinsic to how the breakpoint affects Morphic / UI rendering of >> Pharo. > > I never use such functionality so I cannot comment. > I can only say, that if you put a breakpoint at wrong place somewhere in morphic code, you may endup with broken system, when rendering/event handling code always goes to that method and always halts there, causing restarting UI process on every system event.
Debugging UI while UI is running is not an easy task. Mostly done manually with tricks like haltOnce: or invoking doits which lead to parts of code under question. So, it would be good to know first, where exactly you put breakpoints. >> >> I have done fair amount of work spread across several days with the same >> image earlier, days prior to "breakpoint" capabilities on Pharo 1.1, but now >> I barely have the image last the day, goes sluggish and with these UI >> blemishes may be unrelated but I suspect a correlation: >> >> ( Pharo is Lot better though than Linux blemises with Compbiz where you >> loose all window bars, decorations.. once a while..!) >> >> On Pharo 1.3 stable mostly/ Also Pharo 1.4 latest : >> >> * The thumbnail image of taskbar windows will remain painted, behind the >> top window, on the World.. ( thankfully..) but at times on front occluding >> the top window . >> * Windows/ Menus will come up partially occluded and running the mouse over >> exposes it fully.. >> * Mouse inputs become sluggish... >> * Transcript opened in these situations sometimes has a funny effect of >> only the textMorph of transcript partially overlapping the top Window >> >> * From a newbie perspective, need to keep a list of methods break point >> cannot be put in, which are polling code.. >> >> Will need to get more precise and come back on them with fixes as possible. >> I will revert to the older breakpointing of using self halt inserted at top/ >> line I need with the "Toggle breakpoint" and check also.. >> >> Will dig in deeper and come back. >> > > -- Best regards, Igor Stasenko.
