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 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. >
