Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Change bar feature in scintilla

<< < (2/7) > >>

Jenna:
I just created a patch against the new-scintilla-branch.

I think patching the (older) scintilla version in trunk is much more difficult, because the patch gryphon has found is against scintilla 1.7.5 and we use 1.7.7 in scintilla branch, but 1.6.x in trunk.

I uploaded it to my server ( http://apt.jenslody.de/patches/scintilla_changebar.patch ).
I'm not sure if I should commit it to the scintilla-branch, because I did (could) not test it much.

At the moment it can not be turned on or off, and the colours are not configurable.

It's tested under linux (debian 64bit) and windows.

Unfortunately the patch changes the colour of the second margin.
I don't know why, because I did not go deeper into the code, but I hope I will find the time to do so (maybe this evening/night).

gryphon:
Ok, I've uploaded a patch here:
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=2596&group_id=5358

Hopefully the patch will work for everyone.

A couple of points about the patch:

* The scintilla changebar patch itself was not written by me, but by Neil Hodgson as you can see from the first post in this thread.
* The changebar markers are placed in their own margin to prevent overlapping of markers.
* Currently the changebar is placed as the last margin, after the folding margin. This is a little different than how it appears in C++Builder and Visual C++. I did it this way as it also solved another problem I commonly have - I often want to select a line of text by draggingat the left of the line. With the folding margin there I often click inside it and fold the text rather than selecting it. With the changebar margin I now have a 4 pixel wide strip I can select lines from. Of course if folding was only activated when clicking on a '+' or '-' this would not be so much of an issue. I haven't investigated if that behaviour can be achieved for not.
* Making the margin orders configurable would not be a problem and currently in the patch the ordering of the changebar margin and the folding margin is controlled by two constants making swapping their order at compile time easy.
* The comments associated with the changebar patch indicated that the code is a memory hog and it is unlikely to be integrated into scintilla anytime soon. As such I think it would be sensible to further enhance the changebar patch to make it optional. I'd hope that would make it more likely for this to make it into scintilla. Once optional there would be opportunities to improve the changebar feature as part of scintilla itself. Separating the changebar code out further would also allow us to patch scintilla as appropriate with the changebar code even if it was not going to become part of scintilla. Or at least until it was efficient enough to become so.
gryphon

gryphon:
@Jens: Thanks for trying this! (my previous post crossed your last one as I was busy doing other things in-between writing it)

Yes I had thought about the differing versions of scintilla. My intention was to provide a patch against 1.7.7 of scintilla after I had cleaned it up. Please have a look at the patch I added to berlios to see what you think. It might be a straightforward merge.

Of course my patch in berlios is against trunk which means most of the changebar patch is actually a patch to 1.7.5 from the scintilla trunk version. With my limited testing I have not encountered any big issues but I am sure those more familiar with scintilla will be able to identify problems. Otherwise my patch against trunk seems ok.

About the margin colours (and other related issues you'll find): Have a look at how I patched the cbeditor.cpp and other codeblocks files (I think that was the main one). I think enabling the feature in codeblocks works ok and I have not had any issues so far.

Configuring, turning on and off and colour customisation, are definitely worth exploring. I didn't add that to the patch I put up to keep it smaller, I'd say though we'd really want to have that (see my comments in the previous post also).

Finally (and OT) - something I've been meaning to do for a long time: Thank you very much for you debian repository, it's been incredibly useful for me ever since you first started it  :)

gryphon

Jenna:

--- Quote from: gryphon on November 15, 2008, 09:55:07 pm ---Finally (and OT) - something I've been meaning to do for a long time: Thank you very much for you debian repository, it's been incredibly useful for me ever since you first started it  :)

--- End quote ---

Many thanks  :D

You did not change the value of wxSCI_MASK_FOLDERS to the changed value of SC_MASK_FOLDERS, otherwise you would have two changebars, one in its own margin and one inside the folder-margin.
I have to subtract the changebar-masks from wxSCI_MASK_FOLDERS for the folding mask.

But I guess the own margin is better. And it's a good idea to place it at last, because I sometimes have the same problem then you (folding instead of marking text).
If the colurs are configurable, there should be no problems with the standard-colour for "Highlight line under caret" (lightyellow).

I think the order of the margins can be hardcoded.

If it would be possible to switch the changebar off and on at runtime and to clear the history of the actual editor from the context-menu it would be really great.
I think that it should be possible, but needs some investigation, to do it "the right way".

gryphon:

--- Quote from: jens on November 15, 2008, 10:26:12 pm ---You did not change the value of wxSCI_MASK_FOLDERS to the changed value of SC_MASK_FOLDERS, otherwise you would have two changebars, one in its own margin and one inside the folder-margin.
I have to subtract the changebar-masks from wxSCI_MASK_FOLDERS for the folding mask.

--- End quote ---

Good catch! I missed that, though I had to try this to see what you mean. What is the preferred approach?

1. Leave wxSCI_MASK_FOLDERS as 0xFE000000 and no need to negate the change-bar masks (as the current patch does), or,
2. Update wxSCI_MASK_FOLDERS to the new value of 0xFF800000 and then negate the change-bar masks when setting the folding masks? I guess the original scintilla patch thought mimicking VS by default was the best approach.

My feeling is we should use the value of SC_MASK_FOLDERS from 1.7.7 (whatever that is) and perhaps add a SC_MASK_CHANGEBAR which ORs the two changebar masks together.

If you think I need to make a change to the patch regarding this let me know.


--- Quote from: jens on November 15, 2008, 10:26:12 pm ---But I guess the own margin is better. And it's a good idea to place it at last, because I sometimes have the same problem then you (folding instead of marking text).
If the colurs are configurable, there should be no problems with the standard-colour for "Highlight line under caret" (lightyellow).

--- End quote ---

Glad I'm not the only one who hits that problem :) Making the colours configurable should be straightforward. If you don't beat me to it I'll have a go at adding that.


--- Quote from: jens on November 15, 2008, 10:26:12 pm ---If it would be possible to switch the changebar off and on at runtime and to clear the history of the actual editor from the context-menu it would be really great.
I think that it should be possible, but needs some investigation, to do it "the right way".

--- End quote ---

Yeah, I think that's true. I've only begun digging deeper into the scintilla code today so haven't really got a feel yet of how to do that. I guess I should start by diff'ing against 1.7.7 to get a feel for how invasive the changebar patch actually is.

Navigation

[0] Message Index

[#] Next page

[*] Previous page