28/05/2013 06:35, Cyrille Artho:
Of course we can start brainstorming about some of the details now, as
that does not take much time per day. For instance, it may be useful to
have a list of things that can be too wide to fit into a line:
* Tables
* Math elements (formulas)
* Mini pages (boxes)
* Images (although there is no need to do much here, as an image cannot
be edited in LyX).
The first point is that, if we work at the level of LyX display rows
(any inset is on its own row and may contain rows itself), we _may_ be
able to code generically. Note that the term of Row here is different
from a tabular row. The whole tabular inset is on a same row.
What I do not know is whether we could want to use the scrolling
behavior inside an inset which contents is too large, or whether it
should only be done at top level.
* Keyboard navigation. This is already implemented for many of these
cases, and complements mouse-based solutions.
It is only implemented at cell level for tabulars. This is not good IMO
and should be replaced by a new solution.
* Horizontal scrollbar. This is the original plan of the project. The
advantage of a scroll bar is that it allows fast and targeted scrolling
to a certain point. The disadvantage is that usually the user would
expect the entire screen (editing panel) to scroll. However, this would
result in text scrolling off (to the left) while the element that is too
wide is the only thing left. While logically consistent, this is not
very elegant.
The scrollbar could be local to the element that is too large.
I think there is a general agreement that we would like to retain (and
perhaps extend) keyboard navigation. The scroll widget for the mouse
(scroll bar or buttons?) is, as far as I can tell, less settled.
The first big milestone is keyboard navigation, because it ensures that
we can scroll display so the cursor is visible. Once it works, it will
be easy to plug in other UIs to do the scrolling.
If we go with a scroll bar, should the rest of the window stay or scroll
alongside? How do we treat a document that has several elements that are
too wide, with text in between? It probably looks odd if the scroll bar
behavior affects only one element; which element would even depend on
the cursor position (and the cursor may not even be within the current
view). So global scrolling seems the natural solution. This would,
however, entail a horizontal scroll bar that is active even if the
current view contains only text.
If the effect of the scrollbar is local, the scrollbar itself should be
local too.
JMarc
