Repository navigation
[Feature Request] Ability to preview layouts at Edit time #13
Description
Right now there is not a way to see the final layout at Edit time, you have to run to see it constructed. It would be nice to have a the Canvas automatically build the Panels as the settings are being tweaked or at a minimum a button in the Canvas inspector to build the layout so you can see what it will look like without running.
Activity
yasirkula commentedon Jun 10, 2021
I'll keep it in mind, thanks!
yasirkula commentedon Jun 10, 2021
One thing I didn't think about at first is the panels themselves. Panel instances are created at runtime; they mustn't be created at edit-time because that isn't how this plugin works (i.e. we can't instantiate Plugins/DynamicPanels/Resources/DynamicPanel.prefab in the preview). In the preview, we can reposition/resize only the RectTransforms that are assigned to tabs in DynamicPanelsCanvas' inspector. That can look weird for panels with multiple tabs because those tabs' RectTransforms will overlap each other in the preview. And I don't think that's how users would expect the preview to be.
JLeybovichLFL commentedon Jun 10, 2021
Right but the content can still be disabled in Edit time as well. Its essentially just the ability to see what it will look like without entering Runtime, tweaking visual elements is always better to do at Edit time. If it is configured before Runtime as the user sees it, is there really a benefit to rebuild it at Runtime?
JLeybovichLFL commentedon Jun 10, 2021
I think once the ability to set a reference to the DynamicPanel prefab in the inspector (the set the custom style reference issue) is done then it would make building at Edit time more doable because you wouldn't have the dependency on loading from Resource.
yasirkula commentedon Jun 10, 2021
What I'm trying to say is, you need to think about not just the feature you're interested in, but also the edge cases it brings to the table. I won't implement this feature until I find a way with almost no edge-cases.
JLeybovichLFL commentedon Jun 10, 2021
Right, in an ideal world I think the layout changes made in Edit time and Runtime would persist between each other that way its always WYSIWYG. I understand that the plugin is more code driven at this time but that doesn't mean that one day it cant be completely customizable from the Editor and Scene view. Most times when working on visual things like UI you expect to have Edit time capabilities to lay things out rather than setting everything up in the code, its just a better workflow for artists and designers and therefore an easier workflow for devs.
I don't think the entire plugin needs to change right away that's why I suggested just a build layout button as an initial step towards utilizing Edit time more. If a user decides to mess with the scale, well I would say that's their decision and you can't predict all the wrong ways someone will utilize your tool.
Its better to be flexible than restrictive in this regard. Imo a good tool gives you an easy way to do something, a great tool gives you multiple ways. Code, Editor, Edit, Runtime should all be valid ways to utilize an API in Unity.
Another principle I am basing my pov on is "Edit time < Compile time < Runtime < Build time" meaning the further left you can have changes visible and testable the less time it takes to iterate on them.