KTabWidget task

David Faure faure at kde.org
Sun Mar 24 09:01:37 UTC 2013


On Sunday 24 March 2013 00:28:02 David Gil Oliva wrote:
> Hi,
> 
> I'm David Gil, from Barcelona. During this last year I have learned C++
> with Qt. I have developed a couple of programs and begun to develop a
> library in Qt. I have contributed to Qt revising some classes'
> documentation.
> 
> I don't have much experience in coding, but I have found this task in the
> Qt 5.1 merging page easy enough to accomplish:

Hi,
Thanks for your interest in helping with KDE Frameworks 5!

> TODO: QTabWidget: give the possibility to hide the tabbar (used in many
> places if count is 0). Preferably called setTabBarHidden(bool) /
> isTabBarHidden() (then deprecate ktabwidget).

Hmm, having another look at the implementation of KTabWidget::setTabBarHidden,
this method is really only tabBar()->setVisible(bool), plus showing/hiding 
corner widgets if any. But that means in the common case it's already just one 
method call. I thought this was about automatically hiding the tabbar if 
there's only 0 or 1 tabs, but apparently it's not, it's lower-level than that.

OK in konqueror for instance there are two corner widgets (new tab and close 
tab), so there the convenience method is useful. Let's ask lxr.kde.org.... OK, 
same in akregator, kleopatra, ksystemlog, kdenlive. I guess that's enough 
arguments for getting it into Qt.

Other apps, like krdc, powerdevil kcm, kftpgrabber, use the method, but don't 
have corner widgets, so tabBar()->setVisible(bool) would be enough.

The reason I'm telling you all this is that it might be useful in the Qt 
review request, to convince Qt developers of the usefulness of the convenience 
method :)

> Could you confirm me that nobody is working on it and that it's Ok that I
> begin with this task?

As far as I know, nobody is working on it. Please write your name in the wiki 
to let people know you are starting on it.

> The new code has to be commited to the Qt dev branch, isn't it?

Yes.

> By the way, I have found KColorDialog in kde4support, but it seems that two
> tasks haven't been done yet (porting web color line edit and color picker
> button to QColorDialog). Won't they be implemented?

Kévin?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5



More information about the Kde-frameworks-devel mailing list