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

#1
Help requests / Re: Changing font size for a widget
15 September 2020, 01:17:04
Stupid me:

I overlooked getTextsize and setTextsize functions.

Ingar
#2
Help requests / Changing font size for a widget
15 September 2020, 00:47:56
Hi.

I have a "tgui::Label::Ptr" for a widget created by guibuilder.

I want to change the font size for the widget.
What is the best way?

Ingar
#3
Help requests / Re: Screen sizing
12 September 2020, 07:51:13
Quote from: texus on 11 September 2020, 17:50:04
This is the default SFML behavior (which I am no longer using in 0.9-dev exactly because most people probably don't want it).
You have to call gui.setView when you receive the Resized event, using the a view with rect (0, 0, newWindowWidth, newWindowHeight).
Code (cpp) Select
gui.setView(sf::View(sf::FloatRect(0.f, 0.f, static_cast<float>(event.size.width), static_cast<float>(event.size.height))));

Worked!
Thanks :)
#4
Help requests / Screen sizing
11 September 2020, 17:39:10
Hi all,
I want to make an extension to my Raspberry Pi app that allows my program to run on different screen sizes.
I could make a table containing some information for every widget on the screen in terms of position and size, in order
to control the position and size of the controls.

I have seen, though, that if I make a SIZEABLE TGUI screen, TGUI somehow stretches/shrinks my controls according to the
main window size. This is something I do not want, since I want to be in the driver's seat myself.

Q: Is there a way to disable this option?
     I tried to test for the sf::Event::EventType::Resized in the message loop, and do not call gui.handleEvent for than event.
     But that didn't seem to have ant effect.

Ingar
#5
General Discussion / Re: TGUI and Unicode
04 June 2019, 21:05:01
Worked! :)

But I wonder what Mikkesoft is doing. Because their font files are about 1Mb in size, and I have never
had problems to display Unicode Asian characters.

Ingar
#6
General Discussion / Re: TGUI and Unicode
04 June 2019, 19:48:26
Thanks a lot. I will try that.
#7
General Discussion / Re: TGUI and Unicode
04 June 2019, 16:38:35
HI again,

Arial is one of the most commonly used fonts used by Windows, and does indeed support Japanese and other Asian languages.
I also tried Tahoma. This font also displays just about everything.

One thing I haven't tried is to use the font in an SFML only app I have (i.e. without any tgui components).

Ingar


Quote from: texus on 04 June 2019, 16:22:00
I don't see anything wrong with your steps.

Maybe storing the buffer in an std::string can be skipped if fromUtf8 supports a begin and end pointer (I'm not sure if it does), but it will work equally well when first stored in an std::string.

The type is Uint32 because it stores the string as UTF32. Two bytes wouldn't be enough to store ALL possible unicode characters.

If squares are displayed then it would mean that the chosen font (arial.ttf in this case) does not contain these japanese characters.
#8
General Discussion / Re: TGUI and Unicode
04 June 2019, 16:13:42
Hi again,

I am still having problems with tgui/sfml and Unicode. I have a server returning UTF8 data in a character buffer.
The data may contain Asian characters.

I have previously received some very useful help here, so I am thinking I am doing things the correct way:

First I am creating a "tgui::Font" object from a Windows font file (arial.ttf or other).

Then I am doing "m_labShipname->getRenderer()->setFont(Font)", where "m_labShipname" is
a pointer to a Label field. This works, I can see that the text displays in the correct font.

From the server I am receiving this in a character buffer, named "buffer":

0x41, 0x42, 0xe6, 0x9d, 0xb1, 0xe4, 0xba, 0xac,0

In case you do not see what this is, :), it is AB東京 in UTF8 Japanese (A and B in front of "TOKYO").

I am then doing:

std::string s = buffer;
sf::String str;

str=sf::String::fromUtf8(s.begin(),s.end());
m_labShipname->setText(str);


I finally check the content of my "sf::String str". This I do using the sf::String::Iterator.
The iterator is of type Uint32 (this is a bit strange, why not Uint16?).
And the content of my Unicode string is:

0x0041 , 0x0042, 0x6771, 0x4eac

This is correct. Unfortunately, it is displayed as AB[][].

When I receive another string with Norwegian UTF8 characters containing ÆØÃ...,
they display correctly.

What could be wrong? Perhaps tgui/sfml does  not support the Windows True Type fonts?
Or did I miss something?

My OS is Raspian Stretch. I see the same on VmWare X86 as well as on a native Raspberry Pi.

Ingar


Quote from: ingar on 07 May 2019, 21:53:12
Hi all,

A general question:

Are there any ways of supporting Unicode in TGUI? I am hoping to be able to replace a Windows CE application with a TGUI app. But the Windows CE app is connecting to a server that returns UTF8 data.
And I cannot see how to TGUI can display those Japanese names...

Ingar
#9
Hi again,

I have this scenario:

I receive a .jpg file image on TCP/IP from an external server.
So I have a byte buffer (with a given length) containing the jpg file.

So how do I update an existing Picture widget from this buffer?

I know how to create a NEW Picture widget from a buffer, using an sf::Texture in the constructor,
but isn't it a bit overkill to create a new one every time? I saw that a function tgui::Picture::setTexture was available
in version 0.78, but this function has been removed in the latest version (0.85).

Ingar
#10
General Discussion / TGUI and Unicode
07 May 2019, 21:53:12
Hi all,

A general question:

Are there any ways of supporting Unicode in TGUI? I am hoping to be able to replace a Windows CE application with a TGUI app. But the Windows CE app is connecting to a server that returns UTF8 data.
And I cannot see how to TGUI can display those Japanese names...

Ingar

#11
Hi again,

OK. I can do a mutex. And probably call a function to handle the external event from the main event loop.

Thanks,
Ingar


Quote from: texus on 05 May 2019, 09:51:09
You can't access the same SFML or TGUI objects from multiple threads at the same time, it is up to you to do the synchronization. One way would be to use mutexes around the TGUI objects you access, but that will likely decrease performance as you would have to lock practically everywhere in the main thread (locks around both event handling and drawing and anywhere else where you access TGUI widgets). So the best way is probably to only let the main thread access TGUI and get your data to the main thread somehow. How to do this is of course not related to TGUI.

I don't have much experience with syncing between threads myself, other than on a windows-only project that uses the Windows functions like PostMessage, SetEvent and WaitForSingleObject.
A pure c++ alternative to SetEvent/WaitForSingleObject would probably be to have a mutex around a shared variable. Every frame (or every X milliseconds) you lock the mutex, check the variable and unlock the mutex again. In the other thread, when data is read from the card, it locks the mutex, writes the data in the variable and unlock the mutex again.
#12
Hi,

In my app I have a thread that checks if an RFID card is placed over an RFID reader. If a card is detected the app reads some data from the card. This data I would like to pass to an event handler in my main thread. Q: What's the best method for doing this in tgui?

I Windows programming, the thread typically issues a PostMessage to the main window thread, and the message handler in the main thread does the handling.

Regards,
Ingar
#13
Hi again!

VERY GOOD NEWS. I tried the tgui:Group and it worked beautifully.

So now I only create ONE RenderWindow. In my screen class  I declare tgui::Group::Ptr and load all my
widgets into the group from a stringstream (gui-builder was used to create the screen). And then I did gui.add(...).

When I enter the second screen, I did what you said: Doing setVisible(false), and when the second screen closes I do
setVisible(true). I do not have to do a setVisible(false) on the second group, because (I guess) the Group is destroyed
when my second screen class is destroyed, or perhaps when the second Gui is destroyed. What is correct? I am worried to create memory/resource leaks.

I am bit confused by the tgui::Ptr's. They cannot be C++ class pointers, since I cannot do new/delete on them. But still,
I have to use -> operator, not dot(.).

Ingar
#14
Hi again,

Thanks for the hints. :)
For now I just keep the multiple RenderWindows. I will try out Group widgets later. On my Raspberry by creating RenderWindow is not that slow, it's when I am running via an X-Windows (Xming) window on another computer I can see a 2 second delay.
But, it would be interesting to know why the RenderWindows stops returning events AFTER the second Gui has been terminated.

My first app only contains two screens, but I am planning another bigger app that uses may sub-windows. In this case, I need to figure out what happens. Perhaps, by patching SFML, I can figure out why pollEvent always fails.

Another thing: I have now made an App that creates a new app with two windows. If I send it to you, you can decide if you want to publish it as a sample source.

Ingar

Quote from: texus on 02 May 2019, 18:10:58
Is there anything that prevents you from just keeping the window and gui and just calling gui.removeAllWidgets() and adding the widgets for the next screen?
Multiple screens could be prepared upfront by creating a Group widget per screen (and adding the widgets to the group instead of to the gui). Then showing another screen is as simple as calling group1->setVisible(false); group2->setVisible(true);

Or maybe use a tgui::ChildWindow instead of an actual window?
#15
Hi again,

I tried it. The second window just set a flag, and the event loop was finished for the second Gui.

But, unfortunately, the RenderWindow stopped responding to events. After the Gui was closed, three more
events came out of RenderWindow (I will figure out what events), and after that, pollEvent always returned false.
I guess, the Gui somehow is doing something so that RenderWindow does not return events.

Ingar



Quote from: ingar on 02 May 2019, 14:53:31
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.