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: Incorporating a form file into a release .exe
« on: 13 February 2020, 08:42:04 »
If the form is stored as a resource in the exe (which is Windows-specific) then you need to load it, get its contents in a string, put this string into an std::stringstream and pass this stringstream to gui.loadWidgetsFromFile.
You can't store your themes in resources without writing your own theme loader though, so you won't be able to easily put everything inside your exe.

Help requests / Re: Highlighting Keywords
« on: 31 January 2020, 18:36:08 »
It's currently not possible to have multiple text colors on the same line. It also won't be added anywhere soon (unless someone were to contribute it).

Next time the signal system gets a rewrite I will try to implement a way to trigger signals from another widget, but it currently isn't possible. But can't you simply bind the same function for both the edit box and button?
void func()
  [If edit box contains something, add a line to chatbox]

  editBox-> setText("");
  editBox->setFocused(true); // In case the user clicked on the button

button->connect("pressed", &func);
editBox->connect("ReturnKeyPressed", &func);

Help requests / Re: "Keyword list"
« on: 27 January 2020, 17:53:46 »
I haven't added it to the tutorial yet (I'll try to do so soon), but you can find the signal supported by each widget in the tgui::Signals namespace:

Thanks for implementing this.

It would indeed be useful. I'll add it to my todo list.
If you want it soon then you will have to implement it yourself though (the code is probably similar to DefaultText in EditBox).

I have solved the issue now in the latest 0.8 version that you can download from github.

I don't know why it gives a linking error for this instead of a compile error, but I was just missing an "ostream" include.

The reason why my CI tests never failed was because I am doing a unity build to speed things up and it must have gotten the ostream include via another source file.

The middle is passed as a (left, top, width, height) rect. If top is 0 and height is equal to the texture height then it splits the image in 3 parts. In this case the left and right parts will keep their ratio while the center part is stretched to fill the remaining of the area.
If the middle part doesn't has the same height as the texture and divides the image in 9 parts then 9-slice scaling is performed. The corners will not be scaled, the top and bottom bar will be stretched only horizontally, the left and right bars will only be stretched vertically and the center part is stretched to fill the remaining area.

The implementation itself is just a matter of creating triangles with the right texture coordinates.

I test TGUI with a CI on mac and that build is still working:
I'm not sure what the difference with your build is (and I don't have enough time to look at it right now), but maybe you can already check what you did differently which could narrow down the issue.

The String class is actually a class that shouldn't really have been added to 0.8. The file can't be removed, but almost none of these functions are used. So maybe you can also check if you can compile it if you put String.cpp#L2284-L2294 and String.hpp#L843-L844 in comments. I find it weird that it is giving a linking error for it though, that would imply that those operator<< functions are declared in the std headers but not in the standard library itself.

I'll try having a look at this tonight, but  I unfortunately no longer have a working mac VM to test on, so it might take a couple days before I can run tests here locally.

Help requests / Re: Adding signals to derived widgets
« on: 28 December 2019, 13:18:48 »
Add the following to your derived class.
Signal onGropWidgetPress = {"GropWidgetPressed"};

Signal& getSignal(std::string signalName) override
    if (signalName == onGropWidgetPress.getName().toLower())
        return onGropWidgetPress;
        return Group::getSignal(std::move(signalName));

In your code where you want the callback function to be called you call the emit function:

Help requests / Re: Handling signal "Closed" for ChildWindow.
« on: 15 December 2019, 13:33:38 »
I should probably add it to the onClose signal and at tgui::Signals::ChildWindow::Closed in the documentation. It seems like right now it is only mentioned at the destroy() function.

I wouldn't know which questions to best put in a FAQ. So far I only encountered a single question where I really felt that it belonged in a FAQ (because it was asked a few times already), but I didn't want to create a FAQ with only one question in it. Unfortunately I forgot where I wrote it down so I don't even know what that question was anymore :)

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"}, []{ });

Pages: [1] 2 3 ... 100