search

Helion-Engine / Helion

A modern fast paced Doom FPS engine
GNU General Public License v3.0
122 stars 10 forks source link

Implement list and file browser dialogs; use file browser to select SoundFonts #603

Closed lemming104 closed 2 months ago

lemming104 commented 2 months ago

In this change, I am adding an abstract class that provides "list dialog" functionality. A derived class populates the backing list, and handles selection changes to ensure that the correct data is returned when the user selects OK. The derived class can also draw a header above the list.

The list functionality itself includes item selection and highlighting, scrolling (if needed), and should be navigable with either mouse or keyboard. As in the other options menus, there is a scroll bar provided as a visual cue only (the user cannot directly interact with it).

I have created one derived class that acts as a file browser for selecting SoundFonts. File names are displayed directly, directories are enclosed in square brackets. If using the mouse, clicking on a directory name will automatically browse to that directory.

I designed the class hierarchy this way so that we could also write a picker for things like the HUD background tile in the future. I don't know what the backing store for that is, or how to get a valid list of strings out of it, because I haven't looked at it yet. Since I have provided a facility to write a header at the top of the list control, there could even be a little preview up there or something.

Please feel free to give me feedback or propose code changes before merging this, as I realize this is a relatively large change in terms of lines of code, although the functional impact is (thankfully) contained.

nstlaurent commented 2 months ago

This looks good. My only suggestion for now is to add a blinking cursor like the console for the text. I accidentally stumbled on realizing I could type there. :)

lemming104 commented 2 months ago

I added a blinking underscore to the end of the path as a visual cue.

I also made some changes to ensure that these dialogs (at least the message box and list dialog types) don't recompute a bunch of string splits or truncations on each frame, but still redo these calculations when they need to (when the box size changes because the user resized the game window--as far as I know, this is the only "resize" likely to happen when a dialog is already up). That way, we shouldn't burn a bunch of unneeded CPU or churn memory just to render a menu.