Review Request: fix KoDocumentRdf::findXmlId(KoTextEditor *) to find the correct xmlId

[C. Boemann]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107617/#review23109
-----------------------------------------------------------


in https://git.reviewboard.kde.org/r/107621/ I think I've fixed the true reason for the SKF issue.

You request here though raises some issues. Well that and my previous response. We should really consider if we want such conceptually broken methods in the api. Naturally we have code that depend on it so we need som (hopefully better) alternative.

anyway this is a definite decline of the review request.

Please close. 

But let's discuss on irc what to do with the implementation and/or api and/or apidox and then either fix or open a bug about it. It's too broken to be just forgotten again.

- C. Boemann


On Dec. 6, 2012, 8:37 p.m., Friedrich W. H. Kossebau wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107617/
> -----------------------------------------------------------
> 
> (Updated Dec. 6, 2012, 8:37 p.m.)
> 
> 
> Review request for Calligra and C. Boemann.
> 
> 
> Description
> -------
> 
> Currently the code does not really seem to do what the API dox proposes: "find the xmlid of the semitem that is at or surrounding the cursor given. As with findExtent() this will be only the most nested semitem."
> 
> Attached patch changes that, in a naive approach. Correct one?
> Or does the API dox need adaption?
> 
> Okay to commit to 2.6 and forward port to master?
> 
> 
> Diffs
> -----
> 
>   libs/main/rdf/KoDocumentRdf.cpp 49275c4 
> 
> Diff: http://git.reviewboard.kde.org/r/107617/diff/
> 
> 
> Testing
> -------
> 
> Selecting tables in orpheus works for me with this patch.
> 
> But there is a problem: on exchanging the cell contents the bookmark start moves behind the new content in the first cell. So putting the cursor onto the new content will fall outside of the bookmark range. Similar problem at the end. This needs to be fixed separately.
> 
> 
> Thanks,
> 
> Friedrich W. H. Kossebau
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20121207/6920df67/attachment.htm>