✔️ FIXED BUG: Settings not scrolled properly

Eggheads talking about bytes and stuff.
Post Reply
User avatar
Krishty
Site Admin
Posts: 1271
Joined: 2022-Jan-09, 00:59

✔️ FIXED BUG: Settings not scrolled properly

Post by Krishty »

Upon first visit, the settings list will be scrolled like this:
image.png
image.png (6.13 KiB) Viewed 1758 times

But it should be scrolled like this:
image.png
image.png (8.38 KiB) Viewed 1758 times

This is a weird problem with layout, visibility, and auto-scrolling to newly-added list item.
mikew
Data Genius
Posts: 559
Joined: 2022-Jan-09, 20:21

Re: 🔴 OPEN BUG: Settings not scrolled properly

Post by mikew »

Yep, does that here as well. I wouldn't have picked up on that as a problem as I've seen much much worse with modern GUIs.
User avatar
Krishty
Site Admin
Posts: 1271
Joined: 2022-Jan-09, 00:59

Re: 🔴 OPEN BUG: Settings not scrolled properly

Post by Krishty »

Let’s aim for the best, not compare with the worst :D
User avatar
Krishty
Site Admin
Posts: 1271
Joined: 2022-Jan-09, 00:59

Re: 🔴 OPEN BUG: Settings not scrolled properly

Post by Krishty »

Here, the bug is in the concept, and those are the worst, so I’ll document the problem.

Assume you have a window with a list-view control and some text below that. The layout is dynamic, so on a phone screen it could look like this:

  ┌───────────┐
  │┌─────────┐│
  ││ Item 1  ││
  ││ Item 2  ││
  ││ Item 3  ││
  │├─────────┤│
  ││THIS IS A││
  ││VERY LONG││
  ││TEXT     ││
  │└─────────┘│
  └───────────┘


But on a wider screen (or rotated) it might look like this:

  ┌──────────────────────────┐
  │┌────────────────────────┐│
  ││ Item 1                 ││
  ││ Item 2                 ││
  ││ Item 3                 ││
  ││ Item 4                 ││
  ││ Item 5                 ││
  │├────────────────────────┤│
  ││THIS IS A VERY LONG TEXT││
  │└────────────────────────┘│
  └──────────────────────────┘


Note that we can now see five items instead of three because the text takes up less vertical space, so the list-view control can expand.

TFXplorer handles all layout dynamically because we don’t want to be fixed to a specific resolution like 800×600 (I’m looking at TAW here!).

The very important fact is: The list-view control cannot determine its size without the text control having determined its.

Now consider how this gets built:
  1. The main window (a.k.a. container) is created.
  2. The list-view control is created as the first child of the container.
  3. The text is created as the second child of the container.
  4. Now that the container has created all childs, it computes the layout.
  5. The text reports its size to the container.
  6. The list-view control reports its size to the container.
  7. Now that the container knows both sizes, it can place the list-view control and text at their final positions.
How large is the list-view when it is creatd in step 3.?

It cannot know because its size depends on the text, but the text hasn’t even been created yet. And why should we care? Everything gets resized neatly when we’re done initializing!

Now imagine the list-view control, when it is created, is intended to scroll item 4 into the visible range because that’s the default selection or whatever. (It doesn’t matter because there is always an item that breaks in some situation, be it the first or the last or really any one.)

In order to determine whether item 4 is visible – and if not, where to scroll – the list-view needs to know how tall it is. But it can’t because that depends on the text, and the text hasn’t even been created!

Now you could specify a dummy size during creation, just some number and stick to it until construction is complete and the container re-computes the final layout. But if that number is too small, the scrolling breaks for all items but the topmost one. If it is too large, the scrolling breaks for all items but the last one. The former is the case with the TFXplorer settings menu.

Now we could just defer selecting the default item until after everything has been laid out correctly. But this brings a series of caveats – list-views have to disable auto-scrolling when new items are inserted, because that’s usually done during construction. We may have a non-empty list-view without a selection, which means every user of the list-view now has to check for that special case.

The TFXplorer settings have no text below the list-view control, so why do they break anyway? Because the rules are written for all situations equally. We could code a fix by first checking if width/height of a control depends on any neighbor, and if not, set it to the final size right away. Except we now have a new special case, and it doesn’t work when the container is itself nested into something dynamic, and now the code starts doing two different things depending on some detail in the control’s parent’s parent.

All of this sucks, and I’m not yet sure what I’ll do. In TFXplorer, we usually select something at the top as default (not the topmost item, because in this specific case it’s a group caption instead of a clickable item!), so I might go with “reasonable” default sizes for windows under construction until the next thing breaks …
mikew
Data Genius
Posts: 559
Joined: 2022-Jan-09, 20:21

Re: 🔴 OPEN BUG: Settings not scrolled properly

Post by mikew »

The only way to win is not to play...

I'd suggest yoiu come back to this after implementing the dynamic campaign or anything else really. :D
User avatar
Krishty
Site Admin
Posts: 1271
Joined: 2022-Jan-09, 00:59

Re: ✔️ FIXED BUG: Settings not scrolled properly

Post by Krishty »

With the latest update it’s not 100 % fixed, but certainly good enough for now.
Post Reply