Community
Participate
Working Groups
JGS (8/14/01 11:48:04 AM) We need a way to style individual TreeItems, by setting font styles and/or colors. Right now, all items in a tree share the same font and color properties. There are workarounds, but they are complex and involve setting TreeEditors. KH (9/19/2001 9:49:53 AM) Moving to SWT SN (10/3/01 6:23:19 PM) Could this be implemented as a hint on platforms whose native tree doles not support this capability?
Somehow this wound up in my bucket. Moving back to SWT, and assigning to Steve.
It was put in your bucket, so you could answer the question. Restated it is: "Would you be willing to accept this feature, even if it was available on some platforms and not others?"
Oh sorry, I didn't see it as a question for me. The answer is yes, I think. On platforms that didn't support the styling, would there be any way to detect TreeItems that were supposed to have been styled differently, so that we could implement workarounds for them? Is this what Steve's comment about a hint means?
It depends. Hints are taken to be "just" appearance issues, so there may or may not be feedback on their availability. For things which are set as style bits, if the style isn't available, getting the style after the widget is created will show the bits as unset. Can you describe how you intend to use this feature? If you are going to provide a workaround on some platforms, does it make sense to just do this everywhere? Please give PR ownership back to me after you make your comments.
We've had two situations where being able to style individual tree items would have been useful: (1) Setting the foreground text color for stack frames in the debug tree to some gray value when stepping. For now, we only set a different icon on the stack frame TreeItems. I experimented with setting TreeEditors, etc., but this was clumsy and problematic. (2) Setting a bold font on variables in the Variables view that have changed 'recently' (since last step or suspend). I was interpreting the question about platform support for this as an open- ended thing, i.e., some platforms in the future *may* not support this . . . If we know for sure that there are platforms we intend to support that DO NOT support this feature (e.g., Windows, Linux), then I agree that a mix of native support and workarounds makes no sense. Otherwise, this is a useful enough feature that I'd vote to implement it and take a chance on future platforms.
Ok. I understand the situation. I'm not sure when/if we'll get to this, but it's on the list.
Color has been implemented. Joe, can I close this PR? (ie. not implement font)
Yes, close it. Glad to have the color ability. Thanks.
Closing. Thanks Joe.
