viewer feature suggestion: secondary view windows

[gasche]

(This is not an urgent feature request, but something I thought would be nice in the long run.)

When working on a scientific document, it is frequent to navigate through the document to go back to a part written before. (For example: going back to read a definition, or the statement of a theorem, or a figure that we are now discussing.)

When using texpresso, it is tempting to always keep the viewer centered on the part of the document that we are actively editing.

To resolve the tension between these two needs, it would be nice to have support for opening several independent view windows onto the same document. (If the logic in texpresso is optimized to incrementally re-render only a single viewpoint, I think it would be fine as a first step for "secondary" widows to not show live updates.)

It is possible to realize this today by launching a separate PDF viewer to use as a secondary window and go look for definitions, figures etc. But if the texpresso viewer eventually gets support for clicking references/links to follow them ( #35 ), then that feature would naturally interact with multiple windows -- I may want the click to create a new secondary window to show the reference content, keeping the main window focused on the edition point.

[let-def]

It seems that this features and some other we have discussed will require an overhaul of the UI... Or rather, a proper UI rather than the current hack ;). I would like to get there eventually, but is will take time.

My plan is to write a new feature-equivalent UI in a modular way (I took some note on how I would like this), and once this is stable, experiment improvements (adding an help screen, moving some keyboard shortcuts to buttons for better discoverability, etc).

[gasche]

I wonder if it is possible to isolate the "viewer" part of texpresso and implement it into some easier-to-use language that has a decent SDL API and is more likely to attract external contributions, for example OCaml^WPython. There is no shortage of UI features that would be reasonable, probably more than you want to work on yourself. Or maybe it is possible in the medium term to tweak an existing UI, just like you have done for the rendering part.

[DominikPeters]

I've also wondered if it would be possible to let extensions take care of doing the viewing, maybe by letting texpresso output bitmaps of the current page, or (partial) updates to previously communicated bitmaps. I don't know if there is a risk that such message passing would be a big performance hit.

[let-def]

The viewer is in a sense already partially isolated in the form of the "engine" abstraction in the code, though it still uses a lot of side-channels for communication. I plan to make it more reusable so that one could plug a custom UI, but I don't have time for that right now.

A client enabling "remote use" by sharing bitmaps sounds like a good way to validate the design. To avoid a performance hit, the traditional way to achieve this locally has been to setup shared memory between the consumer and the producer (see, for instance, https://en.wikipedia.org/wiki/MIT-SHM). If possible for your use case, that would be nice. If not, there is enough memory bandwidth on a modern computer for a simple protocol to be performant enough.