Flexibility of dockwindow handles

Ravikiran Rajagopal ravi at kde.org
Sun Jun 22 21:55:21 BST 2003


Hello,
  Thank you for your reply. I am ccing core-devel because it is a kdelibs 
issue, and because it brings up an interesting example of MDI complications.

> >   Why do we force showing the caption of QDockWindows (in the handles)
> > even when they are docked? This is really messy for a couple of reasons:
>
> Before I read further, there are many people that think this looks very
> nice (eg, in designer), and nobody objected to this, so it has been in KDE
> for over a year.

I believe dockwindows will play a much more important role now that MDI is in 
kdelibs, as they provide a nice way to organize various views. I do agree 
that it looks nice, but it makes for a rather inconsistent interface (see 
later for comments about extensibility). As an application author, I should 
not have to handle, say, Windows style differently from Keramik.

The other reason why nobody complained is that the natural audience for 
dockwindows are (were?) using KDock* from kdelibs. While I applaud their 
efforts for bringing dockwindows into KDE before Qt supported them, they do 
not play nicely with QDockAreas, require the use of KDockMainWindow which 
duplicates most of the dock functionality in QMainWindow, and do not allow 
styling primitives.

> There are two solutions, either use a short name, or use a style which
> doesn't display dockwindow captions on its handle.

Neither of these is really workable. As an application author, I cannot force 
my users to use a particular style, nor would I want to :-( Short names are 
not an option either because of i18n - in my TA environment, there is no 
chance of using small names because most modern technical terms are 
translated into huge multisyllable phrases.

> >   2. Using QDockWidgets in more complex container widgets becomes a pain.
> > For example, let's say that we would like to have dockwidgets in a
> > container widget (such as tab widgets, QtoolBoxes, etc.). Such a
> > situation is not uncommon for stacks of detachable tools such as
> > KDevelop's file selector and other views. Then, since we always display
> > the caption on the handle, it becomes ugly to display it again in the tab
> > bar or list view. The bottom line is that we are forcing a specific UI
> > style which may be inconsistent with the rest of the application.
>
> Can you please provide me with a screenshot of this problem? Its hard to
> visualise it in words. :)

Ok, though this is not the best example. Look at
 http://www.kdevelop.org/graphics/screenshots/3.0/gideon-tabbedmode-cvs.png
The panes on the left and at the bottom are tabwidgets which contain dockable 
windows. Now, if these were QDockWindows (and if I were using Keramik or 
Liquid), then the title would be present both *in* the tab bar and in the 
widget itself. In the screen shot, instead of the dock handle, you would see 
a titlebar saying "Messages", which would be ridiculous.

> >   I suggest that we allow the application to request that we treat dock
> > window handles the same as toolbar window handles.
> > [snip]
>
> There is no easy way to do this - QDockWindowHandle is an internal Qt
> class.
> [snip]
> Ideas are welcome.

Brainstorming: how about a static boolean variable in KApplication or the 
style, and a static method which turns caption painting on/off? This would be 
BC, and not interfere with current applications.

> >   On a related note, how can I get window decorations for undocked
> > QDockWindows?
>
> You cannot. Qt treats undocked QDockWindows as popup windows, so the window
> manager will never give it a frame. TrollTech has decided that, due to the
> inconsistency of window managers, this was the best option.

Ok, I will bug the Trolls about this. I haven't seen much QDockwindow code 
outside of designer, and may explain why no one has bugged them about this.

Regards,
Ravi




More information about the kde-core-devel mailing list