SFGUI (old thread)

[Ceylo]

Hey again there,

I do have my first criticism to do : when loading the interface from a YAML file, the GUI handles the loading and object construction, defining all of its settings. I disagree with this approach as it means you need to modify the GUI class implementation in order to load a custom widget. I actually don't understand why this construction is not delegated to the specific class with a specific constructor ?

Hum.. after a bit of thinking, I don't know how you can call the right constructor (especially of the right class) only with the widget's type (which is a string). Would need some tricks...


Edit: after having looked at how the GNUStep library unarchives objects from files, I've noticed all the classes are registered in the runtime at the initialization time with a name and a pointer to the class. Thus when unarchiving an object with the given name from a file, the runtime is able to tell which class's constructor is to be used. This would be a small overhead to the SFUI library but would allow custom GUI object deserialization.

[Ceylo]

I tried to do the build process on Windows but it the source code is actually not up to date with the latest changes on the sf::Rect structure . I'll have to do some updates..

[Nexus]

Yes, that's what Tank said:

Since sf::Rect's interface has been completely changed, there's again a lot of work to do to make SFGUI compile with the latest SFML2 trunk.

I think you should just have some patience or try with an older SFML version...

[Ceylo]

Ahum quite true. I think I won't be able to wait for Tank though ^^ (I think I'm going to do the fix myself).

[Tank]

At first, thank you Ceylo for all your feedback, it's very appreciated!

Last night I've updated the source code to be compatible with the latest SFML revision, again (thus supporting the modified (and very nice!) sf::Rects).

It might be true that the MSVC and C::B project files are still kinda outdated. Since I'm on Linux and a console kid (), I'm not maintaining these. I'll ask the proper persons if they can update the project files.

Regarding loading UIs from YAML:
Yes, it's kinda restrictive at the moment, and I'm planning to change the design of code here and there a bit, so that implementing custom widgets is easier. The current implementation needs to have a custom sfg::GUI, which isn't a real problem -- but I agree with you that it's not the way that it's supposed to be.

One idea is to register widget factories with sfg::GUI, that get called after each other when loading YAML files. This way you can extend sfg::GUI with your widgets a lot easier.

Regarding to the GUI designer:
No, there isn't one yet. I also thought about this, but I think I'll  better concentrate on the library itself. Maybe another developer will find the time and motivation to create such a tool. If so, I'd really love to see it in action.

Anyways, thanks for your words!

[Ceylo]

Hey Tank!

I'm really pleased to hear from you after sooo much time (well.. one month) and know that you still keep your library up to date.

I don't really know what you mean with "register widget factories with sfg::GUI", I'd need further explanations on this point. Moreover, considering a GUI designer, one would need not only GUI loading, but also GUI saving.

As far as I said about registering classes and calling the proper loading method, it's based on the serialization and deserialization system used by Cocoa : http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/Archiving/Archiving.html#//apple_ref/doc/uid/10000047i (it's Objective-C, neither C nor C++, but I think the idea is still useful).

And as written, I'd love to help (if not do it completely) at developing the GUI designer (until you can gives me the features I request do to so ).

[Tank]

I don't really know what you mean with "register widget factories with sfg::GUI", I'd need further explanations on this point.

Just implemented this by separating the code for creating widgets from YAML and also applying skin settings.

If you plan to extend SFGUI by your own widgets, you can now write a factory for these, which is responsible for creating widgets based on a type name and also applying settings from a loaded skin.

To get an idea of how that works, just take a look at the included "standard" factory here. For registering your own factories, you'd have to call sfg::GUI::RegisterFactory<Type>(), as done here with the default factory.


I've also changed the signalling system completely -- any code written for previous revisions of the SFGUI code will be broken, so be warned. (check this sample to see what has changed -- however sfg::Connect will be renamed to sfg::Slot -- be warned again ).

[Ceylo]

Hi,

I'm running Ubuntu right now (no SFML 2 on Mac OS X, and no up to date project on Windows (and a bit lazy)).

I built SFUI but I couldn't build the samples because of undefined symbols in the SFML libraries :

Code: [Select]

g++ -o samples/bin/avatar samples/Avatar/Avatar.o -Llib -Lsamples/bin -lsfml-system -lsfml-window -lsfml-graphics -lsfml-audio -lsfgui -lsampleapp
samples/Avatar/Avatar.o: In function `Avatar::OnAvatarChanged(boost::shared_ptr<sfg::Widget>)':
/home/ceylo/Bureau/SFGUI/samples/Avatar/Avatar.cpp:43: undefined reference to `sf::Sprite::SetImage(sf::Image const&, bool)'
samples/Avatar/Avatar.o: In function `Avatar':
/home/ceylo/Bureau/SFGUI/samples/Avatar/Avatar.cpp:8: undefined reference to `sf::Image::Create(unsigned int, unsigned int, sf::Color const&)'
/home/ceylo/Bureau/SFGUI/samples/Avatar/Avatar.cpp:9: undefined reference to `sf::Sprite::SetImage(sf::Image const&, bool)'
/home/ceylo/Bureau/SFGUI/samples/Avatar/Avatar.cpp:32: undefined reference to `sf::Sprite::SetImage(sf::Image const&, bool)'
/home/ceylo/Bureau/SFGUI/samples/Avatar/Avatar.cpp:8: undefined reference to `sf::Image::Create(unsigned int, unsigned int, sf::Color const&)'
/home/ceylo/Bureau/SFGUI/samples/Avatar/Avatar.cpp:9: undefined reference to `sf::Sprite::SetImage(sf::Image const&, bool)'
/home/ceylo/Bureau/SFGUI/samples/Avatar/Avatar.cpp:32: undefined reference to `sf::Sprite::SetImage(sf::Image const&, bool)'
[...]


I neither got warnings nor errors before this. And when I type..

Code: [Select]

nm /usr/local/lib/libsfml-graphics.so.2.0
It says :

Code: [Select]

nm: /usr/local/lib/libsfml-graphics.so.2.0: no symbols

This may be because the debug symbols were stripped from the binary file but it prevents me from checking whether the missing symbols are.. indeed missing (and I dunno how to build the debug libraries on Linux, I found no information on the forum about it).

Note that I just get the latest SFML 2 sources from the SVN repository, and the latest SFUI sources from the Git repository, I just installed scons and boost 1.37 through apt-get and... that's all.

I'mma try to do my own sample but that's weird..


Edit: there were SFML 1.5 libraries in /usr/lib ... fixed.

[model76]

Hi Tank,

Your project looks really promising!

I would, however, prefer a more open license. The problem with LGPL is that it doesn't allow static linking in closed source projects, and that might prove problematic for some users.

Any chance of a more open license? I would suggest using zlib/png, like SFML, for the sake of consistency.

[Tank]

Thanks for your feedback.

I've already switched the license from GPL to LGPL. However, both of them are as open as a license can be.

This doesn't mean it's the final choice of the license, but up to a stable version of SFGUI I do not plan to switch it again. The reason is simple: Being it (L)GPLed, I hope to get some more feedback because you have to release changes to SFGUI under a similar license.

On the other hand, I'm a follower of the FOSS principle: Software should be open, so that people can modify it or learn from it.

Btw, what is the problem of linking SFGUI dynamically (besides of having to include an SO/DLL files)? You can even extend SFGUI without modifying the source itself, so you're fine with a closed source project and SFGUI.

You see, I kinda want to make sure that additions (bugfixes, patches, enhancements) get back to the origin, so that everybody benefits from those, because they can be included into the mainline. Extensions however are separate and don't need to be GPLed.

However, if someone really really really needs another license and has good reasons for that, then drop me a line and I'll think about it (no, don't want to make money out of it, just to make sure SFGUI keeps open).

[Trass3r]

Good point(s)

[Ceylo]

I agree with Tanks about the licence (what's the problem with dynamic linking ?).

Anyway Tank, do you have some news about SFGUI progress ? A release date or something ?

Ceylo

[Tank]

I currently fiddle around with the documentation of SFGUI. There will be an user's manual that tries to cover the most aspects of SFGUI (setup, basics and customization/extensions). At the moment I guess its status is about 60%.

The public API is almost complete. However there're still some internal glitches here and there that need my attention.

Speaking of a release date, I think I can make it in 1-2 months (subject to change! ).

Are you guys using Code::Blocks and/or Visual Studio? I'm looking for someone who's able to create proper project files when SFGUI is being released.

[Ceylo]

1-2 months .... ><

You'd have said 1-2 weeks I'd be happy but.. well I suppose I'll just have to keep being patient (besides you don't look to be asking for someone else's help.. too bad).

As for the question, I'm using Xcode on Mac OS X *gets out*. I'm not doing a lot of work with Linux/Windows..

[Mindiell]

The public API is almost complete. However there're still some internal glitches here and there that need my attention.

Why don't you let us play with it in order to help you finding "maybe other glitches" and permitting us to advance with it ?