Nesting Windows

[petert]

Could someone explain or show me a picture of what "nesting" windows is/are? (Referring to SVN r17662)
Thanks.

[CommanderZ]

That is a new (=better) way to define layout of GUI boxes, but there are AFAIK no immediate user-side benefits. All windows are being converted to this standard. It is supposed to allow some advanced features like GUI scaling in future.

[Gremnon]

I can't be sure, but maybe the new difficulty settings dialog is an example? I have no idea what nested windows are either, so I'm making a stab in the dark too.

[Eddi]

no, that has nothing to do with it. the nesting is purely internal change, the user will not notice anything from these changes.

changes for the users are marked [Feature] (or occasionally [Fix] if there was an error). these nesting widget changes are marked [Codechange], so they are only relevant for patch authors and may be the base for future features.

[Alberth]

The 'old' way of defining the contents of a window is something like (just a few lines to give you an idea)

Code: Select all

/** Widget definition of the view industy gui */
static const Widget _industry_view_widgets[] = {
{   WWT_CLOSEBOX,   RESIZE_NONE,  COLOUR_CREAM,     0,    10,     0,    13, STR_BLACK_CROSS,           STR_TOOLTIP_CLOSE_WINDOW},
{    WWT_CAPTION,  RESIZE_RIGHT,  COLOUR_CREAM,    11,   247,     0,    13, STR_INDUSTRY_VIEW_CAPTION, STR_TOOLTIP_WINDOW_TITLE_DRAG_THIS},
{  WWT_STICKYBOX,     RESIZE_LR,  COLOUR_CREAM,   248,   259,     0,    13, 0x0,                       STR_TOOLTIP_STICKY},
{      WWT_PANEL,     RESIZE_RB,  COLOUR_CREAM,     0,   259,    14,   105, 0x0,                       STR_NULL},
{      WWT_INSET,     RESIZE_RB,  COLOUR_CREAM,     2,   257,    16,   103, 0x0,                       STR_NULL},

This are the first few widgets (=elements you see in a window) of the 'view industry' window.
The WWT_CLOSEBOX is the 'x' element at the top-left. You can see its colour, and its coordinates (horizontally from 0..10, vertically from 0..13). (all coordinates start from the top-left of a window).
The WWT_CAPTION is the title bar. You can see it is immediately at the right of the close box (it starts at 11), is equally high (from 0..13), and runs up to 247 horizontally. The 'STR_INDUSTRY_VIEW_CAPTION' is the text being printed in the title bar. The last entries (STR_TOOLTIP_* entries) are the texts of the tooltips.

In this way, all 117 or so windows were defined.
Due to the hard-coded positions, making a widget larger or smaller by hand is a lot of work. Doing it automatically (eg because you want to use a bigger or smaller font) is impossible.
The same happens with translations. Different languages use different wording for describing an action, yet they all had the same amount of available space in a button.
Naturally, this does not work, and if you search in fly spray you will find several reports of cases where it fails.

Hierarchical widgets (also known as nested widgets) tries to improve this situation (amongst others).
The above is in nested widgets something like (again, just a few lines)

Code: Select all

static const NWidgetPart _nested_industry_view_widgets[] = {
	NWidget(NWID_HORIZONTAL),
		NWidget(WWT_CLOSEBOX, COLOUR_CREAM, IVW_CLOSEBOX),
		NWidget(WWT_CAPTION, COLOUR_CREAM, IVW_CAPTION), SetDataTip(STR_INDUSTRY_VIEW_CAPTION, STR_TOOLTIP_WINDOW_TITLE_DRAG_THIS),
		NWidget(WWT_STICKYBOX, COLOUR_CREAM, IVW_STICKY),
	EndContainer(),
	NWidget(WWT_PANEL, COLOUR_CREAM, IVW_BACKGROUND),
            ....

Again you can see the close-box, caption, and sticky-box listed, but there are no coordinates! (there were, but they are not needed so I removed them ).
Instead, they are all indented into a container called NWID_HORIZONTAL. Basically, it says 'take these widgets, and line them up from left to right'. In this way you get some elements lined up horizontally or vertically in a container (look at a window, and you will notice that all is lined up nicely horizontally, vertically, or both). Such a container with elements can be seen as a (more complicated) window element (a 'window header' element in this case), so you can use it in yet another container, etc. In that way you get containers in containers in containers ...., down to the elements you see at the screen.
Due to this nested structure, the name of the new way is called 'nested widgets'.

As you can see, there are no hard-coded coordinates, these are calculated by the computer instead. Secondly, each element (for example, the title caption) knows its own contents, and uses that to compute its size. So if you set a bigger font size, the title bar will automatically get bigger. If you switch to a language that uses a longer wording at a button, that button will become longer. The other widgets around it will also adapt to the new size.

This is one of the benefits we hope to achieve with the conversion. If you pay really good attention you can see changes here and there in the nightlies, but they happen rarely, and are very small, at most in the order of a few pixels if you play with the english UK strings.

[belugas]

And if I may add, http://www.tt-forums.net/viewtopic.php?f=31&t=45054 could very well be on of the impacts the new system has on the game.
Remember, it's all for the best! Not to annoy people

[petert]

Ok, I understand.

It's sounds sort of like a way to remove/change some extra code.

[Alberth]

My overview file says:

Code: Select all

_land_info_widgets:			done (r17324)
_build_rail_widgets:				done
_nested_main_window_widgets:	done
_toolb_normal_widgets:			STILL ORIGINAL

Ie the land information window is, the rail build toolbar is, the background is, main toolbar is not.

Since the functionality does not change, there is little code that can be removed. Instead, it increases slightly, since the machine now does coordinate and size calculations which it didn't do before.


Edit: the main toolbar is not, only because we didn't come to converting it yet.

[petert]

Sorry if I wasn't clear enough, I only meant the Land Information window.
Thanks.

[SirkoZ]

How many % is this new method more CPU intensive? Do you have any data on this, Alberth?

[Rubidium]

How many % is this new method more CPU intensive? Do you have any data on this, Alberth?

Although I'm not Alberth: it depends on how you measure it. If you're comparing purely copying a few hundred bytes versus building a nested window then it'll probably be several magnitudes slower, resizing maybe up to a factor 2 and for drawing it's negligable because most time is spent in the actual drawing. Then if you take a look in the grand picture it's unnoticable to the player.

So it's definitely slower, but... it will, in the end, support larger fonts, all translations without overflowing widgets/windows, ... However, the extra time is mostly for resizing and initial window creation, which means it's negligable in the big picture.

[SirkoZ]

I see. Thank you for such a good explanation, Rubidium.

I only asked Alberth since it was initially his project and perhaps he has had the most experience with it.

[Roujin]

Albert, could you tell us (roughly) which percentage of windows in your handy overview file have which status?

Thanks in advance

[Alberth]

Last count had 65 of the 120 widget arrays converted.
For details, see: http://devs.openttd.org/~alberth/nested ... status.txt

[Roujin]

Code: Select all

(svn r18092) -Codechange: remove support for the unnested widgets

Congratulations to the devs for finishing the switch of all windows to the new system
hurray for full support of differing fonts and internationalisation in 0.8 (?)

[petert]

Good job. I've noticed in the nightlies that when I open the multiplayer server window, it automatically resizes to fill the whole screen, is this part of nesting widgets/windows?

[Alberth]

Congratulations to the devs for finishing the switch of all windows to the new system
hurray for full support of differing fonts and internationalisation in 0.8 (?)

The switch was only the preliminary step, actually adding such support is the next step (which is hopefully smaller than the switch ).

@petert: I noticed that too, today. Why that change was made, I don't know.
Strictly speaking, that change was not part of the nested widget conversion since the latter aims to replace the widget system without changing the user interaction of the windows. On the other hand, of course the new widget system was used, since as of r18092, OpenTTD only has one such system

[Roujin]

I know that changing the windows to the new system does not magically make it all different-fonts-and-textlengths-compatible..
But at least you've got the annoying part with a lot of work for (optimally) no visual difference behind you now

I'm already seeing a whole of bunch of fixes/improvement commits done today after 18092, seems you guys're motivated that the only-change-stuff-to-the-new-system part is over and you're can finally change/improve some things now

[Alberth]

But at least you've got the annoying part with a lot of work for (optimally) no visual difference behind you now

I didn't find that annoying, in fact it made the change simpler.

I am more reading and changing code than looking at the screen, and there, major shuffles took place all the time. So in my experience, the GUI code was making big movements all the time It was in code that had been unchanged for years, and all that without breaking the existing program (another thing I had never done, a quite interesting experience).

Not making changes visually made it easier in the sense that I had a fixed reference to test against (ie I was done with a window if all code was changed and the front interface look the same down to the exact pixel, and functioned the same, except for a change here and there that was intentional).

Not all windows came out exactly as wanted, so those need a little more care.
However, after r18091, I took the rest of the day off

I'm already seeing a whole of bunch of fixes/improvement commits done today after 18092, seems you guys're motivated that the only-change-stuff-to-the-new-system part is over and you're can finally change/improve some things now

Yeah, a few fellow devs are having a good commit count today

[Expresso]

One more question: do the nested widgets also support widgets which have optional animations? This could be useful for widgets which show an animation when the mouse-pointer hovers over them.