Question about the excutive way of redline

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about the excutive way of redline

Fan Zheng
Hi, All:

I have a question about the Change Recording (Redline), would you pls give
me some tips on it?

As all we know, under the redline mode "Show", the content of all changes
with type "Delete" recorded in the redline table of current document will
still be visible in the context.

And if we change the redline mode from "Show" to "Hide", said "Delete" typed
changes related content will be invisible by moving said content from main
body of document into the segment of hided changes (SHC).

Said operation Hide for "Delete" changes was designed in 2 ways (Implemented
in SwRedline::Hide()):
A. Move delete changes related content from main body into SHC;
B. Make a copy of delete changes related content in SHC, and remove the
original content from main body;

Said design B is for almost all invoking of SwRedline::Delete(). And design
A is only invoked in the SwDoc::CompressRedlines(), which is a method for
combining the existed change records.

My question is, what do we concerned about to make the design of Hide in 2
different ways?
Reply | Threaded
Open this post in threaded view
|

Re: Question about the excutive way of redline

Michael Stahl-3
On 09/03/2010 08:27, fan Zheng wrote:

> Hi, All:
>
> I have a question about the Change Recording (Redline), would you pls give
> me some tips on it?
>
> As all we know, under the redline mode "Show", the content of all changes
> with type "Delete" recorded in the redline table of current document will
> still be visible in the context.
>
> And if we change the redline mode from "Show" to "Hide", said "Delete" typed
> changes related content will be invisible by moving said content from main
> body of document into the segment of hided changes (SHC).
>
> Said operation Hide for "Delete" changes was designed in 2 ways (Implemented
> in SwRedline::Hide()):
> A. Move delete changes related content from main body into SHC;
> B. Make a copy of delete changes related content in SHC, and remove the
> original content from main body;
>
> Said design B is for almost all invoking of SwRedline::Delete(). And design
> A is only invoked in the SwDoc::CompressRedlines(), which is a method for
> combining the existed change records.
>
> My question is, what do we concerned about to make the design of Hide in 2
> different ways?

this is a very interesting question.
in fact i have probably asked it myself :)
the problem is that nobody knows the answer... the original authors of the
sw redline code have left many years ago.

i can only speculate that in some cases there can be a difference whether
some range is moved or copied and then deleted.
for example, if the range contains frames, or footnotes, which have a
special section at the beginning at the nodes array for their content.
or maybe the reason has something to do with undo.

maybe there was a reason many years ago, but today that reason no longer
exists?

i guess the only way to find out would be to change the implementation to
do it only one way, and then test a lot to see what breaks.

actually, imho, the redline design in writer is fundamentally broken,
because the redlines are really part of the document model.
the option to change the redline mode from "Show" to "Hide" is purely a
view option, and should not change the document model in any way.

regards,
michael

--
"I conclude that there are two ways of constructing a software design:
 One way is to make it so simple that there are obviously no deficiencies
 and the other way is to make it so complicated that there are no obvious
 deficiencies." -- C. A. R. Hoare (in "The Emperor's Old Clothes")


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Question about the excutive way of redline

Fan Zheng
Hi, Michael:
Thanks for your response!

2010/3/10 Michael Stahl <[hidden email]>

> On 09/03/2010 08:27, fan Zheng wrote:
> > Hi, All:
> >
> > I have a question about the Change Recording (Redline), would you pls
> give
> > me some tips on it?
> >
> > As all we know, under the redline mode "Show", the content of all changes
> > with type "Delete" recorded in the redline table of current document will
> > still be visible in the context.
> >
> > And if we change the redline mode from "Show" to "Hide", said "Delete"
> typed
> > changes related content will be invisible by moving said content from
> main
> > body of document into the segment of hided changes (SHC).
> >
> > Said operation Hide for "Delete" changes was designed in 2 ways
> (Implemented
> > in SwRedline::Hide()):
> > A. Move delete changes related content from main body into SHC;
> > B. Make a copy of delete changes related content in SHC, and remove the
> > original content from main body;
> >
> > Said design B is for almost all invoking of SwRedline::Delete(). And
> design
> > A is only invoked in the SwDoc::CompressRedlines(), which is a method for
> > combining the existed change records.
> >
> > My question is, what do we concerned about to make the design of Hide in
> 2
> > different ways?
>
> this is a very interesting question.
> in fact i have probably asked it myself :)
> the problem is that nobody knows the answer... the original authors of the
> sw redline code have left many years ago.
>
> i can only speculate that in some cases there can be a difference whether
> some range is moved or copied and then deleted.
> for example, if the range contains frames, or footnotes, which have a
> special section at the beginning at the nodes array for their content.
> or maybe the reason has something to do with undo.
>


Doing something with undo... Gash, that is my biggest headache currently.

In OO, Some flying object related undo action in SW, for example the inherit
class of SwFlyingUndoBase, refer a SwFlyFrmFmt pointer as a member data, all
the recording modifications must be undone or redone on the flying object
through said pointer. For maintaining the validate of the pointer, any user
modification of flying object must have corresponding undo action to be
recorded into undo list. Some special modifications, such as the deletion of
flying object, will just remove the corresponding SwFlyFrmFmt from the
flying frame format list of data module (SwDoc::pSpzFrmFmtTbl), and the
exact memory alloced in heap is not actually destructed. The destruction of
said flying frame format could be invoked inside the corresponding undo
actions.

But on the other side, in the process of changing redline mode from "Show"
to "Hide", the Deleted sections will be copied into SHC (by
SwRedline::CopyToSection) and the original parts will be deleted from data
module (by SwRedline::DelCopyOfSection), which is the directly deletion
without any corresponding undo action recorded in (of cause should be
designed like this. For changing redline mode from Show to Hide is not exact
a user modification). That means, if there is any flying object inside
corresponding deletion range, it will be deleted directly (destructed
already). Any said flying object related undo actions recorded in list
become time bombs. Crash is just standing at the corner of the street.

In general, this is a problem about a same data managed by different
patterns. Obviously, the design of undo action and design of redline is made
by different person or team, right?

The best way for solving said problem should be: shift "copy/delete" way
into "move" way. And that is why I asked the former question...

Do you any better idea on it?

Thanks alot !
Easyfan.Zheng

>
> maybe there was a reason many years ago, but today that reason no longer
> exists?
>
> i guess the only way to find out would be to change the implementation to
> do it only one way, and then test a lot to see what breaks.
>
> actually, imho, the redline design in writer is fundamentally broken,
> because the redlines are really part of the document model.
> the option to change the redline mode from "Show" to "Hide" is purely a
> view option, and should not change the document model in any way.
>
> regards,
> michael
>
> --
> "I conclude that there are two ways of constructing a software design:
>  One way is to make it so simple that there are obviously no deficiencies
>  and the other way is to make it so complicated that there are no obvious
>  deficiencies." -- C. A. R. Hoare (in "The Emperor's Old Clothes")
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Question about the excutive way of redline

Michael Stahl-3
On 10/03/2010 14:26, fan Zheng wrote:

> Hi, Michael:
> Thanks for your response!
>
> 2010/3/10 Michael Stahl <[hidden email]>
>
>> On 09/03/2010 08:27, fan Zheng wrote:
>>> Hi, All:
>>>
>>> I have a question about the Change Recording (Redline), would you pls
>> give
>>> me some tips on it?
>>>
>>> As all we know, under the redline mode "Show", the content of all changes
>>> with type "Delete" recorded in the redline table of current document will
>>> still be visible in the context.
>>>
>>> And if we change the redline mode from "Show" to "Hide", said "Delete"
>> typed
>>> changes related content will be invisible by moving said content from
>> main
>>> body of document into the segment of hided changes (SHC).
>>>
>>> Said operation Hide for "Delete" changes was designed in 2 ways
>> (Implemented
>>> in SwRedline::Hide()):
>>> A. Move delete changes related content from main body into SHC;
>>> B. Make a copy of delete changes related content in SHC, and remove the
>>> original content from main body;
>>>
>>> Said design B is for almost all invoking of SwRedline::Delete(). And
>> design
>>> A is only invoked in the SwDoc::CompressRedlines(), which is a method for
>>> combining the existed change records.
>>>
>>> My question is, what do we concerned about to make the design of Hide in
>> 2
>>> different ways?
>> this is a very interesting question.
>> in fact i have probably asked it myself :)
>> the problem is that nobody knows the answer... the original authors of the
>> sw redline code have left many years ago.
>>
>> i can only speculate that in some cases there can be a difference whether
>> some range is moved or copied and then deleted.
>> for example, if the range contains frames, or footnotes, which have a
>> special section at the beginning at the nodes array for their content.
>> or maybe the reason has something to do with undo.
>>
>
>
> Doing something with undo... Gash, that is my biggest headache currently.
>
> In OO, Some flying object related undo action in SW, for example the inherit
> class of SwFlyingUndoBase, refer a SwFlyFrmFmt pointer as a member data, all
> the recording modifications must be undone or redone on the flying object
> through said pointer. For maintaining the validate of the pointer, any user
> modification of flying object must have corresponding undo action to be
> recorded into undo list. Some special modifications, such as the deletion of
> flying object, will just remove the corresponding SwFlyFrmFmt from the
> flying frame format list of data module (SwDoc::pSpzFrmFmtTbl), and the
> exact memory alloced in heap is not actually destructed. The destruction of
> said flying frame format could be invoked inside the corresponding undo
> actions.
>
> But on the other side, in the process of changing redline mode from "Show"
> to "Hide", the Deleted sections will be copied into SHC (by
> SwRedline::CopyToSection) and the original parts will be deleted from data
> module (by SwRedline::DelCopyOfSection), which is the directly deletion
> without any corresponding undo action recorded in (of cause should be
> designed like this. For changing redline mode from Show to Hide is not exact
> a user modification). That means, if there is any flying object inside
> corresponding deletion range, it will be deleted directly (destructed
> already). Any said flying object related undo actions recorded in list
> become time bombs. Crash is just standing at the corner of the street.

hmmmm.... that sounds pretty bad...

i'm not (yet) familiar with most of the code that handles frames.

i've looked a bit in issuezilla, and there is this:
http://www.openoffice.org/issues/show_bug.cgi?id=101666

this issue seems to be caused by the design flaw you describe.

> In general, this is a problem about a same data managed by different
> patterns. Obviously, the design of undo action and design of redline is made
> by different person or team, right?

i'm not sure... from what i've heard i think it was more a problem of "the
boss says it must be finished tomorrow, so let's take some shortcuts".
nowadays we don't work like that anymore :)

> The best way for solving said problem should be: shift "copy/delete" way
> into "move" way. And that is why I asked the former question...

there is also a comment in the issue by cmc (Caolán McNamara):
> Hmm, using MoveToSection/MoveFromSection in the redline stuff instead of
> CopyToSection/DelCopyOfSection would workaround this by transferring the
> SwFrmFmt around instead of making a copy of it and deleting this original, but
> causes other problems later. redlining is such a horror

maybe cmc remembers what problems exactly are caused by Move...?

> Do you any better idea on it?

maybe it would be possible to create a copy of the SwFrmFmt when creating
the undo object?
that way the show/hide cannot invalidate the undo object.

> Thanks alot !
> Easyfan.Zheng
>
>> maybe there was a reason many years ago, but today that reason no longer
>> exists?
>>
>> i guess the only way to find out would be to change the implementation to
>> do it only one way, and then test a lot to see what breaks.
>>
>> actually, imho, the redline design in writer is fundamentally broken,
>> because the redlines are really part of the document model.
>> the option to change the redline mode from "Show" to "Hide" is purely a
>> view option, and should not change the document model in any way.

regards,
michael

--
"Simplicity is the ultimate sophistication." -- Leonardo da Vinci


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Question about the excutive way of redline

Caolán McNamara
On Mon, 2010-03-15 at 15:05 +0100, Michael Stahl wrote:

> On 10/03/2010 14:26, fan Zheng wrote:
> > In OO, Some flying object related undo action in SW, for example the inherit
> > class of SwFlyingUndoBase, refer a SwFlyFrmFmt pointer as a member data, all
> > the recording modifications must be undone or redone on the flying object
> > through said pointer. For maintaining the validate of the pointer, any user
> > modification of flying object must have corresponding undo action to be
> > recorded into undo list. Some special modifications, such as the deletion of
> > flying object, will just remove the corresponding SwFlyFrmFmt from the
> > flying frame format list of data module (SwDoc::pSpzFrmFmtTbl), and the
> > exact memory alloced in heap is not actually destructed. The destruction of
> > said flying frame format could be invoked inside the corresponding undo
> > actions.
> >
> > But on the other side, in the process of changing redline mode from "Show"
> > to "Hide", the Deleted sections will be copied into SHC (by
> > SwRedline::CopyToSection) and the original parts will be deleted from data
> > module (by SwRedline::DelCopyOfSection), which is the directly deletion
> > without any corresponding undo action recorded in (of cause should be
> > designed like this. For changing redline mode from Show to Hide is not exact
> > a user modification). That means, if there is any flying object inside
> > corresponding deletion range, it will be deleted directly (destructed
> > already). Any said flying object related undo actions recorded in list
> > become time bombs. Crash is just standing at the corner of the street.
>
> hmmmm.... that sounds pretty bad...
>
> i'm not (yet) familiar with most of the code that handles frames.
>
> i've looked a bit in issuezilla, and there is this:
> http://www.openoffice.org/issues/show_bug.cgi?id=101666

> maybe cmc remembers what problems exactly are caused by Move...?

I forget unfortunately, I thought I was on a winner with a move instead
of copy/delete for exactly the reasons mentioned in that bug and the
above commentary which is pretty much the same problem.

All I can remember is that the new problem is pretty obvious quickly
enough if you just toggle copy/delete to move and do a few undos with
frames and/or tables. More than likely the copy/delete was to workaround
the move problem. The whole thing should be taken out the back and
buried in a shallow grave, its difficult to get involved with red-lining
when you're unsure if there is any solid ground in there to lay
foundations on top of.

C.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Question about the excutive way of redline

Fan Zheng
2010/3/15 Caolán McNamara <[hidden email]>

> On Mon, 2010-03-15 at 15:05 +0100, Michael Stahl wrote:
> > On 10/03/2010 14:26, fan Zheng wrote:
> > > In OO, Some flying object related undo action in SW, for example the
> inherit
> > > class of SwFlyingUndoBase, refer a SwFlyFrmFmt pointer as a member
> data, all
> > > the recording modifications must be undone or redone on the flying
> object
> > > through said pointer. For maintaining the validate of the pointer, any
> user
> > > modification of flying object must have corresponding undo action to be
> > > recorded into undo list. Some special modifications, such as the
> deletion of
> > > flying object, will just remove the corresponding SwFlyFrmFmt from the
> > > flying frame format list of data module (SwDoc::pSpzFrmFmtTbl), and the
> > > exact memory alloced in heap is not actually destructed. The
> destruction of
> > > said flying frame format could be invoked inside the corresponding undo
> > > actions.
> > >
> > > But on the other side, in the process of changing redline mode from
> "Show"
> > > to "Hide", the Deleted sections will be copied into SHC (by
> > > SwRedline::CopyToSection) and the original parts will be deleted from
> data
> > > module (by SwRedline::DelCopyOfSection), which is the directly deletion
> > > without any corresponding undo action recorded in (of cause should be
> > > designed like this. For changing redline mode from Show to Hide is not
> exact
> > > a user modification). That means, if there is any flying object inside
> > > corresponding deletion range, it will be deleted directly (destructed
> > > already). Any said flying object related undo actions recorded in list
> > > become time bombs. Crash is just standing at the corner of the street.
> >
> > hmmmm.... that sounds pretty bad...
> >
> > i'm not (yet) familiar with most of the code that handles frames.
> >
> > i've looked a bit in issuezilla, and there is this:
> > http://www.openoffice.org/issues/show_bug.cgi?id=101666
>
> > maybe cmc remembers what problems exactly are caused by Move...?
>
> I forget unfortunately, I thought I was on a winner with a move instead
> of copy/delete for exactly the reasons mentioned in that bug and the
> above commentary which is pretty much the same problem.
>
> All I can remember is that the new problem is pretty obvious quickly
> enough if you just toggle copy/delete to move and do a few undos with
> frames and/or tables. More than likely the copy/delete was to workaround
> the move problem. The whole thing should be taken out the back and
> buried in a shallow grave, its difficult to get involved with red-lining
> when you're unsure if there is any solid ground in there to lay
> foundations on top of.
>

Hi,  McNamara:
Thanks for your response.

I do agree with what you said. Redline of writer is pretty complex and
horror in design. I still trying to find some solid ground :)

Actually, I have thought another method to solving the crash problem (just
want to keep away from Redline...): make the undo action for flying objects
recording the name of SwFrmFmt which is referred as pointer inside. When
undo/redo happens, retrieval  the SwFrmFmt object form SwDoc::pSpzFrmFmtTbl
by recorded name. Unfortunately, said name is user visible and modifiable.
And in several cases, the SwFrmFmt will be created with a empty name string.
And there could be 2 or more SwFrmFmt in table with duplicated name. All the
exceptions also introduce serious problems.

Do you have further plan for said problem?

Thanks alot!
Easyfan.

>
> C.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Re: Question about the excutive way of redline

Fan Zheng
In reply to this post by Michael Stahl-3
2010/3/15 Michael Stahl <[hidden email]>

> On 10/03/2010 14:26, fan Zheng wrote:
> > Hi, Michael:
> > Thanks for your response!
> >
> > 2010/3/10 Michael Stahl <[hidden email]>
> >
> >> On 09/03/2010 08:27, fan Zheng wrote:
> >>> Hi, All:
> >>>
> >>> I have a question about the Change Recording (Redline), would you pls
> >> give
> >>> me some tips on it?
> >>>
> >>> As all we know, under the redline mode "Show", the content of all
> changes
> >>> with type "Delete" recorded in the redline table of current document
> will
> >>> still be visible in the context.
> >>>
> >>> And if we change the redline mode from "Show" to "Hide", said "Delete"
> >> typed
> >>> changes related content will be invisible by moving said content from
> >> main
> >>> body of document into the segment of hided changes (SHC).
> >>>
> >>> Said operation Hide for "Delete" changes was designed in 2 ways
> >> (Implemented
> >>> in SwRedline::Hide()):
> >>> A. Move delete changes related content from main body into SHC;
> >>> B. Make a copy of delete changes related content in SHC, and remove the
> >>> original content from main body;
> >>>
> >>> Said design B is for almost all invoking of SwRedline::Delete(). And
> >> design
> >>> A is only invoked in the SwDoc::CompressRedlines(), which is a method
> for
> >>> combining the existed change records.
> >>>
> >>> My question is, what do we concerned about to make the design of Hide
> in
> >> 2
> >>> different ways?
> >> this is a very interesting question.
> >> in fact i have probably asked it myself :)
> >> the problem is that nobody knows the answer... the original authors of
> the
> >> sw redline code have left many years ago.
> >>
> >> i can only speculate that in some cases there can be a difference
> whether
> >> some range is moved or copied and then deleted.
> >> for example, if the range contains frames, or footnotes, which have a
> >> special section at the beginning at the nodes array for their content.
> >> or maybe the reason has something to do with undo.
> >>
> >
> >
> > Doing something with undo... Gash, that is my biggest headache currently.
> >
> > In OO, Some flying object related undo action in SW, for example the
> inherit
> > class of SwFlyingUndoBase, refer a SwFlyFrmFmt pointer as a member data,
> all
> > the recording modifications must be undone or redone on the flying object
> > through said pointer. For maintaining the validate of the pointer, any
> user
> > modification of flying object must have corresponding undo action to be
> > recorded into undo list. Some special modifications, such as the deletion
> of
> > flying object, will just remove the corresponding SwFlyFrmFmt from the
> > flying frame format list of data module (SwDoc::pSpzFrmFmtTbl), and the
> > exact memory alloced in heap is not actually destructed. The destruction
> of
> > said flying frame format could be invoked inside the corresponding undo
> > actions.
> >
> > But on the other side, in the process of changing redline mode from
> "Show"
> > to "Hide", the Deleted sections will be copied into SHC (by
> > SwRedline::CopyToSection) and the original parts will be deleted from
> data
> > module (by SwRedline::DelCopyOfSection), which is the directly deletion
> > without any corresponding undo action recorded in (of cause should be
> > designed like this. For changing redline mode from Show to Hide is not
> exact
> > a user modification). That means, if there is any flying object inside
> > corresponding deletion range, it will be deleted directly (destructed
> > already). Any said flying object related undo actions recorded in list
> > become time bombs. Crash is just standing at the corner of the street.
>
> hmmmm.... that sounds pretty bad...
>
> i'm not (yet) familiar with most of the code that handles frames.
>
> i've looked a bit in issuezilla, and there is this:
> http://www.openoffice.org/issues/show_bug.cgi?id=101666
>
> this issue seems to be caused by the design flaw you describe.
>
> > In general, this is a problem about a same data managed by different
> > patterns. Obviously, the design of undo action and design of redline is
> made
> > by different person or team, right?
>
> i'm not sure... from what i've heard i think it was more a problem of "the
> boss says it must be finished tomorrow, so let's take some shortcuts".
> nowadays we don't work like that anymore :)
>
> > The best way for solving said problem should be: shift "copy/delete" way
> > into "move" way. And that is why I asked the former question...
>
> there is also a comment in the issue by cmc (Caolán McNamara):
> > Hmm, using MoveToSection/MoveFromSection in the redline stuff instead of
> > CopyToSection/DelCopyOfSection would workaround this by transferring the
> > SwFrmFmt around instead of making a copy of it and deleting this
> original, but
> > causes other problems later. redlining is such a horror
>
> maybe cmc remembers what problems exactly are caused by Move...?
>
> > Do you any better idea on it?
>
> maybe it would be possible to create a copy of the SwFrmFmt when creating
> the undo object?
> that way the show/hide cannot invalidate the undo object.
>
Hi, Michael:

I dont think make a copy of SwFrmFmt when creating the undo object could
work. For undo action must operate the flying object through the SwFrmFmt
while undo/redo happens. If the SwFrmFmt recorded in undo action is a clone
one of former SwFrmFmt, the changes in undo/redo process can not be applied
onto the exact flying object that user could see. Which means an invalid
undo action.

And the flying object and SwFrmFmt is designed as Client/Modify
(SwClient/SwModify) module. Which means, a single SwFrmFmt could refer more
than 1 flying objects, but a single flying object could only be referred by
1 SwFrmFmt. Based on this, it is impossible for us to do a SwFrmFmt copy in
flying object multi-reference way.

I do agree with  what you mentioned in the earlier letter: "the option to
change the redline mode from "Show" to "Hide" is purely a view option, and
should not change the document model in any way." Seems it needs some
different drawing layer/portion for presenting the redline contents, which
may keep the redline content in stable way.

Thanks alot!
Easyfan.

>
> > Thanks alot !
> > Easyfan.Zheng
> >
> >> maybe there was a reason many years ago, but today that reason no longer
> >> exists?
> >>
> >> i guess the only way to find out would be to change the implementation
> to
> >> do it only one way, and then test a lot to see what breaks.
> >>
> >> actually, imho, the redline design in writer is fundamentally broken,
> >> because the redlines are really part of the document model.
> >> the option to change the redline mode from "Show" to "Hide" is purely a
> >> view option, and should not change the document model in any way.
>
> regards,
> michael
>
> --
> "Simplicity is the ultimate sophistication." -- Leonardo da Vinci
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>