← Back to team overview

kicad-developers team mailing list archive

Re: UIpolicies.txt


--------------060001010605070802010708 Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Dick Hollenbeck wrote:
> Wayne,
> Were you thinking this would be done programmatically at runtime?


Yes. I believe it has to be done programmatically. This is especially
true if you populate the content of any controls after the dialog object
is created. I discovered that if you let the sizers readjust by calling
Layout() and Fit() after populating the controls then use updated size (
GetSize() ) as the minimum size of the dialog it does a very nice job of
creating the correct dialog box size. If you don't set the minimum size
or define the initial dialog size, the dialog will allow resizing
smaller than the initial size which obscures the controls. It didn't
make sense to me to allow resizing the dialog smaller than it's contents.

> Avoid defining initial dialog sizes if possible. Let the sizers do 
> their
> job. After the dialog is fit to the sizers, set the minimum size to the
> current size to prevent the dialog controls from being obscured when
> resizing the dialog. If the labels or text of the dialog controls are,
> set or changed at run time. Rerun wxWindow::Fit() to allow the 
> dialog to
> re-size and adjust for the new control widths. This can all be done 
> after
> the dialog is created but before it is shown or use class methods to
> re-size the dialog as required. Reset the minimum size to the updated
> dialog size.

I added this so that developers wouldn't have to relearn what I had to
figure out the hard way. It's like section on the set focus to get the
escape key to cancel dialog bug in GTK.

> I fear a minimum size is fraught with platform dependencies, some of 
> which can only be known at runtime, due to font sizes, etc.

This actually fixed a platform related issue as the layout issue was not
quite the same on win32. I tested this on both GTK and win32 ( I don't
have access to a Mac ) and seems to work fine on the new dialogs I added
to EESchema. It worked much better than the fixed size spacer hack that
I originally used to solve the wxFlexGridSizer problem I had with the
pin properties dialog on GTK. Granted, I didn't test it with every
possible sizer type and control combination so there may be some cases
where this doesn't work. You can check this out by commenting out
dlg.Layout() and dlg.Fit() ( lines 81 & 82) in pinedit.cpp. On GTK the
units label will not be shown ( at least with wxWidgets 2.8.7 in Debian
testing). You can also see the resize issue by commenting out
dlg.SetMinimumSize( dlg.GetSize() ) (line 83) and making the dialog
smaller than it's calculated size. The attached images should make the
explanation more clear.

> If to be done at runtime, and I feel this is the only sensible way, then 
> maybe we need to start deriving all dialogs from our own common base 
> class so we can take care of all these things in a common way.

If you could come up with a clean method of guaranteeing that anytime
the contents of a control was changed that the dialog got resized
correctly then yes it would make sense to create a base dialog class.
Off the top of my head, I think this would be a very complex object and
would be difficult to integrate with wxFormBuilder. If you don't change
the contents of the dialog controls at runtime, then you really don't
need to do this. It may make more sense to just add the three lines of
code above as required.

I apologize for not getting back to you sooner. I have been trying to
finish this email since yesterday. This is just a really busy time of
the year for me.


> Dick

--------------060001010605070802010708 Content-Type: image/png;
Content-Transfer-Encoding: base64
Content-Disposition: inline;

[Attachment content not displayed.] --------------060001010605070802010708 Content-Type: image/png;
Content-Transfer-Encoding: base64
Content-Disposition: inline;

[Attachment content not displayed.] --------------060001010605070802010708 Content-Type: image/png;
Content-Transfer-Encoding: base64
Content-Disposition: inline;

[Attachment content not displayed.] --------------060001010605070802010708 Content-Type: image/png;
Content-Transfer-Encoding: base64
Content-Disposition: inline;

[Attachment content not displayed.] --------------060001010605070802010708 Content-Type: image/png;
Content-Transfer-Encoding: base64
Content-Disposition: inline;

[Attachment content not displayed.] --------------060001010605070802010708 Content-Type: image/png;
Content-Transfer-Encoding: base64
Content-Disposition: inline;

[Attachment content not displayed.] --------------060001010605070802010708-- 

Follow ups