Add support for tool panels

[MuhammadMuradG]

Suppose we have a dozen of commands, like what is found in text editor app and image manipulation app, putting all of them in one view will make a user interface very complex or putting them in menus will make the accessing is uncomfortable for the user. What do you think about best way to handling these commands in Toga?

[saroad2]

If you ask me, menus and submenus are the right way to go. We recently added submenus in #1083, so you can start using them right away 😄 .

[MuhammadMuradG]

Don't you think using sub-menus will also make accessing is uncomfortable? For example, suppose you need to crop rectangle shape from an image, what you will do? First, you will go to Edit menu then Crop sub-menu and finally choose Rect option from sub-menu. Isn't this uncomfortable?

What about putting these commands in tabs for example to ease of access?

[freakboy3742]

I think you're going to have to give us an example (like a screenshot) of what you've got in mind, because I can't think of any GUI design that could be described "Commands in tabs".

As for whether having commands in menus will be onerous - IDEs can have hundreds of commands, and they're all in menus. They also have keyboard shortcuts, so you don't have to navigate the menus unless you're trying to work out what you want to do, or you're not familiar with the GUI. Your example of "Edit then crop then rect"... sounds like the UI of every image processing tool I've ever used.

[MuhammadMuradG]

Well, following is what I have in mind

Also, HIG Design principles have a nice formulation of what I mean in section Use progressive disclosure to show controls when they are needed. Isn't Toga toolbar always show commands even if not needed?

[MuhammadMuradG]

I think we can provide the two themes to comply with the goal of the application, so if you are build for example a IDEs the menus and sub-menus and fixed toolbar will be the good principle but if you are build for example a text editor like MS Word the tabs will be a good principle.

What do you think? Or am I missing something?

[freakboy3742]

Ah - you're talking about the ribbon. That's an extremely Microsoft-specific control; there's no analog of the ribbon on any other platform that I'm aware of.

However, AFAICT, this is a perfect example of why Toga defines Commands, rather than "menus". Although Microsoft uses a unique visualization for its "menus" that is unlike macOS and Linux, it is fundamentally exposing the same thing - there are "things" that can be done, and they are available in the GUI to be navigated. Windows has a unique way to visually represent that idea - but the core idea of "show the user the commands that are available" is the same.

This also maps onto the structure that we've already got in place for Toga Commands. Your screenshot shows a Pages command group currently selected; it contains sections named Tools, Navigation, Page Marks, etc. The Tools section contains 3 commands (Hand, Select Text, Object Select). Navigation > Bookmarks is a subgroup that contains commands.

There are also "app level" commands (the commands above the ribbon) for File open, Save, Print, Email, and undo/redo.

The only thing I can see that is currently missing is the ability to name the sections; currently a section is an integer, but we could add a "Section" object without too much trouble.

So - if you want to work out how to use the ribbon instead of traditional menus - I'd be completely on board with that.

What I wouldn't support is a "theme" - because that "theme" would only have an interpretation on Windows. The Windows HIG describes the ribbon as the way to access app functionality. There would be no meaningful interpretation of that "theme" on any other platform, so it would be a setting that exists purely for the benefit of Windows apps - and, speaking as a non-Windows user... I would have no idea when it would be appropriate for an app to use one or the other. Unless you're able to find a higher level abstraction of when you need to use menus vs the ribbon (e.g., maybe single window apps use a menu, Document-based apps use a ribbon?), we need to pick one and use it.

[MuhammadMuradG]

I am very grateful for your clarification.

Now I think defining toga Command really was an excellent choice. But, I think there is some missing features that made me asking the previous question. Is current implementation enable me to use toggle buttons or radio buttons or enable me for example to chose the pen color from list of colors rather than current implementation that only use button to call a function? Is this features are really needed or we can replace them using current toga Command implementation by a way that I missed?

[freakboy3742]

You're correct that we don't currently support checkbox/toggle menu items; I'd definitely consider that a feature we could add. I'd imagine both of those would be new Command subclasses.

If you're planning to look at this problem, it would be worth looking into #1096 - that's to PR to add "recent files" as a menu item, and highlights how a "command" can be a quite rich concept, not just a "single item invoking function".

[MuhammadMuradG]

When I proceeded to implement this, I thought why we don't allow the user to add any available toga widget rather than restricting him to a number of options (checkbox/toggle menu items). In Gtk for example you can use Gtk.ToolItem() tp add to the toolbar any Gtk widget. @freakboy3742 What do you think?

[freakboy3742]

I can't say I'm convinced. Menus/Toolbars are not widgets by design - they're manifestations of Commands. This gives us the flexibility to expose those commands in ways that are platform appropriate.

If you want to convince me, you'll need to give examples of how this capability is used in practice, in apps that are following the platform's HIG.

[MuhammadMuradG]

I am only trying to make Toga mature and ready in long-term needs to deal with complex apps and the previous comments were my tries to do this.

To put you in what I'm countering, currently I am trying to design an application using Toga, everything are going well but I have counter a problem of putting the tools that I will be used in this application (this app like Photoshop), these tools will be many and will be used extensively so I need to provide accessing to them in easy way. The keyboard shortcuts option was very nice but these tools are many and differ in each application view and remembering shortcut for every tool will be onerous to new user and to attract users from other similar apps. So, I decided to provide accessing to these tools using attractive GUI. My initial thought was ribbon and as I understood toga Commands is an idea to replace Microsoft-specific control ribbon to have meaning with other platforms. The second thought was providing these tools in toga Commands but as I understood from your explain Commands are not designed to handle widgets (like scroll container that handle colors list or fonts list) which are important to user for customizing the tools.

Now, What do you think about handling these tools? Am I missed something in designing my application? What do you think about providing ToolBox widget? I'm really very sorry for you if I missed again something you are clarified before, and thanks in advanced for your clarification.

PS: All application, like Photoshop, Blender and others, that use many tools provide a space in the application without dispensing to menu-bar to ease access of these tools using mouse and dispensing this feature will condemn the app to death before it starts.

[freakboy3742]

So - it sounds like what you're describing here is a "tool palette", or something like that - a (possibly standalone) window (or windows) that contains dozens of icons, and sometimes other widgets. For example, here's Pixelmator on macOS (A Photoshop-like image editing app):

The main document window has a toolbar, with some icons controlling overlay, color choice, and so on. But there are multiple other dialogs - most notably, the "Tools" dialog, that contains dozens of buttons, each of which controls the currently active tool.

On macOS, these are an entirely different class of window, called a Panel. The have a distinct thinner titlebar, and they generally aren't minimizable. When the app loses focus, these panels disappear.

I know GTK has a GtkToolPalette, but I'm not 100% sure how that widget should be included in an overall app structure; looking at screenshots of GIMP, preference is to include these panels "in window" as toolbar-like structures. I definitely don't know Windows HIG guidelines, but screenshots of Photoshop seem to match GIMP.

So - I'd argue that what you're talking about isn't about trying to make menus or toolbars more effective, or about building apps with hundreds of commands - it's about building tool panels (or some similar name), which is a whole new way to expose functionality. On Windows/GTK, these might end up being implemented with toolbar APIs - but to my mind, they're a distinct organisational element within an app.

[MuhammadMuradG]

That's correct, I'm trying to find a way that handles hundreds of tools in an easy use way for user.

Following is the summary of what this discussion conclude, for developers and contributors:

1. We need to add checkbox/toggle features to menu items and commands.
2. We need a name proposal for tool panels current names suggested are: ToolPanel and ToolBox.
3. We need an API proposal for this tool panel

@freakboy3742 Please, confirm this if accepted.

[freakboy3742]

Re 1: Agreed that we need a "Toggle Command" or similar; Ideally, that command would be tied to a ValueSource (which may be the trigger to finally get ValueSource working and used in more places).

An interesting macOS artefact - there's two "styles" of toggle menu item; there's menu items that have a checkmark next to them:

and there are menu items whose text changes as the item is toggled:

Based on the macOS HIG, checkboxes are used for "feature that might be enabled"; changing titles are used for "show/hide" on GUI features. Again, I'm not 100% sure on how that distinction manifests on GTK or Windows, but we should be HIG compliant - and that might mean 2 "toggle" is actually 2 different types of commands - one for toggling a boolean ValueSource, and one that will show/hide a window/panel/dialog etc.

Re 2: My concern with ToolBox as a name is that we already use Box for layout, and this won't be a "regular" box. Panel is a new term. I don't think we need to be as explicit as ToolPanel though - Panel is more than enough IMHO, and allows for ControlPanel, ToolPanel, or whatever other panels types might be appropriate.

Re 3: Yes - API design comes first, for both of these features.

A couple of initial design considerations for Panel:

1. I don't think this is something that is deeply integrated with Commands. It's more of a "new type of dialog window" (although obviously not actually a dialog).
2. I would expect the content of the Panel would be laid out using normal Toga layout boxes.
3. In the macOS context, the visibility of panels is controlled by a "title-changing" menu item (show/hide panel X) for each panel you create. Windows/GTK should follow whatever local HIG usage should be, but we have to be able to support HIG-compliant usage on all platforms.
4. There will need to be some sort of API to control placement of the panel. In the macOS context, it's "where does the panel appear on the screen"; in the Windows/GTK context, I guess it's "which side of the application window does the panel attach to".

I'm sure other things will come up during the design process, but that should be enough to get going :-)

[MuhammadMuradG]

@freakboy3742 add labels please, if there are.