Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
Help requests / Re: Converting TGUI 0.6 project to TGUI 0.8.5
« Last post by texus on 11 August 2019, 09:55:18 »
You would basically just have to read the 0.8 tutorials and relearn how widgets are created now and rewrite the code that deals with the gui.
If you don't want to rewrite your code then you will have to stick with 0.6, there have been 4 active years between those two version so a lot has changed (with most of the changes between 0.6 and 0.7).

Looking at the code you basically need the following changes:

Lines like
tgui::Checkbox::Ptr syncbox(gui);
basically have to be changed to
tgui::Checkbox::Ptr syncbox = tgui::Checkbox::create();  // You could use "auto" as type here, to not write "Checkbox" twice
gui.add(syncbox);

In 0.6 I think you still had to have a theme to render something, since 0.7 there actually is a default White theme that gets used if you don't set any theme. I'll just assume you want to keep using the Black theme. You will have to change THEME_CONFIG_FILE to "data/themes/Black.txt" as that is where the new Black theme would be located.

For the Black theme you will have to create a Theme object somewhere. Assuming you only use a single theme you can set it as a default as well. The "theme" object has to remain alive, if the variable is destructed (e.g. when it goes out of scope) then the built-in White theme will automatically be used again.
tgui::Theme theme{THEME_CONFIG_FILE};
tgui::Theme::setDefault(&theme);
If you have a default theme that you want to use then you can just remove lines like
syncbox->load(THEME_CONFIG_FILE);
If you don't have a default theme, then you need to replace the lines with something like
syncbox->setRenderer(theme.getRenderer("CheckBox"));

The biggest difference is probably going to be the callback code. TGUI 0.6 queued callbacks and let you get them later with pollCallback. (This code is so old that I had already forgotten that it used to work like that). Since TGUI 0.7 the callbacks are like interrupts, your callback function will be called immediately. You should definitely read the signal tutorial.
How you need to change the code depends on the structure of your code. If your code is really all in one big main function, then you should actually be able to port it without too much changes.
knob1->bindCallback(tgui::Knob::ValueChanged);
knob1->setCallbackId(Knob_CALLBACK_ID + 1);
and
case Knob_CALLBACK_ID + 1:
{
        [...]
        break;
}
would become
knob1->connect("ValueChanged", [&]{
    [...]
});

Those are just the differences that I saw when scrolling to the code. It is possible that there are other differences, but the biggest changes happened in the way widgets are created and their events. The functions of the widgets themselves (e.g. setPosition, addItem, setSelectedItem, etc.) will mostly be compatible.
22
Help requests / Converting TGUI 0.6 project to TGUI 0.8.5
« Last post by Hexile on 11 August 2019, 04:14:03 »
So a while back I was working on something using TGUI 0.6 and now i'd like to move onto TGUI 0.8 only grabbing the basic import and event setup.

However, as there is still documentation missing. I'm not sure how to do this.

Should i really go back to 0.6 ?  :-\

i've attached the source of the old project after removing parts that were too similar.
23
Feature requests / Re: TGUI builder 0.8.5 - missing vertical slider
« Last post by Hexile on 11 August 2019, 01:39:33 »
Quote
The option is missing.
You actually just have to set the Height to a larger value than the Width. I'll put on my todo list that I should add a property for it in the gui builder to make it more intuitive, because someone else recently had the same problem with a Slider and I agree that it isn't obvious at all.
Alright.

Quote
Also; If possible, it would be nice if we could set the angles of scrollbars, sliders, etc.
When rotating over an angle other than 90° there is no more obvious definition about where the top left position actually is. There are multiple ways the scrollbar could be positioned after e.g. a 45° turn. I've never seen diagonal scrollbar, is there a use case that you have in mind where you would need to rotate it over such a non-standard angle?

I do agree that beyond 45 degrees do not make sense, however, i'm interested in replicating the EQ sliders on an obscure hifi unit i saw a while back.
Instead of them being vertical |||||| they were slanted/angled like //////
24
Feature requests / Re: Gui-builder - add work with menu(MenuBar,Menu,MenuItem)
« Last post by texus on 10 August 2019, 22:54:30 »
The MenuBar widget is a bit more complicated than most widgets. I would somehow need to provide an interface to set the menus and their items. I would also need to serialize the menus (including potential submenus) into a single string, preferable without newlines.

The serialization problem could easily be solved if I just use the same format that I currently use for saving a MenuBar to a text file and just replace the newlines with spaces, although maybe there are better alternatives.
The thing that will take more work is providing a form where you can change the properties without having the manually type in the serialized string by hand. The thing I have in mind is something similar to how items of a ListBox are set, but with a TreeView to display the menus. The ability to enable and disable any item complicates this a bit more.

I recently added ChatBox and TreeView widgets to the gui builder, but only because they could be added without a way to set their items at design time. For a menu bar, being able to set the menus at design time is more important so I really do need to provide a way to input the menus. Unfortunately I currently don't have the motivation to actually implement it, I haven't been able to get myself to work on any non-trivial features in TGUI lately.
25
Feature requests / Re: TGUI builder 0.8.5 - missing vertical slider
« Last post by texus on 10 August 2019, 22:40:14 »
Quote
The option is missing.
You actually just have to set the Height to a larger value than the Width. I'll put on my todo list that I should add a property for it in the gui builder to make it more intuitive, because someone else recently had the same problem with a Slider and I agree that it isn't obvious at all.

Quote
Also; If possible, it would be nice if we could set the angles of scrollbars, sliders, etc.
When rotating over an angle other than 90° there is no more obvious definition about where the top left position actually is. There are multiple ways the scrollbar could be positioned after e.g. a 45° turn. I've never seen diagonal scrollbar, is there a use case that you have in mind where you would need to rotate it over such a non-standard angle?
26
Feature requests / Gui-builder - add work with menu(MenuBar,Menu,MenuItem)
« Last post by Kvaz1r on 10 August 2019, 21:58:03 »
It's a very common controls so it would be great have opportunity use them from builder.
27
Feature requests / TGUI builder 0.8.5 - missing vertical slider
« Last post by Hexile on 10 August 2019, 20:45:27 »
Hi. The option is missing. did it get removed from the builder?

Also; If possible, it would be nice if we could set the angles of scrollbars, sliders, etc.
28
Help requests / Re: menu bar colors when enabled/disabled
« Last post by roccio on 10 August 2019, 16:26:52 »
Thanks fot the help, will try your solution to change the text.

Fot the future I like most the first solution as it is more clear and more consistent with the other functions.
The image would be a great update, but better would be to have a checkbox.

Best regards
29
Help requests / Re: Binding function calls in tgui::SignalWidgetBase::connect()
« Last post by Hexade on 09 August 2019, 23:33:11 »
Alright, that clears everything up then. Thanks a lot for the help and clarification.
30
Help requests / Re: Binding function calls in tgui::SignalWidgetBase::connect()
« Last post by texus on 09 August 2019, 23:13:02 »
Quote
My need for std::bind is a bit more complex than this example
If you had tried a simple case first then maybe it could have saved you some time with trying different things :).
After some debugging, trying to compile the code you described, I decided to just check the most basic code that you mentioned at the top. It didn't work either.

It turns out there is a good reason why it isn't in the 0.8 tutorial, it simply no longer works.
The reason it used to work was more of a side-effect of the way my internal code worked, it was never an intended feature to have (although I did document it in the tutorial after I found out about it). All parameters passed to the connect function were passed to std::bind inside the signal class. The getNum function being called at the moment func1 is called was a consequence of passing an std::bind argument as parameter to an std::bind call. In 0.8 I don't use std::bind anymore however. I've learned that lambdas are both faster and more powerful and saw no more use to rely on std::bind in my implementation.

The quick solution should have been to just surround everything with the std::bind that used to be inside the connect function...
button_image->connect("MouseEntered", std::bind(&TitleMenuButton::ButtonFocused, this, std::ref(button_selected), std::ref(current_button), std::bind(get_button_function, current_button)));
... but that unfortunately doesn't work. My new signal system in 0.8 doesn't seem to like the argument being a bind expression (which acts really weird). (EDIT: Although I don't recommend doing it like this, I do consider this a bug. So I will try to change the code soon so that the above line does work.)

I would recommend just not using std::bind at all:
button_image->connect("MouseEntered", [&,get_button_function]{ ButtonFocused(button_selected, current_button, get_button_function(current_button)); });

In the above line, the get_button_function is passed as a copy to the lambda because unlike the other parameters it is a local variable and thus a reference to it won't be valid anymore when the MouseEntered event occurs. The "&" makes sure the other parameters do get passed as a reference.
Pages: 1 2 [3] 4 5 ... 10