Andy Ross said:

> Jim Wilson wrote:
> > On my system (CVS), the xml dialogs keep shrinking, just like Mike
> > Teevee.
> Confirmed.  Unfortunately my analysis has been delayed by the need to
> google the Mike Teevee reference. :)
> Seriously, I'm really busy right now at work, so I'm hoping someone
> else can hack at this for the 0.9.5 release.  The essence of this bug
> is that something isn't properly deleting the "height" and "width"
> values on the top-level dialogs before doing the layout.  So the
> second time the dialog pops up the layout manager thinks the dialog is
> asking for the size it had the last time, applies (maybe?) a padding
> correction, and lays it out a little smaller than last time.
> The code looks correct, but clearly I missed something.  It might have
> to do with the top-level PUI frame that gets added automatically by
> the dialog code?  It looks like this is the only object that has its size
> changed.  The rest of the dialog layout seems to be static across
> invocations?

I just tried this and it seems to work.  Is this bad?  Everything seems to
look ok here with this patch in place.



Index: src/GUI/layout.cxx
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/GUI/layout.cxx,v
retrieving revision 1.2
diff -u -r1.2 layout.cxx
--- src/GUI/layout.cxx  14 May 2004 17:16:35 -0000      1.2
+++ src/GUI/layout.cxx  22 Jul 2004 19:16:08 -0000
@@ -24,7 +24,10 @@
 int LayoutWidget::padding()
     int pad = isType("group") ? 0 : 4;
-    if(isType("dialog")) pad = 2;
+    // As comments above note,  this was being set to 2.  For some
+    // reason this causes the dialogs to shrink on subsequent pops
+    // so for now we'll make "dialog" padding 0.
+    if(isType("dialog")) pad = 0;
     if(hasParent() && parent().hasField("default-padding"))
         pad = parent().getNum("default-padding");

Flightgear-devel mailing list

Reply via email to