Suggestion/feedback: better visibility for opening/saving project

[adxlv-co]

After using Workbench for small quick tests and demos, I decided to test and prototype a more complex project to explore the GNOME APIs (it's great tool, thanks for making this, I'm really glad this software exists!).

Since I didn't see a way to save the project (first I tried to hit Ctrl+S, but I also noticed there's no option in the main menu¹), I ended up keeping Workbench running, never turning my computer off. I also kept copying and pasting the source code of the different files into a separate text editor out of caution, to make sure I wouldn't loose anything.

After saving a backup once again I felt confident enough to close the program, and to my surprise I saw a dialog offering to save the project!

I was glad this functionality exists, but I wish it didn't hide itself like that! Since there's no save shortcut (a standard HIG convention), and no "Save project" item in the main menu, I thought there was no such feature, and avoided closing the app altogether, fearing I'd loose my prototype.

After opening Workbench again, another surprise: there was no way to open a saved project. Only after choosing one of the demo projects I got a way to select the "Open project..." menu item.

So, to summarize, two suggestions:

• Include "Save project" as an item in the main menu, following HIG's Ctrl+S keybindings.
• Include an "Open" button in the Header bar of the Welcome screen, allowing to open a saved project without having to open a random demo project first.

---

Appendix 1: Save dialog mock

I made a mock showing the save dialog. It's really just the existing one minus the "Discard" button + unsaved messaging:

---

Appendix 2: Open button in Welcome screen

Following the HIG suggestion of avoiding text-only buttons in header bars, I included a document-open-symbolic icon.

Footnotes

1. Also I thought the "Open project..." menu item would take me back to the Demos list in the welcome screen. ↩

[arigit]

Tested the latest flatpak.

I was looking forward to jump into Workbench for my new GTK4 project, it's a brilliant idea and the implementation is really nice, but it seems to be optimized for playing/tinkering with the demos as opposed to UI development, for example: there is no way to right-click on a .blp/blueprint file in nautilus and have it open in Workbench, like one could do with glade/cambalache

There is also no way to right click on a project folder in nautilus and "open with" workbench.

In those two cases, workbench opens but on it's own it presents the demo library, or the latest open demo if there was one.

Lastly, it doesn't automatically save the XML UI file, the only way I found to bring the UI to my project is to copy it from the workbench UI and paste it in a XML file that then my python project loads. Could we have the option to automatically save the UI in XML format so that after editing in workbench and saving, the UI can automatically be loaded by the app being developed.

Workbench is not really integrated to a workflow where one is developing code in e.g. VSCode and needs to develop/tweak UI in parallel.

Looking forward to workbench to be the UI development tool of choice of gtk4, such a brilliant idea, we only need better development workflow integration.