Expose more of the GUI elements.

[Plorntus]

Currently I require the graph view and text box (multiple lines) however the code to do that hasnt been exposed to the gui add method. Could we please have this functionality?

It would be nice also to get all the other GUI elements currently not createable: RadioButton, DropDown, ScrollBar, ScrollPane, Slider, TabbedPane and ToolTip

Further in the future could we have some way of hooking on input events in a specific field and moving the cursor inside such fields.

[necavi]

I believe that this definitely could use a bump - I've been very interested in using most of the elements listed here, the currently available set just isn't sufficient for a complex UI.

[L0771]

RadioButton

Can be simulated with checkbox, but is better with a radiobutton.

DropDown, ScrollBar

Are very used in factorio's gui, is coded, but we can't use

[kovarex]

I believe that this definitely could use a bump.

Sure, I added Sticky to be sure.

There are even more elements that I would like to add, one of the, that could be super useful could be some kind of camera view.

[vzybilly]

I was also trying a list box the other day and couldn't get any luck, pretty much need to add the train stop GUI into a requester chest GUI...

[Ichorio]

I think rendering an entity,or tile into the GUI would be quite useful, similar to the preview on the right of the screen.

EDIT: I think that should probably just be an element, so you can tack a couple onto a GUI frame, and render a somewhat sane picture of entities.

[y.petremann]

For now you can also only attach a window to the center of the screen or to top or left, it could be interesting to add the possibility to add movable windows

[silent]

Thirded! There's lots that can be done but the lack of core ui widgets (like a scrollable pane/frame/flow) is very restricting. And I have to assume it would make mainline UI development much faster if it was de-coupled from the C++ (ofc. I'm totally assuming the state of the internals, so assumption = ass u me etc..)

Also, making the UI just another part of base would really change the game for mods, and also open up the field for creative UI ideas to trickle into the base.

Also, hotkeys!


i.e.
A. I'm playing around with making an action-bar mod on the left side, but I cannot add a button to open the electricity or production panels, or show/hide minimap etc...
B. Also working on an in-game panel for runtime config and data, but not being able to use a scrollpane results in extremely clunky UX if you have lots of mods running
C. Scrollable multi-line text pane(s) would be debug heaven for modders (imho) (this can be simulated or just piped into the player console, but again, clunkily)

Edit: grammar and some afterthoughts

[JasonC]

Can we document the existing ones first?

In particular there is no documentation for element-specific styles.

I think a pre-requisite to new GUI elements is us all knowing what the difference between, say, a monolith and a composition is, what the values for "priority" mean (and what the "-no-scale" ones are that are in the game code), that some elements take "graphical_sets" and some don't, that checkboxes are the only widgets that don't scale images in styles, that "tint" exists, etc. Then we can start tackling new elements.

Some of that stuff I could at least add to the wiki. Other things I could not. Plus the wiki is a bit overwhelming, it's got a lot of old info in it and even removing most of it and updating it as merely a supplement to http://lua-api.factorio.com/ is a fairly daunting task. Maybe we could somehow organize a mass effort to re-write all the modding docs in the wiki first. I'd be happy to help but definitely not by myself.

And in any case I think the element style docs really ought to be on http://lua-api.factorio.com/ and not the wiki.

[Moonheart08]

+1! Upcoming mods (including the one i have as a pet project) would benefit, for now, i think ill just have to fake radio buttons

[aubergine18]

I'd like to be able to render background images on GUI elements - including sprite-buttons. This would enable enhanced UI, for example I might want to show step by step instructions for setting up a complex entity, or I might want a picture of a character to associate with a storyline, etc. The ability to update the background image at runtime would also be desirable, so as the user interacts with the GUI I can change the background on the fly.

I realise that technically I could do some of this with existing sprite-button, however I'm already realising that won't suffice for a lot of the UI stuff I want to do. As an example, I might have a sprite-button with a static background but want to update the foreground image without changing the background. In this scenario, the background would be the sprite of terrain or an entity on the map, so it's not like I can pre-determine the graphics used for the background (and even if I could, it would be hundreds of megs to generate all the different combinations of background vs foreground).

Being able to update the foreground image of a sprite-button at runtime (ie. while user is actively using the GUI) would also be desirable. An example is I want an entity that has customisable inputs and outputs, and I want to create a UI that allows the user to drop the various ingredients on the desired "ports" of the entity.

Additionally, if possible, the ability to take a screenshot in memory (rahter than saving to disk as it currently works) of a specific map area using 1:1 ratio (ie. each tile 32x32 px) would be very useful to provide initial background image for a flow or frame.

[Rseding91]

Which GUI elements are still missing that people want?

Scroll pane and radio button have been added. Is there anything else?

[aubergine18]

Are the docs updated? I didn't see new elements mentioned in the list here so not sure what the scroll pane is.

A slider (eg. for setting quantity by dragging handle) and drop-down list (anchored to a position of some existing element for example) would be very useful.

Some way, at runtime, to rotate background image of an element (without affecting size/shape of the element itself) would be very useful. It would allow custom gauges and certain other UX to be implemented.

[Rseding91]

Are the docs updated? I didn't see new elements mentioned in the list here so not sure what the scroll pane is.

A slider (eg. for setting quantity by dragging handle) and drop-down list (anchored to a position of some existing element for example) would be very useful.

Some way, at runtime, to rotate background image of an element (without affecting size/shape of the element itself) would be very useful. It would allow custom gauges and certain other UX to be implemented.

That's the problem with static text in the docs - it's always wrong when things change. The docs shouldn't mention any of which types are supported except for auto-generating that list.

[aubergine18]

With the news that a GUI update is on the cards for 0.14/0.15, would it be worth taking a step back and considering a different approach to the GUI?

Specifically, I'm thinking a generic 'panel' could form the basis of most aspects of GUI.

Panel would have properties such as:

* background image
* margin (outer spacing between panel and siblings/parent)
* padding (inner spacing between panel and children)
* clickable = when true, panel is clickable
* width, height, minWidth, minHeight, maxWith, maxHeight
* scroll properties
* flow properties (vertical, horizontal, etc. CSS-like flexbox features would be ideal)
* sounds (or maybe better just a new sound API)
* etc.

Thus a frame is a panel with background image, containing a label and a flow. A flow is just a basic panel with no background image. A button is a clickable panel with a label, a glyph button with a sprite.

Thus, I could easily create a button with both a glyph and a label: a clickable panel, with two children (a glyph and a label). That also pretty much deals with checkbox and radio button - would we need dedicated elements for them any more?

When user clicks the UI, if the element they click on is not marked as clickable, the click ripples up through parent and ancestors until it finds a clickable panel. If it reaches LuaGui (top, left, center) the click is discarded.

If flexbox-like features are implemented (would be available on all gui elements, not just panels) then grids could be implemented without the need for a special control (although specifying num columns might need some ponderage).

Almost all elements could have child elements, notable exceptions might be label and textbox. Speaking of textbox, a new .pattern field which would be a pattern to constrain user input (eg. to numbers or specific chars).

Add a .draggable = LuaGuiElement property and now we have custom scrollers, sliders, etc. The LuaGuiElement specified must be parent or ancestor of the draggable element, and is used to constrain where the draggable element can be dragged to. Exposing properties like x,y (top, left) and width, height would mean we could easily keep track of where dragged things are.

Also, option to rotate an element (.rotate prop) with or without rotating its children. This, when use in conjunction with draggables or carefully styled sliders, would allow creation of dials, knobs, analog displays (think steampunk). Delta events or even remote calls would be required to make this sort of thing reality (we'd need events/calls to update our UI while something is being dragged, not just when the dragging is complete).

Ability to define composition and monolith images in their own right (like we can do with sprites), and then use them by named reference in prototypes. Ability to define GUI style sheets at runtime, eg. in control.lua, and "compile" them (get a handle to C object representing the style) for fast re-use and application. These two things combined would make it much easier to do GUI stuff - simply reloading a save after making changes, without needing to exit game to update prototypes.

Most element properties could be set to special 'inherit' value that causes them to get the value from parent (recursive, until found, up to and including to LuaGui top/left/center). This would allow, for example, me to set font or color at top-level of a dialog and have all text in that dialog inherit the setting from the dialog Panel.

Full list of GUI elements could therefore be:

* Panel
* Sprite
* Label / Textbox (a textbox is just an editable label?)
* Progress
* Grid (flexbox with specific number of columns)
* Monitor (shows live map view, similar to the train station UI) - can contain child elements so I can overlay UI on it
* Slider (could be created with draggable panel, but convenient to have dedicated element)
* Checkbox / Radio (again, just for convenience)

Sorry for huge post. :/

[aubergine18]

There doesn't seem to be any way to set the scrollbar_style or slider_style of the scrollbars on a scroll-pane element (also, scroll-pane element isn't mentioned in API docs). Background discussion can be found on github: https://github.com/aubergine10/Style/issues/1

Desirable syntax:

Code: Select all

{
  type = 'scroll_pane_style',
  -- ....,
  scrollbar_style = {
    vertical_spacing = <number>,
    horizontal_spacing = <number>,
    background_color = <Color>,
    slider_style = {
      -- etc...
    }
  }
}

[aubergine18]

Table enhancements:

There's currently no way (that I know of) for mods to define table header rows, and thus take advantage of things like the ascending/descending styles for column sorting indicators as defined in table_style prototypes.

Instead we have to do manual workarounds, like this: https://github.com/Helfima/helmod/issues/11

It would be nice if LuaGuiElement had a .heading_row property, specific to table elements, which if true would tell table that the first row is a heading row.

For elements in that first row, a .sortable property could tell the table that the column is sortable. For elements in all the other rows, a .sort_on value, if present, would be used instead of the .caption (translated), .value, .text etc., when sorting.

Currently we have to manually sort, which is painful and requires rebuilding the whole table (we can't simply re-order the .child_names array on LuaGuiElements it seems).

Also, there is no way to mark a row as selected - maybe a ".selected_rows :: array of row numbers" on table LuaGuiElements? So we can select multiple rows by putting numbers in that array; if nill or empty then no rows are selected. It would be up to mod to handle the values in the .selected_rows array. The rows would be styled with the selected_row_color property from table_style prototype defined on tableElement.style.

[Sigma1]

I would love to access the actual HUD to do stuff like add weapon slots etc.

[aubergine18]

I would love to access the actual HUD to do stuff like add weapon slots etc.

+1

I'd also like to be able to reposition those things or better still just turn them on/off in a more granular manner than is currently possible and be able to add stuff to gui.right, gui.bottom_left, gui.bottom_center and gui.bottom_right.

[Godmave]

Listbox and its children please