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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development