Messages

16

SFML projects / Re: SFGUI (0.3.2 released)

« on: July 21, 2017, 12:00:33 pm »

Thanks for your responses.

First question: yes, that sounds like a good idea. I got another idea too: split the value of attributes into subvalues: base, bought, bonus. Only "bought" is a spinbutton, the others are regular labels. If the user buys ST, it increases the "bought" subvalue of ST and the "bonus" subvalue of HP. In this system, the values of the interactive widgets don't have to be changed programmatically. And also, the accounting of CP becomes easier. Cost has to be computed only for "bought" attribute points. That makes it both easier for the program to recalculate all values, and for the user to keep track of where his CP budget goes to. It also makes it easier to keep track of free (temporary) bonuses caused by spells, magic items etc. They al go to "bonus" and that way they are not included in calculating the CP cost.

Second question: yes I keep member variables pointing to widgets, so they are easily accessible from the callback functions. Those references will prevent the widgets from being destroyed. That will probably be the reason why they stay visible. This is easily fixed by setting the member variables to nullptr when the widget is no longer needed.

Also for this I have thought up a slightly different approach. The different screen objects stay alive in the screen manager object. I guess it is more efficient to just keep the windows intact, but only make the active screen visible and sensitive. That way it's easy to make a back button that keeps the choices the user made beforehand: just switch the visibility and sensitivity.
So it will work like this:
- the screen manager keeps the SFGUI and desktop objects, they are passed by reference to each screen object in the run () function. Don't want the compiler to copy them. So the run function has three parameters, all references: the SFML rendertarget, sfg::SFGUI and sfg::Desktop.
- each screen has its own sfg::Window object. The GUI layout (the widget hierarchy) is build up in the constructor of the screen object.
- if run () is called by the manager, make the current sfg::Window active: guiwindow -> SetState (sfg::Widget::State::NORMAL); and guiwindow -> Show (true);
- if "next" or "back" button is clicked, just make the current window inactive and invisible: guiwindow -> SetState (sfg::Widget::State::INSENSITIVE); and guiwindow -> Show (false);. Now the manager will call the run () of the appropriate next window. Will making the window INSENSITIVE also make all underlying widgets INSENSITIVE? Otherwise there may remain invisible hot zones on the screen, which is not what I want.
- if the wizard is left altogether, reset all widgets to default value, so the next time the user has a clean start.

Does this approach make sense?

17

SFML projects / Re: SFGUI (0.3.2 released)

« on: July 19, 2017, 01:30:53 pm »

In the meantime I have been doing something else, and run into another problem.

I'm trying to make a wizard-like sequence of GUI screens. You fill in one screen, click "next" and get the next screen. I use the approach described here (https://github.com/SFML/SFML/wiki/Tutorial%3A-Manage-different-Screens) for going from screen to screen.

The problem I observe, is that when I go from screen 1 to screen 2, I see both screens through each other, transparent-like. What I suspect is happening is that both screens have their own sfg::Window object and both are being displayed. The transparancy can be due to the style chosen. My time for this project is little and fragmented (really lost moments), so I have not been able yet to experiment exhaustively.

My question is, what is the best approach for doing what I attempt to do.
- use one sfg::Window and one sfg::Desktop and propagate them through all screens of the wizard. I guess I will have to remove all widgets from the sfg::Window object when going to the next screen. Since RemoveAll doesn't seem to be recursive, this means I will have to keep pointers to all containers, and clean them in the right order.
- at the end of each screen close the sfg::Window and the sfg::Desktop and open new ones in the next screen. Since I still have the SFML RenderTarget, the application window should survive this (does it?). This way, I won't have to traverse the widget hierarchy, but I do get the overhead of opening new sfg::Window and sfg::Desktop objects for each screen.

Another question: is there any hope that the SFGUI website will be back in the forseeable future? Now there is no documentation at all on using themes. On the website there was not much, but at least there was something. Also the forum dedicated to SFGUI was nice and instructive.

I am not an experienced GUI developer. I am a programmer, but normally I do backend stuff. So maybe I miss some insight on how these things are normally done.

18

SFML projects / Re: SFGUI (0.3.2 released)

« on: July 19, 2017, 12:56:32 pm »

No answer for my previous question?

Let me give some background: I'm trying to implement a GURPS character generator. For those unfamiliar to GURPS: it's an RPG system, with a point-buy character generation process. You buy attributes, skills etc from a given budget of character points (CP). The default level of all attributes is 10.

A peculiar feature is that buying one attribute, can give you another attribute too. So if you buy one level of Strength (ST, cost 10 CP), you also get one level of Hitpoints (HP, cost 2 CP). And you can also buy HP separately.

So, if for example you buy one ST and one HP, it will cost 10 + 2 = 12 CP. The end result will be ST 11 and HP 12 (one HP for free from ST, and one from HP).

In my mind, the obvious way to implement that is as given in the code in my previous posting in this thread, with two spinbuttons (ST en HP), where interactively changing ST will programmatically change HP too. Problem is, that the behaviour when programmatically changing the value of the second spinbutton can give one or two signals, depending on the order of clicking. The behaviour seems to be deterministic, so it is possible to code around it. The code will have to remember the previous click too. But that will be kind of convoluted and before I go into that, I would like to know if this behaviour is intended (and if so, what is the logic behind it) or a bug.

19

SFML projects / Re: SFGUI (0.3.2 released)

« on: April 24, 2017, 11:48:06 pm »

I notice that the SFGUI website is still down, and since some developers read this thread, I take the liberty of asking my question here too.

The problem is as follows.

I have two spinbuttons, A and B.
Both can be changed individually by user interaction.
If I change the value of A by user interaction, the bound processing function also changes the value of B programmatically, through the SetValue function.
If I do this, button B gets two signals instead of the expected one.

Here is the code:

#include "stdafx.h"
#include <iostream>
#include "SFGUI/SFGUI.hpp"
#include "SFGUI/Widgets.hpp"
#include "SFML/Graphics.hpp"

using namespace std;

constexpr int SCREEN_WIDTH = 800;
constexpr int SCREEN_HEIGHT = 600;

class HelloWorld
{
public:
   HelloWorld () {}
   void value_changed (sfg::SpinButton::Ptr button);
   void Run ();
private:
   sfg::SFGUI sfgui;
   sfg::SpinButton::Ptr _button_a;
   sfg::SpinButton::Ptr _button_b;
};


void HelloWorld::value_changed (sfg::SpinButton::Ptr button)
{
   auto value = button->GetValue ();
   if (button == _button_a)
   {
      cout << "button A" << endl;
      _button_b->SetValue (value);
   }
   if (button == _button_b)
   {
      cout << "button B" << endl;
   }
}

void HelloWorld::Run ()
{
   sf::RenderWindow render_window (sf::VideoMode (SCREEN_WIDTH, SCREEN_HEIGHT), "Hello world");

   auto window = sfg::Window::Create ();
   window->SetTitle ("Test spinbuttons");

   auto table = sfg::Table::Create ();
   auto fill = sfg::Table::AttachOption::FILL;
   auto padding = sf::Vector2f (10.0f, 2.0f);

   auto label_a = sfg::Label::Create();
   label_a->SetText ("A");
   table->Attach (label_a, sf::Rect<sf::Uint32> (0, 0, 1, 1), fill, fill, padding);

   auto button_a = sfg::SpinButton::Create (1.0f, 10.0f, 1.0f);
   _button_a = button_a;
   button_a->SetValue (5.0f);
   button_a->GetSignal (sfg::SpinButton::OnValueChanged).Connect ([=](){value_changed (button_a); });
   button_a->SetRequisition (sf::Vector2f (60.0f, 0.0f));
   table->Attach (button_a, sf::Rect<sf::Uint32> (1, 0, 1, 1), fill, fill, padding);

   auto label_b = sfg::Label::Create ();
   label_b->SetText ("B");
   table->Attach (label_b, sf::Rect<sf::Uint32> (0, 1, 1, 1), fill, fill, padding);

   auto button_b = sfg::SpinButton::Create (1.0f, 10.0f, 1.0f);
   button_b->SetValue (5.0f);
   _button_b = button_b;
   button_b->SetRequisition (sf::Vector2f (60.0f, 0.0f));
   button_b->GetSignal (sfg::SpinButton::OnValueChanged).Connect ([=](){value_changed (button_b); });
   table->Attach (button_b, sf::Rect<sf::Uint32> (1, 1, 1, 1), fill, fill, padding);

   window->Add (table);
   sfg::Desktop desktop;
   desktop.Add (window);

   render_window.resetGLStates ();

   sf::Event event;
   sf::Clock clock;
   while (render_window.isOpen ())
   {
      while (render_window.pollEvent (event))
      {
         desktop.HandleEvent (event);
         if (event.type == sf::Event::Closed)
         {
            render_window.close ();
         }
      }
      desktop.Update (clock.restart ().asSeconds ());
      render_window.clear ();
      sfgui.Display (render_window);
      render_window.display ();
   }
}

int main ()
{
   HelloWorld hello_world;
   hello_world.Run ();
   return 0;
}

Now, if I click the up-button of spinbutton B, I get the expected output:

button B

But, if I click the up-button of spinbutton A, I get two signals on b:

button A
button B
button B

This is a problem, because I want to ignore signals originating from programmatical change of the value of B, while still handling the signals originating from user interaction with B.

It gets even stranger if I first click A, then B, en then A again. In this case the output is:

button A               // click button A
button B               // SetValue on B
button B               // mysterious second signal on B
button B               // click button B
button A               // click button A
button B               // SetValue on B, no second signal!

So, the number of signals received on B seems to depend on the exact sequence of clicks: if I click A after having clicked B, I get one signal on B. If I click A while the previous click was not on B, I get two signals on B.

Probably I am making some silly mistake, and probably I am making a fool of myself by asking, but I genuinely don't see it.

20

SFML projects / Re: SFGUI (0.3.2 released)

« on: April 10, 2017, 04:45:00 pm »

OK thanks.

21

SFML projects / Re: SFGUI (0.3.2 released)

« on: April 10, 2017, 01:02:15 pm »

Hello,

Is there a known problem with the SFGUI website? I asked a question on the forum, but now I can't reach it anymore. First it gave a 404 (not found), now the URL dumps me to the github site.

Thank you.