Hi, Thorbjørn I understood situation with show/hide/setHidden methods. In my opinion if there were no methods setRowHidden/setColumnHidden (and many others with name "set*Hidden") choice between set*Hidden and set*Visible could be discussed, but now this talk is senseless.
On Mon, May 20, 2013 at 10:34 PM, Thorbjørn Martsum <tmart...@gmail.com>wrote: > I think you are reading the documentation a bit wrong. Read (all) class > member-functions to understand it. > Yes, you are right. I should read docs more carefully. But I got accustomed to cross-links between descriptions of methods, so often I read docs like I read wikipedia. I think if methods are connected it would better if they were have cross-links between each other (QWidget's method show<http://qt-project.org/doc/qt-4.8/qwidget.html#show>has links to setVisible and isVisible). I know, that linking methods is routine work. In fact I have some ideas how to link articles automatically, but unfortunately my examinations are getting closer and I have no time to implement them. And I think I shouldn't participate in documentation process directly because of my poor English. On Mon, May 20, 2013 at 10:34 PM, Thorbjørn Martsum <tmart...@gmail.com>wrote: > Hi Roman > > Thanks for your suggestion and your interest in improving Qt. If > QTableView hadn't already had hideRow/showRow and hideColumn/showColumn - I > would however hesitate with supporting them added. I do not see the problem > with: > table->verticalHeader()->setSectionHidden (QHeaderView also hase > hideSection, showSection). > > The tableView functions have however been added for convenience. The > reason there is no single function that takes an argument is that they are > slots, and when connecting signals it has been considered more easy to have > it that way. It wouldn't be easy to connect something with row x happened > so it should be hide the row with a slot that takes a boolean, too. > > > *OK, that means the problem is in docs: there are no references to those > methods from (show/hide)(Row/Column). How could I find it if methods don’t > copy QWidget’s logic and even descriptions of methods don’t contain word > “visible”? > * > I think you are reading the documentation a bit wrong. Read (all) class > member-functions to understand it. The functions exist and they are > well-documented (more than other things, actually). I don't know if it is > possible to tweak in the word visible without making the documentation > sound weird, but if you have any suggestion to making documentation better > - feel free to upload them to gerrit (codereview.qt-project.org) or > discuss it with somebody on qt-labs. > > regards > Thorbjørn > > On Mon, May 20, 2013 at 6:11 PM, Roman Inflianskas <infr...@gmail.com>wrote: > >> As Chris Kawa pointed in thread >> <http://qt-project.org/forums/viewthread/27971/>there are methods >> QTableView::setRowHidden<http://qt-project.org/doc/qt-5.0/qtwidgets/qtableview.html#setRowHidden> >> *,*QTableView::setColumnHidden<http://qt-project.org/doc/qt-5.0/qtwidgets/qtableview.html#setColumnHidden> >> . >> OK, that means the problem is in docs: there are no references to those >> methods from (show/hide)(Row/Column). How could I find it if methods don’t >> copy QWidget’s logic and even descriptions of methods don’t contain word >> “visible”? >> But: why this methods are inverted? I think it would be more natural if >> they be setRowVisible/setColumnVisible. >> >> >> On Mon, May 20, 2013 at 7:53 PM, Roman Inflianskas <infr...@gmail.com>wrote: >> >>> Hi. >>> I want to change visibility of rows and columns of QTableWidget. I know, >>> that I can use (show/hide)(Row/Column) methods, but sometimes more elegant >>> solution is to use functions that take visibility factor. So, I think it >>> would be better to have methods setRowVisible/setColumnVisible. Second >>> reason is current inconsistency: QWidget and other classes provide all this >>> methods: show, hide, setVisible, while QTableView doesn’t have similar >>> methods. >>> I think that this wouldn’t break API. >>> >>> -- >>> Regards, Roman Inflianskas >>> >> >> >> >> -- >> Regards, Roman Inflianskas >> >> _______________________________________________ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> >> > -- Regards, Roman Inflianskas
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
