Window Title Bar and Menus

[JohnDog3112]

As we talked about, I've been doing some research on how different programs/operating systems handle the title bar for a window. Here's what I have found so far:

Windows

2 main approaches:

• simple:
  • Icon, title bar, and colors can be changed
• extended:
  • The draw area for the window is expanded to include the title bar
  • Space is reserved for the icon in the top left and close/minimize/maximize buttons in the top right
  • The program sets a drag area that a user can click on to drag the window around
  • The program sets "interactive" areas in the drag area to add exceptions and to get user interaction
• both:
  • In both cases, the application is responsible for drawing and handling any menus it wants to provide. For the simple approach, the menus might be below the title bar while the extended one allows them to be part of it.
  • Windows does provide some builtin frameworks/libraries for this however such as:
    • Win32 API
      • text (buttons), seperaters, checkboxes, radio items, submenus, owner-drawn items (items drawn by the application itself)
    • Microsoft Foundation Classes (MFC)
      • Seems to be an abstraction over the Win32 API
      • In addition, it seems to emphasize defining that majority of the menu structure and layout in a menu resource file (.rc)

MacOS

• Menu is at the very top of the screen; icon, caption, close/minimize on window
• The menu seems to use a widget like system
  • From what I can find, it seems like a limited(?) widget system
  • Main elements:
    • Menus, submenus, buttons, check boxes, radio (select 1 from group)
  • example:
    • On macos, vscode seems to place the search bar at the top of the window rather than with the rest of the buttons like file, edit, selection, etc. that are placed at the menu bar at the top left of the screen.

Electron

• Seems to use a very similar system to MacOS and will adapt it to the two methods talked about above depending on the OS it is running on.
• Available types:
  • normal, separator, submenu, checkbox or radio (select 1 from group)

Amiga

• Menus are part of the application title bar, but are hidden until right clicked by default
• Seems to use a similar system to MacOs and Electron:
  • Text (buttons), submenus, seperators
    • checkboxes and radio elements can be simulated by adding characters like [X] and [ ] that are appended to the front of the button text and changed when clicked.

twr-wasm implementation

• I believe it would be better to do one of the simpler options like how MacOS, Electron, Amiga, and the Win32 API do it rather than windows full system for the extended title bar.
• As for the placement of the menu bars, I think it depends on the "supported" targets. For instance, if the only target is desktops I think having them as part of the title bar would work just fine. However, if devices like tablets or phones were included, it might be better to hide it like Amiga or have it centralized at the top like MacOS.
• keyboard shortcuts:
  • I didn't really talk about this above, but it seems like Windows, MacOS, and Electron call keyboard shortcuts accelerators. From what I can find, it seems like they have general functions for setting up shortcuts, but some menu APIs allow you to attach shortcuts directly to menu items.
  • I believe both should be implemented where the menu API simply uses the underlying shortcut registration function.

[JohnDog3112]

For defining the menus, there seems to be two main approaches. In the first one you create each item as a series of objects and bind them to their Parent like a submenu or the main menu bar. The other method is defining a representative structure like JSON or similar that the API parses and converts into the above.

I'm not quite sure how to do the first method however. The main problem I see comes from how one might delete an item.

My first idea was to make every widget a console that extends basic functionality like changing text, callbacks, etc. to reduce repeated code. However, one problem is that every library/console is registered via twrLibraryInstanceRegistry and as of now there is no true way to completely free an element. Though, thinking about it, this applies to Windows as well, so when we want to be able to open/close windows the sub-canvas it uses to allow the application/user to draw with can never truly be freed. I'll open up an issue for that discussing what to do about it and link it back here later.

The second idea would be to just embed all the functionality with custom id's in the window itself. Either the above or this method would work about the same for the end user assuming the right format was used.

However, both ideas suffer from the same common problem: does it need to support a single window being controlled by two separate WASM apps? The idea is that for a single WASM interface, you could store the button under an ID (or console) in the window class and then also assign it to a menu. So, to delete, you first remove it from the menu and then from the window. However, this runs into issues when another WASM program might be interfacing with it. Though, maybe this doesn't matter much since this shouldn't happen unless the programs were made with eachother in mind.

I think the main approach would be to just assume that any WASM applications sharing a window are aware of each other. Though, it might be good to add functions to check if an ID still exists.

For now, I'm thinking of the following for a menu widget system talked about above:

• all widgets are registered through the window console
• each widget is given a unique id and there are helper functions in C that generate structs with both the window console and the widget id so you can just pass the struct around
• Widgets are created and then attached to a parent
• for deletion I have two ideas
  • Must be removed from any parents before being deleted (easy to design, harder to work with for the user)
  • A widget keeps track of the parents it's been attached to and automatically removes itself upon deletion (harder to design and involves circular references, easier for the user)

[JohnDog3112]

I've been doing some prototyping with the widget system. I would like to revise the above system with the following:

• Widgets are created and registered with their direct parent
  • Thinking about it more, there are plenty of cases where a widget might need to talk to a widget managing it. For instance, a menu that closes when you're no longer hovering over it. In this case, it's important that it has exactly 1 parent which constructing with the parent ensures.
  • In addition, it looks like while Amiga Intuition does the old method I mentioned, they also caused issues if you assigned the same widget to two places at once.
• With the above change, deletion also becomes easier since it can just remove it's direct parent. Additionally, it allows the deletion of a "menu" to also delete all of it's child objects since there's a direct connection.

[JohnDog3112]

Here's a diagram of how the approach I'm currently prototyping works:

classDiagram
    class Widget{
        parent: WidgetManager
        id
        requiredEvents
        getMinSize(ctx)
        render(ctx, offsetX, offsetY)
        handleEvent(event)
        getDimensions(): [x, y, width, height]
        setDimensions(ctx, x?, y?, width?, height?)
    }

    class WidgetManager {
        childUpdated(ctx, widget?, sendToRoot?)
        addChild(ctx, widget)
        openPopup(ctx, widget)
        closePopup(ctx, widget)
    }

    class Button {
        addEvent(callback)
        removeEvent(callback)
    }
    Widget <|-- Button

    class Menu {

    }
    Widget <|-- Menu
    WidgetManager <|-- Menu

    class MenuButton {

    }
    Button <|-- MenuButton
    Menu <|-- MenuButton

    class Text {

    }
    Widget <|-- Text

    class CheckBox {

    }
    Widget <|-- CheckBox

Loading

The idea is that it's broken down into Widget classes that can somewhat handle themselves. In addition, the WidgetManager interface allows widgets like a Menu to handle child widgets. Then, the popup function allows a widget to be temporarily opened. The last main thing to note is that a class like MenuButton can simply be a widget that wraps around a button and menu. That way, when it's internal button is clicked, it can open the menu via openPopup.

[JohnDog3112]

This was mostly designed with the idea that this could be extended to make a full widget system/library. Then, the menus could just use a subset of it.