More re Rev 5464: Changing text pane colors dynamically is now deprecated

[Edward K. Ream]

Besides scrolling-related issues, rev 5464 takes another step towards eliminating all problematic calls to w.setStyleSheet.

It does this by honoring focus-border settings in preference to background/foreground colors in text widgets.  This will happen if @bool use_focus_border = True This is the default, so by default you will get the new scheme.

**Important**: you can still specify colors for text widgets in the Qt style sheet as always, so don't panic ;-)  The new scheme simply means that if you allow focus border colors, only focus borders will be redrawn when focus changes *or* when input state changes from, say, insert state to command state.

Because the focus borders are updated without using w.setStyleSheet in any way, the new way will completely eliminate the unwanted scrolling that results from calls to w.setStyleSheet.

Furthermore, using focus borders colors should work well with *any* color scheme, including solarized colors.  But the color scheme I prefer and recommend is simply to use a white or sepia background in the body pane.  Imo using strong border colors to indicate state is much better than using subtly-different pastel shades for the text background.  Ymmv.

Some new settings are needed to make the new scheme work.  They are in leoSettings.leo.

    @color focus_border_color = blue
    @color focus_border_command_state_color = red
    @color focus_border_overwrite_state_color = green

The first setting is not new, but iirc, the old default value for the first setting was red.  Naturally, you should copy these to myLeoSettings.leo if you change them.

I think most people will enjoy the new scheme.  It is much more solid than the old.  No unwanted scrolling ever.

Please report any problems with the new code immediately.

Edward

[F.S.]

This was reported to the scroll issues thread already. I added a bit more details below:

Rev 5465 is fairly unusable. 

1) Switching between large nodes takes forever. It used to be snappy.

2) Cursor is no longer visible if I navigate away from a node and then come back to it. Coming back to a node I always get the beginning lines.  I believe the cursor position is not lost but is just out of view. It takes a lot of scrolling to get the cursor back in view again.

[F.S.]

On Friday, September 28, 2012 11:57:44 PM UTC-7, F.S. wrote:

This was reported to the scroll issues thread already. I added a bit more details below:

Rev 5465 is fairly unusable. 

1) Switching between large nodes takes forever. It used to be snappy.

Okay. I was wrong about the snappy part. The performance seems about the same: switching between large nodes have been slow all along. I just didn't notice it until I was testing the switching behavior because of the lost cursor visibility, when how slow it is really stood out. How comes Leo is able to open many large files quickly but can't handle a few large nodes?

[F.S.]

By "large" I mean leaf nodes containing up to maybe 1200 lines of codes. About 6 such or smaller nodes in a file. It takes very noticeable amount of time to switch nodes.

As I noted before qtGui alone contains over 10k lines and is only one part of the Leo file that contains many other source files, yet one is able to navigate around the nodes without effort.

[Edward K. Ream]

On Sat, Sep 29, 2012 at 2:24 AM, F.S. <speec...@gmail.com> wrote:

> How comes Leo is able to open many large files quickly but can't handle a few large nodes?

It takes a long time to syntax color large nodes. Use @killcolor to
suppress syntax coloring.

Edward