Gaetano SANTORO wrote:
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.
IMO using either scheme can be visually overstimulating :-( Coloring
of icons does have the advantage of showing up in the editor gutter
(for breakpoints and IP), but ideally the choice should be up to the
user.
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.
I didn't mean to imply that we would add the new label provider to
platform. Since it would only be implemented in DSF it could just be
added to DSF.
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
There is another thing to consider: sometime in 1.1 cycle we plan to
complete the refactoring of the DSF label providers (see bug 225650).
This will likely affect any changes that you may want to add on top of
the existing implementation, and it's something we would need to wrap
up before adding this feature. Given this uncertainly, my suggestion
would be for you to experiment with different approaches. We could
then use your finding in creating a permanent solution within DSF.
Cheers,
Pawel
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
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
|