qpdfview team mailing list archive

[Tim Wischmeier <question678138@xxxxxxxxxxxxxxxxxxxxx>]

Question #678138 on qpdfview changed:
https://answers.launchpad.net/qpdfview/+question/678138

Tim Wischmeier posted a new comment:
Hello Adam,

I am sorry for going awol on you, there has been some personal stuff I
needed to deal with... Well, I have some days off from work and had the
time to get back to this project.

Thank you very much for your detailed and quick answer, and for a
recommendation on how to quickly solve my use case.

I am somehow a bit uncomfortable with duplicating pages, so I would like
to try a refactor stuff a bit. I don't know if the result will be push-
worthy, but I will see. I think I have a better feeling on how
DocumentView and DocumentLayout interact (I hope):

DocumentLayout is expected to layout it's pages once, ordering them
"row-wise" vertically in "flick order", while each row will be displayed
by the DocumentView. The View will set the top of the clipping rectangle
(called sceneRect) to the last page that matches leftIndex.

My first thought is that the View might be putting a constraint on the
Layout that it shouldn't. That way, the view has (assumed) knowledge
about the Layout, because it wants to determine the clipping rectangle.
One could let the Layout determine the clipping rectangle (area to be
viewed). Of course you would need to tell it what the user wants to view
(e.g. the selected page). The view would then still be responsible on
setting the pages inide that rectangle visible (and those outside
invisible).

This sounds fine in my head as long as the user can only flip from one
page to the next. It gets a bit complicated when the user wanted to flip
horizontally or vertically (imagine you arranged 81 pages in a 9x9 grid,
and 2x1 are visible at any time). Or even more when there is continuous
scrolling involved.

So, we might consider abstracting the layout a bit more. I could see a base class which accepts the following parameters:
- Vertical or Horizontal Layout (right now the DocumentView basically expects a vertical layout, I think)
- Number of Pages per Screen
- Coninuous Mode (on/off; you want to space out pages differently in horizontal mode)
- Number of Pages on first Screen

The view can then
- ask it to layout the pages (as it can now), providing the current screenRect
- ask for next / previous page (as it can now)
- ask the origin for the screenRect for a given page

This would eliminate the need for left and right indices. The
DocumentView knows the size of the screenRect. It can eihter move it
freely (continuous mode) or snap it to different pages. For the latter,
it can ask the Layout where it needs to go for a certain page.

We should be able to map the current layouts to this and probably also
horizontal continuous scrolling (Question #679376). there are still some
constraints: the pages are expected to only exists once on the whole
layout. So you still have a fixed layout, are you just move the clipping
rectangle around; the layout does not change depending on what you view,
and you basically expect the layout to produce "view clusters".

Ok, so this turned out to be more of a brainstorming :). I think I might
be able to implement what I have in mind. I am new to developing in
linux, c++, and git, though. Just to have the right keywords: would I
push my changes to a branch, or what would be the right way to do it?

Best regards,
Tim

-- 
You received this question notification because your team qpdfview is an
answer contact for qpdfview.