Menu

#420 dynamic background color

open
Scintilla (391)
2
2007-05-20
2007-05-20
No

Currently it's only possible to change/set the background color of styles, or with the SC_MARK_BACKGROUND marker.

I'd like some sort of callback function Scintilla calls to ask for the background color of a specific line it draws. Maybe from Editor::DrawLine().

Reason why I need such a feature:
I'd like to change the background color of lines dynamically to indicate their 'age'. I'm using Scintilla to show a blame/annotation of a file in version control, and it would really improve if I could show the user which lines are old and which ones got changed very recently by changing the background color of those lines. E.g., red indicating 'hot' lines which were changed recently, and fading over to blue the older the lines are.

Since such an 'age indicator' would need a lot of colors (I was thinking of about 100 different shades of red->blue), using styling doesn't work.

Discussion

  • Stefan Kueng

    Stefan Kueng - 2007-05-20

    patch

     
  • Stefan Kueng

    Stefan Kueng - 2007-05-20

    Logged In: YES
    user_id=466795
    Originator: YES

    patch attached with an example implementation on how this might work.
    File Added: scintilla_bkcolor.patch

     
  • Neil Hodgson

    Neil Hodgson - 2007-05-20
    • labels: --> Scintilla
    • priority: 5 --> 2
    • assigned_to: nobody --> nyamatongwe
     
  • Neil Hodgson

    Neil Hodgson - 2007-05-21

    Logged In: YES
    user_id=12579
    Originator: NO

    Scintilla has avoided callbacks for a number of reasons and has further avoided modifying values in the notification structure because this is difficult for some languages. Except for SCN_STYLENEEDED, events are sent to the container as notifications with no expectation of response. The model is that of having a state mostly contained within Scintilla that can be modified by the API rather than sharing state between the container and Scintilla.

    This particular modification conflicts with paletted display support. Scintilla knows (to an extent - there are complications) all the colours that are going to be used in its display so can respond to a palette query with that list. The list is then arbitrated by the platform (since there may be more colours used than palette entries) and the window is drawn with that 'realized' palette. Paletted displays are now fairly uncommon but some platforms mediate colour access through palette calls so that is how Scintilla works.

    An implementation more in harmony with Scintilla's design would allow setting a list of background colours so they can take part in palette creation and then associate entries in that list with particular lines. I'm not sure what the best implementation would be. Possibly extending the marker system to allow for more than 32 markers without supporting the bit set calls for those beyond 32. Another approach would be to allow an extra parameter to each marker so you could say that the background colour marker for line l should use colour index i.

     
  • Stefan Kueng

    Stefan Kueng - 2007-05-27

    Logged In: YES
    user_id=466795
    Originator: YES

    I think just because it is difficult for some languages to handle callbacks is not a good reason to completely abandon callbacks completely. Even if some feature might be impossible for some languages to use, other languages still could use them.

    Your idea of extending the marker system seems ok, but it would require a lot of more memory. A callback would not require more memory at all.

    Maybe implement both? Callbacks for those languages/systems which can use them easily, extended markers for those who can't.

     
  • Neil Hodgson

    Neil Hodgson - 2007-05-29

    Logged In: YES
    user_id=12579
    Originator: NO

    Cross-language and cross-platform support are core aims of Scintilla and shouldn't be compromised because a feature can be added more easily for a subset of containers. I don't believe the additional memory required is unreasonable for normal use. The current API is already very large - implementing a feature twice just adds to API bloat. You haven't addressed the palette issue.

     

Log in to post a comment.