Hi Martin,
Undocking panes doesn't work in EWriter -- at least not with the separate window method that's used in those skins -- that's why that option is deactivated in those skins there.
The issue with long TOCs and indexes on mobile devices isn't the time they would take to load. It is that they quickly start to behave strangely or grind to a halt when these elements grow beyond a certain size. Try publishing a project with a large index using one of the standard HM7 responsive skins and then open it on a mid-range Android phone and try to browse in the index.
The current V3 index solution gets around this by hiding what is not currently rendered but still allowing you to do a lighting fast search of the whole index, because the search is performed in the compressed JSON object. I'll see if I can add an Expand All for desktop mode only though, although I can't promise this will make it into 3.2 if I still want to release that this week.
Martin Wynne wrote:What I would really like for the V2 skins in EWriter would be an option to have 3 columns instead of 2 columns. TOC + Index + topic pane.
That's a major project. I'll keep it in mind for the future but it's not a quick job.
At present in V2 clicking back to the index tab after finding that what you clicked wasn't what you wanted, loses your place in the index.
I'll have to look into that. It's a scrolling problem, not something fundamental. In the standard HM skins and templates the TOC, index and search tabs only exist at all when they are visible. So when you switch back to them -- for example between the index and the TOC -- the page you were just viewing is thrown away and replaced with the page you want to view. For example, when you select something in the index the entire index is closed and the entire TOC is reloaded and re-synchronized. And when you switch back to the index the entire index page is reloaded and re-rendered. In the V2 skins there are separate iFrames for all three and they remain loaded all the time. So not losing your place when you return to the index would be a simple exercise -- it's simply a matter of not losing the scroll position in the existing page.