Review Request: Correctly trigger executed signal of KListWidget for both single click and double click.

[Albert Astals Cid]

> On Jan. 4, 2013, 1:03 p.m., David Faure wrote:
> > This patch looks correct to me. Question for release team: shall I commit it to KDE/4.10, or wait until 4.10.0 is out (but that would mean Feb 6), given that it's not a release showstopper and we're in RC2 already.
> 
> Allen Winter wrote:
>     David,
>     Technically speaking you should hold off until 4.10.0 is out the door. Since this isn't a showstopper.

But we all know this is a myth that [almost] noone respects, people have been commiting silly minor stuff to the 4.10 branch all the time, if this is going to make it in 4.10.1, i don't see why we should not have it in 4.10.0 given [almost] noone is really respecting the "RC" meaning.


- Albert


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


On Dec. 22, 2012, 7:46 p.m., Yichao Yu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107829/
> -----------------------------------------------------------
> 
> (Updated Dec. 22, 2012, 7:46 p.m.)
> 
> 
> Review request for kdelibs and Stephan Kulow.
> 
> 
> Description
> -------
> 
> When clicking on a item in a KListWidget, the `executed` signals is not correctly emitted.
> If the system-wide setting is to use single click, only `executed( QListWidgetItem *item )` is emitted (once).
> If the setting is to use double click, `executed( QListWidgetItem *item )` will be emitted twice and `executed( QListWidgetItem *item, const QPoint &pos )` is emitted once, which cause the edit note dialog in Kontact_KNotePlugin to popup a second time right after close in some cases.
> 
> This patch fixes the problem. It is a little hacky but there isn't another easy way to get the position of the single click event except overriding the mouseReleaseEvent function AFAIK.
> 
> According to git log, this bug was introduced by commit b4a7662da2ddd14c8f1a9c97dc65b25418a5c05b back in 2007. In the commit log, it says
> 
>     executed(item, pos); is no longer supported and should
>     be removed
>     CCMAIL: robertknight at gmail.com
> 
> But I cannot found this anywhere else, as least neither in the api document here[1] nor anywhere in the source code/headers (correct me if I am wrong). Is this signal really to-be-removed? (At least this patch makes it work again.)
> 
> [1] http://api.kde.org/4.9-api/kdelibs-apidocs/kdeui/html/classKListWidget.html#a3d8fe2b4c4240e4073bd824e0599b24e
> 
> 
> This addresses bug 201093.
>     http://bugs.kde.org/show_bug.cgi?id=201093
> 
> 
> Diffs
> -----
> 
>   kdeui/itemviews/klistwidget.h 9309efc 
>   kdeui/itemviews/klistwidget.cpp 13497bf 
> 
> Diff: http://git.reviewboard.kde.org/r/107829/diff/
> 
> 
> Testing
> -------
> 
> Compiled kdelibs as well as program that has problem (kontact) and the signal is triggered correctly.
> 
> 
> Thanks,
> 
> Yichao Yu
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130105/d58c33bf/attachment.htm>