ScPostIt revision

[Eike Rathke]

Hi Mike,

On Saturday, 2015-06-20 10:31:51 +1000, Mike Kaganski wrote:

> >>1. *Ordinary* objects: they belong to one and only one cell in a document.
> >>They don't share anything with no other *ordinary* note, nor with
> >>*clipboard* notes. But they always share data with *undo* notes.
> >You'll need copy-on-write for that, otherwise modifying a note would
> >also modify the Undo note.
> 
> Well, that's not a problem. In undo notes, unmodified caption state is not
> required at all times, only when it is about to be used (i.e. it's at the
> top of undo stack). Any following modification (including modifying the note
> in question) will create its own undo, and put it to undo stack. Rewinding
> modifications will bring the modified object to original state when the undo
> note in question will have to be used.

Then I don't understand what exactly you mean with "they [ordinary
notes] always share data with *undo* notes". I understood share as share
non-copied. Is it? Maybe I'm confusing whether you write about the
current implementation or what it should be.

> >>- to *clipboard* notes - then do deep copy; but the copy data should also be
> >>able to live without drawing layer. I believe that cut-to-clipboard should
> >>be treated uniformly, because there are *undo* objects that share data with
> >>original object, so transferring it to clipboard is prone to problems.
> >As long as they *are* the same you don't need deep copies.
> 
> Well, that *requires* the copy-on-write logic. As I mentioned, currently,
> it's not implemented for notes. And that's the major change that everyone
> advises me to avoid in the beginning.

Yes, you should do that only after having fully understood the logic and
have tests written.

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20150622/e411fa03/attachment.sig>