[0.12.29] [kovarex] Tables render incorrectly in full screen mode

[kovarex]

- Added sprite-button gui element, works the same way as button, but it can have sprite property assigned, which refers to the sprite identifier.
- Custom sprites can be defined in lua data definition (type = sprite, the rest is sprite definition).
- Sprite identifier can either point to custom definition from the data, or have form "<type>/<id>", type can be (item, entity, recipe and technology), for example button.sprite = "item/iron-plate"

This should make things easier in 0.13

[JasonC]

So I have a proposition:

I will make this addition for 0.13 and I will do these 2 things:

• Custom image specification (would work similarly as fonts), every image specification would use the same object system as any other moddable object, including name, type etc.
• Picture button (derived from button and similar to it), which would be a button, with picture on it, the picture would be specified using name that would point to the custom image.
• ImageWidget, because why not, if we already have the images.

Would it solve the problems?

This would solve the problems we talked about here and definitely will make things easier. It looks like you already made the changes, but I have an alternate proposition. There's another use case for images; in the case of e.g. Advanced Logistic System the images aren't buttons; they're just images. They're essentially image labels. So consider this instead of sprite buttons or any new widgets in general:

• Switch checkboxes and any other GUI elements to take graphical sets instead of plain images (buttons already take *_graphical_sets in their styles) (partial feature request), and add this support to labels.
• Add a working and consistent scalable property to all GUI elements which, if true, disables scaling for that element.
• Add a new image type (along side composition and monolith) that can layer images (feature request).
• For things with captions (labels, buttons, etc.) just draw the text over top of any background image as is done now.

What do you think of this instead? There's a few other details that would need to be worked out if this makes sense, in particular centering images (involves the "align" property) and the possibility of per-image scaling (involves honoring the "*-no-scale" priorities maybe) -- I have ideas but I want to keep this post short-ish.

This way, you don't add new widgets (I think this could be the start of a slippery slope of too many widgets in the future), you get image powers on buttons, labels, and any other creative uses (in the future too for new GUI elements we don't have yet) with a consistent API, and you get pixel-accurate control over the sizes of all widgets if you want them. Plus, philosophically (if you're into that sort of thing), text and image buttons are both "buttons", text and image labels are both "labels", and so you're not creating separate conceptual widgets for what's essentially the same GUI control with different types of content on it.

This accomplishes the same thing as sprite buttons, but also a lot more, and also leaves the opportunity open for a lot of flexibility in the future for uses we can't foresee yet. Plus it makes the API a bit more consistent, the *_background vs *_graphical_set is already kind of confusing. It does everything the sprite button changes does, makes pixel-accurate control manageable and optional, and implicitly adds image support to any widget now and in the future that supports background images. It also makes it simple to adjust the size of widgets without having to redo their graphics; e.g. consider the flexibility and convenience of a button with a "layered" background image that consists of a monolith (the image) on top of a composition (the background and border). As a bonus it might give you more consistent rendering logic for all the elements.

Those changes you made look exciting, and thanks; but even though you already made them would you consider something like the above instead? I think it is a more elegant and flexible approach and nails multiple birds with ... less stones than birds. Even if it is a bit more work, it does a lot more things, and it's probably better in the long run than adding new special-purpose widgets.

Sorry it took so long to reply, I wanted to give it some thought.

[JasonC]

By the way:

- Sprite identifier can either point to custom definition from the data, or have form "<type>/<id>", type can be (item, entity, recipe and technology), for example button.sprite = "item/iron-plate"

In terms of solving problems I'm not sure if this particular change is necessary, since button.sprite = item.type.."/"..item.name isn't much different than whatever.filename = item.icon.

Also it might actually make mod code slightly more verbose; if the prefix differs depending on the item type, e.g., "inserter/smart-inserter", then you have a couple extra string concatenations to do and a tiny bit more information to track (e.g. item.type .. "/" .. item.name everywhere, or passing item.type around to functions along with item.name if your implementation is structured that way). Not a big deal, but I'd still probably just prefer to grab icon filenames myself even if this interface were present. Note, by the way, that this kind of stuff is, at least currently, generally done in data-final-fixes rather than in control, where you're working with data.raw.

Also just out of curiosity, how would sprite IDs interact with the spritesheet position and offset properties, and other incompatible properties, already in the API? E.g. what happens if you do

Code: Select all

{
   sprite = "item/iron-plate", -- used to be sprite = "my_own_graphic.png" but changed for version 85 of this mod
   width = 20,
   height = 20
   x = 9,
   y = 31
}

That said it is, at least theoretically, a more modular API than copying icon filenames. And it could also work into the proposal above as well if you e.g. let monoliths take sprite identifiers.

[kovarex]

This would solve the problems we talked about here and definitely will make things easier. It looks like you already made the changes, but I have an alternate proposition. There's another use case for images; in the case of e.g. Advanced Logistic System the images aren't buttons; they're just images. They're essentially image labels. So consider this instead of sprite buttons or any new widgets in general:

• Switch checkboxes and any other GUI elements to take graphical sets instead of plain images (buttons already take *_graphical_sets in their styles) (partial feature request), and add this support to labels.

Sounds reasonable, added to our tasks.

• Add a working and consistent scalable property to all GUI elements which, if true, disables scaling for that element.

As I said, we actually want to remove the scalable property eventually, as we want everything to be scalable without opt-out option. With the high-resolution retina displays, it is a problem when people can't scale things.

• Add a new image type (along side composition and monolith) that can layer images (feature request).

Why would you need this, once you have the picture button?

- Sprite identifier can either point to custom definition from the data, or have form "<type>/<id>", type can be (item, entity, recipe and technology), for example button.sprite = "item/iron-plate"

In terms of solving problems I'm not sure if this particular change is necessary, since button.sprite = item.type.."/"..item.name isn't much different than whatever.filename = item.icon.

Also it might actually make mod code slightly more verbose; if the prefix differs depending on the item type, e.g., "inserter/smart-inserter"

Not it doesn't work like that, for entity icons is always just entity, so it would be "entity/smart-inserter" for entity icon, or "item/smart-inserter" for item icon (which are the same currently, but doesn't have to be and not all entities have corresponding item.

Also just out of curiosity, how would sprite IDs interact with the spritesheet position and offset properties, and other incompatible properties, already in the API? E.g. what happens if you do

Code: Select all

{
   sprite = "item/iron-plate", -- used to be sprite = "my_own_graphic.png" but changed for version 85 of this mod
   width = 20,
   height = 20
   x = 9,
   y = 31
}

No, this is not the way it can be used. the "Item/iron-plate" can be currently only used, when setting the picture of the sprite-button element. It can't be used inside lua definitions, it wouldn't make any sense to me.

[JasonC]

• Add a new image type (along side composition and monolith) that can layer images (feature request).

Why would you need this, once you have the picture button?

Well, what I proposed was an alternative to the picture button, and I think it is a better option.

So, no picture buttons. Layered images on regular buttons instead. Then you implicitly get picture buttons, picture labels, and picture anything else all for the price of one new image type. The rest of the points in my list are things that would be needed to support that (also, I specifically added those things based on observations I've made about current behaviors, it was a carefully chosen list -- everything in it would have to happen to make this work well).

Then you wouldn't have to create a new picture button widget. You could use the existing button. And you wouldn't have to create any new picture vs. text widgets, you'd get that power on all of them.

It'd involve undoing the picture button work you did yesterday and doing this instead (again, sorry about the late reply). Having a layered image type not only provides the functionality of the new picture button you just added (making it unneeded), but adds a ton of functionality to other widgets as well (such as labels, and widgets that haven't even been conceived of yet that may come in the future). Does that make sense?

[kovarex]

• Add a new image type (along side composition and monolith) that can layer images (feature request).

Why would you need this, once you have the picture button?

Well, what I proposed was an alternative to the picture button.

So, no picture buttons. Layered images on regular buttons instead. Then you implicitly get picture buttons, picture labels, and picture anything else all for the price of one new image type. The rest of the points in my list are things that would be needed to support that (also, I specifically added those things based on observations I've made about current behaviors, it was a carefully chosen list).

Then you wouldn't have to create a new picture button widget. You could use the existing button. And you wouldn't have to create any new picture vs. text widgets, you'd get that power on all of them.

It'd involve undoing the picture button work you did yesterday and doing this instead (again, sorry about the late reply). Having a layered image type not only provides the functionality of the new picture button you just added (making it unneeded), but adds a ton of functionality to other widgets as well (such as labels, and widgets haven't even been conceived of yet that may come in the future). Does that make sense?

I think that you don't understand what I mean by picture button. The difference is, that you can specify and/or change the picture runtime, not in the data definition.

Code: Select all

/c game.local_player.gui.top.add{type="sprite-button", name="test", sprite="item/iron-plate"}
/c game.local_player.gui.top.test.sprite = "duck" -- lets change the picture to duck

For the layered style, I mean, if you want to have specific background under a label, you can just create a flow or frame with that background and put the label on it, can't you?

[JasonC]

- Sprite identifier can either point to custom definition from the data, or have form "<type>/<id>", type can be (item, entity, recipe and technology), for example button.sprite = "item/iron-plate"

Not it doesn't work like that, for entity icons is always just entity, so it would be "entity/smart-inserter" for entity icon, or "item/smart-inserter" for item icon (which are the same currently, but doesn't have to be and not all entities have corresponding item.

Hm, but in data-final-fixes, the game doesn't know that things in e.g. data.raw.inserter[] are entities or items yet, right? From my understanding and chat conversations, the game can't actually tell that data.raw.inserter[]'s contents are items, entities, etc., until after the game parses them into LuaWhateverPrototypes and makes them accessible in control.lua via game.item_prototypes, etc.

So how would you be able to coalesce all item prototypes into "item/" in the data-* scripts? The stuff isn't parsed into actual prototypes at that point, is it?

Or are you proposing that sprite IDs in styles be set at runtime via control.lua (after data.raw has been properly parsed into items, entities, etc.)?

[JasonC]

I think that you don't understand what I mean by picture button. The difference is, that you can specify and/or change the picture runtime, not in the data definition.

Ah, I understand now. Hm, well, it's neat... but I don't see this as being much benefit over just dynamically generating the styles in the situations we're talking about, at least. Similar code, different places. I still think it's a good idea but it doesn't impact the issues here.

For the layered style, I mean, if you want to have specific background under a label, you can just create a flow or frame with that background and put the label on it, can't you?

The ability to put backgrounds on flows and frames is news to all of us. I'll give this a shot, but it's still a hack (e.g. you have a table, then you put a flow in each cell with a background and a single label in each of those flows... it's messy but it doesn't have to be). It'd be nice to get rid of the necessity for hacks, that's the goal of the changes you made already and also the ones I proposed -- most of what we're talking about can already be done with tricks, but then you have things like the recent checkbox scaling behavior changes that break all those tricks, that's what's not good, that's the kind of thing that should be avoided.

The layered image type sort of accomplishes this as a side-effect; it lets labels be labels, buttons be buttons, etc. Philosophically, a frame holds components, a flow determines their positions - putting background images in them to workaround not being able to put images on widgets is asking for trouble.

Btw, I only speak for myself but I'm totally willing to wait until a few (or many) updates into 0.13, or even 0.14, for this kind of stuff. I'd rather see a consistent, predictable, and flexible system than have the features implemented quickly, there's no rush here. There's already more than enough stuff in 0.13 to be excited about!

PS About "scalable" - Sure. If you're moving for scaling to be mandatory, though, then instead of my proposal for a working scalable property, instead consider implementing higher quality scaling of images with interpolation (unless it's there already, in which case, how do I enable it?). That'd also give good results. That was my primary motivation for making scaling optional; the quality - because on "normal" displays (not insanely high dpi) you run into a lot of situations where e.g. a 32x32 graphic is scaled to 33x33 or something, and it's ugly.

[kovarex]

Our plan is to have 64X64 icons for everything eventually, so scaling it shouldn't be a problem.

[JasonC]

Well (unrelated to scaling), I do think the layered-image-for-all-widgets approach is the way to go, but I understand that there's also a ton of other stuff going on right now. Thanks for the changes, they will definitely be useful.