Questions around UI Scale / HiDPI

[mobiuscog]

I notice that there is provision regarding UI Scale in the headers
clap_plugin_gui->set_scale()

However, there are a couple of points that I'm unclear on (or perhaps misunderstanding).

1. Scale is not called on floating windows. I presume this is because they are independent of the host, but it could be beneficial for them to know the scaling that the host is using.

2. Scale is set after clap_plugin_gui->create() is called. This means that the create should not layout any elements until the scale has been set (or get_size() is called) and their layout and size will be unknown until scale is given (unless an additional re-layout is wanted). I realise that layout/sizing may want to be within a more dynamic nature, for plugins that scale on re-size. However, for any wanting to initialise with a default resolution, knowing the scale up-front could be useful.

[robbert-vdh]

2. This works kind of analogously to VST3, but with all function pointers on the GUI extension structs instead of it being distributed over multiple objects. The whole thing is essentially a builder pattern, and after checking whether the plugin supports an API with clap_plugin_gui::is_api_supported() the host will start the GUI building process with clap_plugin_gui::create(). At that point the plugin can start initializing some things, but the actual window will only be created when clap_plugin_gui::set_parent() is called for embedded windows. For floating windows clap_plugin_gui::set_transient() is the equivalent 'build' function, but I do feel like suggest_title() should probably be before then. This is the current correct order of operations:

   clap/include/clap/ext/gui.h

   Lines 16 to 30 in 55ee06f

   	/// Showing the GUI works as follow:
   	/// 1. clap_plugin_gui->is_api_supported(), check what can work
   	/// 2. clap_plugin_gui->create(), allocates gui resources
   	/// 3. if the plugin window is floating
   	/// 4. -> clap_plugin_gui->set_transient()
   	/// 5. -> clap_plugin_gui->suggest_title()
   	/// 6. else
   	/// 7. -> clap_plugin_gui->set_scale()
   	/// 8. -> clap_plugin_gui->can_resize()
   	/// 9. -> if resizable and has known size from previous session, clap_plugin_gui->set_size()
   	/// 10. -> else clap_plugin_gui->get_size(), gets initial size
   	/// 11. -> clap_plugin_gui->set_parent()
   	/// 12. clap_plugin_gui->show()
   	/// 13. clap_plugin_gui->hide()/show() ...
   	/// 14. clap_plugin_gui->destroy() when done with the gui

[mobiuscog]

Thanks for this - I'm not coming at it from VST(3) experience, so perhaps that's partly why.

I'd missed the set_parent() aspect (it's clearer now you mention it, working through the clap-saw-demo), and can see the builder pattern as you mention. That all makes sense.

I would also agree that suggest_title() would make more sense for floating winfows, although personally I would have preferred an explicit function name that is consistent with both, for a standard - a clear point of state that the host expects the UI to be 'built'. I guess show() could be used in that regard, but that's likely also leaving things too late for anything 'heavy' on the first instance.

Anyway, I appreciate the clarification. Thanks.