On Sun, May 8, 2011 at 22:51, Oto BREZINA <otik_at_printflow.eu> wrote:
> Dear Stefan
>
> 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.
Seems to be a good idea.
> 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.
ok.
> 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.
TMerge has grown over time. The decisions at the beginning were ok,
but of course with more and more features added those decisions won't
hold up anymore.
> This whole thing may be separated class with its own file. Object itself
> may be placed in MainForm and shared or implemented as Singleton.
>
> Thoughts?
Depending on the object, I'd implement it as a singleton. But a member
of CMainForm would be fine too.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2732764
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-05-09 08:47:12 CEST