Bug 394944

Description Andrew Eisenberg 2012-11-22 17:00:39 EST

Bug 392070 c13.  https://bugs.eclipse.org/bugs/show_bug.cgi?id=392070#c13

Separating out the comment into a new bug. Here is the text, copied from the original bug report:


5.) Regarding "styleClass" within an "attributedString" proposal -- I'm not clear on what the purpose is. Is this to expose a CSS class name so external stylesheets can target it? Moreover, if we're going to add "attributedString", do we really need to keep our existing styleClasses ('proposal-emphasis', 'proposal-noemphasis', etc.) around? For API clarity, I'd prefer having 1 single way to style proposals, rather than 2 potentially-overlapping ways. 


With points #4 and #5 in mind, what do you folks think about making styleClasses extensible, and incorporating the kind of style information Tom's created for attributedStrings? Rather than making each proposal carry its style info, we could define the styleClasses separately (with a different service name, to avoid overloading orion.edit.contentAssist). Then a proposal would simply carry a styleClass field referencing the styleClass that provides its styling, and also carry the values for the segments.

For example, a Java content assist plugin might define some styleClasses like this:

> registerService('orion.core.contentassist.style', {}, {
>   styleClasses: [
>     {
>      id: 'public-method',
>      icon: { src: 'data:image/png;base64,...' }, //image data goes here
>      segments: [
>        { color: 'black', bold: true },
>        { color: 'gray' }
>      ]
>     },
>     {
>      id: 'private-method'
>      icon: { src: 'data:image/png;base64,...' },
>      segments: [
>        //whatever style is appropriate for private methods
>      ]
>     }
> })

then an individual proposal would be assigned a styleClass by having this shape:

> {
>   description: {
>     styleClass: 'public-method',
>     segments: [
>       'bla() : void', // value of first segment
>       ' - Test'       // value of second segment
>     ]
>   }
> }

I've made the assumption that most clients will have a finite set of styleClasses (eg. public, private, protected) into which proposals are categorized, so arbitrarily styling an individual proposal would not be necessary (although I guess we could add it later if needed). Interested in hearing your thoughts.

[