It seems declaring GUIStyle as a var always creates a new style; it is not a project resource. This makes re-using existing styles a PITA (and is inconsistent with other resource usage in Unity).
Example: Typically if i access a resource of var type Texture2D, then the inspector for that var sees all objects of type Texture2D in the project. However, this is not the case when declaring a var as type GUIStyle… it creates a new GUIStyle right then and there.
Consistency is a big part of what makes a good interface (more than is often realized) so naturally I wish to make a few styles and reuse them in various GUI scripts.
The current “non-project resource” implementation of GUIStyle seems to encourage that if I wish to reuse a style I must: - create a GUI script with the GUIStyle, setting all the many vars as I desire
in my other GUI script, manually recreate the style, manually copying all the settings (did I mention there are many variables!?)
recreate it again for each individual GUI script
repeat ad nauseum E.g. it gets inefficient very quickly if I want to reuse styles.
To avoid this, I’m currently creating GUIStyles in a single GUIManager class, then using an helper function GetGUIStyle() to access them in individual GUI scripts, via string parsing.
Although it “works” this seems a very primitive way to deal with such a resource, in contrast to how Unity otherwise adeptly deals with resources (adding, the current approach also makes using @script ExecuteInEditMode() useless for GUI scripts, creating yet another step between creating the GUI and seeing the result).
Why is GUIStyle not a project resource? Am I missing a fundamental aspect of the new GUI paradigm here?
It’s not much of an issue if you always use the default style, but as nice as it is, I don’t always want to use Arial and do not want my GUI looking like every other Unity game, so the default is not very interesting as a creator.
Just use Asset->Create->GUI Skin, and work with that.
The default one is just for convenience, so you don’t have to create the look before beginning to work… of course we don’t expect that many games will be re-using the default skin, good looking as it is.
Asset->Create->GUI Skin will create a duplicate of the stock base skin in your project folder that you can customize.
If you want to duplicate your customized skin to make further modifications (say to re-skin custom styles), you can just duplicate it in the Project view like any other asset (and package it to copy between projects, etc.)
Sorry I wasn’t more specific. Was referring more to the fact that the images used in the default skin cannot be accessed otherwise (try it).
It’s “there” in the default skin you created, but you cannot access it directly or restore it if you try another image, and want to switch back.
A quick look seems that the default skin images are not in the Unity.app package either, so extending from it is also out of the question (until the images are released publically).
It seems strange the new GUI system doesn’t encourage a trial refine flow (the heart of all good interactive content), as much as the rest of Unity encourages it (the most major and useful selling point imo).
It’s the same with the default particle texture… just quirky that it’s “there” but “not there”.
Ah, OK. Here’s the built-in skin (distributed during the testing phase of 2.0). You can install it in your project to revert back to it, as well as to modifiy the individual elements.
I see your point. But if you instantiate a new copy of the GUISkin, and install the source images in your project, you can swap textures around to your heart’s content. It’s true that there’s no automatic “revert” to the “original copy”, but with the source images, you can pretty quickly reset them to the same image as used in the default skin.
I don’t mean to dismiss your issue, but I have felt very free to experiment and haven’t had too much trouble putting things back if I needed.
