This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Going from FreeLayout to any other layout (needlessly) wipes out the dimenions of the container | ||
---|---|---|---|
Product: | guibuilder | Reporter: | ahristov <ahristov> |
Component: | Natural Layout | Assignee: | issues@guibuilder <issues> |
Status: | NEW --- | ||
Severity: | blocker | ||
Priority: | P3 | ||
Version: | 5.x | ||
Hardware: | All | ||
OS: | Windows XP | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
ahristov
2007-02-06 10:39:29 UTC
There are certainly cases when we could do better, but in general the problem is not that we would set or reset the size of the container, but the opposite - we do no changes. And in many cases the size simply can't be maintained. A container with "free design" defines fully its size and appears to its parent as having the preferred size (so no specific size is set in the parent layout). Thus when you change the layout of the inner container, it may change its size because its preferred size changes with the new layout. If the inner container is empty and the parent container has the "free design", then switching layout in the inner panel should probably keep the size in the parent container - by setting specific component size in the parent layout. However, I'm not sure if this should be done for non-empty containers. Probably yes if changing to AbsoluteLayout/Null. Perhaps the same could be done if the parent layout is Absolute/Null. But for the other layout managers there is no direct control over the components' sizes. By maximized mode you mean you invoked "Design This Container" action on the container? Here the container spans whole designer and the "visible" size does not have to match the real size in the parent container. Changing the layout should not change the designer size except growing due to changed minimum size. (This seems working to me in 6.0 dev.) Well, surely the fact that the user has expressed (by resizing) a different preferred size for the container has greater priority than its own preferences :-) (in FreeDesign layout, that is. Of course in other layouts the size is determined by the parent, but I'm speaking about FreeDesign, and possibly null layout) (BTW by "maximized" I mean just that the designer tab occupies the whole IDE window) As for "I'm not sure if this should be done for non-empty containers", I disagree. Here's my particular (real) case : I start with a panel resize it and align it and start placing components. Now suddenly I decide " What the heck, I'd be better with a flow layout rather than placing the component with gaps and so". So I change the layout to flow and suddenly BAM! - chain reaction : the panel resizes, all components anchored or somehow related to it change, and they trigger some other change and...you get the picture (and this is componunded by the fact that undo fails occasionally). My suggestion is that after changing the layout of a container (whose parent allows sizes to be manually specified) and before anything else, the IDE should resize the container to whatever the previous dimensions were. It matches the intuitive notion that things that that affect only the interior of something (in this case, how this something arranges and sizes its children) should not affect the outside. I understand you case, however we need to take into account the consequences of setting the specific size of the changed container and ignoring its new minimum size. Setting absolute size is bad. As I said in my first report, the starting dimensions do not conflict with the new layout because after changing the layout, the container can be resized again to the starting size. Nobody is talking about ignoring minimum dimensions. I'm just talking about preserving something that was, and that is non-conflicting. As for "absolute size is bad", well this is a matter of preferences, target market and many other things, among them simply personal taste. I'll point out that there are thousands of applications that have done and are doing perfectly fine (and leading markets as well) without resizing every single minuscule component or icon when a window resizes. Just like an IDE shouldn't force the coding style (or whatever) of its authors to me, a GUI designer tool shouldn't force the authors' personal preferences or beliefs about what is good or bad, either. Especially considering that we are talking about containers handled by FreeLayout. Personal judgements aside, I think that we can agree that the fact that 1) an absolutely sized container changes its *inner* layout to something else that *does not conflict* with the starting absolute size (i.e. minimum size <= original size) and 2) the change results in a completely altered *outside* design is a designer bug - for whatever reasons down the chain of calls - and it should be fixed. The absolute sizes are not bad because of resizing, but because of different platforms the UI may run on. If you are sure you run your app always in the same look&feel and localization, you can do that, but that's a rather special case. > 1) an absolutely sized container changes its *inner* layout to something > else that *does not conflict* with the starting absolute size > (i.e. minimum size <= original size) If you have a panel with three buttons positioned vertically in a column and the panel size is just enough to display the buttons, then changing it to FlowLayout violates the minimum size of the panel. FlowLayout's minimum size is computed trying to put all components on one line. Now you force it to wrap, but the result will depend on the target look&feel or localization - it may lead to clipping the components or placing two on one line, etc. This is what I don't like. In the originally free design-based layout this was not the case, even if you sized the container to certain size. It will always make sure there is appropriate space (provided you did not make it smaller than min size). > 2) the change results in a completely altered *outside* design > is a designer bug - for whatever reasons down the chain of calls > - and it should be fixed. I understand the user impact - in some specific situations. Maybe you are right and switching silently to absolute size from correct default size is less evel than potentially destroying the user design. I'm not saying we are not doing it, I just have not decided yet. Could you attach your form here (or send it) so I have more exact idea? Thanks > The absolute sizes are not bad because of resizing, but because of ... I know I know, I wasn't pretending to be exhaustive. I simply wanted to point out that absolute sizes are not an absolute evil to be banished :-) > If you have a panel with three buttons positioned vertically in a column and > the panel size is just enough to display the buttons, then changing it to > FlowLayout violates the minimum size of the panel. FlowLayout's minimum size > is computed trying to put all components on one line. Well, this is a different issue you are pointing here. If the minimumLayoutSize is interpreted as a "minimum area", then it is a mistake to consider separately each of the longitudinal dimensions as a minimum value. If instead the minimumLayoutSize is interpreted as a set of two minimum longitudinal sizes, then Flowlayout is simply lying (=method contract breach) because obviously the minimum width is not minimum if the container can live with a smaller one. But that's not the point. The point that I'm trying to make is that if the container with the new layout can live on with the dimensions of the old one, there's no reason for not keeping them. >I just have not decided yet. Could you attach your form here (or send it) so I have more exact idea? Thanks I'm afraid the design changed since then so I don't have the original one, but since I'm trying very hard to use the NetBeans GUI designer and to report anything strange I find for the benefit of all as soon as I get to another case I'll attach it here. Thanks for your patience, by the way :-) According to the discussion above it seems that it might be possible to do better in some cases, but that it is mostly a matter of preference. There are strong arguments both for and against this change. It clearly is not a pure defect. Hence, changing the issue type to enhancement. *** Issue 139022 has been marked as a duplicate of this issue. *** |