Re: Persistent document range markers?

On Mon, 2011-08-01 at 15:51 +1000, Martin Sevior wrote:
> Hi Ben,
>
> What is the purpose of this listener? Do you want to update the
> document view upon changes within the begin and end-points of the PDF
> markers?

The purpose is if I want to examine the RDF for the document between two
locations. For example, for a selection in the document. Thinking ahead,
if a dialog pops up it might be handy for that dialog to keep an eye on
the document, and update itself if the RDF for the range changes. And of
course if you insert a new xml:id in that range the dialog would want to
notice that action and update itself to include any new RDF that is
linked. Likewise, if you have a text:meta with an xml:id and you delete
that whole subrange in the document then the dialog might want to remove
that RDF from it's display because it is no longer relevant to "it's
range".

>
> This could get complicated. Can't you re-use the existing mechanisms
> we have for hyperlinks and annotations?

I'll take a look. One snag is that xml:id can potentially link RDF to
document elements. Part of the RDF code behaves like the hyperlink,
annotation, and bookmark code. For example, the ODF text:meta allows you
to explicitly associate RDF with a document span. So it gets markers at
each end. On the other hand the xml:id can be applied to many ODF
elements and doesn't currently induce explicit PTO_RDFAnchor objects in
the document.

So
<text:p>This is a <text:meta xml:id="magic">magic</text:meta>
koala.</text:p>

Would look a bit like this in abiword

PTX_Block
PFT_Text This is a
PTO_RDFAnchor With attribute xml:id = magic
PFT_Text magic
PTO_RDFAnchor With attribute PT_RDF_END = yes
PFT_Text koala.

But if the xml:id was on a text:span it would just be an attribute on
that span. ie, no explicit PTO_RDFAnchor wrapping it.

If the RDFRange remembers the xml:id values which are relevant at it's
creation time it becomes need to see basic CRUD events:
a) xml:id created
b) xml:id renamed
c) xml:id removed

But the RDFRange would need to filter those based on the start-end
positions to make sure it only responds to xml:id CRUDs which are in
range. Short term I guess it could hang onto the pf_frags for the start
and end, which would allow text edits and maintain position markers
somewhat there.

Of course, there might be memory management issues with holding onto
pf_frag* values returned by doc/pt->getFragFromPosition().

Luckily I can get the code working and should be able to bolt this smart
stuff on as a cute addition :)

>
> Cheers
>
> Martin
>
>
> On Sun, Jul 31, 2011 at 4:15 PM, Ben Martin
> <monkeyiq@users.sourceforge.net> wrote:
> > Hi,
> > I'd like to have "begin" and "end" PT_DocPosition like markers which
> > can mutate with the document and which can call a notification function
> > when text inside that range changes. By mutate I mean if you insert a
> > character in the range then the "end" marker is incremented.
> >
> > This seems to be similar to what the various Listener classes are
> > doing. In particular pt_PieceTable::tellListenerSubset() seems to be the
> > code to run the show. Though my listener use case is persistent range
> > markers. Of course the notification function might also invalidate a
> > cache if something "significant" changes.
> >
> > My use case is for RDF, having a section of the document watched by a
> > listener and if new xml:id or RDF links are put in then the
> > RDFRangeListener will know it needs to update its RDF iterators to
> > possibly include new RDF in results. The RDFRange would also have to
> > keep an eye on the raw RDF to see if any new results link in that way.
> >
> > Any recommendations of code that monitors a persistent range in the
> > doc would be greatly appreciated. Otherwise at least I know I'm not
> > duplicating wheels when I write it ;)
> >
> >
>