Some more GUI instances [ ColorInversion, Colorizer ]

My idea is basically to have 2 more GUI objects:

  • ColorInversion
  • Colorizer

Basically, the ColorInversion object will take every object in the GUI object and flip it’s colors. This would also work for ImageLabels’ image color.

The colorizer object would act similar to the Decal Color3 property. This would also have a second slider for brightness, (which would change the brightness of all GUI objects.)

GUI objects, such as Frames, ImageLabels, TextLabels, etc. could have a property called “ExemptFromColorObjects” or something similar - which would make them unaffected by the two objects listed above.

Currently, I find it too hard to have themes for UIs (which is something I want for my games so there will be more customization in my games.) This would also work quite well for plugin interfaces as well.

6 Likes

The main force behind a feature request is the problem, not the solution (I know, the name is a bit misleading, but it shouldn’t exactly be called ‘Complaint Category’, should it?). There are exceptions, but this is the general format.

For an almost superficial feature like this, I think that must be accounted for when writing your thread. The engineers can usually come up with a solution on their own if a problem is worth it, too. Bloat features that are wanted just because they’ll be cool won’t be added. Just a friendly reminder :wink:


This is your issue, however your solution provides 2 unrelated objects, one of which has nothing to do with the problem.
Evilly :evil: shooting your idea down further, the remaining Colorizer object wouldn’t work well for color themes that have more than one customizable color (AKA most themes).

Alternate solution

Another idea is to have a single object with lots of different ‘keys’ (similar to how localisation tables work), except these keys would be written in a property in GUI objects and would all be for a single color pallette.

For example, a TextLabel’s TextColor3 could have its ‘color key’ be set to text*. This would reference the text key in the associated Colorizer object:

{ -- table representation
text = Color3.new(1, 1, 1),
frame = Color3.new(0.2, 02, 02),
shadow = Color3.new(0, 0, 0)
}

These Colorizer objects could be swapped out with other objects to change themes.

* This would also require the Color3 property to be modified to support this object (unless we want the written color key to apply to every Color3 value in the object, which wouldn’t be very good).


The problem is interesting, although to be honest I’m not sure if it’s a big issue.

You can pretty easily (if you’re a scripter) make a system to support different themes if you were to give things CollectionService tags, value objects, or even coded properties (e.g. having a Color3 of 0.5, 0.5, 0.5 would mean the object uses the abstract ‘Frame’ color, which would vary from theme to theme).

3 Likes

I’m not entirely sure how my problem doesn’t fit the two objects I requested - and they could be enabled/disabled like the ColorCorrection object for lighting/camera.

Also, according to most descriptions of this forum, my idea fits perfectly with the vain of the description of said forum. :stuck_out_tongue:

I also probably should have mentioned that the Colorizer object would be relative to existing Color3 values - so no internal modifying of the Color3 object.

How many use cases are there for using colors relatively?

As a fairly experienced UI designer, the only cases where I have used relative colors are for having certain greyscale images change color (e.g. team color of the team that won the round).

However, note that I said greyscale images. I never actually use relative colors as relative colors.
Unless you have a very specific, niche theme, relative colors are almost never used. It could just be me, though.


Mhm, but look at the feature request template. It doesn’t ask to give any solutions or ideas. It asks you what the problem is and how fixing it would help you. That should usually then be the focus of a feature request. Also note that this is what I have been told, and have read, during my time on the DevForum.

> Please complete one of the following sentences:
> As a Roblox developer, it is currently too hard to . . .
> As a Roblox developer, it is currently impossible to . . .

> If Roblox is able to address your issue, how would it improve your game and/or your development experience? Please be as specific as possible.


The questions I am asking to myself about your solutions are:

  1. Are they actually needed, or would they just be cool to have?
    i. Is it easy to do already?
  2. Would they be used a lot, or just there to bloat the engine?
  3. Are there better implementations?
  4. Can I think of a way to make a theme switching system using the suggested solutions?

[Q1/2] Having color inversion would be cool… but how many times would we use it? [Q1] I’ve never had a use case for this before (although I considered making a Persona-style UI once). [Q2] How many games have you seen that have even attempted to invert colors?

[Q1/1i/2] And although having an official way to make a theme switcher would be cool, it’s not too hard to script and the only use case I can come up for it is switching themes (something most players in a popular game wouldn’t care about anyway, given their mean age).

[Q4] Honestly, I’m trying to figure out how a relative theme changing system would work. It’d be annoying to design, as I’d only be able to use 1 automatically-applied color and everything else would need to be set manually. [Q3] My solution idea in my previous post addresses this I think. At this stage, I don’t see your idea in a state that would be good to use.


This is very opinionated, as the way people can visualise your idea is subjective, but I think I am raising valid concerns (and either way, it reinforces & clarifies your argument if you beat me :slightly_smiling_face: )

If you’re wondering why I am so interested in breaking down your ideas, asking questions about whether they’ll be used or not, etc. etc., it’s because that’s what Roblox staff do when looking at feature requests. Time & resources are finite, and Roblox already has a lot on their plate.

It would be great if we could have tons of cool UI features (cough actually we are missing out on a lot of useful stuff cough) but there’s more to Roblox than that.

The important part of a feature request is the ‘why’, just like in game design and product design (at least from my experience as a developer and as a student).

Idk, I’ll rest my case here.

1 Like

After thinking about it somemore, I feel it’d be a nicer feature to have for the developer specifically - i.e. if you want to invert the colors from say, blue and white, you could quickly change all GUI elements to red and black - which would be extremely helpful if you have hundreds of GUI elements that need a color swap.

The Colorizer would work in the same aspect, but the color change would be relative, i.e. if you select a color in the Red spectrum, it would change all GUI colors relative to the red area.

A good example of this would be PaintDOTNet’s Hue/Saturation under it’s Adjustments tab.

Of course, these objects could be used for making themes much, much easier on the player, but I also think they’d be extremely helpful in allowing a developer to quickly and efficiently change the colors of a GUI.

Perhaps I’ll write a plugin for that? :wink:

(( If of course, my idea isn’t as good as I thought it was. :stuck_out_tongue: ))

1 Like

Yeah, sure man, that’d be fine (and I might use it too!) :wink:

At this stage I think what would really be useful would be shaders (so we can code custom color inverters and stuff).

2 Likes