I'm not sure if mailing list is best platform to talk about this (bit
slow), but anyway.
Till now I:
* improve KANJI support
* cleaned UseThis, UseBoth ... code
* move text and block selection (back) to view coordinates
What I would like to do:
* extend KANJI support finding way for proper wrapping for minimal
speed cost (add option to select wrap engine in worse case)
* fix some wrapping issues - may need caching
* enable cursor even in read-only view - it do all staff you just
don't see it
* editing both views in diff mode
* convert cursor to view-line coordinates
This have cons and pros I have to check. Cursor can be more persistent
over resizing and easier to use - It can speed up or slow down system.
* cache data collected from/for screening
This is main point of this email.
What we have today is three views with view-data and Screened data cache
in each. Then common Screen2View vector.
If I leave fact that no all view are used all time - all views and
screened data should have same size.
Once I insert any line in any of view I have to do it with all views.
For now this is handled by editing methods (UseLeft, PasteText ...). So
first point is to instead of manipulating views vectors separately
implement one common threeviewdata vector to handle this. I don't know
how first compare (on load) is performed though.
After inserting line we have to rebuild screen2view and screened data as
well. If we move screened data into threeviewdata vector we get screened
data keept with their source even after line insertion a thus reduce
need for rebuild.
I don't know what lead you to current design so I like to share my long
term plans to check it they don't collide with some of your design
decision before I start.
This whole thing may be separated class with its own file. Object itself
may be placed in MainForm and shared or implemented as Singleton.
Oto BREZINA, Printflow s.r.o., EU
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-05-08 22:59:54 CEST