Review Request: Fix scrolling with mouse (without wheel) in krunner

[Jacopo De Simoi]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/948/
-----------------------------------------------------------

(Updated 2009-07-15 09:49:09.569362)


Review request for Plasma.


Changes
-------

+ ws cleanup in interface.cpp
+ moved the initialization stuff from the interface ctor to the view ctor
+ found out the problem with the pixmap stuff: the point is that krunnerdialog paints its own background and then the QPainter is passed on to child widgets to paint; blitting directly the gradient using the QPainter results in a hollow window since the paint of the dialog background is still pending. 
In r2 now, we redirect the QPainter to a QPixmap and then blit it with the gradient if necessary. This is much cleaner than calling render(); also I find more convenient and elegant to use paintEvent rather than drawForeground because drawForeground uses scene coordinates;  


Summary
-------

Krunner does not have a vertical scrollbar in the result view for design reasons. This patch fixes this by adding two page buttons.
The buttons are painted inside the view and are shown only if they are needed. Also, the view fades if other items are available but not visible (please see attached screenshot).
This was done for a couple of design reasons:
- putting the buttons outside the view was wasting too much space if they were always visible;
- making them appear/disappear would necessarily displace up or down the results view, possibly during user interaction (in case new results are added late) and possibly resulting in misclicks;
As for the technical side please note:
- the scrolling is actually implemented by selecting an item which is outside the current view; this smoothly scrolls the view for free with a nice animation, as a bonus the selected item is always visible. A double fallback mechanism makes (hopefully) sure that some scrolling is always performed.
Some questions:
- to fade the view I could not find a better way than calling QGV::render(); _please_ have a look at paintEvent and let me know if there is a more efficient way to do what I do.
- to check if there are items outside the view I use some very naïve approach. Is there a better way to do that ?
- apparently the strings ``Previous Page'' and ``Next Page'' have already been i18ned; can I add them as tooltips? does this break the string freeze?
- now that we subclass QGV, should I move all QGV->initialization stuff which is now in the ctor of interface to the ctor of resultsview?

Finally, I would consider this a bugfix rather than a feature (we have already a bug opened for that and we already established we do not want a real scrollbar) and throw it in 4.3 branch before release. However, of course the final decision is not mine, so let me know what I should do.
Thanks


This addresses bug 198501.
    https://bugs.kde.org/show_bug.cgi?id=198501


Diffs (updated)
-----

  branches/KDE/4.3/kdebase/workspace/krunner/CMakeLists.txt 995691 
  branches/KDE/4.3/kdebase/workspace/krunner/interfaces/default/interface.cpp 995765 
  branches/KDE/4.3/kdebase/workspace/krunner/interfaces/default/resultsview.h PRE-CREATION 
  branches/KDE/4.3/kdebase/workspace/krunner/interfaces/default/resultsview.cpp PRE-CREATION 

Diff: http://reviewboard.kde.org/r/948/diff


Testing
-------

Tested for a few days, did not notice any glitch so far


Screenshots
-----------

Mouse hovering the previous page button
  http://reviewboard.kde.org/r/948/s/135/


Thanks,

Jacopo