See how easy it was for me to throw together the basic outline of my two-pane character editor Gui? It literally takes me over five times as long in Studio, typing in sizes and coordinates number by number just to get some blank boxes in place.
Some very basic drag and drop, resize and scale tools for Gui elements would greatly speed up UI production.
(I used LucidChart in that gif)
I think it’d be more useful if we got more control over guis in the first place
Disgusted this hasn’t been done yet.
chill.
I have a gui editor plugin I found a long time ago that sort of does this. I made a thread about it once.
http://hastebin.com/meboxusoni.lua
Add it as a lua file then Execute it in studio.
What you’re really asking for there is a Widget toolkit… which can already be built on top of the existing GUI objects. It’s just really hard to make a good Widget toolkit, so nobody has.
The most realistic solution would probably be someone doing a clean room re-implementation of NGUI from Unity or something like that.
There’s a fundamental gap between the fact that the Roblox GUI system is basically just a 2D drawing / user input API, while what most people actually want / need is widget toolkit.
This was the #1 reason why I requested to be able to create and utilize Studio panes with plugins. I wanted to make something that it wouldn’t be frustrating to make GUIs with. Unfortunately that feature request was blocked after voting finished on the Trello board. Using GUIs to edit other GUIs would get annoying when the editor was covering what you wanted to work on, so Studio panes are really the only way to do it.
Obviously it would be nice to have said feature for that case, but I’m sure you understand why it was blocked… it’s really hard to support Lua going in and messing with the studio GUI. Even the really simple case of plugin toolbars has had it’s fair share of bugs along the way… an API comprehensive enough to really make a good GUI plugin studio integrated would be a nightmare to get into a stable enough for production and to maintain going forwards.
Plus, I’m not convinced that that’s what’s stopping there from being a good GUI plugin. You have to support multiple screen sizes anyways, so you can (and usually should) work on the GUI constrained to a smaller portion of the screen than the whole thing.
That’s a great idea. I might end up making some sort of plugin then. My only worry then is it’ll still be slightly annoying to use just because how bad ROBLOX TextBoxes are. I could emulate highlighting, shortcuts like Ctrl+A, etc, but plugins don’t have access to the clipboard (still 
), so I’d have to do something weird to get copying out of textboxes working. I could disable pasting and then emulate that alongside copying, but then you wouldn’t be able to paste in anything from external sources (including property fields in Studio). I hope that wouldn’t be too much of an issue.
Copying / pasting text is the last thing that you should worry about. In fact, you can still use the regular old explorer window for people editing text / object colors / etc. For a Widget toolkit here is how I would proceed:
Have widgets in your hierarchy still be normal Roblox GUI objects. That is, button = TextButton, scrolling area = ScrollingFrame etc (This facilitates the easiest movement of bits and pieces made with the plugin between places / publishing components / etc).
Add additional properties / options to said objects as necessary through the use of *Value objects. These additional options can be edited either in the normal explorer or inside of your plugin interface and those methods of editing mirror eachother.
The plugin provides visual layout and nice pre-fab components in a WYSIWYG editor.
The plugin injects scripts / modules into the object hierarchy to augment the plain hierarchy of roblox GUI objects with additional GUI objects / layout behaviors as necessary at run-time.
The plugin also packages each GUI hierarchy edited as a module for components that are dynamically created. This all requires a global “registry” of GUI object <-> script side object relationships to work.
Common components that you want: LinearLayout (“Just get this stuff to line up in a row for me!”), ScrollingGrid (“Just throw objects in there and it does it’s best to lay them out in a grid with scrolling behavior if they don’t all fit”), Right-Click / Long-Touch Context Menus (Really hard to implement at present, I probably have about 300 lines of complex code dedicated to implementing a robust dropdown menu for my current game), Split Sliders to split a pane into resizable halves (Most games don’t use these even where they would be ideal because they’re too hard to implement)
I essentially wanted to redo the properties window, explorer, and advanced objects. For instance, how would I go about allowing users to tile images? The most user-friendly way imo is to add a “Tile” option to the ScaleType dropdown in the properties window, but I can’t do that with the ROBLOX properties window. Then, with the ROBLOX explorer, how are you going to be able to distinguish a dropdown list? I want to be able to give it a custom explorer icon. I could skimp on the custom advanced objects window by making a RMB context menu though.
How, without making it clunky to use? I’d rather design my GUIs in an external program if in ROBLOX I have to resort to toggling BoolValue instances under objects.
This works nicely for you (Well, I’m not even convinced it would work nicely for you), but it throws interoperabibility and usability by the average developer down the drain. Think about how frustrating having to go out to an external editor or fire up a plugin or open up a script and dig through a bunch of machine-generated code just because you want to change what a label’s text is. With the system I’m proposing all you have to do is open the GUI in he explorer (also easy, because the hierarchy is still logically sound and clean, without a bunch of auto-generated garbage in it to make it hard to navigate) and change the text there, and it’s done.
Having an opaque system where you can no longer use the explorer window to do edits to it is basically unacceptable once you think it through (And I believe, why none of the existing GUI editing tools / GUI libraries on Roblox have caught on).
ROBLOX Studio is so bad of a place to work with GUIs that if I start off on projects with interface, I’m entirely exhausted and fed up with the project by the day’s end. Even if the existing behavior is augmented, all you’ve done is made it augmented shit. Maybe it’s not that bad of an experience for anyone who just wants to make quick-n-dirty interface, but thoroughly designing UI in ROBLOX Studio is painful to the point of me wanting to avoid it at all costs – even having to switch to an external program every time I want to make a small change. That being said I wouldn’t do anything like import .rbxm files into that external program. Ideally it’d be drag-n-drop or cut-n-paste to transfer between it and Studio.
I think that your expectations of what you claim you would do don’t line up with reality here. I can’t believe that you would actually resort to an external editor for most tasks if you could avoid it with a quick change to the object hierarchy. It just doesn’t make sense.
I’m entirely exhausted and fed up with the project by the day’s end.
Recognize that that’s not at all a problem unique to Roblox though. Most people working with most GUI libraries tend to hate doing GUI work, because as soon as you try to do something that doesn’t exactly line up with an established GUI pattern, GUI work is always a very finicky and tedious process to get it feeling good, with every task often requiring special and hacky requirements on how it interacts with the rest of the stuff.
This is something we’ve thought about on and off and would require a large amount of time and resources to design and create.
There are a bunch of plugins that make GUI elements WYSIWYG, and general-purpose GUI libraries as well. Anyone want to post one they use?
In addition, we’re into making built in higher-level GUI primitives.
There are a bunch of things to consider such as ease of use, device responsiveness and etc so this is a ways off.