[Bug 1.4.1.7] input() Whitespace when using Tabs

[aliasmask]

This has probably always existed, but I have an excessive number of tabs and when playing around the formatting I noticed the whitespace at the bottom got bigger when my tab menu got bigger. They seem to be the same size.

So, the white space below the input data is the same amount of space taken up by the tab menu. So, if you have a thin menu and a lot of tabs then you can't access the okay/cancel buttons at the bottom.

[wolph42]

Hi Alias, it seems you're really guarding the fort here I've been too busy with side projects (IoT related) to also be here regularly. anyway I've passed this on to the devs who are more active on discord.

[Azhrei]

This has probably always existed, but I have an excessive number of tabs and when playing around the formatting I noticed the whitespace at the bottom got bigger when my tab menu got bigger. They seem to be the same size.

So, the white space below the input data is the same amount of space taken up by the tab menu. So, if you have a thin menu and a lot of tabs then you can't access the okay/cancel buttons at the bottom.

Hm. So are you talking about tabs in the UI of MT, such as JIDE lockable panels, or are you referring to tabs as a result of the input function?

For the former, I don't think there will be anything we can do about it; the JID library handles all rendering of the panel decorations (like close buttons and such).

For the latter, we might be able to do something about it, depending on what it turns out to be. It could be that the HTML rendering library has a glitch (wouldn't be the first ). MT 1417 is using Java 9 and the newer HTML library, which is using CSS to control rendering of components. Maybe there's some CSS that was added to the stylesheet for input in order to work around a bug in the old HTML library, and now that same CSS is messing up the newer library.

Can you provide some clarity — and some small screenshots of the relevant portions of the screen — concerning the exact issue? Thanks.

[aliasmask]

Maybe this will help clarify.

[Azhrei]

Thanks, alias. I've added issue 198 to track this.

Based on your screenshot, it's probably not CSS; there's not a builtin way to tell CSS to make the bottom spacing the same as the height of another element (web sites use JavaScript to do it).

[Merudo]

Posting the macro code generating the issues above would be helpful.

[aliasmask]

Code: Select all

[H: input("tab|tab|tab|tab","label|A really wide label to show how the bottom space changes.|tab|label",
"tab|tab|tab|tab",
"tab|tab|tab|tab",
"tab|tab|tab|tab",
"tab|tab|tab|tab",
"tab|tab|tab|tab",
"tab|tab|tab|tab",
"tab|tab|tab|tab",
"tab|tab|tab|tab",
"tab|tab|tab|tab",
"tab|tab|tab|tab",
"tab|tab|tab|tab",
"tab|tab|tab|tab",
"tab|tab|tab|tab",
"tab|tab|tab|tab",
"tab|tab|tab|tab",
"tab|tab|tab|tab",
"tab|tab|tab|tab",
"tab|tab|tab|tab",
"tab|tab|tab|tab",
"tab|tab|tab|tab"
)]

[Merudo]

I did some tests and I believe the code doesn't take into account that multiple tabs can appears in one row.

The code acts as if every single tab was suppose to form a single column. So if you have 20 tabs, your input window will have enough height to accommodate 20 lines of tabs, even if you only need a few lines because multiple tabs appear by row.

In the example you posted, this can be shown by reducing/extending the label - you'll notice the total height of the window stays constant. And if you remove the label, everything will be in a single column, and the window height will fit its content perfectly.

[emmebi]

This should have been fixed in PR https://github.com/RPTools/maptool/pull/1289 and should go in 1.6.0 once it is out.