Add default Full Screen command

[hyuri]

What is the problem or limitation you are having?

Much like #796, the default Full Screen shortcut(s) is(are) missing. Toga does not send the app into Full Screen when the default platform keyboard shortcut for Full Screen is pressed. (tested on macOS)

On macOS, two shortcuts are available by default: Command + Control + F and Fn + F. On Windows and Linux, it's F11.

Describe the solution you'd like

Make the default platform keyboard shortcut for Full Screen trigger Full Screen.

Describe alternatives you've considered

None

Additional context

No response

[freakboy3742]

Makes sense. We might need to wait until #2473 is finalised before it's possible to implement this, though.

The implementation on macOS would be a menu item View > Enter Full Screen with the shortcut (Fn + F). That menu item should change text to "Exit Full Screen" when you're in full screen mode.

I don't have access to my Windows and GTK boxes right now, so I can't confirm what an appropriate menu rendition on Windows or GTK would be.

[proneon267]

It seems that on macOS, the reason for the "Enter Full Screen" menu option not being shown is because we are creating the toga command groups dynamically(i.e., only those groups are created for which we are explicitly specifying a command).

Therefore, the Group.VIEW is currently not being created for a toga app, as we are not adding any commands to the Group.VIEW group(by default like standard commands).

This is effectively preventing the system from adding standard system commands to the standard groups for a toga app. For example, if I add a dummy command to Group.VIEW:

import toga

class HelloWorld(toga.App):
    def startup(self):

        self.commands.add(toga.Command(None, text="", group=toga.Group.VIEW))

        self.main_window = toga.MainWindow(title=self.formal_name)
        self.main_window.content = toga.Box()
        self.main_window.show()

def main():
    return HelloWorld()

Then the view command group is shown correctly, along with fully functional commands, all populated by the system itself:

Unless I am missing something, I think we need to create the app menu in 2 stages:

1. Create the standard command groups
2. Then, create the standard commands

This would allow the system to populate the default command groups by its own, even when we are not explicitly specifying a command.

[freakboy3742]

@proneon267 I think you're massively overthinking things.

If you modify the Cocoa app's create_menus method to do the following:

    def create_menus(self):
        ...
        view_menu = None

        for cmd in self.interface.commands:
            if cmd.group.order > Group.VIEW.order and view_menu is None:
                view_menu = submenu_for_group(Group.VIEW, group_cache)

the view menu will always exist. Commands are processed in group order, so if you've got a command that is sorted into a group with a larger sort order than View, then the view menu must exist. If it doesn't... manually force it to be created.

[proneon267]

Indeed, I was overthinking it 😅 Thanks for the help!

[proneon267]

@freakboy3742 Another question 😁, how are the order numbers decided for the groups? Is there any specific calculation to arrive at these order numbers: https://github.com/beeware/toga/blob/main/core/src/toga/command.py#L158-L164

[freakboy3742]

A highly technical and scientific process known as "picking values that seemed like they made sense at the time" :-)

To the extent I can explain the values: App, File, Edit and View are all fairly standard menu name, and in almost every app I can find, they occur in that order - so they've got negative numbers so that they'll come before any user-selected positive value .

Command is a completely arbitrary "30" - a value that gives plenty of room before and after.

Window and Help are "bigger" numbers, again reflecting the fact that they're almost always the last two menus (and in that order).

So - as a user, you can pick any order value between 0 and 90 and you'll get a user-custom menu in a location that is fairly consistent with local platform expectations.

Are these defaults causing a problem somewhere, or is this just a request for a background explanation?

[proneon267]

Are these defaults causing a problem somewhere, or is this just a request for a background explanation?

No, I just needed an explanation. Thank you 😊

Also, regarding implementation on other platforms:

On Windows, the newer iterations of native apps like MS Paint, have a default Full Screen option in "View" Menu:

On Linux, most GTK apps don't have a default Full Screen option in their menu, but they do respond to the F11 keyboard shortcut.