Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
Help requests / The implementation of "Middle" parameter on themes syntax
« Last post by Maksat on 07 January 2020, 14:49:11 »
Hi Texus! Could you tell me how you implemented the "Middle" parameter on themes syntax? How do you scale given rect of texture and remain unchanged other parts?
22
Installation help / Re: Linking error with TGUI 0.8.6 on OSX using Clang
« Last post by N0things on 07 January 2020, 11:06:24 »
I followed your advice regarding the String class, I then made a patch to remove the useless methods and it is now working well, somehow.

Thanks for your help.
23
Installation help / Re: Linking error with TGUI 0.8.6 on OSX using Clang
« Last post by texus on 07 January 2020, 08:17:11 »
I test TGUI with a CI on mac and that build is still working: https://travis-ci.org/texus/TGUI/jobs/632626868
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.
24
Installation help / Linking error with TGUI 0.8.6 on OSX using Clang
« Last post by N0things on 07 January 2020, 07:18:43 »
Hello,

I am currently making a little project using SFML (2.5.1) and TGUI (0.8, the current stable one) with CMake. I am building SFML and TGUI from sources before building my project, however I can't manage to build TGUI 0.8 correctly on OSX (macOS Mojave 10.14.6) using Clang.

I figured out that, by changing the branch from 0.8 to 0.7, TGUI compiles successfully. I can not get satisfied with this however because I am using some 0.8 features. Here is the piece of log that describes my error :

Code: [Select]
[ 95%] Linking CXX shared library ../../lib/libtgui.dylib
Undefined symbols for architecture x86_64:
  "std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<<<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
      tgui::operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, tgui::String const&) in String.cpp.o
  "std::__1::basic_ostream<wchar_t, std::__1::char_traits<wchar_t> >& std::__1::operator<<<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> >(std::__1::basic_ostream<wchar_t, std::__1::char_traits<wchar_t> >&, std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> > const&)", referenced from:
      tgui::operator<<(std::__1::basic_ostream<wchar_t, std::__1::char_traits<wchar_t> >&, tgui::String const&) in String.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [lib/libtgui.0.8.6.dylib] Error 1
make[1]: *** [src/TGUI/CMakeFiles/tgui.dir/all] Error 2
make: *** [all] Error 2

I don't know if I did something wrong, but I developed this project few months ago and everything worked fine with TGUI 0.8 back in this time. Now, I just wanted to add a bit of continuous integration to the project with linux (works fine with Gitlab-CI) and osx (fails with Travis-CI).

Here is my Travis-CI log for OSX : https://travis-ci.com/matthieu-locussol/golPlayground/jobs/272932475, interesting log informations are under the (line 88) $ sudo ./INSTALL.sh command. The source code for my project is therefore on Github (you can access it using Travis) if you need to look at the CMake files / Installation file.

If you need any other information let me know, I am a bit desperate as I've been investigating this issue for a few days now. Thank you in advance for your time :)
25
Help requests / Re: Adding signals to derived widgets
« Last post by Maksat on 28 December 2019, 15:37:14 »
It worked! Thanks!
26
Help requests / Re: Adding signals to derived widgets
« Last post by texus 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;
    else
        return Group::getSignal(std::move(signalName));
}

In your code where you want the callback function to be called you call the emit function:
onGropWidgetPress.emit(this);
27
Help requests / Adding signals to derived widgets
« Last post by Maksat on 28 December 2019, 13:08:52 »
Hello! I made class inherited from tgui::Group, which contains some other widgets. Is it possible to add new signal like "GropWidgetPressed" so I could use it like this:
myGroupWidget.connect("GropWidgetPressed", [](){});
 
28
Help requests / Re: Handling signal "Closed" for ChildWindow.
« Last post by texus 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 :)
29
Help requests / Re: Handling signal "Closed" for ChildWindow.
« Last post by Kvaz1r on 15 December 2019, 13:22:55 »
Right, "vetoing" mechanism. Maybe it worth to mention about the behaviour in documentation or gather such non-always obvious questions in special FAQ topic on the forum.
30
Help requests / Re: Handling signal "Closed" for ChildWindow.
« Last post by texus 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.
Pages: 1 2 [3] 4 5 ... 10