Sure, I hope my understanding of the system, polling events is good enough to avoid basic pitfalls.. But this is debug breakpoint of custom classes for Morphic View.. simple morphic compositions.. not in the Pharo framework code.. But as you said let me get this cleanly replicable this weekend and give a heads up.. else its like finding a needle in a haystack.. On Mon, Feb 13, 2012 at 10:36 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 13 February 2012 16:58, Stéphane Ducasse <stephane.ducasse@inria.fr> 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.