Re: [platform-debug-dev] Collapsing thread behavior

[Joe_Szurszewski@xxxxxxx]

Let this be a lesson.  When I post a proposal, you should respond immediately with "Agreed".  Otherwise, the mailer daemon will spam the list until you do.

;-)

Joe

Jared_Burns@xxxxxxx Sent by: platform-debug-dev-admin@xxxxxxxxxxx 11/15/01 03:09 PM Please respond to platform-debug-dev

To:        platform-debug-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-debug-dev] Collapsing thread behavior

I've gotta say... I just wasn't convinced the first dozen times I read 
this. But by the thirtieth time? Sold!

Nice one, Joe. :)
- Jared





Joe_Szurszewski@xxxxxxx
Sent by: platform-debug-dev-admin@xxxxxxxxxxx
11/15/2001 02:24 PM
Please respond to platform-debug-dev

 
        To:     platform-debug-dev@xxxxxxxxxxx
        cc: 
        Subject:        Re: [platform-debug-dev] Collapsing thread behavior









Jed and I have mocked up a tree with 100 children, and a toggle button to
toggle the children back forth from "enabled" to "disabled".  What this
really means is individually contacting each child and having it set its
foreground color to gray and its icon to a grayscale version of the
original.  The only way to do this on TreeItems is to set non-editable
TreeEditors on the TreeItems in question.  This gives us the ability to 
set
the foreground color.  Given that the number of stack frames that exist at
any one time should be reasonably small, this doesn't seem like too much 
of
a heavyweight approach.  We could also pool TreeEditors so that we don't
have to always create new ones.  The actual toggling from enabled to
disabled is very fast.

Thus, I think Jared's proposal is the path we should follow.  It gets rid
of the timeout concept entirely, and is less disorienting to the user 
since
they will never see stack frames disappearing, then reappearing.  We 
always
gray out the stack frames on a step start, and always un-gray them on a
step end; because no text changes (except maybe in the thread label), 
there
shouldn't be any perceivable flicker for fast steps.  I think it is also
more helpful for the user to see the stack frames, even during a long 
step,
since without them, the user has no context as to where they were 
stepping.
All of the alternative approaches involve new API, are much more complex,
and almost all of them are susceptible to timing problems.  This approach
involves no new API, is very simple, has no timing issues, but still
separates the model and UI code.

Attached are two screen prints of the mock up.



Any and all comments encouraged,
Joe
|------------------------+------------------------+------------------------|


|                        |   Jared_Burns@xxxxxxx  |
|
|                        |   Sent by:             |           To:
|
|                        |   platform-debug-dev-ad|
platform-debug-dev@ec|
|                        |   min@xxxxxxxxxxx      |   lipse.org
|
|                        |                        |           cc:
|
|                        |   11/15/01 10:16 AM    |           Subject:
|
|                        |   Please respond to    |   Re:
|
|                        |   platform-debug-dev   |   [platform-debug-dev]
|
|                        |                        |   Collapsing thread
|
|                        |                        |   behavior
|
|------------------------+------------------------+------------------------|










I propose an alternate solution: greying out stack frames during a step


_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev