[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-debug-dev] Collapsing thread behavior
|
A problem with this approach:
What does it mean to gray out text, if the user has already set it to gray?
How do we determine a "gray" color given the current foreground &
background color?
jkca
"Darin Wright/WPG/OTI"
<Darin_Wright@xxxxxxx> To: platform-debug-dev@xxxxxxxxxxx
Sent by: cc:
platform-debug-dev-admin@e Subject: Re: [platform-debug-dev] Collapsing thread behavior
clipse.org
11/15/2001 06:27 PM
Please respond to
platform-debug-dev
I like this approach, as
1) The user sees that they are in an "interim" state
2) it greatly simplifies the implementation.
let's give it a try.
Darin
Joe_Szurszewski@xxxxxxx
Sent by: To:
platform-debug-dev-admin@ecli platform-debug-dev@xxxxxxxxxxx
pse.org cc:
Subject: Re:
[platform-debug-dev] Collapsing thread
11/15/2001 02:24 PM behavior
Please respond to
platform-debug-dev
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
