kdelibs/kdeui/paged

[Sebastian Sauer]

Sebastian Kuegler wrote:

> On Tuesday 20 November 2007 17:18:04 Sebastian Sauer wrote:
>> atm it is not possible to disable aka hide the header within a
>> KPageView/KPageWidget if the faceType != Tabbed. Following both patches
>> to fix this;
>>
>> 1. the header uses the name if QString::null and if "" the header does
>> not got displayed. While this seems ugly it should provide the less
>> offensive way to fix it since places where it's used atm without defining
>> the header will still work as before and only an explicit setHeader("")
>> does disable aka hide the header.
> 
> Apart from if this patch should be merged or not, do you have a list of
> those dialogues that don't specify titles? Those are probably hotspots
> where we can easily make our configuration more clear to the user.

thanks to dfaure who pointed me once to http://lxr.kde.org/ last time I had 
such a question :) Just search for KPageDialog to see a rather huge list of 
all canidates. 

So far I started to look where the setHeader is not used and came up with that 
list;
kdeaccessibility/ksayit/src/voicesetupdlg.cpp
kdeadmin/kuser/ku_edituser.cpp
kdebase/apps/dolphin/src/dolphinsettingsdialog.cpp
kdebase/workspace/ksysguard/gui/SensorDisplayLib/DancingBarsSettings.cc
kdebase/workspace/ksysguard/gui/SensorDisplayLib/FancyPlotterSettings.cc
kdeedu/kbruch/src/mainqtwidget.cpp
kdeedu/kstars/kstars/detaildialog.cpp
kdeedu/parley/src/entry-dialogs/EntryDlg.cpp
kdeedu/parley/src/statistics-dialogs/StatisticsDialog.cpp
kdegames/kjumpingcube/kjumpingcube.cpp
kdegames/kolf/newgame.cpp
kdegames/libkdegames/highscore/kexthighscore_gui.cpp
kdegames/libkdegames/highscore/kexthighscore_item.cpp
kdegames/libkdegames/kgame/dialogs/kgamedebugdialog.cpp
kdegames/libkdegames/kgame/dialogs/kgamedialog.cpp
kdegraphics/okular/ui/annotationpropertiesdialog.cpp
kdegraphics/okular/ui/propertiesdialog.cpp
kdelibs/kio/kfile/kpropertiesdialog.cpp

and then stopped once I note, that the list even gets larger if KConfigDialog, 
KCMultiDialog, etc. who inherit it are included in that search :-/

So, now I would suggest to commit the ugly (but compatible) solution 1) rather 
then solution 2) cause imho we are to deep in freez to probably break the 
headers for so much apps + guess it goes beyond my timeframe to check+change 
them all.

So, I would suggest to land the quick+dirty hack + add proper doxygen-comments 
and a "\\\todo KDE5 get right of that dirty hack" now, ok?