Ed Leafe wrote:
> On Jun 1, 2007, at 6:43 PM, Paul McNett wrote:
>
>> I'm using this as a project to understand the cdxml format, and have
>> noted some questions/possible defects in my mind so far because of the
>> exercise:
>>
>> + Grid columns apparently put all property values into the cdxml,
>> whether or not they were changed from the default.
>
> This one is unusual, but looking back at the code, I don't remember
> why. Here's the code in question from the LayoutSaverMixin class in
> ClassDesignerComponents.py
>
> if isinstance(self, dabo.ui.dColumn):
> # We need all props for this class.
> allProps = True
>
> I'll look into what would happen if these lines were removed.
Probably something to do with the fact that dColumn isn't a full
dPemMixin object, but merely a dObject.
>> + The sizerInfo attribute stuffed into each and every object added
>> appears to mostly have default values, such as BorderSides=["All"] and
>> Border=0. The default stuff should not be part of cdxml.
>
> This is a known limitation that comes when you have to handle
> inheritance. You can't just assume that something is different than
> the default setting; you have to determine if it is different than it
> was in its superclass. There is a lot of code that deals with this
> for controls and their props; but for sizerInfo stuff hasn't been
> done yet.
Ok, fair enough.
> What this means is that if you have, say, a panel class and define
> the sizer settings on one of its objects, and then use that class in
> another class, you see the sizer set the way it was in the
> superclass. Now if you go back and change the sizer settings in the
> superclass, save that, and then open up the subclass/instance, it
> still shows the original settings.
I don't follow this paragraph... The sizerProps are merely helpers for
how to execute the append() call, right? IOW, they don't specify the
actual properties of the containing sizer.
>> + Seems that Width, Height, Left, and Top are always saved, whether or
>> not they are relevant for the given object. For example, your dPages
>> have these properties, which really makes no sense because a given
>> page
>> will be positioned inside the pageframe and take up all the space
>> it is
>> given in that context. This could be bad elsewhere too, such as with
>> grids and textboxes, because by explicitly setting Width and
>> Height, you
>> are also implicitly setting the minimum size which could have
>> aggravating results with sizers at runtime (the design will only
>> resize
>> down to everyone's aggregated minimum size, bringing in the
>> scrollpanel's scrollbars prematurely). To be clear, Width and
>> Height are
>> relevant because of this but it seems to me you have them set pretty
>> high - whether you set them explicitly high or whether they just got
>> saved that way because that's how big the sizer made them in the
>> designer, I don't know. If the latter, I think it is a defect.
>
> Well, this ties in to the previous matter. What is done is that
> every property that is different than the default for that class is
> saved. Pages, being panels, have a default size of (0,0), so yeah,
> they get saved.
>
> There used to be code that filtered these properties out; when it
> was changed I left it as a comment, which means I wasn't sure that
> this was the best approach. Here is the code where properties that
> are not to be saved get weeded out:
>
> for prop in desProps:
> if prop.startswith("Sizer_"):
> continue
> if prop in propsToExclude:
> continue
> if (hasSizer or isinstance(self, dabo.ui.dPage) or
> isSplitPanel)
> and prop in ("Left",
> "Right", "Top", "Bottom"): #,
> "Width", "Height"
> continue
> if prop == "BackColor" and isinstance(self, (LayoutPanel,
> LayoutSpacerPanel)):
> continue
>
> I don't remember what the trade-off here was, but apparently
> something was getting screwed up by not including these properties.
>
> If you can find a case where the inclusion of these properties is
> causing a problem, let me know.
The inclusion of them for dPage isn't really a problem, and not the gist
of my comment. The real problem could very well be in Dabo itself, but
it's been this way for ages, and it exists in wx too:
When you explicitly set the size of an object, you also implicitly set
the MinSize of the object. So, if you explicitly set txt.Width to 300,
and that txt is part of a vertical sizer with the "expand" flag, or a
horizontal sizer with a proportion > 0, that txt will never get sized <
300. I think this is a nice feature/side-effect, but if you have
something like the class designer saving the width/height of the *sized
at design-time* properties (IOW, the sizer made the textbox have a width
of 312), then this runtime feature doesn't work so well.
Run the two examples of EtypEnum (the cdxml versus the .py version) and
play with sizing the form down to small values, to see what I mean. In
the .py version, I didn't include the explicit size values (for the most
part), so the user gets well-laid-out smaller sizes. In the cdxml
version, the controls don't want to get very small so you end up getting
scrollbars instead of lower sizes.
I think it is important to let the user specify Width/Height as props in
the class designer, but we somehow have to keep those values from
getting overwritten by the width as a result of sizer operations.
>> + I notice several layout panels in the design, and sizers in the
>> hierarchy that aren't really necessary to get the desired layout.
>> Probably a necessary evil (benefits of having sizer slots as a visual
>> element during the design outweigh the possible excessive number of
>> sizers/layout panels). I removed a couple obviously-unnecessary layout
>> panels.
>
> Did you also change the SlotCount for the sizer that contained them?
Does SlotCount exist outside of cdxml? If so, I wasn't aware of that. I
didn't include SlotCount at all in my Dabo/py conversion.
> Designs are supposed to be re-entrant; you can start working on
> something, save it, and then re-open it just as it was when you left.
> I don't know how you would imagine restoring a panel that may have
> modified sizer settings without including that panel in the design.
Ok.
> As far as the "unnecessary sizers" are concerned, I'd have to see
> that design to understand why that happened. Sounds more like poor
> execution than something structural. There's no way for me to
> implement DWIM().
I know.
>> + There are some properties of the form that don't exist in raw Dabo,
>> and perhaps they should: CxnFile, and CxnName. I don't really
>> understand
>> how these come into play at runtime, though.
>
> Just look at the __init__() for dFormMixin. The same thing happens
> for MenuBarFile.
Ok, so they do exist for non-cdxml classes as well. Was there a reason
we didn't implement these as actual properties?
--
pkm ~ http://paulmcnett.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
Searchable Archives: http://leafe.com/archives/search/dabo-dev
This message: http://leafe.com/archives/byMID/dabo-dev/[EMAIL PROTECTED]
