- All of the GUI related code and style are removed from screens, making it easy to change them directly without worrying about the errors.
But :/ The style are already mostly independent of the screens. The "navigation" screen by example, have only three styling information :
Code:
xpos gui.navigation_xpos
yalign 0.5
spacing gui.navigation_spacing
Two of them are totally independent of the screen, since they refer to external variables, and the third one (the
yalign) is present in your version (that also define an
xalign) :
- All comments are removed, pros don't need those (will add back renpy licensing at some point)
Please, don't tell this to my boss, he really think that his society is full of professional programmers.
- The screens are broken into files for faster access and less scrolling.
Which will be useful only when you'll have duplicated all the screens. Actually the user will have to edit the "screens.rpy" file, to keep only the screens "about", "history", "help", "keyboard_help", "mouse_help", "gamepad_help", and "nvl_dialogue". He'll also have to get ride of few things, like by example the
default quick_menu = True line.
Plus, nowadays almost all (if not all) the text editor oriented coding have a fast jumping feature. Find the screen you want to access, double click on it, and no need to scroll.
This for a screen that you'll edit once. Yet if really you edit it, since most of the time changing the style is enough, and it can be done from the "script.rpy" file.
- The interface is animated with a single transform, making it easy to get a new look out of the interface animation with few changes.
This, it's an interesting feature.
- The style of screen elements can be changed by modifying few lines of code.
Like I said previously, Ren'py already do this, and do it better than 0gui. I'll keep my previous example.
If you want to change the idle and selected color of the buttons for the main menu and game menu, with Ren'py's gui, you just need those two lines :
Code:
define gui.navigation_button_text_idle_color = "#0F12FF"
define gui.navigation_button_text_selected_color = "#FF120F"
With 0gui, you'll need to edit/update the style of the main menu and the game menu to achieve this :
Code:
style mm_button_text:
idle_color "#0F12FF"
selected_color "#FF120F"
style nav_button_text:
idle_color "#0F12FF"
selected_color "#FF120F"
This because of two limitations of 0gui :
Firstly, when you define the "text color", it apply to all the texts, for all the screens, because you only define one style, the "default" one.
Secondly, you can only choose the base color, it's 0gui that will take care of the declination of the color for the "selected", "hover" and "hover_selected" colors.
- It is independent of any images, you can remove everything in GUI folder except the window icon.
This also I have already said it, it's exactly the same with the actual gui. You can get ride of all the images if you want. You don't want a background image for the main menu ? Just write this in the "script.rpy" file :
Code:
define gui.main_menu_background = None
But, at the opposite, if you want you own image as background for the main menu, you just need to write this, still in the "script.rpy" file (and obviously put the image in the "images" folder) :
Code:
define gui.main_menu_background = "myOwnBackGround.png"
While you'll need to edit the "main_menu" screen of 0gui to achieve the same result.
- You can remove or change part of the interface by simply removing or swapping their files, no coding required.
Which present really few interest. Once you've designed your screens, you rarely go back at them.
- Additional functions are added to the interface
Which isn't related to the gui.
- It is being improved constantly
Like Ren'py.
- Mobile variations are developed separately and fitted for touch. and you can swap two folders for different builds instead of including both interfaces in the build.
Yet something I already talked about. This imply more works for the author of the game, since he need to maintain two projects, or remember to swap the folder each time he'll build a distribution.
- The look of interface can be changed by giving it a small image to use as frame
But it's the only thing that can be changed without the need to edit/update the style. Unlike with the actual gui, that just need the update of a variable.
the fact that you don't like some of the changes doesn't mean you can dismiss all of them.
Could it be the reason why I said that "The idea is interesting, but it's look more like an attempt to add a new looks to Ren'py interface (which isn't at all a bad idea), than an effective new feature." ?
Sorry but yes you are bringing back themes to Ren'py. 0gui is more rigid than the actual screens are.
By example, with the actual gui, if you want the main_menu to be somewhere else than at the left side, you just need to change the value of
gui.navigation_xpos. If you want to achieve the same with 0gui, once again you'll have to edit the "nav" style to overwrite the fact that everything is centered by default. And the same apply for everything else. I already talked about the color above, but it also apply for the background, the padding and the spacing.
With the actual gui, you just need to change or define a value in the "script.rpy" file, while with 0gui, you'll need to update the right style.
Look above about everything I said. Actually to change the style of a screen, you just need to change the value of a
gui.something variable. And when it happen that it's something not handled by the actual gui, then you just need to update the style in the "script.rpy" file, which is anyway what you'll need to to with 0gui.
So, I stay on what I said, it's already easy to change the style of a screen, and it need really few lines of code. Especially since, unlike with 0gui, the style of each screen is independent of the style of the other screens by default.
[...] I wouldn't be supprise if they show up in your work sometime soon, you just have to get past your prejudice agains it.
Er... Firstly, I don't have prejudice against 0gui, I wanted to understand it better. And I stay on what I said, as theme for the GUI, it's something interesting and easy to use, but it's nothing near to an effective gui.
Secondly, I'm more than sure that it will never show up in my works. 0gui is way too limited for what I usually do. Have you take a look at the scroll bars in the screenshot of my previous comment ? You can't do this with 0gui without redefining the whole style of the said bar. Same for the buttons. It's not visible in the screenshots, but they act as button in relief, changing the effect when you press them. This while some buttons are highlighted when selected, while other aren't, and highlighted with a contrasted color, not with a variation of the defined color like with 0gui. Anyway, the color of the buttons aren't fixed, it can be white, blue or green, depending of exterior factors.
Obviously, all of this need the definition of a style with the actual gui... but it need the exact same works with 0gui. So, there's no advantage, at least for me, in its use.
All this doesn't mean that I don't like it or anything else, just that it's not a gui, it's a theme. It would be way more interesting, and useful, if instead of trying to make a gui that isn't one, you would have added functionalities over the actual gui. The auto declination of the colors, by example, is something that can be useful. You also have good idea for the transform, and a transform bank is something that can help many people.
The addition of sound is also something interesting. But as addition to the actual gui, not as forced feature of 0gui like is the fact that everything is centered unless you explicitly define a style to say that it shouldn't.
but please don't show of your own work under this topic, it's unrelated and causes lots of scrooling.
Don't worry about this, I have my own threads for that. Just don't assume what the other do or not next time, and it will not happen again. But you're right, I should have put them into spoiler from the start.
