Dear Hashini,
Welcome to Google Summer of Code. Please take things slowly for now and
focus on your exams, as they have the first priority. There is still time
for everything else in two weeks.
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).
Any others? Depending on what solution we choose, it may be good to have a
(prioritized) list of elements we will support. You can also create a
number of test documents having such items (and maybe some "lorem ipsum"
text as a placeholder for text around them).
Also, tables containing mini pages (boxes) are very common, so that
combination should be tested as well.
As for the solution, there are several possibilities:
* Keyboard navigation. This is already implemented for many of these cases,
and complements mouse-based solutions.
* Swiping/scrolling with the mouse. Mac OS X supports this, but other
platforms may not have the hardware or software support. This is a very
elegant solution and would be nice to have (if Qt supports it), as
currently vertical scrolling (using the panning gesture on Mac OS X) works
but horizontal scrolling does not. However, it can only complement other
solutions, so I would consider this low priority but nice to have if there
is time left at the end.
* 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.
* Scroll buttons. This looks like a nice way to scroll just the inset in
question, without scrolling the entire editing panel. However, it is
difficult to scroll a large distance accurately using buttons (you can drag
a scroll bar but you can only press and hold a button).
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.
What do others think? A scroll bar is probably best if there are tables or
other elements that are much too wide (several screens wide); or are there
people who think buttons are definitely better?
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.
Because I did not want to bring up all the design problems/choices up front
(before proposals were submitted), I had not mentioned that earlier, but I
hope we will have some fruitful discussions on what solution we choose. :-)
--
Regards,
Cyrille Artho - http://artho.com/
Those who will not reason, are bigots, those who cannot,
are fools, and those who dare not, are slaves.
-- George Gordon Noel Byron
