On Tue, Dec 18, 2018 at 11:49:22AM +0000, Eike Ziller wrote: > > > > On Dec 18, 2018, at 11:25, Konstantin Shegunov <[email protected]> > > wrote: > > > > On Tue, Dec 18, 2018 at 9:39 AM Martin Smith <[email protected]> > > wrote: I'll argue with you about it being a p1. If the problem is > > confined to the all-members list, it's not a p1 problem because the > > information is still there via the inherits links, which are more > > useful for seeing what is inherited anyway. > > > > You can argue with the people that handled it through the tracker, I > > don't prioritize bugs. From my point of view, however, it falls > > strictly into the P1 category - it's a regression from the last > > version, not an edge-case data loss, and it's pretty embarrassing. > > > > My own opinion is that the all-members list should be removed. > > > > I think no, unless there's another way to search for a method in the > > hierarchy. Allowing for a somewhat contrived example: Say I'm > > working with `QTemporaryFile` I know there exists something for > > checking about it being readable but I don't know exactly from where > > it comes from, then the all-members page is really useful. That > > use-case gets even more prominent for classes that implement > > interfaces and/or that have multiply inherited (e.g. QLabel's > > indirect inheritance from QPaintDevice). > > This happens to me all the time with classes inheriting from IODevice, > layouts like QHBoxLayout, and quite some widgets, where the useful > methods are often spread through the whole hierarchy. Clicking up > through the hierarchy works, but is not very efficient, the all > members list is much more convenient.
Same here. Especially for "feature discovery" one flat list is the best option. Andre' _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
