[Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Matthew Woehlke]

On 2015-02-20 04:04, André Somers wrote:
> Bo Thorsen schreef op 20-2-2015 om 09:03:
>> Andrés question about how this would change the API is a lot more 
>> interesting. I so far haven't seen a single case where someone has 
>> described how access to lambdas might improve the API. If they are 
>> there, I'd love to see them, because maybe this would teach me 
>> something I haven't figured out yet.
> 
> One example I could come up with as a potential new API is 
> QSortFilterProxyModel. Currently, it requires subclassing to change the 
> sort or the filter functions: it supplies protected filterAcceptsRow, 
> filterAcceptsColumn and lessThan functions. I think that it would be 
> much more convenient if these filters and the comparator could be 
> supplied as a function object (a lambda, or a functor, or a std::mem_fn, 
> anything callable as a function). While this wasn't all that practical 
> in the past, I think C++/11 makes this much more convenient than 
> subclassing.

On that note... a potential use I just ran into yesterday that I might
use is *duck punching* (essentially what you're describing, but in a
more general form).

I am in the process of porting a multi-column item list from a somewhat
ad-hoc implementation to one based on reusable classes. The new version
uses a complex two-layer item model setup; an underlying model to track
the raw data, and a proxy model to provide an appropriate representation
of that data. This *almost* allows me to drop the old subclassed
QTreeView in favor of a stock QTreeView... but there's a problem: one of
the columns is a "star" that allows the user mark "interesting" items.
The user should be able to toggle this just by clicking on the star icon.

The old stuff handled this by simply overriding a mouse event handler
for the view. The new stuff doesn't (yet?) have a subclassed view, and
I'd really like to keep it that way. (I'd also really like to avoid
creating a custom delegate widget just for this, as I'd then have to
move the display logic to that rather than the proxy model; that's an
undesirable duplication of code.)

If this was in Python, I'd just replace the mouse event handler in the
QTreeView :-). I could imagine it being useful in other situations also
to be able to override the event handlers (not necessarily event(), but
specific ones e.g. paint(), mouseMoveEvent(), keyPressEvent(), etc.)
with a QFunction.

p.s. besides being less elegant, installing an event filter doesn't seem
to *work*; it doesn't see mouse events!

-- 
Matthew