Main Menu
Menu

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.

Show posts Menu

Messages - ingar

#16
Hi again,

Thanks. I will try to re-use the RenderWindow.

My application has a main window, and a button for starting a "Setup" window. So what is then the best procedure?

A: Creating a new RenderWindow and a new Gui, as I am doing now
B: Re-using the RenderWindow with a new Gui.
    The change in my code will then be to let the "Back" (or "OK") button just set a "Finish" flag,
    instead of, as now, closing the RenderWindow.
C: Other method?

Ingar




Quote from: texus on 30 April 2019, 15:57:19
tgui::Gui just keeps a pointer to the RenderWindow, it will not destroy the window when the Gui gets destroyed. You only have to make sure not to call functions on the Gui object after the window it uses has been destroyed.

Why do you need a second sf::RenderWindow? Can't you just continue to use the existing window? If you really need a second window then you also need a second Gui that renders to that window.
#17
General Discussion / Re-using RenderWindow
30 April 2019, 15:50:39
Hi,

I have a TGUI app where a screen (dialog) starts another screen (dialog) with a button.
The second screen creates an sf::RenderWindow and attaches this window to a tgui::Gui.
This works, but to construct a new sf::RenderWindow everytime takes time.

Q: Is there a way a new tgui:Gui can reuse a window used by another tgui:Gui?
     The problem, as I can see, is that the render windows also gets destroyed when the Gui is destroyed,
     so that the old Gui crashes when it continues trying to use the destroyed window.
     Perhaps sf::RenderWindow has a copy constructor that doesn't take that long time to execute,
     or there is a way of detaching a window from the Gui?

Ingar

#18
Hi again,

Not so important, but it did not work. I did:

export SFML_ROOT=/usr/local/sfml_251
cmake . -DTGUI_SHARED_LIBS=FALSE
make -j2
sudo make install

Everything worked fine, except static TGUI still uses SHARED sfml libraries.

Linux system is: Native Raspberry Pi board (Raspian Linux (=Debian Stretch)).

Regards,
Ingar

Quote from: texus on 26 April 2019, 17:53:15
That option has to be set to FALSE, but it should be done in cmake (either by unchecking it in the gui or by specifying -DTGUI_SHARED_LIBS=FALSE at the command line). If that option is TRUE then you are building dynamic tgui libraries (which will obviously link to dynamic sfml libraries).
#19
Help requests / MessageBox how to use
26 April 2019, 18:43:47
Hi all,

I am sure this question has been posted many times before, but anyway:

How do I display a message box in TGUI?

I have tried tgui::MessageBox::Create("Heading","Message",{"OK", "Cancel"});
Then I add it to the gui, and it displays in the upper left corner.

But how do I get the events from my buttons (OK or Cancel)?

Can someone give me a complete example. Then I can make a function that just displays the message and returns with a value.

Ingar
#20

Hi texus,

I found this out, because I forgot to tell the Linux loader "ld" where the SFML dynamic libraries where. So I got an error message when trying to run my program.

I changed line 35 in the cmake CMakeLists.txt file, as seen below. But perhaps this wasn't the correct way?

Best Regards,
Ingar

PS: Thanks for your effort. You are really helpful :)

# Add an option for choosing the build type (shared or static)
if(NOT TGUI_OS_IOS AND NOT TGUI_OS_ANDROID)
#    tgui_set_option(TGUI_SHARED_LIBS TRUE BOOL "TRUE to build TGUI as a shared library, FALSE to build it as a static library")
    tgui_set_option(TGUI_SHARED_LIBS FALSE BOOL "TRUE to build TGUI as a shared library, FALSE to build it as a static library")
else()
    if(TGUI_OS_IOS)
        set(TGUI_SHARED_LIBS FALSE)
    elseif(TGUI_OS_ANDROID)
        set(TGUI_SHARED_LIBS TRUE)
    endif()
endif()



Quote from: texus on 25 April 2019, 17:54:51
How did you check which libraries TGUI depends on (to exclude that you are linking to the dynamic libraries yourself, and more importantly so that I can try it here)?

TGUI is supposed to always link in the same way as SFML unless you manually specify otherwise. Did you change some cmake flags? Are you adding defines other than SFML_STATIC in your project?
#21
Hi,

I found another strange thing. Not very important, but anyway:
After I managed to install the TGUI STATIC library, the TGU STATIC library still loads the SFML DYNAMIC libraries.
I would have guessed that a static library should try to use the static libraries of the other modules it depends on.
Does anyone know how to change this, so that my app does not depend on other dynamic libraries?

Ingar
#22
Worked!

Thanks!

Ingar

Quote from: texus on 21 April 2019, 18:08:24
The background color of all rendering is chosen in the window.clear() call. If you want a red background behind everything then you can just do window.clear(sf::Color::Red).
If the gui only fills part of the screen and you want to give it a different color then you can just add a Panel to the gui and add your widgets to the panel.
#23
Hi!

One thing I miss in tgui::Gui:

Setting the background color. Because from what I can see the background color is black. I can do this by creating a Picture widget that has a specific color. But why not have a function tgui::Gui::SetBackgroundColor(...)?

Perhaps I missed something?

Ingar
#24
Hi again,

Thanks a lot. It worked. I used the "loadWidgetsFromStream", since I have automatic the process of embedding
external files in my executable (in this case "form.txt"). TGUI now displays the form created by gui-builder.

Now I think I have one more to figure out: How do I get hold of the control objects created by "loadWidgetsFromStream"?
If I know this, I can start using the controls. After that, I think I will make me a class call CDialog, similar to the one in
Microsoft MFC.

Ingar


Quote from: texus on 12 April 2019, 18:21:18
The Gui class and any container widget have a loadWidgetsFromFile function where you can pass the filename (and a loadWidgetsFromStream function in case you want to load it from memory).
#25
Hi all,

I am very new in this. But one question:
Do I have to decode the form.txt file created by tgui-builder myself, or are there some functions I can call
for decoding the file and creating the window?

Ingar Steinsland
ingar@labelcraft.net
#26
Feature requests / Theme constructor
12 April 2019, 09:17:55
Hi,
I am very impressed of all the work you have done with TGUI. Out of interest: How many developers are working on the project?

Anyway, from the "widgets" test program, I was thinking of the following improvements:

1: Is it possible to add a Theme constructor that takes a theme from memory instead of from file?
    Like the "LoadFromMemory" functions in SFML? In this way, we could prevent users to tamper with
    the theme.
2: Perhaps also make a constructor for predefined themes?
    Something like:

    #define THEME_BLACK         1000
    #define THEME_GRAY           1001

    tgui::Theme theme(THEME_BLACK);

Small things, but anyway.

Ingar Steinsland
ingar@labelcraft.net

#27
Hi again,

WORKED! Thanks a lot. :)

Ingar


Quote from: texus on 09 April 2019, 19:09:56
I didn't notice earlier that your last error was after the TGUI library was already build. Try disabling TGUI_BUILD_GUI_BUILDER when building TGUI. In the cmake gui uncheck the option or in the command line pass -DTGUI_BUILD_GUI_BUILDER=FALSE
This might be a problem with how the gui builder is linked.

Update:
I just tested it here and I also get these errors when TGUI_BUILD_GUI_BUILDER is on (default). I'll look into it.
Disabling the TGUI_BUILD_GUI_BUILDER fixes the issue.

Update 2:
I figured out why the gui-builder is giving these undefined reference errors.

SFML radically changed their cmake script in SFML 2.5 but in order to remain compatible with older SFML versions I added a compatibility layer. Since SFML_DIR is not defined, TGUI is using it's own way to find SFML which was apparently broken for static linking. This has now been fixed in the latest version on github.

However it turns out that if the compatibility layer isn't used (by setting SFML_DIR to /usr/local/lib/cmake/SFML/ or wherever SFML is installed), it will give undefined references to GLX functions instead. I had to manually link to GLX to build statically. This does look like an issue with SFML itself. I'll try to investigate it further in the next few days.
#28
Hi again,
As soon as I also did the dynamic SFML libraries, TGUI installed fine. Also the tgui-builder was made.


Quote from: texus on 09 April 2019, 19:01:02
QuoteI managed to install TGUI as Dynamic Library on my Raspberry PI 386 Debian Linux.
Did you encounter any issues in doing this? It's been a few years since I tested TGUI on a Respberry Pi, so I'm interested to hear whether or not it still works without manual changes.

QuoteIn the long run it creates a lot of support issues.
What kind of problems would you expect? I know it is possible to bundle the .so files with the application. It takes a lot of experimenting and you missed a file which causes it to break on newer linux systems several years later then you just need to ship that extra file. But I would consider the issues with .so files more on a short term, once you figure out how to do it properly it should continue to work on newer systems.

I've never build statically on linux so I can't help much. How did you get the other .a files? I'm not sure if they are all going to be compatible with each other when you download some random versions, but building them yourself is probably too difficult.

XRRQueryVersion and XRRGetScreenResources are part of the xrandr library. So maybe you have an incompatible libxrandr.a file or something?

I don't think this is specific to TGUI, if you reproduce it with only SFML then maybe you could ask it on their forum. Hopefully someone on the SFML forum would be able to help you further. You should try to make your own simple cmake project (which only uses SFML and not TGUI) and see if the issue still occurs, e.g. something like this:
Code (cmake) Select
cmake_minimum_required(VERSION 3.5)
project(CMake-test)

add_executable(Test main.cpp)

set(SFML_STATIC_LIBRARIES TRUE)
find_package(SFML 2 COMPONENTS graphics window system REQUIRED)
target_link_libraries(Test PRIVATE sfml-graphics)

#29
Hi again,

I have now come a bit further:

After 5-6 hours I finally found libxcb-image.a on the net in a .deb file. I manually copied into /usr/lib..
And then "cmake ." worked. But now I get this error when I run "make":

[ 95%] Built target tgui
[ 96%] Linking CXX executable gui-builder
/usr/local/sfml_251/lib/libsfml-window-s.a(WindowImplX11.cpp.o): In function `sf::priv::WindowImplX11::resetVideoMode() [clone .part.12]':
WindowImplX11.cpp:(.text+0x1a1c): undefined reference to `XRRQueryVersion'
WindowImplX11.cpp:(.text+0x1ac1): undefined reference to `XRRGetScreenResources'
.....
And a lit of undefined X functions.

I guess this is X11 not linked in. So somewhere in the many Makefile(s) I need to put "-lX11".
But the question is WHERE? These files are unreadable for me (I am fairly new in this game - previously
brainwashed by Microsoft...).

Any help appreciated.

Ingar
#30
Hi!
I managed to install TGUI as Dynamic Library on my Raspberry PI 386 Debian Linux.
But, DLL dependencies in Windows and .so dependencies in Linux I do not like. In the long run it creates a lot of support issues. Therefore, I try to install TGUI as STATIC library, i.e. making a .a file. But I am running into a problem when running "cmake ." on the TGUI 0.84 source. I get this message:

SFML found but some of its dependencies are missing ( xcb-image)
CMake Error at CMakeLists.txt:206 (message):
  CMake couldn't find SFML.

The problem, I think, is finding the libxcb_image.a library. The .so library files are there:

pi@raspberry:~/TGUI-0.8.4 $ locate libxcb-image
/usr/lib/i386-linux-gnu/libxcb-image.so.0
/usr/lib/i386-linux-gnu/libxcb-image.so.0.0.0

So my question is:
1: How can I get hold of a libxcb-image.a file?
2: Or perhaps I can do something else?

Regards,
Ingar Steinsland
ingar@labelcraft.net