> On Aug. 29, 2011, 9:28 a.m., Albert Astals Cid wrote: > > ui/pageview.cpp, line 1258 > > <http://git.reviewboard.kde.org/r/102358/diff/1/?file=32144#file32144line1258> > > > > Have not tried, but does this survive zooming in/out of the document? > > Jiri Baum wrote: > Ah, no it doesn't. Neither does the selection tool, from which I was > copying, but I guess zooming in/out while holding down the mouse button is > not a common use case. > > How would you recommend I fix this, please? I'm not particularly familiar > with the internals of okular, so I've been mostly copying from the Selection > Tool, and it has the same behaviour... > > Albert Astals Cid wrote: > I guess storing the normalized coordinates and then multiplying > accordingly to the size is the way to go. Unrelated to this line, but related > to the painting, does opening a different file in the same okular instance > clear correctly the painting?
OK, opening a different file is easy to watch for and call selectionClear(), done. However, with the normalized coordinates, that seems a bit more difficult. NormalizedRect is relative to a PageViewItem, but the selection can span more than one. Presumably each page can have a different size. The behaviour also somehow interacts with the Continuous view, so that when Continuous is on, the selection only appears on one page, while when Continuous is off, it's repeated on each page. I haven't tested single vs facing pages, but I suspect it would quickly become very very complicated. I guess I could forbid mouseSelectionRect spanning pages (restrict it to a single PageViewItem), but that may be a rather drastic step to take. With that restriction, it would be fairly easy. So I guess the question is whether there are use-cases that require mouseSelectionRect spanning multiple pages, or if it's OK to forbid that. - Jiri ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102358/#review6127 ----------------------------------------------------------- On Aug. 29, 2011, 12:05 p.m., Jiri Baum wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/102358/ > ----------------------------------------------------------- > > (Updated Aug. 29, 2011, 12:05 p.m.) > > > Review request for Okular. > > > Summary > ------- > > Table selection tool, as per the bug description. > > Usage: from the menu, select Tools | Table Selection Tool (or use the > shortcut Ctrl-5). Use the mouse to select the whole table (in a manner > similar to the existing Selection Tool), then click near the edges of the > table to add and remove row and column dividers; the table is automatically > copied to the clipboard after each change. When ready, paste into another > document (spreadsheet, word processor, etc). Press Esc to clear the selection. > > The patch also fixes handling of Esc key, so that it's not consumed by the > closeFindBar KAction when the FindBar is closed. Previously this bug was > non-obvious since the rectangular selection tool can in any case be cancelled > by releasing the mouse button, then pressing Esc; cancelling it without > releasing the mouse button was presumably not a common use-case. > > > This addresses bug 279859. > http://bugs.kde.org/show_bug.cgi?id=279859 > > > Diffs > ----- > > AUTHORS 55b672e > aboutdata.h f9c5896 > part.h a36031b > part.cpp e6b80a5 > part.rc 928168d > ui/pageview.h cd88b99 > ui/pageview.cpp 25da571 > > Diff: http://git.reviewboard.kde.org/r/102358/diff > > > Testing > ------- > > It works for me, even under demo conditions... > > > Thanks, > > Jiri > >
_______________________________________________ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
