Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [dsdp-dd-dev] Coloring launch view contexts

Hi Pawel,
 
In attach two screenshots of how I imagine a colored launch view, it's a bit different from the one in WindRiver proposal.
I only color the foreground text, without coloring icons, (colored icons get a little confusing, IMHO), that's more simple and clear to see.
 
What you see in the screenshots is easily done using ILabelUpdate.setForeground when implementing IElementLabelProvider.update because I get the context with findDmcInPath (IDMContext in my case), then I get the associated color.
 
But, I've a doubt adding a new interface IMultiColorElementProvider, implies modification at least in org.eclipse.debug.internal.ui.viewers.model.TreeModelLabelProvider.update, and there I have no visibility of IDMContext.
The above implies big modifications out of the DSF project.
I think it is easier to limit the contribution to DSF Project instead that in org.eclipse.debug.ui.
 
What you suggest about this? We can find another way to have colored launch view limiting modifications only in DSF?
 
Any suggestion is welcome,
 
Ciao,
Gaetano

From: dsdp-dd-dev-bounces@xxxxxxxxxxx [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
Sent: Friday, May 23, 2008 23:28
To: Device Debugging developer discussions
Subject: Re: [dsdp-dd-dev] Coloring launch view contexts

Joi Gaetano,

Using colors to visually identify colors in Debug views is something that Wind River debugger has had for a long time (see http://www.eclipse.org/downloads/download.php?file=/dsdp/dd/2005-10-12_Chicago_DD_MultipleDebugContexts.ppt).  As we migrate our product to fully utilize DSF, this is one of the features that we will need to port.  So if this is a feature that you would be willing to develop in open source we would gladly contribute applicable components from our product so you could use it as well.

That said, I have to admit that there are a lot of usability issues with this feature (as it exists in our product today), which makes this feature not contributable to Eclipse as is.  I have been trying to work with this community to come up with ideas to improve the overall workflow story of multi-core debugging in Eclipse, through the Multi Context technology sub group, and through this group I would like to work out a way to contribute this feature as well as other features to Eclipse into the appropriate Project/Component (Platform Debug, or CDT, or DSF, etc). 

There is no doubt that we (at least Wind River) will want to see the capability of using colors in the debug views, like I said the Wind River product will need it as well.  What is unclear is how this capability should integrate with the rest of the Eclipse workflow.  So if you would like to contribute this feature to DSF, we will need to do it in such a way that the linking to the entity that will decide what colors to use where remains flexible.  So with that in mind I'll try to respond to your questions:

Gaetano SANTORO wrote: 
Hi all,

I would like to add a coloring feature that assign a color to a context in the launch view.

So if I'm debugging a multicore processor I can see every core/context in different color.

If I'm not clear, I can provide an image to explain what I mean. (can I send attach to the mailing list?)
If you have something different in mind than the Wind River presentation, llinked above, please provide more dtails, and screenshots are fine to send to the mailing list (I think).
I'm starting investigating how to implement it, and already have some ideas.

I would add a class in org.eclipse.dd.dsf.debug.ui that associate a color to a context/core.
In particular, the above class take as input an IDMContext and map this context with a color.
So when I need to print some information related to the context, I ask which is the color associated to the context, for example using a method called getRgbColorForContext(IDMContext).
This is more less the mechanism we're using, although instead of returning the RGB directly, we use a separate object to represent a given color-space.
In my case I need to color the treeitems of the launch view, so I will use the above defined class in the LabelProviders of the launch view. The result is that each core has an unique color associated.

It is the correct way? What do you think about this feature? Any suggestions are welcome
Yes, this is also how Wind River's implementation works.  The weakness I find in this is that it spreads the responsibility of providing colored contexts into a lot of classes.  If I was designing this again, I would see if I can get the label providers for individual elements return a standard image, which could then be colored to the desired RGB in a central location.  So in terms of implementation, what I could imagine is that elements which support coloring would implement IMultiColorElementLabelProvider instead of the standard IElementLabelProvider, and the IElementLabelProvider would be implemented centrally and delegate to the multi-color label providers as needed, only adding the coloring to the correct RGB.

I hope this doesn't sound too confusing, we may need to have a phone call to work out the details of this.

Cheers,
Pawel
Thanks,
Gaetano

Attachment: launchview1.png
Description: PNG image

Attachment: launchview2.png
Description: PNG image

Back to the top