Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - texus

Pages: [1] 2 3 ... 100
Help requests / Re: Handling signal "Closed" for ChildWindow.
« on: 09 December 2019, 18:15:53 »
This behavior is intentional, it allows you to block the closing of the window (e.g. to ask the user if he is certain that he wants to close it).
If the "closed" signal isn't connected then the window is destroyed when the close button is pressed, but if you connect to the signal then you have to destroy it yourself.

Help requests / Re: Portability
« on: 08 December 2019, 20:12:39 »
sfml-git package is not required by tgui-git
The tgui-git package requires "sfml" as a dependency, this can either be the actual "sfml" package or the "sfml-git" package. Either one has to be installed in order to install "tgui-git". If neither is installed, the "sfml" package will be installed as dependency when trying to install "tgui-git".

You should however not rely on "sfml-git" nor "tgui-git" at all for any project that you have to show somewhere else. Although it is unlikely to happen, the git version could be broken when I put a newer version online and make some mistake in the code. Although I will likely know about it as the CI will fail, there would be a period where the git version doesn't compile at all and you wouldn't be able to install your project at such time. The "sfml" and unofficial "tgui" packages would be a safer choice.

I don't have access as a user on that computer to install the dependencies
I'm not sure why you are mentioning the sfml-git and tgui-git packages, as I don't see how you would be able to use them in this case.

I have no experience with static linking on linux so I can't help you with that.
I have however been in the scenario where I needed to run a program on a pc without root access. The solution I used was to simply build the dependencies from source on the destination pc. This is of course only possible if gcc and cmake are preinstalled, but that was the case for me. Thinking about it now, I think that SFML was preinstalled, I only had to build TGUI which made the task significantly easier.

First of all you need to find out if you can build SFML on that computer. While TGUI only has SFML as a dependency, SFML has a lot of other dependencies that may not be preinstalled. If you can't build SFML from source (even dynamically) then you have to find another solution (it is possible to run a linux executable on a different pc than it was build on with some care, even when linking dynamically).

Assuming you can build SFML, and assuming you are using cmake for your own project, the easiest solution would probably be to include SFML and TGUI as subfolders to your project and build them together with your project. I haven't actually done this myself, but I know it can work (with some caveats as you will probable have to manually tell TGUI where to find SFML). This way your project can link to the SFML and TGUI targets that were just build and cmake hopefully takes care of finding the libraries even when dynamic linking. If not, you can either overwrite the linker search path when executing the program by setting some environment variable, or link the project with $ORIGIN in the rpath, but you will have to see when you get to this point.

If you get stuck somewhere I might be able to help further, but you may have to experiment a bit yourself first.

Feature requests / Re: Widget for viewing HTML or markdown
« on: 21 November 2019, 20:18:12 »
HTML is rather complex and I'm not sure even a markdown renderer is in the scope of a gui library.

This request consists of 2 phases to me:
1) Create some kind of RichTextLabel that allows rendering text with different colors and text styles.
2) Implement an HTML or markdown widget that uses the RichTextLabel internally.

Although I would love to have both of these things in TGUI, it is very unlikely that the second phase will be implemented unless someone contributes it.
The RichTextLabel is something that is already on the TODO list, but it also shouldn't be expected anywhere soon.

Help requests / Re: tgui::EditBox signal on Unfocused
« on: 19 November 2019, 22:33:42 »
It's not easy to find, but there is a list of signals in the documentation. The available signals can be found under the Public Attributes section. There you can unfold the inherited properties to get a full list of all signals supported by the widget.

In TGUI 0.8.6 I also added a Signals namespace that can be used as alternative to using the strings. You can now use tgui::Signals::EditBox::ReturnKeyPressed instead of "ReturnKeyPressed", which means that auto-complete in an IDE might also give you a list of possible signals. The documentation of these structs also provide a list. I don't think the Signals namespace is mentioned in any tutorials yet, so it also easy to miss.

I always wanted to have a good overview of widgets somewhere, some place where it shows how every widget looks and what signals you can use etc, but I just don't have the time for it.

Help requests / Re: tgui::EditBox signal on Unfocused
« on: 19 November 2019, 20:09:31 »
EditBox also has signals that it inherits from the Widget base class, the "Unfocused" signal is one of them.

Both can be connected at once to the same function like this:
edit->connect({"ReturnKeyPressed", "Unfocused"}, []{ });

Help requests / Re: BitmapButton change image at runtime
« on: 26 October 2019, 19:23:41 »
I use references in function headers to avoid copies, but in combination with a foreign library i fail.
To keep it simple you can assume that Widget::Ptr is a Widget* (so if you copy it then you are just copying the pointer and not the actual widget), but to fully understand how it works you would need to understand std::shared_ptr because Widget::Ptr is just an alias for std::shared_ptr<Widget>.

I know its wrong what i did. (Although i dont know why. I just read that its wrong to have global variables)
There are 2 reasons why global variables are bad. The first one is mostly relevant to larger projects while the second one is typically only relevant for classes.

The first reason is simply because it can make the code harder to understand. Global variables can be changed from anywhere in your code, so it would be harder to follow where the value is changed throughout the code. This is why having "const" variables in global scope isn't a problem, it is only a problem with regular variables that can be changed.

The second reason is because there is no guaranteed order of construction and destruction of global variables across source files. If you have a global variables A and B then they are constructed in the order they appear in your cpp file, but if they appear in different cpp files then A could be constructed either before or after B. This is only a problem if you try to e.g. initialize A with the value of B.
SFML relies on some global variables to work, so if you create an sf::RenderWindow in global scope then it is possible that it crashes because the globals that sf::RenderWindow relies on aren't initialized yet when the window is created. It is also possible to get lucky and have the SFML globals initialized before your window in which case everything works fine, but that is not something you will want to rely on (although you will always get the exact same outcome as long as you don't change your linker settings).

So having a few integers in global scope isn't really a big issue when quickly writing a small piece of code.

Help requests / Re: BitmapButton change image at runtime
« on: 26 October 2019, 18:33:25 »
Actually putting those variables in the header isn't a good solution (I'm not even sure why it would work).
When I told you to use "=", I wasn't really looking at your code. The EraserON and Hue values probably still need to be passed as references to the lambda, by using "=" instead of "&" you are making copies of them and you would be changing a local variable inside the lambda instead of the variable that you had outside. You might want to look up how lambdas work, but the "=" and "&" are just the defaults for the variables. To pass some variables by value and some by reference you would do something like
slider->connect("ValueChanged", [&,slider]() { Hue = slider->getValue(); }); // All variables passed by reference except slider
slider->connect("ValueChanged", [=,&Hue]() { Hue = slider->getValue(); }); // All variables passed by value except Hue

When you choose a tool then the button stays pressed.
When u choose another tool then this button stays pressed and the previous goes back to unpressed.
I dont know if BitmapButton is the right choice here.
You might want to use RadioButton widgets for this. The downside is that the RadioButton places its text next to the image, so if you need text on top of the button then you would have to add a Label in front of it manually on which you call isIgnoringMouseEvents() to make sure clicks on the label are passed to the button instead of absorbed by the label. I'm not sure if there are better options, but if you don't need any text then what you need definitely sounds like how radio buttons work.

Help requests / Re: BitmapButton change image at runtime
« on: 26 October 2019, 17:52:53 »
Is the issue resolved when changing the "&" to "=" in the BBTN_Erase->connect line?
You are currently storing a reference in that lambda. If the BBTN_Erase variable goes out of scope (so at the end of the function that contains the code you showed) then this reference will become invalid. This would cause a crash when trying to use the variable when the lambda function is being executed.
The Widget::Ptr is a pointer, so it can be passed by value without having to worry about performance with copying it.

Help requests / Re: BitmapButton change image at runtime
« on: 26 October 2019, 17:14:05 »
It is impossible for a program to know what variable name you used, the compiler just translates it to an address in memory, so you do need to pass the string yourself
gui.add(BBTN_Erase, "BBTN_Erase");

Help requests / Re: BitmapButton change image at runtime
« on: 26 October 2019, 14:59:19 »
Check if BBTN_Erase is a nullptr when calling BBTN_Erase->setImage. If it is then it means no widget was added to the gui with name "BTTN_Erase".
Are you passing that string as second argument to gui.add?

Feature requests / Re: Missing .pdb files
« on: 13 October 2019, 16:32:56 »
PDB files have been added in TGUI 0.8.6

Help requests / Re: Antialiasing problem with buttons
« on: 10 October 2019, 18:56:19 »
The gui builder shouldn't have different behavior.
However, the widget files created by the gui builder embed the theme in them, so they don't read the theme file when loading them. Maybe you had a changed theme file at the moment you generated the widgets file with the gui builder or at the moment you opened the gui builder? You can check this by seeing if the form file contains the "Smooth" or not, it doesn't contain it by default (since the properties are copied from the theme files which don't have it).

Help requests / Re: Antialiasing problem with buttons
« on: 10 October 2019, 18:01:40 »
Can you try adding "Smooth" behind the texture in the theme file?
So the lines in the Button section in BabyBlue.txt should look like this:
Texture = "BabyBlue.png" Part(269, 40, 90, 60) Middle(30, 0, 30, 60) Smooth;

I never really saw any difference between enabling smoothing on textures before so I just kept the default (which is false in sf::Texture).
Although I can't reproduce the way it looks for you, when zooming in on the button I can see a difference between non-smoothed and smoothed here, so this looks like it might solve your problem.

Help requests / Re: Close button
« on: 07 October 2019, 11:09:57 »
It gives the exception because you are missing a semi-colon behind "ShowTextOnTitleButtons = true".
The parser sees "true CloseButton=&Button" as the value of ShowTextOnTitleButtons, which it considers invalid since it contains an unquoted '=' sign.

Feature requests / Re: Multiple selection items for ListView.
« on: 05 October 2019, 22:17:33 »
So basically the question is what to do in setSelectedItems when setMultiSelect wasn't called yet (or when it was set to false again).

I wanted to look up how other libraries did it and I noticed that in .NET the selected items is a read-only property. Maybe we don't need to have a setSelectedItems at all?
If you do add the function then you can choose what it does, as long as the behavior is documented. When I said that the mode should not be changed automatically I wasn't thinking about a scenario like this, enabling multiselect when calling setSelectedItems with more than one item would be a valid solution. But unless someone has a need for the function maybe it would be better to just not have a setSelectedItems function.

Pages: [1] 2 3 ... 100