On 12/9/19 10:40 AM, Scott Kostyshak wrote:
> On Sun, Dec 08, 2019 at 11:03:20PM -0500, Richard Kimberly Heck wrote:
>> On 12/8/19 9:20 PM, Scott Kostyshak wrote:
>>> Attached is a patch that refreshes previews whenever the user activates
>>> or deactivates a branch. The motivation for this patch is that if a
>>> child document is previewed in the master document, and if the child
>>> document has the branch inside it as well, the preview will be incorrect
>>> when the branch is toggled (without this patch).
>>>
>>> However, this patch will cause all previews to refresh. I'm concerned
>>> that the inefficiency is not worth the benefit. Any thoughts on this
>>> patch and any thoughts on an ideal solution? For example, would
>>> removePreviews() and updatePreviews() ideally have arguments that allow
>>> to specify which type of previews to update?
>> It makes sense to me.
>>
>> Do we have to remove previews first?
> Good question. It doesn't work if I don't include that line, and it's
> consistent with Buffer::reload(). The following contains a clue for why
> I think it's needed (copied from RenderPreview.h):
>
> /** Remove a snippet from the cache of previews.
> * Useful if previewing the contents of a file that has changed.
> */
> void removePreview(Buffer const &);
>
> From the perspective of the master document, the LaTeX export
> corresponding to the child document has not changed (it is just
> \input{child.tex}). So if we only "update" the previews, I think that
> would only regenerate previews for insets where the LaTeX as viewed by
> the master document has changed.
>
> The patch does not actually call the function I reference above. It uses
> removePreviews() (note the extra 's'), which creates an entirely new
> previewLoader. Perhaps it would be more efficient to loop through the
> insets and call removePreview() on them (or only the ones that depend on
> a file?).
It probably doesn't matter very much, since all the regeneration happens
in the background.
Riki
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
