Proposed changes for SDL2

[backwardsEric]

A draft of changes to the SDL2 front end is up at https://github.com/angband/angband/pull/5804 . The main intent of those changes is to allow adding more complicated dialogs (namely a font selection dialog like the SDL front end has). It also changes the rendering of the menus in ways that I thought would make the interface easier to use: toggleable items now have a small filled rectangle drawn next to them when on rather than changing the color of the label, and the item with focus is outlined with a thin rectangle rather than changing the background color. Screen shots before and after the changes are at https://github.com/angband/angband/pull/5804 . The menus should also be navigable with the keyboard (the Angband keys for up/down/left/right should work as does tab (next item), shift-tab (previous item), enter (default action for the current control), and escape (dismiss the menu)). The font size and tile size entries in the menus should respond to mouse wheel events.

If you care about the SDL2 front end, I'd appreciate your thoughts on these changes either here or on the pull request at GitHub. If you are comfortable compiling the code, I'd also appreciate it if you compile the changes and test the new version on the hardware you have. The source code is available in the sdl2-dialogs branch of https://github.com/backwardsEric/angband . If you do test the new version, you should make a backup copy of your current sdl2init.txt since these changes add entries to that file, and the newly generated file won't be readable, without editing it to remove the new entries, in previous versions.

[Sacksquatch]

I'm not slick enough with github to clone the code from a PR that hasn't been accepted yet without manually making the changes. Though there is a functionality of sdl2 I'd like to see preserved.

In sdl you need to click the font box. Select the font from the dialog. The dialog closes. If you want another font, repeat. The dialog closing each time makes it a bit tedious to get that right font for each window.

In sdl2 the dialog stays open and you can continue to select fonts one after the other and see what they look like. Then close the dialog when you're done.

The dialog staying open is handy as you don't have to re-open the dialog box every time. Especially when you're messing with tiles and trying to get that 'just right' resolution.

As for the changes in color and the rectangle. Dats otay by me. Also menu navigation by keyboard sounds kickass.

[backwardsEric]

In sdl you need to click the font box. Select the font from the dialog. The dialog closes. If you want another font, repeat. The dialog closing each time makes it a bit tedious to get that right font for each window.

The mechanics of selecting a font will remain much the same as with the current SDL2 front end: a pull down menu (or nested pull down menus if there isn't enough vertical space to hold all in one) to select a font from those in the lib/fonts directory. The dialog I mentioned in my earlier post would be for selecting a font from outside the lib/fonts directory. If one did that, altering the size would be done with Menu->Font->Size as is used for the standard fonts.

[Ituirth]

Hello, I compiled on Debian 12, sdl2 (v2.26.5)
'main-sdl2.c' (+ sdl2 pui_) code

spaces in https://github.com/angband/angband/b...n-sdl2.c#L2546

1. 'ttf' font doesn't work 'Size' (- points +) button https://github.com/angband/angband/b...n-sdl2.c#L2471

2. subwindows are attached to each other and in order for them to come unstuck I need to move the mouse very hard.

3. problem with Event buffer
'Move' button, I click to move subwindow, after 1-2 seconds it starts moving.
and delay for clicking on ui buttons
I think it's something in the event buffer
fixed by adding SDL_FlushEvent(SDL_MOUSEMOTION); https://github.com/angband/angband/b...n-sdl2.c#L3359

handle_mousemotion() {
.....
/* dont need other mousemotion events */
SDL_FlushEvent(SDL_MOUSEMOTION);
return false;
}

I added and it worked well without delays

look at SDL_FlushEvent()
there is one more in the code

do_status_bar_loop()
if (event.type == SDL_MOUSEMOTION) {
/* annoying mousemotion spam! */
SDL_FlushEvent(SDL_MOUSEMOTION);
}

-> https://github.com/angband/angband/b...n-sdl2.c#L3348
-> https://github.com/angband/angband/b...n-sdl2.c#L3376

[backwardsEric]

For the queued mouse motion events, rather than calling SDL_FlushEvent(SDL_MOUSEMOTION) does the change below to the start of handle_mousemotion() in main-sdl2.c solve the delay for you?

static bool handle_mousemotion(struct my_app *a, const SDL_MouseMotionEvent *mouse)
{
        struct sdlpui_dialog *d;
        SDL_Event pendm[4];

        if (!a->w_mouse) {
                return false;
        }

        /*
         * If more than one consecutive motion event is queued, only process
         * the last one.
         */
        while (1) {
                int npend = SDL_PeepEvents(pendm,
                        (int)(sizeof(pendm) / sizeof(pendm[0])),
                        SDL_PEEKEVENT, SDL_MOUSEMOTION, SDL_MOUSEMOTION);

                if (npend <= 0) {
                        if (npend < 0) {
                                SDL_LogError(SDL_LOG_CATEGORY_APPLICATION,
                                        "SDL_PeepEvents() for pending motion "
                                        "events failed: %s", SDL_GetError());
                        }
                        break;
                }

                for (; npend; --npend) {
                        int gote = SDL_PollEvent(&pendm[0]);

                        if (!gote) {
                                SDL_assert(0)
                       }

                        SDL_assert(pendm[0].type == SDL_MOUSEMOTION);
                }

                mouse = &pendm[0].motion;
        }

[Ituirth]

Yes it worked without delay. I added your fix to top handle_mousemotion() code, and subwindows (attache/detache) moved correctly.
but an error window appeared. quickly pressing arrow keys and move mouse

Assertion failure at handle_mousemotion (main-sdl2.c:3309), triggered 1 time:
'pendm[0].type == SDL_MOUSEMOTION'

L3309  SDL_assert(pendm[0].type == SDL_MOUSEMOTION);

[backwardsEric]

Hopefully the altered version below avoids that assertion failure:

static bool handle_mousemotion(struct my_app *a,
                const SDL_MouseMotionEvent *mouse)
{
        struct sdlpui_dialog *d;
        SDL_Event pendm[4];

        if (!a->w_mouse) {
                return false;
        }

        /*
         * If more than one consecutive motion event is queued, only process
         * the last one.
         */
        while (1) {
                int npend = SDL_PeepEvents(pendm,
                        (int)(sizeof(pendm) / sizeof(pendm[0])),
                        SDL_GETEVENT, SDL_MOUSEMOTION, SDL_MOUSEMOTION);

                if (npend <= 0) {
                        if (npend < 0) {
                                SDL_LogError(SDL_LOG_CATEGORY_APPLICATION,
                                        "SDL_PeepEvents() for pending motion "
                                        "events failed: %s", SDL_GetError());
                        }
                        break;
                }

                SDL_assert(npend <= (int)(sizeof(pendm) / sizeof(pendm[0]))
                        && pendm[npend - 1].type == SDL_MOUSEMOTION);
                mouse = &pendm[npend - 1].motion;
        }

[Ituirth]

checked, code works fine

[backwardsEric]

The changes in the original post were incorporated in the post 4.2.5 builds from 4.2.5-65-gd68863680 on. Further modifications to address the delays handling mouse motion and the disabled menu entry for changing a TTF font's size are in builds from 4.2.5-79-g518ecde11 on. Those are available at https://github.com/angband/angband/releases .

[tangar]

Great, thanks guys! These changed ported to PWMA/Tangaria and we are testing them

I wonder, is it possible to hide red frame around main screen? I always play with overlapping windows as it gives more view. previously there wasn't any red outline. Screenshot:

https://cdn.discordapp.com/attachments/535396965433868288/1194615746869874698/image.png

[backwardsEric]

I wonder, is it possible to hide red frame around main screen? I always play with overlapping windows as it gives more view. previously there wasn't any red outline. Screenshot:
https://cdn.discordapp.com/attachmen...4698/image.png

The red border indicates that the subwindow does not fit in the bounds of the containing window. I'd guess that after the changes in the original post the window's menu bar is slightly taller than it was before and now overlaps with the subwindow. Resizing the whole window (via whatever controls your desktop environment gives you) should coerce all the subwindows to fit in the new bounds. Another way would be to move that specific subwindow downward until it the top border no longer overlaps with the menu bar.

[Ituirth]

if the subwindow becomes red, it cannot be moved or resized. the buttons are locked 'Move', 'Size'.
and I accidentally made the entire window small it caused an error
Fatal Error: Window is too narrow for menu bar

angband: main-sdl2.c:5007: adjust_status_bar_geometry: Assertion `mw <= window->full_rect.w' failed.

then the game won't start

angband: main-sdl2.c:6376: free_globals: Assertion `!a->subwindows[i].inited' failed.

to start the game again I had to delete 'sdl2init.txt'
checked the previous code, the window can be made minimal and there is no error

[tangar]

The red border indicates that the subwindow does not fit in the bounds of the containing window. I'd guess that after the changes in the original post the window's menu bar is slightly taller than it was before and now overlaps with the subwindow. Resizing the whole window (via whatever controls your desktop environment gives you) should coerce all the subwindows to fit in the new bounds. Another way would be to move that specific subwindow downward until it the top border no longer overlaps with the menu bar.

Nope... I mean:

I always play with overlapping windows as it gives more view. previously there wasn't any red outline

so previously it looked like:
https://www.youtube.com/watch?v=lY2Ivd2KTU4 (no red border even though windows were overlapping).

with new changes in SDL2 now it has red border.. which makes impossible to have previous nice layout with the most efficient subwindow position this red border makes UI ugly.

so.. is it possible to hide red frame around main screen? maybe add an option for it?

[tangar]

ok, this worked: subwindow-full-rect:0:0:19:1920:952 -> subwindow-full-rect:0:0:30:1920:952

hm... half of a line in text messages doesn't fit cut in half. screenshot:

https://cdn.discordapp.com/attachments/535396965433868288/1194698161193750658/image.png

seems new SDL2 window now has bigger borders or padding.. so half of a line cutted in msg window. Previously there were 4 lines:

https://www.youtube.com/watch?v=lY2Ivd2KTU4

now 3.5

I suppose best solution will be possibility to hide menu (after initial setup you do not need it really) - it will give possibility to have more space which is critical on small screens (eg I play on 15'')... As it is quite advanced feature - it could be a config file options (sdl2init.txt).

So /rfe
please add sdl2init.txt option to hide menu (this way there will be more "useful" space on the screen)

[backwardsEric]

ok, this worked: subwindow-full-rect:0:0:19:1920:952 -> subwindow-full-rect:0:0:30:1920:952

Changing the third value there changes the y coordinate for the upper left corner. Since you increased that by 11, if you decreased the last value, 952 which is the height, by 11 you would get the same amount of overlap with what's below as you had before (though you will lose some space in the map display). Also, did you try any value for the start coordinate between 19 and 30? From your screenshot, it looks like there's blank space between the menu bar and the start of the main subwindow, so I suspect that something like 22 or 23 for the start (and therefore 949 or 948 for the height) would work without resulting in the red border.