Hi,
> > (https://codereview.qt-project.org/#change,46020) > > You are the only one who doesn't like that patch. Otherwise it could have > gone in before Qt 5.0. > > > https://codereview.qt-project.org/#change,39624 > > This patch is the opposite of the previous one, so only one will go in. > But why bring that discussion into this one? I'm not going to abandon > either one of them until one of them is integrated. > Slightly off-topic, but in any event, I think we can all agree that there's a huge difference between a good QML API and a good C++ API. I haven't looked at it, but if Alan thinks that QScreen, as is, shouldn't be exposed to QML as a property of QQuickItem, then I think that we need some serious discussion and review before I'd give a +1 to it. But it's not my area, so I'll stay out of that one. I would think that Martin Jones or Andrew den Exter would have some useful input on those changes, though. > > Also try looking at it from the other perspective - we could add a > > filter for you that shows your abandoned patches for easy tracking :) > > That's a really good idea, as long as there's a guarantee that abandoned > patches don't get deleted until I want them to be. Then we could label it > "deferred", at least that sounds better to me. > > As it is, they are hard to find, and I figured somebody is going to > unilaterally decide to garbage-collect them some day, if it's not already > scheduled. > Right, and this is the main issue. Sometimes a patch which seems like a good idea initially, gets discussed during review and eventually abandoned. That discussion might be long and involved, and might include discussion of internal implementation detail (which rarely get documented in our classes, for better or worse. This is a discussion I've had with... various people over the last couple of years, and on the one hand, if you document internal stuff in too much detail, then you have to maintain that documentation as well as the code, when the implementation changes; on the other hand, I personally like verbose documentation of architecture and design decisions. But anyway, the reality is that in many cases, it's not documented). In that case, that abandoned review actually becomes a useful resource (you can refer people to it when discussing the topic of changes in the future, etc). Although I would argue that the relevant information should probably be put into JIRA, in the task related to the change request, but sometimes that isn't practical (you need the context of the sourcecode for the comments to make sense, etc). So, just because a change has been abandoned, doesn't mean that it has zero value, IMO. Cheers, Chris.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
