Re: Review Request: Fix scrolling with mouse (without wheel) in krunner
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/948/#review1630 --- Ship it! branches/KDE/4.3/kdebase/workspace/krunner/interfaces/default/resultsview.cpp http://reviewboard.kde.org/r/948/#comment1066 blitting the whole pixmap on every paint event seems a bit wasteful; it should probably just paint the event-rect() - Aaron On 2009-07-15 09:49:09, Jacopo De Simoi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/948/ --- (Updated 2009-07-15 09:49:09) Review request for Plasma. 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 - 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix scrolling with mouse (without wheel) in krunner
On 2009-07-16 17:47:03, Aaron Seigo wrote: branches/KDE/4.3/kdebase/workspace/krunner/interfaces/default/resultsview.cpp, line 176 http://reviewboard.kde.org/r/948/diff/2/?file=8540#file8540line176 blitting the whole pixmap on every paint event seems a bit wasteful; it should probably just paint the event-rect() We would need to paint the event-rect() + the rects of the gradients since they could be shown/hidden without notice... I thought we would not get a performance gain in calling three times drawPixmap w.r.t. just once with a big pixmap. I'll look into that. Thanks for your prompt answer. - Jacopo --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/948/#review1630 --- On 2009-07-15 09:49:09, Jacopo De Simoi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/948/ --- (Updated 2009-07-15 09:49:09) Review request for Plasma. 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 - 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix scrolling with mouse (without wheel) in krunner
On 2009-07-16 17:47:03, Aaron Seigo wrote: branches/KDE/4.3/kdebase/workspace/krunner/interfaces/default/resultsview.cpp, line 176 http://reviewboard.kde.org/r/948/diff/2/?file=8540#file8540line176 blitting the whole pixmap on every paint event seems a bit wasteful; it should probably just paint the event-rect() wrote: We would need to paint the event-rect() + the rects of the gradients since they could be shown/hidden without notice... I thought we would not get a performance gain in calling three times drawPixmap w.r.t. just once with a big pixmap. I'll look into that. Thanks for your prompt answer. It works just with event-rect() as you said; this is probably because whenever an event would trigger the buttons (and therefore the gradients), there is a paint event on the region of the gradient. This is obvious while scrolling, less obvious when adding items, but it seems still ok. I'll see if I encounter any glitches, otherwise I'll commit. - Jacopo --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/948/#review1630 --- On 2009-07-15 09:49:09, Jacopo De Simoi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/948/ --- (Updated 2009-07-15 09:49:09) Review request for Plasma. 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 - 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix scrolling with mouse (without wheel) in krunner
--- 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix scrolling with mouse (without wheel) in krunner
On Friday 10 July 2009 15:23:24 Aaron J. Seigo wrote: On Friday 10 July 2009, Jacopo De Simoi wrote: foreground is the same used to draw the background of the widget, therefore putting 0 alpha would make the dialog as well transparent. that completely depends on the composition mode. For sure, but DestinationIn seems the correct choice to me... Again, It seems that I have to redirect the painter to a pixmap and then blend over it, that's what you do in the resultitem::paint iirc... Any better idea than render(), again? there should be no need to render to a pixmap. something is not right in your code. i'll try and take a look on the airplane later today. That would be great! right now I'm going to a (sicilian) wedding and I'll probably be ko for a couple of days ;) Thanks a lot. J ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix scrolling with mouse (without wheel) in krunner
On Thursday 09 July 2009 13:31:10 Jacopo De Simoi wrote: On Wednesday 08 July 2009 23:49:43 Aaron J. Seigo wrote: On Wednesday 08 July 2009, Jacopo De Simoi wrote: On Wednesday 08 July 2009 19:41:30 Aaron J. Seigo wrote: On Wednesday 08 July 2009, you wrote: QPainter from paintEvent.. here is the result: http://imagebin.ca/view/TFWmBq.html to be clear, the problem we're seeing in that screenshot is what exactly? the colouring of the fade out or the positioning of it? The problem is that the dialog itself becomes transparent, and fades into the desktop; it's like there's a hole in the dialog, whereas we would like that just the items become transparent and fade into the background of the dialog, as we manage to have if we let QGV::render paint items on a pixmap and then put a gradient on it before drawing it using the painter... perhaps you are using the wrong compositing setting when painting? it sounds like you aren't blending it with the contents but rather doing sth like QPainter::CompositionMode_Source? I'm using destinationIn, basically I copied from your piece of code for the items, however I'll check with other CompositionModes Nah, no luck. I believe that the QPainter used to draw Background, items, foreground is the same used to draw the background of the widget, therefore putting 0 alpha would make the dialog as well transparent. Again, It seems that I have to redirect the painter to a pixmap and then blend over it, that's what you do in the resultitem::paint iirc... Any better idea than render(), again? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix scrolling with mouse (without wheel) in krunner
On Wednesday 08 July 2009 23:49:43 Aaron J. Seigo wrote: On Wednesday 08 July 2009, Jacopo De Simoi wrote: On Wednesday 08 July 2009 19:41:30 Aaron J. Seigo wrote: On Wednesday 08 July 2009, you wrote: QPainter from paintEvent.. here is the result: http://imagebin.ca/view/TFWmBq.html to be clear, the problem we're seeing in that screenshot is what exactly? the colouring of the fade out or the positioning of it? The problem is that the dialog itself becomes transparent, and fades into the desktop; it's like there's a hole in the dialog, whereas we would like that just the items become transparent and fade into the background of the dialog, as we manage to have if we let QGV::render paint items on a pixmap and then put a gradient on it before drawing it using the painter... perhaps you are using the wrong compositing setting when painting? it sounds like you aren't blending it with the contents but rather doing sth like QPainter::CompositionMode_Source? I'm using destinationIn, basically I copied from your piece of code for the items, however I'll check with other CompositionModes ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix scrolling with mouse (without wheel) in krunner
On 2009-07-07 11:47:32, Aaron Seigo wrote: i quite like how it feels in use. nice :) and yes, i think the initialization code should go into the subclass itself to keep it tidy. as for the fade effect, however, that should be using QGraphicsView::drawForeground :) other than that, i think this is ready to go, and yes, should be backported for 4.3 Uhm, I have troubles using drawForeground, as I had by using directly the QPainter from paintEvent.. here is the result: http://imagebin.ca/view/TFWmBq.html Perhaps I should use drawItems; trying that now. - Jacopo --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/948/#review1485 --- On 2009-07-07 10:12:01, Jacopo De Simoi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/948/ --- (Updated 2009-07-07 10:12:01) Review request for Plasma. 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 - branches/KDE/4.3/kdebase/workspace/krunner/CMakeLists.txt 991523 branches/KDE/4.3/kdebase/workspace/krunner/interfaces/default/interface.cpp 991523 branches/KDE/4.3/kdebase/workspace/krunner/interfaces/default/resultscene.cpp 991523 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix scrolling with mouse (without wheel) in krunner
On 2009-07-07 11:47:32, Aaron Seigo wrote: i quite like how it feels in use. nice :) and yes, i think the initialization code should go into the subclass itself to keep it tidy. as for the fade effect, however, that should be using QGraphicsView::drawForeground :) other than that, i think this is ready to go, and yes, should be backported for 4.3 Jacopo De Simoi wrote: Uhm, I have troubles using drawForeground, as I had by using directly the QPainter from paintEvent.. here is the result: http://imagebin.ca/view/TFWmBq.html Perhaps I should use drawItems; trying that now. No luck with drawItems either, some problem as with drawForeground; I really need to first paint to a pixmap.. maybe I am using some wrong flags in the view background stuff... - Jacopo --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/948/#review1485 --- On 2009-07-07 10:12:01, Jacopo De Simoi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/948/ --- (Updated 2009-07-07 10:12:01) Review request for Plasma. 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 - branches/KDE/4.3/kdebase/workspace/krunner/CMakeLists.txt 991523 branches/KDE/4.3/kdebase/workspace/krunner/interfaces/default/interface.cpp 991523 branches/KDE/4.3/kdebase/workspace/krunner/interfaces/default/resultscene.cpp 991523 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix scrolling with mouse (without wheel) in krunner
On Wednesday 08 July 2009, you wrote: QPainter from paintEvent.. here is the result: http://imagebin.ca/view/TFWmBq.html to be clear, the problem we're seeing in that screenshot is what exactly? the colouring of the fade out or the positioning of it? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix scrolling with mouse (without wheel) in krunner
On Wednesday 08 July 2009 19:41:30 Aaron J. Seigo wrote: On Wednesday 08 July 2009, you wrote: QPainter from paintEvent.. here is the result: http://imagebin.ca/view/TFWmBq.html to be clear, the problem we're seeing in that screenshot is what exactly? the colouring of the fade out or the positioning of it? The problem is that the dialog itself becomes transparent, and fades into the desktop; it's like there's a hole in the dialog, whereas we would like that just the items become transparent and fade into the background of the dialog, as we manage to have if we let QGV::render paint items on a pixmap and then put a gradient on it before drawing it using the painter... ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix scrolling with mouse (without wheel) in krunner
On Wednesday 08 July 2009, Jacopo De Simoi wrote: On Wednesday 08 July 2009 19:41:30 Aaron J. Seigo wrote: On Wednesday 08 July 2009, you wrote: QPainter from paintEvent.. here is the result: http://imagebin.ca/view/TFWmBq.html to be clear, the problem we're seeing in that screenshot is what exactly? the colouring of the fade out or the positioning of it? The problem is that the dialog itself becomes transparent, and fades into the desktop; it's like there's a hole in the dialog, whereas we would like that just the items become transparent and fade into the background of the dialog, as we manage to have if we let QGV::render paint items on a pixmap and then put a gradient on it before drawing it using the painter... perhaps you are using the wrong compositing setting when painting? it sounds like you aren't blending it with the contents but rather doing sth like QPainter::CompositionMode_Source? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix scrolling with mouse (without wheel) in krunner
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/948/#review1485 --- i quite like how it feels in use. nice :) and yes, i think the initialization code should go into the subclass itself to keep it tidy. as for the fade effect, however, that should be using QGraphicsView::drawForeground :) other than that, i think this is ready to go, and yes, should be backported for 4.3 - Aaron On 2009-07-07 10:12:01, Jacopo De Simoi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/948/ --- (Updated 2009-07-07 10:12:01) Review request for Plasma. 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 - branches/KDE/4.3/kdebase/workspace/krunner/CMakeLists.txt 991523 branches/KDE/4.3/kdebase/workspace/krunner/interfaces/default/interface.cpp 991523 branches/KDE/4.3/kdebase/workspace/krunner/interfaces/default/resultscene.cpp 991523 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
