Those seem not really full solutions. As the first one only handles layout (which is one of the simpler things in a GUI library) and the second doesn’t seem to be a renderer at all, rather like HTML parser + web page crawler.
1 Like
static text you can just draw, text boxes you have to allow cursor nonsense, selecting, and stuff like that, plus there’s still all the other features i mentioned
1 Like
Anything good on this list?
GTK+ looks like it had updates this year. Don’t know if they hook into OGRE.
Well, yes, the selecting part is a bit difficult to make properly, but luckily it isn’t needed right away. And the current insert position with a cursor isn’t the most difficult thing, just one more thing that takes a bit of time.
You have to allow selection to a level where at the very least you can tell which text box is active
if there is one, and also make sure it doesn’t mess up all the hotkeys
1 Like
I have checked that list in the past and I don’t think there is anything better. It’s mostly desktop toolkits, which don’t work great with embedding.
I have used GTK in the past and in theory what you can do is render Ogre inside GTK (as it is a full desktop GUI toolkit it is difficult to go the other way), but that is pretty volatile setup and getting GTK building on windows is pretty damn difficult.
I was talking about selecting the text areas and doing copy+paste with the selected text. Highlighting an active widget isn’t what I’m worried about.
At this point you are just listing work that would need to done on this hypothetical leviathan gui library, im sure he thought of these things, hes been annoyed by the gui for months, and had talked about it all the time. Im more worried about the delay it would impart, im not afriad to have to rewrite the gui, in some new library, i just hate the idea of taking 6 months to get 0.4.2 or 0.4.1 out. I dont want any more long delays before releases. Our community quite literally degenerated in that time frame.
what i’m trying to say is that it’s not just adding all the features we need now, we will also need features later, and not having them would mean we would have to code them when we needed them. It would be good if we didn’t stop someone from making an options menu just because they don’t know how to code a slider.
1 Like
I’ve managed to reason to myself that this GUI change wouldn’t really cause release delays.
As it can first be prepared by me without any impact on Thrive development, other than my already limited time, it’s going to be a really tough semester for me, being put to something else. But even with that the release timeframe wouldn’t be hugely affected as I think I may have more motivation to work on a new GUI library instead of working away on the issues on github. The only thing this would delay is implementing a new looking GUI.
I wouldn’t trust such a person to properly code applying the changes without having to restart to the resolution, fullscreen, sound device and maybe even key rebindings. So I think anyway I have to write the options menu, unless @Higami gets even more involved with the engine.
I meant the options menu as an example, you would also need things like that in the editor (for example the appearance editor).
I’m currently looking towards getting more involved with the engine side, but it’s going to take a long time before I’m capable of adding something as big as an options menu
2 Likes
If you expose stuff to the angelscript/thrive, you dont need to code an options menu, just the basic functionality stuff of changing global volume (which is in there already, so i could make an options menu and call that) , you arent the only person who works on issues. The whole thing of changing the way our gui works means that there are alot of issues WE cant work on until you are done writing your own gui library or something, which i think is a problem.
1 Like
For example i wanted to get an appearance editor in 0.4.1and have a plan for that, but if we have to wait on a new gui, i cant work on that. and a ton of other examples.
Hopefully most of the needed GUI controls would already be done once we start needing them all over the place.
Sure, but that’s part of the problem. I need to make code for switching into fullscreen mode, etc. and also save it to the configuration file. The actual GUI part of the options menu is not a huge amount of work if the backend stuff isn’t factored into it.
I get that, but now that 0.4.1 features were locked down the only GUI thing (I think) is selecting what type of membrane the player wants and that’s just a small GUI change, and hopefully won’t be a problem to convert over later.
So I think the perfect time to work on a new GUI system is in the background while 0.4.1 is being made.
Yep, that’s a bit cumbersome if you planned on adding colour selecting etc. there. But that wasn’t selected as an issue for 0.4.1, so…
I don’t think that was included in 0.4.1 here: 0.4.1 Features Discussion Thread
Edit: I cleared the milestone on that issue
I have the groundwork in there for a behavior editor too, /: with the new AI behavior values.
I think re this GUI situation: If it is possible to shore up the system we have been using so that it’s good enough then that would be good. It seems having an HTML + JS gui works well for the team and it is already installed and working. I’d like to try to make some decent progress over the next period.
However I understand that it’s not wise to build on rotten foundations just because that is easier. So I guess really it’s up to you @hhyyrylainen as I don’t have the knowledge to judge. If the GUI engine needs to be replaced then it’s ok with me for you to make that decision and do the replacement. However if there’s a way we can avoid doing it that might be better, just because it would save a lot of effort.
I think if you do the replacement it would be interesting to think about what the minimum features we need are. For example I’m not sure we need sliders, a lot of games have a “left button + right button” setup for moving things on a scale which are like a slider but are just actually clickable buttons.
Making changes to the GUI has been great with CEF and productive as well. But the technical issues with it are bad, and unfortunately, no matter how well it works for us developers it is extremely bad if the GUI library limits play sessions to a maximum of a few hours due to it glitching out, it just isn’t going to work for the long term.
I’ll start with basic stuff. My goal is to be able to replace maybe just the main menu or the microbe stage HUD at first and leave all the rest unchanged. I’ll report back once I make progress.
1 Like