CWForm sizing troubles

[Richard Sargent]

I have been working on a browser extension, so I am working with Common Widgets and Motif rules.

I have tried laying out a small form comprising a couple of widgets (a label on the left and a combo box beside it). The horizontal sizing and spacing works exactly as I want and expect.

But the vertical aspects are driving me around the bend. I set the top as inset 30 from the enclosing form (XmATTACHFORM 30) and the bottom inset 55 from the enclosing form's top (XmATTACHOPPOSITEFORM -55, per the rules.)

The problem is that VAST concludes the height should be 85 rather than 25. The CwFormConstraints think the height should be 21. I don't agree with that, but it's hardly the big problem. 85 is a problem. It causes this form to overlay the two below it in the layout, one at 60 inset from the enclosing form and one at 90 inset.

This overlaying prevents one from clicking on or into a toggle or text field and sometimes, seemingly depending on whim, hides some or all of the lower widgets.

I hacked CwFormConstraints and CwWidget, etc. to report information about what they think. The screen shot shows red highlights on relevant things. It looks like the constraints pretty much agree with me and my wishes. But, the form has numbers apparently pulled by some random algorithm. Actually, it is consistent. If I vary the numbers, I get a corresponding result.

It's as if the top inset is added to the bottom inset to come up with a fictitious total.
I cannot compass that such a thing could have existing in VA the nearly four decades of the software's lifespan. But, I can't imaging it is a recently introduced anomaly.


If anyone can explain this behaviour, I would be grateful.

[Marcus Wagner]

Just two quick facts: first base of the ST Model  was Motif. Its coordinates are different, to mention shells coordinats, the label and the (dynamic) Windows header. Reaction: necessity of negative coordinates in contradiction to the original.

 Second fact: scalability in combination with multi monitors (and ...) plus a long time (several years) to stabilize this being implemented on a changing base (8, 10, 11). The initial aspect, to provide a uniform (common widget) model in Smalltalk being platform independent still is a challenge being permanently stressed because of changes of the underlying host systems, following different targets and often ending up in contradictions. That means, the measures like x points (size, attachments) become more and more meaningsless. May be that you have to search a solution which just fits the host (which is not knowing about ATTACHOPPOSITE). Or in other words: design it under host OS principles, not being bound in thinking of terms of the Common Widget model / or try to fill evolving gaps between the initial common widget model and the actual changed reality, if you have to stick to the platform independence goal.

Kind regards

M

[Richard Sargent]

Hi Markus,

Thanks for the answer. However, my experience with ABT parts is that XmATTACHOPPOSITEFORM did not need negative offsets to inset the attached part. When I tried that with CwForms, I ended up with the widget reporting a negative height equal to the other edge's inset minus the  XmATTACHOPPOSITEFORM side's offset.
I also had nothing visible within the form (being very hard to see anything). When I use negative offsets, the form reports a positive height and the widgets contained within it are visible. However, the reported height is not correct, appearing to be the sum of the absolute values of the respective offsets.

Leaving the top, left, and right attachments specified and the bottom unspecified resulted in correct placement of the contained widgets and a computed height of the form equal to the sum of the top offset of the last contained widget and its height. e.g. offset 85, a combo box (or was it a check box - can't recall now) with a height of 27 yielded an enclosing form with a height of 112, exactly as one would expect.

I did try to explicitly change the height of the fully specified form attachments. Following it through, I came across logic that exited. This method was CwForm>>#resizeChild:width:height:, IIRC. I looked for the XtGeometryNo reference and found exactly what I thought I saw.

So, this leads me to think that there is something wrong in how the height of a fully constrained form is calculated.

[Marcus Wagner]

Hi Richard, 

thank you for more details, I can now focus on the offended coordinate layer, dealing with forms, instead of philosophing about deeper (widget) and higher (multimonitor, universal desktop) layers and coordinate systems.

First at this layer, there are no negative coordinates (but negative distances, of course) - which immediately poses a horizontal problem under Windows leading s.t. to strange horizontal aspects.

Under Motif, the screen form starting left top is coordinate 0@0. Usually the first widget places there is the header, with labels and positioning buttons (like full, top, etc.) followed by the menu line.

So the form of a window starts later, somewhere at e.g. 0@15 (leaving room for 10 point label bar and a 5 menu line). 

This Motif calculation contradicts Windows coordinates at this level: the form of a window under Windows starts at 0@0. The start of label and menu is negative and ... dynamic and unknown a priori.

The reason: the ability to independendly configure and change the general layout (theme) of all headers. 

You can imagine that easier by the thought of  a header style being independent from  any window and does not belong to it, hence the start 0@0 is later/below than under Motif, which initially did not have such a concept. 

I can drill that down further concerning boundaries and frames, but the label bar on top is a comparatively large (> 15 points) causing a significant change of coordinates already at the top left corner of any window and its main form.

Now the ABT parts are based on Motif. Concentrating on attachments there, I remember some anomalies in size thinking there, which result from otherwise arbitrary complex resize calculations. To avoid complexity, rules about how to apply attachments avoid this. Again, leaving out many details, placement within a form regulates how its contents has to behave if the form is resized, either by relative (percentage) or absolute coordinates / distances related to the bordes of the form.

That means, any form (again) starts top left 0@0 as anchor of its children. The attachopposite term allows to specify relations to the opposite side of the SAME form (not any other form beneath). As simple example

FormLeft                                          <100>                                           FormRIght

                           <30> WLeft            <40>            WRight <30>

A widget to 40 points wide, centered in a form being 100 point wide. There are many (equivalent) definitions, but as giving all distances ends up in overspecification. So two values are sufficent:

a) Widget position left 30, width 40 (will move to right if form is made narrow, potentially right side cut off if form width < 70)

b) Widget position left oppositeform 70 width 40 (will move to the left if form is made narrow,. potentially left side cut off if form < 70)

c) Widget position left 30 right 30 (will become narrower and disappears if form width < 60)

....

The point is: all sizes and distances at this level are cooridinates in this form and relate only to its direct children, that means intern between parent and chidren, starting at parent top/left 0@0. 

Negative values relate distance to the opposite, that means bottom or right side of this form, where bottom @ right is equivalent to width / height of this form.

A combo box e.g. is a compound widget, that means conceptually another (nested) form, having several autonomous corrdinate systems for its children.

Any widget has a top left coordinate (relative to its direct father, a wdith and a height.

Any (primary) widget is placed relative to its direct father/parent using 4  values: 

a coordinate,. vertical and horizontal size. The coordinate (relative to the direct father) can specify/relate to any of the four corners (e.g. you can specify the right bottom corner) and the buld up from there.

the size can be specified as positive distances related to top/left or negatives one related to bottom/right (the opposite side). All suche measures belong either to the father or the widget, not to any other (third form/widget).

Given the size and position of a widget (or form) further details directly relate to that (border, size, nested children etc.).

So resizing is becomes an ordered process: starting from the resized objects the change propagates to the inside, layer per layer.

Coordinates in Common Widgets follow this principle. It is an understandable mistake to relate such numbers to the window, which is normally NOT the direct parent.

Finally this turns out to a local navigation problem clicking at global 5@6, which widget is offended and where (which coordinates within its borders), not to say that 5@6 is already a complex result out of mouse movements over sevarals screens having different resolutions and sizes).

No, there is no known problem in navigation, coordinates at this level, this is stable as far as I remember, the start of (Open System Foundation) Motif < 1990. 

I also do not know any fixes here in Common Widgets built upon that. However any system to be covered by that has to be mapped into this concept. As they frequently change or develop, errors arise occasionally in the concrete mapping (as I entered this discussion).

Did you consider that the numbers in the widgets are relative, not absolute ones?

Kind regards

M