Automatic align controls in Toolbox/Wimp?

Hello,

I need to align controls in the Toolbox/Wimp window automatically when parent window changes its size.
For example I needs a text input control grow width when window width is changed, keep button right aligned, etc..
Something like GtkHBox in Gtk or QHBoxLayout in Qt.
Is it possible in RiscOS Toolbox/Wimp?

PS. I know about subwindows but it seems not helps, it changes the window size only but not position/size of Toolbox controls inside.

I don’t think there’s a way to do it automatically, but you will get an “Open Window” request from Wimp_Poll (https://www.riscosopen.org/wiki/documentation/show/Open_Window_Request) when the window is opened or resized. You can get the size from the block, work out the new sizes and use Wimp_ResizeIcon to change the control sizes.

Something similar should be possible with the toolbox.

[..] use Wimp_ResizeIcon to change the control sizes.

Keep in mind though that Wimp_ResizeIcon does NOT redraw the icon so a suitable Wimp_ForceRedraw is required after resizing is done.

Something similar should be possible with the toolbox.

For Toolbox gadgets you can use Gadget_MoveGadget (which does redraw the gadget).

I did experiment with resizing of gadgets when rewriting Makro (in AppBasic) but got mixed results. At some point the gadgets ended up being too wide or too narrow, not sure why. In the end, I settled for a dialogue box to set the width of the window and that worked fine.

Thanks for the answers.

So needs to do all automatic layout job by hand.

In the Tcl/Tk the geometry manager was implemented in 90’s.
Why RiscOs still does not have it…

So needs to do all automatic layout job by hand.

At the moment yes, but there is a new technology that makes things a lot easier.

The Layout/geometry of windows and widgets has evolved during the past 30 years through three key stages.

1. Absolute Positioning of coordinates
2. Relative Positioning of coordinates & using top/bottom/left/right anchoring to parent window
3. Constraint Based Logic

RISC OS layout of windows and icons has never really went beyond stage 1 – absolute coordinates, but we can jump over stage 2 and take advantage of Constraint Based Layout Managers that exist – see http://overconstrained.io/

Basically it’s a super quick calculation engine that can be used to determine what coordinates to use for the whole window and everything displayed within it. Apple introduced it in iOS about 10 years ago, Google about 6 years ago, GTK unofficially abut 2 years ago. I’m very bad at coding but I’ve been able to create SplitterWindows which is probably a world’s first for RISC OS using one! And dynamically calculated icons is super easy too.

I suggest avoiding stage 2 which is what you were probably thinking about, and jump to stage 3 and use a Constraint Based Layout Manager. Having one that works with the Toolbox controls would be a huge boon to other developers.

Why RiscOs still does not have it…

The RISC OS Window Manager could not handle nested Windows until much later in its development, and hence applications were designed with a very simple one window design. e.g. Paint, Edit, Draw.

When Acorn finally got round to developing the WIMP to handle nested windows (to deliver stage 2 above), developers were left to calculate all the necessary geometry logic themselves – which very few rarely did because it’s really difficult.
Eventually Acorn released classes of controls for the WIMP called the ‘Toolbox’ but again never included any geometry logic for them. Developers would have to do it themselves – which very few rarely did because it’s really difficult.

As a result most RISC OS Apps still use very simple designed GUI’s with very few nested windows and controls with little ability to dynamically change size.

I think in RISC OS terms, it’s a hybrid of #1 and #2. While the positions are absolute, they are relative to the window. However mouse clicks and stuff give absolute positions and you need to fiddle around to work out where that is in the window.

I can understand automatic placements being a useful addition (and it’s a surprise the toolkit never did it), but I don’t consider it an evolution. It’s an alternative. Some stuff (button bars?) may benefit from auto-sizing, but other things probably shouldn’t have it. I can imagine a window that constantly resizes and moves its content to fit its size could be awful (it depends upon the application, obviously).

As a result most RISC OS Apps still use very simple designed GUI’s

Must be why they tend to be usable. :-)

Seriously, though, remember when the world ended because of Word’s new “ribbon”?

UI changes ought to be changes for increased productivity, user friendliness, usefulness. Not because “this looks cool” or everybody jumping on whatever paradigm is “de mode” right now.

developers were left to calculate all the necessary geometry logic themselves

Yeah, the Wimp could have done a lot to help, but the Wimp sort of embodies the RISC principle. Simple and small, and let the developer join the dots for themselves.

which very few rarely did because it’s really difficult.

And there already existed various libraries and bits of code that implemented panes by sticking bits of windows on top of other windows, and keeping track of when/where everything should be placed. I have software with toolbars that are implemented as panes. Why use something new when I have existing code that works (and works on all Wimp versions? (remember – the 4MiB A5000 was ‘current’ back then, so one couldn’t expect that everybody would have softloaded the nested Wimp)).

In the Tcl/Tk the geometry manager was implemented in 90’s. Why RiscOs still does not have it…

You sound surprised. RISC OS is an OS of the late 80s. That, coupled with Acorn’s “approach” to UI libraries should explain the total lack of goodies for us poor developers.

Actually, there was an ambitious project of a toolkit with various layout managers for RISC OS by Sham Gardner (some might remember his “Starboard”, a Pinboard-on-steroids tool). But it never got production-ready.

Graham Shaw did RTK which IIRC also included some layout managers, not sure about its current state. Look here for sources: http://source.riscpkg.org/websvn/listing.php?repname=RTK&path=%2Ftrunk%2F%21RTK%2Frtk%2F&#a64832bccc200accec927fa107bb1eadd