Plugin UI Toolkit

I’m developing mine primarily for a tool for my team on Dragonlore to use for content production. There’s a lot of variable tweaking and text writing, so it needs to be top-notch and done quickly!

I don’t really have an ETA since “done” is probably pretty fuzzy. I’ll just keep adding features as I think of them. I’m taking great care to make sure the user experience is 100% solid, so it’s not the fastest development ever. I would guess that the core features should be in by the end of this weekend.

You can already take the model if you didn’t already see the link. I’ve been documenting some of the API inline, but I think I might rip all of that out and throw it in a ReadTheDocs site on Github or something.

Since there’s more interest than I initially expected, I’m going to get a little more organized with this and probably start a Trello board to track progress!

Me like :heart_eyes:

No reason to make this studio-only if you plan on adding custom styles though.

1 Like

Eh, you can use it outside of Studio, I suppose; there’s nothing stopping you!

I’m seriously considering redoing all my plugins with this system, thanks a lot. >:(

1 Like

nb4 Studio Plugin universal UI standard is made

1 Like

Update of May 10th coming straight at you!

A big refactor is planned for today’s lunch. It should actually be confined to that hour, since it’s mostly just moving code to new modules and making sure there aren’t any missing upvalue references. As a result, the code should be easier for everyone else to slog through rather than just me.

I’m also working on a custom Textbox that does some voodoo to trick ROBLOX into thinking you’re using a regular Textbox but also providing more fun features like text selection, multiline caret navigation, and more scripting control. Unfortunately, I don’t think I can properly do copying text, but pasting might be possible.

2 Likes

Might as well go ahead and remake .Net Framework’s windows forms at this point. The progress on this is crazy.

If we get copy later on, that would be REALLY cool :slight_smile:

Haha, I don’t really want to go that far, but it’s starting to look like it. I just want something lightweight and quick to code with. I’m not sure if plugins will ever get the ability to control Studio’s Qt widgets, but if they do, this will become obsolete pretty quickly!

@Master3395: Maybe! I might see if I can improve ROBLOX’s Textbox object instead…

Its on the Trello. People just have to vote for it.

I’m just saying that since I’m a staff member. :stuck_out_tongue: I can’t really confirm or deny that it’s happening (because I don’t know, and because it’s not my thunder to steal!)

2 Likes

So I didn’t get to that refactor because I was confused about the day of the week, but I do have some ideas to run past the potential users of this plugin:

  • A standardized increment chooser invoked from a script; would store previous options with type and plugin context for quick-choosing and sort by amount of usage. Also a slider and optional key shortcuts for cycling and invocation. Would of course be good looking with flawless behavior.
  • Better, public-facing draggable implementation
  • Separable small tween library
  • A dropdown menu implementation like the animation editor has, but not broken
1 Like

If you want to add features to satisfy your users rather than yourself, I have ideas I can share. Let me know.

As for the four listed:

  • This seems hella specific. I would go for more general-use items, first. What I’m most worried about with such a feature is that it’ll be complex. My intentions are just to provide people who are new to building with just a slider so they can’t do anything to confuse themselves. Unless of course you add a lot of customizability to this element, in which case, I would probably use it. :slight_smile:
  • This might be a good feature. Along the same lines, a “resizable” option would be cool. We could then work with more Windows-style… err… windows. Will your UI require that the user pass mouse events through it, and it decides if it consumes them or not?
  • Tweening is important, but what’s the purpose of this library? What will it do which the built-in one does not?
  • Yes to DropDown.

Good points, here are my responses:

  • You may be right, but the best UX doesn’t confuse anyone :wink: I’m not sure about customizability; the point is to bring about a standard good enough for everyone. You may be able to toggle some parts of it though.
  • Windows are already resizable, but only from the right, bottom, and right-bottom corner. Probably going to improve that! But no, I don’t think event consumption is necessary; it hooks into the Roblox’s UI system already.
  • Would work on anything and everything! Current system is limited to individual GUI elements. Since this toolkit wraps those, that’s not always simple.
  • :smiley:

I haven’t forgotten about this! In fact, I may be working on it even more than I thought, soon…

Anyway, today I’ve made a little slider.

I’m going to improve the looks a little bit if I can and add a popup to tell you which value you’ve chosen. Thanks to my draggable implementation, it behaves a lot better than most. If you grab it and then move your mouse (very) far away, you’re still dragging it until you let go. All about that UX. :wink:

As for wider news on the toolkit itself, I have some big plans. I’m still going to do that refactor, and once I do, I’ll make the styling more robust. I’m also going to add some gamepad support and some crossplatform support in the way of changing some defaults in the styling. Touch interfaces need larger controls, Xbox needs larger text, etc.

When I’m done with it, it should be suitable for games as well as plugins. I have some strict requirements for my own game, so rest assured it will be high quality!

1 Like

Just a sneak peek of my next invocation of black magic and devil worship:

I’m not sure I want to admit how I did this.

1 Like

3 Likes

Do you keep updated documentation for your API somewhere publicly visible? E.g., a google doc?

Not yet, that’s a very high priority to-do! I’ve just changed the API quite a bit, so I threw out all the old documentation I had written.

I was beginning to think I wanted too many options for a simple argument list. I don’t like long, esoteric argument lists that you can never remember the order of, so I decided to go with a descriptor system. Now most controls simply take a parent and a descriptor table, and the descriptor defines everything you need to set up the control. You can get sensible defaults using UI.[ControlName]Desc().

Here’s an example:

local windowDesc = UI.WindowDesc()
windowDesc.title = "NPC Editor"
windowDesc.w = 700
windowDesc.h = 400
windowDesc.canResize = false
		
NPCEditor.Window = UI.Window(windowDesc)

These can be reused and changed. The constructor for the control makes its own copy.

Also, I’ve renamed the ModuleScript from UI to MainModule so it can be used with require(411095678).

1 Like

I’m looking forward for this :smiley: been really lazy on making plugins because of GUIs so this is a huge help.

1 Like