Can a widget specify its size?

[trevordevore]

When dragging a widget onto a card there is a default size that is used (128x32). Is there a way for a widget to tell the engine how big it should be by default? I want one of my widgets to resize itself automatically when I set certain properties so I don't have to fiddle with resizing manually.

[trevordevore]

I filed an enhancement request for this.

http://quality.runrev.com/show_bug.cgi?id=14800

Ben mentioned that

Code: Select all

set my width/height

should work but I couldn't get it to.

[LCMark]

This is something which we need to do some more thinking on - it is definitely a needed ability (very important actually - we also need to separate the idea of 'intrinsic size' from 'rect' so that in the future widgets can have arbitrary affine transforms).

The key thing is getting the process right - I'm not sure whether setting width/height directly is the way to go except for (perhaps) the most simple use-cases (we need to be careful not to get too attached to the current script idea of width/height/rect). There's also a property 'trigger' here too - setting a property could result in the intrinsic size of the widget needed to change. If 'resize' is to also be a trigger then the calculation of intrinsic size would have to be an event which the engine can send and then 'do the right thing'.

Indeed, I wonder if making sizing a sort-of 'deferred' process is the best way to go.

If you want to redraw a part of the widget you use 'redraw all' - this allows the engine to work out when it is best to do so, and what it needed with the actual update occurring in OnPaint at the appropriate time.

Modelling this, we could have syntax 'resize' which would mark the widget as needing to recalculate its size and then the engine will 'at the appropriate point' call something like OnConstrain. It would pass in suggested size, which the widget can then modify. Finally an 'OnResize' event would fire to allow the widget to update its internal state so it can be painted at the new size (if there is any work to do here).

By making the process based on events and deferment, the engine can optimize the case where multiple properties need a resize - there's no need for the engine (or widget!) to do the resizing work until the point the widget needs to report its size (for example, due to painting, its rect being fetched etc.).

This sounds a bit complicated at first sight so definitely more thought needed! We need to make the obvious cases easy, but the general case possible.

[trevordevore]

Makes sense. Here is my specific scenario to keep in mind. In my scenario the widget shouldn't be resizable by the developer. The size of the widget is entirely based on properties that have been set (e.g. the textSize). So the developer sets a property, the widget paints everything based on the property value and sets the size of the widget.