QDockWidgets without central widget

[JoeMerchant]

Disallowing tabbed docks is also a nice touch, is there a way to do this on a DockWidget by DockWidget basis? There are some widgets that we will want to have tabbed, while others will want to be always visible.

Mostly what's going in these windows are graphs of data (similar to a lie-detector polygraph), there will also be a couple of windows with numeric displays, and a few with 2D image representations of data. The graphs will have captions, and be user-configurable - they may change overall size from time to time - so I want the Scroll Area option for when they are just too big for their windows. Also, the numeric displays will be pretty small, even using big fonts, when compared to the polygraph display.

I've done applications like this in the past where only the programmers could re-layout the screen, but that puts programmers "in the loop" - would be best if the users could tweak their own layouts.
-------------------
I suppose what I would wish for would be:

If there are only dock widgets in the top and bottom
and no widget in the top is at minimum height
and any widget in the bottom is not yet at its maximum height
then allow the separator top-bottom to be pulled upwards until either:
a widget in the top is reduced to minimum height or
all widgets in the bottom have reached maximum height
(and, of course, extend this logic for all cases up, down, left and right)

The behavior I see now is stopping the separator when any widget in the row is at (or above) its maximum dimension - but in some window resizing cases the restricted widget is drawn (nicely) centered while allowing other widgets in its row to use the available space.

The "wasted space" around widgets that are in a row/column larger than their maximum dimension isn't such a bad thing - in my opinion. It's just a reality of the chosen layout, and often may be a result of stretching a main window very large for a layout that "works" very efficiently at smaller sizes.

All in all, I think the dockable widget concept is a 100% improvement over "fully configurable" but dumb windows with such annoying layout options as "Tile" and "Cascade".

[marcel]

Disallowing tabbed docks is also a nice touch, is there a way to do this on a DockWidget by DockWidget basis? There are some widgets that we will want to have tabbed, while others will want to be always visible.

Afraid not.
It is a QMainWindow option.
You can always create a custom dock widget that allows tabbing.

I've done applications like this in the past where only the programmers could re-layout the screen, but that puts programmers "in the loop" - would be best if the users could tweak their own layouts.

Well, you can do that( allow the user to choose the layout ).
But you can't put too many restrictions on the dock widgets, or restrictions that contradict with each other( like the sizes ).

Another thing you could do is create like 10-20 layout configurations(which could be more than enough) and let the user choose from them.
In the same time, you could allow dock resizing, but not moving.

Otherwise, if you allow the user full control over the layout and you impose sizes on the widgets, you could get in trouble.
Here's an idea: keep your min/max sizes as they are, but when the user starts moving a dock widget, intercept this move event, and remove the size constraints on your widgets.
When the user finished moving, you can set them back, although that could result in a relayout of the docks made by the main window layout.

Regards

Regards

[JoeMerchant]

Logically, I'm not seeing "contradictions" in the size limits....

Dock widgets fall into one of 4 bars - top, bottom, left or right.

If any widget has a minimum dimension applicable to the bar "thickness" (height for top and bottom, width for left and right), that (plus frames) becomes the minimum dimension for the bar itself. If another widget in the bar has a maximum dimension less than the minimum dimension set by the other, the minimum wins and the widget with the maximum limit is drawn with some blank (background color) space around it, so it hasn't really violated its maximum limit.

Along the bar "length" (width for top and bottom, height for left and right), no widget gets compressed smaller than its minimum, but the bar may be stretched longer than the sum of all maximums, either by minimum constraints on the opposing bar, or by the window itself getting stretched - in which case the dock widgets can be spaced out equally, preserving their maximum limits and again filling wigh background color.

I only see contradictions coming in when the containing window is too small to accomodate all minimum sizes (in which case, shouldn't the window's size act to accomodate all contents?) If the containing window has a maximum size, I could see that precluding certain dock widget arrangements, but if the dock widget minimum sizes can be accomodated, then it should all work.

And of course, the separators allow adjustment within any available range.

Will be wonderful when it works.....

[marcel]

Logically, I'm not seeing "contradictions" in the size limits....

Dock widgets fall into one of 4 bars - top, bottom, left or right.

If any widget has a minimum dimension applicable to the bar "thickness" (height for top and bottom, width for left and right), that (plus frames) becomes the minimum dimension for the bar itself. If another widget in the bar has a maximum dimension less than the minimum dimension set by the other, the minimum wins and the widget with the maximum limit is drawn with some blank (background color) space around it, so it hasn't really violated its maximum limit.

Yes logically .
But the window layout( the one that positions the dock widgets ) tends to disagree.
Take the weird behavior you experienced as proof: sometimes you cannot move the dock widget(at least this happened to me), etc.
All I was saying: it will be pretty hard to get a "normal" dock widget behavior by imposing size restrictions - because you don't know how the user will resize a dock and where that dock will be dragged.

Along the bar "length" (width for top and bottom, height for left and right), no widget gets compressed smaller than its minimum, but the bar may be stretched longer than the sum of all maximums, either by minimum constraints on the opposing bar, or by the window itself getting stretched - in which case the dock widgets can be spaced out equally, preserving their maximum limits and again filling wigh background color.

Not sure if I get that. But if I get it, then I think its correct.

I only see contradictions coming in when the containing window is too small to accomodate all minimum sizes (in which case, shouldn't the window's size act to accomodate all contents?) If the containing window has a maximum size, I could see that precluding certain dock widget arrangements, but if the dock widget minimum sizes can be accomodated, then it should all work.

You could tweak the main window to expand size when the contents require it( and also in the limits of the screen ).

And of course, the separators allow adjustment within any available range.

Again, not sure how you will achieve that ( in the general case ).

Will be wonderful when it works.....

Yes, good luck on that, especially on "defeating" the main window layout.

Regards

[JoeMerchant]

You could tweak the main window to expand size when the contents require it( and also in the limits of the screen ).


Again, not sure how you will achieve that ( in the general case ).

Well, the general case is fairly simple to specify for logical functionality (define which dock bars occupy which corners, which bars "meet in the middle", etc.) but it is apparent that 4.3.0 doesn't yet implement "logical logic." Maybe 4.3.1 (released this morning) is better.

I think what we're going to do from a practical standpoint is implement with dock widgets, but lock them down so they are not user reconfigurable for now, just have a couple of predefined layouts that the user can load. Maybe Trolltech will beat me to it and get the logic fixed before I finish my product specific code - in fact, I bet they will - in which case we can just have a menu option to unlock the display configuration allowing user resizing and drag-drop. If our users are clamoring for it (and promising to buy more copies only if we have it), I guess I could go in and fix the logic myself.... but I think I can add more value to our product in other areas for now.

[marcel]

Well, then you are set .

Maybe 4.3.1 (released this morning) is better.

I didn't know they released it already. Are you sure? Can't find anything at trolltech.com.

Regards

[JoeMerchant]

I didn't know they released it already. Are you sure? Can't find anything at trolltech.com.
Regards

Hmmm...... I received this this morning:

We are pleased to announce that Qt and Qtopia Core 4.3.1 are now available. Qt and Qtopia Core 4.3.1 include bug-fixes and performance optimizations made since the release of version 4.3.0 in May.

Trolltech commercial license holders receive regular releases as part of their annual license. All improvements to Qt and Qtopia Core are also released to the Open Source Community through GPL editions of both frameworks. Both releases are available for evaluation and open source download.

---------

In their typical Troll like way, this mislead me to believe that both releases of 4.3.1 are available now, but I suppose they haven't gotten around to updating the open source version yet. I don't find 4.3.1 on the open source side.

[marcel]

Well, I guess I'll find out next week.
I use the commercial version at work also.

Regards