Just playing around with the new GUI editor. It’s super cool and will save a lot of time compared to creating complex GUIs manually. A couple of ideas / thoughts:
To “Delete Selected”, can we also map the del key as well as the backspace key? On a mac, I my keyboard doesn’t have a backspace button so I must use fn + delete
When clicking the line tool, an arbitrary slanted line is drawn across the screen. The properties on the right side allow changing the endpoints, but it would also be powerful to be able to click the ends of the line and drag and drop them like in power point.
Can we have a ‘preview’ the gui. For example the node material editor has a preview in the lower right corner. I would be interested in having an easy way to test out the checkboxes, rollover states, clicking on the buttons to see how the gui looks and “behaves” as fullscreen and as an immersed texture
Some elements have properties of ‘W’, ‘H’, ‘B’, ‘T’, ‘L’, ‘R’. I figured out that they mean width, height, bottom, top, left, right, but the tool tip could have been a bit more verbose rather than repeating the abbreviated version.
I can’t quite understand how to use ScrollViewer element
Visually I can’t tell what difference the containers Rectangle vs Grid vs Stack Panel have on any other elements I am placing. Would it be helpful to show potentially where the stack lines are or where the grid is?
Would a ruler along the top and side in pixel units help align things?
Snap to grid or alignment with other elements may also be helpful as an option.
===
This tool is super cool given the confines of the GUI api. It reminds me of “Microsoft Front Page” circa 1996 web development. I still wish there was a way to support display of dynamic data. For example to show web pages in VR with working links, or a list of a players inventory. If there was a way to do that, web devs can build UI’s with whatever web technology we are familiar with but not need to rebuild it again for VR.
Thank you, @owen, for your suggestions on the GUI Editor. Most of what you have suggested is on the roadmap for development. Let me go through them one by one:
You can currently delete controls with the del key and we are adding backspace for keyboards without a del key.
Right now our creation model for controls is click to place or drag and drop (this second part is in progress). That means to drop a line, we have to create an arbitrary line, but it’s the same for all controls. For a rectangle, we need to create an arbitrary rectangle on creation that can be edited. The other creation model we would like to add in the future is interactive creation, or click and drag creation. This is the model you describe for the line where you activate the line tool, click the start of the line and drag to the end point of the line before releasing the mouse button to create the line.
Right now, if you have a scene running (in the playground or locally) and invoke the GUI editor from the live scene, any changes you make in the editor will be mirrored in the live scene where the GUI is live. So this is one way to see the final GUI as well as make changes to it. We have on the roadmap a “preview” mode for the GUI when used as a stand-alone editor, but there are some other features we need to light up before that can be a reality. The main one being a state management system which is another tool on the horizon.
There will be a full pass on the UI of the editor before release where we will polish up the tool tips to make sure they are descriptive. If you see any that are not super helpful, they are holdovers from implementation that have not gotten attention yet.
The scrollviewer is a container that will add scrollbars for any child control that is larger than the dimensions of the scrollviewer. So if you have a container for text, you would want to use a scrollviewer rather than a rectangle to contain the text if it is of variable length and may overflow the container. The scrollbars will be added automatically for overflow content. To use it, simply treat it like any other container and drag a control on top of the scrollviewer in the tree view to add as a child. Without the preview running in a connected scene, you won’t be able to interact with it, but you will see the scrollbars rendered when content overflows.
You can click on the guides button to see the row/column guides of the grid container rendered. Rectangle does not have any internal guidelines. Stack panel is a unique case in that there are no guides rendered on the stack panel as the panel itself is like a rectangle, but allows the children to stack automatically and reflow as needed. However there are no actual cells created, so there are no guides to render on this one. We do place the icon for each control next to the name in the properties panel header and will be adding the icon to the tree view (right now we just write out the control type after the name but that will change) for each control. This helps you always know what the control type is, but it may require glancing to the right or left when selecting controls.
Rulers and user-generated guidelines are on the roadmap post launch.
Snapping is also on the roadmap post launch.
Hopefully this helps answer your questions and illuminate the roadmap a bit. Thanks again for your suggestions!
Right now, if you have a scene running (in the playground or locally) and invoke the GUI editor from the live scene, any changes you make in the editor will be mirrored in the live scene where the GUI is live. So this is one way to see the final GUI as well as make changes to it. We have on the roadmap a “preview” mode for the GUI when used as a stand-alone editor, but there are some other features we need to light up before that can be a reality. The main one being a state management system which is another tool on the horizon.
I missed that! how do I invoke a GUI editor from any live scene? I thought when you saved something to a snippet server you get a new hash and each edit was immutable and given a brand new hash address?
Also “state management system” sounds very cool. What pray-tell is that?
From a live scene, you can load a full screen (or mesh projected) GUI from snippet easily. If you are in the playground, you can press ctrl+space to get a shortcut for it:
And then just replace the snippet hash with your snippet ID. If you don’t have a snippet ID yet, you can just leave the default string in the load and it will instantiate a new blank GUI in the scene:
Then if you press the edit icon (pencil) next to the GUI name, you will launch the editor and anything you put into the editor will appear in the scene. We are still cleaning up the connection, so you may see some bugs as we polish:
When you hit save to snippet, we do indeed update the hash on the snippet, but in the PG, we simpply update the code in the editor to the last hash number. In a stand alone project, I would suggest saving to a local server and loading it in with a parse of the file, though I believe this class name is going to be changed just to keep consistency with our other tools. Then you can save your json file and a reload will grab the most recent json.
We are also adding some functionality to easily call controls in your code so you can do things like add button behaviors, update colors based on pointer state, or change the state of the GUI.
The state management system I referred to is a feature we are starting on after this next release which will handle state for the scene as well as features of GUI. I can’t be more specific than that at this time as the idea is still very high level.
The “auto update the code in the editor to the last hash number” feature doesn’t update the code unless the function is populated by an initial hash first (not sure if that is expected behavior). Then on subsequent changes to the GUI editor, the scene’s GUI is updated, however in the code editor the replacement hash became this:
to see the row/column guides of the grid container rendered. Rectangle does not have any internal guidelines. Stack panel is a unique case in that there are no guides rendered on the stack panel as the panel itself is like a rectangle, but allows the children to stack automatically and reflow as needed. However there are no actual cells created, so there are no guides to render on this one. We do place the icon for each control next to the name in the properties panel header and will be adding the icon to the tree view (right now we just write out the control type after the name but that will change) for each control. This helps you always know what the control type is, but it may require glancing to the right or left when selecting controls.
