Extend Slicing to all GuiObjects

For some reason the Slice 9 GUI properties only exist on ImageLabel and ImageButton?

It would be better if SliceCenter, ScaleType and the Image* properties were on GuiObject. I am particular missing them on Frame. The only way to style a dialog box right now is to put a giant image label on it.

If you don’t know what slicing is, it’s this - How to use SliceCenter (Roblox's 9-Slice GUI Property)

Why don’t you use an ImageLabel instead of a Frame? Also, how would you slice a frame with a non-existent image?

What is the distinction between ImageLabel and Frame then?

It looks like to me using ImageLabel instead of Frame solves all your problems, not sure why you are so keen on using Frame.

If you want an image then you should use an imagelabel, right?

5 Likes

My conceptual framework for creating GUIs is that my dialog boxes should always be Frames.

Other GUI frameworks make it easy to style dialog boxes.

Frames in ROBLOX already have many graphical properties.

Lack of slicing on Frames is a strange lacuna.

If they add those properties to Frame as well, then there is no difference between ImageLabel and Frame. An ImageLabel with an empty Image property will act like a Frame.

I don’t think that’s a good reason not to do it.

It’s possible that having both Frames and ImageLabels was a mistake, but we’re here now.

It also makes no sense that Frames are the only GuiObject with the Style property. I know I’m eventually going to use Slice9 GUIs in my game. But right now for prototyping I want to use one of the built-in Styles. To toggle between using Styles that come with the game and custom styles I need to change the type of my GuiObject? That. makes. no. sense.

Imagine if you had to do that in web UX. The designers would go insane.

Okay sure, but if we extend your idea a little further then I could also argue that TextLabel is a silly object since it’s just a Frame with text on it. Better add that text to Frames too then.

Personally I wouldn’t have an issue with collapsing these objects into one and deprecating the unnecessary ones but I can imagine performance-wise it may be useful to have less powerful objects (Frames) and then specialized objects, so that you don’t have to perform specialized checks/procedures for the less powerful objects.

This assumption, while logical, is probably wrong. Or if it is not wrong, it is also not very right and performance is not an issue.

If frames were made to have images, why not make them have text too? Additionally, should scrolling frames get all of these extra properties too, including Style?

Yes.

See the div tag,