Yep. When I originally did the page view math, leaving everything on the
left simplified things quite a bit. See the TODO comments near the top of
FV_View::_draw() for some other simplifying assumptions.
>Quite anoying imo.
If you'd like to take a crack at fixing this, you'll probably want to start
by grepping for fl_PAGEVIEW_MARGIN_X, and replace each instance with a call
to the FV_View::getPageViewLeftMargin() method, which is currently unused,
and ought to be a great place to park most or all of the additional math
needed.
Things to watch out for:
1. As a minimum, the left margin should be at least fl_PAGEVIEW_MARGIN_X
pixels, but whenever:
( m_iWindowWidth > (page width + 2*fl_PAGEVIEW_MARGIN_X) )
you can allocate half of the excess to the left of that page. Note that
these calculations become page-relative, since pages from different sections
could be different widths.
2. You shouldn't need to mess with the FL_DocLayout::getWidth() logic,
which is used to calculate the viewport width for scrolling. It doesn't
need to get any wider -- we're just repositioning the page within an
existing view.
3. Make sure to check that all the mouse hit-testing works properly,
including the following behaviors:
- context cursors change appropriately,
- the top ruler is aligned properly,
- the guideline during tab dragging is in the right spot, and
- selections still draw in the right place.
4. Also, efficiently avoiding drawing artifacts on a resize could get
tricky.
Hope that helps. :-)
Paul
motto -- GUI hacking is fun, right?