Community
Participate
Working Groups
Version: 3.3.0 Build id: I20070525-1350 CVS has defined a very nice set of colours to be used by the quick annotate feature. Other team providers have to copy this class if they want to create matching colours. Would it be possible to either: 1. Push it to Team as a 'utility' class 2. Push it down to Text and have 'Revision' use it as a default implementation or subclass it into a 'DefaultRevision' class or something. My preference would be for option 2 In either case, the class should probably be renamed to 'AuthorColors' to be more general.
Created attachment 71413 [details] patch to org.eclipse.jface.text Changes Revision to provide a default RGB using a copy of the CommitterColours from CVS. Based on http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs this is an API compatible change. Obviously it will break clients that compile against the new version, but run against the old one. One side effect of this change is that all colours will be consistent across team providers. That is, author brockj an CVS and SVN will have the same colour. If this is undesirable, a new method could be added to Revision to get a 'provider id' to partition the used colours.
Moving to Platform Text since the patch is to JFace/Text. Dani, if you don't think that the API belongs in JFace/Text, then please reassign back to Platform/Team and we can put the API there.
I'll take a look during 3.4.
Sorry, too late for API changes.
I like the general approach of unifying author colors but if we do this we need to do a bit more work and also allow users to configure those colors and make them stable per user, so that the colors don't get randomly assigned with each session.
Any chance this will make Eclipse 3.6? Dani, what level of configuration are you looking for? Would it be ok to just locally store a mapping of username to colour and have the colours assigned as new users are discovered? Or do you want the ability for the user to add new user->colour mappings and change them at will? Will you want it to ask the linked team provider for colours, or just use the platform defined strategy. I can write a patch for this, but don't want to waste time implementing something you won't accept.
>Any chance this will make Eclipse 3.6? Yes, if a good quality patch is provided. I'll offer my time for patch reviews. I'm envisioning a simple solution that automatically works for clients i.e. we offer an opt-out instead of an opt-in solution. - We use the same coloring algorithm as now. - Whenever a new user (Revision.getAuthor()) without a color is found we get the next free one and assign it permanently (store in preference store). - We offer a preference page (General > Editors > Text Editors > Quick Diff > Author Colors) where the user can assign colors to author strings. The same color can be assigned to different author strings which allows to map different author strings to the same person. The user will only be able to choose from existing already assigned colors. If authors are mapped then some the freed color(s) will be available again and returned by the coloring algorithm when a new color is requested.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
