Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Looking at ways to improve speed,
there is one glaring road blocks:
Calculating the scroll width for txtDocument.
This slows down opening documents, and also editing documents.
Any thoughts here?
This optimization is only managed by modifying
the underlying c++ code of the stc?
(Although, my eariler investigation into the underlying bottlenecks on gtk2 have lead me to believe the issue is entirely with gtk2, and not at all with scintilla or wxPython. I have not yet recieved a response to the email I sent to their dev list, to try to figure out some speed issues with pango.)
The actual slowdown is that:
1. STC does not automatically calculate horizontal scrollbar size.
2. You have to manually move the cursor to accomplish this.
So, There are two ways to do this, and both revolve around cycling through every line, locating the longest, then either
A. Moving the cursor to the end of the line, and refreshing the scroll
B. (Current), resizing the scrollbar size based on the length of the longest line, as calculated based on the actual pixel width of a character in the current style.
I am wondering if I should:
1. Leave everything as it is.
2. Not set the h.scroll width, and leave it as the stc default.
3. Find some faster way of locating the longest line.
Perhaps there is a built in python function to use instead of a loop.
4. Find a faster way of translating the length of characters of the line to the actual scroll width.
5. Go back to method A, and combine it with solution 3.
One crazy solution for this would be to implement line wrap.
You could have 2 types of wrapping:
1- Fixed width, in which case the scroll width would be equivalent.
2- Logical in which case you don't need a scroll at all since it would wrap depending on the width of the window.
With an option to turn wrap on or off then if the user leaves it off you keep everything as now (ie with the slow-down). When it's on you should notice improvment (although the wrapping logic could slow things down too).
Now ok, I know implementing wrapping would be a hell of a job and obviously not somehting to consider at this stage.
But you could keep it in mind for a future version ;)
Well, there is line wrapping in preferences already. I could check for this before bothering with the scroll width.
I've noticed though, that scite does not seem to account for scroll width at all. If I set the scroll width to a large enough default, people will probably never go outside of it, and only users who do will have to bother will using the keyboard to scroll.
On the other hand, this could be an option :)
How about a preference use the h-scrollbar at all?
I for me don't care for hscroll bar.
Vscrollbar on the other hand is more important.
I see at once, where I am relativly to the end of the file.
Ok, it is getting complicater with option and option more.
(Only a thought)
What about putting seldom usage of options in a kind
of advanced, so that preferences isn't going to be
Bookmarks, Drscript and Plugins are almost empty.
Ah yes, the source browser panel: 25% is minimum.
10 or 15% minimum would be better (it takes to much space for my notion). or remember last panel size
Ah, there is already remember panel sizes; could this be used here?