SFML community forums
General => SFML projects => Topic started by: Trass3r on February 07, 2010, 05:47:03 pm
-
I really wonder why there is not already a topic about SFGUI. It's a very promising and useful SFML project providing a nice GUI framework.
(http://dev.boxbox.org/static/images/sfgui2.png)
The official site is at: http://dev.boxbox.org/projects/sfgui
The german thread about it can be found there: http://forum.sfml-dev.de/index.php/topic,127.0.html
Seems like he's currently waiting for sf::String (SFML2) to get more methods for inserting characters and so on for use in sfg::Editbox.
-
I don't really see that there's much to discuss... There's no download link for library or code, no documentation, no real screenshots. All we have is a list of features, a link to a website that isn't up yet, and tiny screenshots that are fairly hard to make out.
Of course, I'd be interested to see this project in action, but there really isn't a lot to go on right now.
-
Code is here: git://boxbox.org/git/sfgui2
And Videos are here: http://www.youtube.com/TheTankOs
-
I can't download it
-
Come on, you see it's "git://"!
You need a git client.
-
Maybe Tank (who created this lib) is not happy to see a downloadlink published here.
sfgui has not been released officially by him.
-
Yes, it is still work in progress :roll: But you can be sure that it is a very great lib.
-
Ahhhh. :) Of course there's a reason why SFGUI hasn't been announced yet: It's not finished and doesn't compile currently at all.
It's okay to spread the word about it (so I'm fine with this thread, Trass3r), but I highly encourage everybody NOT to use it nor to extend it. There're a lot of todo entries on my side, and like it was said before, I need to wait until SFML 2 reaches a proper state to be able to continue SFGUI.
So yes, SFGUI is in development, and you can follow it on GitHub, but don't expect to get a fully working library yet. When the time is right and I feel the library is stable and well-designed (still a lot of glitches here and there), I'll of course announce it here.
Whatever, thanks for the flowers, Trass3r. ;)
-
Seems like Laurent added some of the things you need (inserting and finding chars in sf::String) :wink:
-
Yes, indeed. The editbox was the smallest problem the last days. SFGUI got rather huge updates that need to be tested for stability. I'm also currently writing documentation for it... So you can except to see it available to the public in a couple of time.
The Git repository is always synchronized with my local copy. So if you feel like testing the library in its current state, then do it. :) However the Visual Studio project files are usually not up-to-date, since I'm developing on Linux.
Thanks for your interest so far.
Edit: Btw, before I forget this: If there are any talented skin designers out there, please please contact me. I'm pissed off using developer art. ;)
-
Any news, Tank?
-
Well, yes. :) 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 guess this is a drawback when using a development version for a library on top of it.
However, the documentation for SFGUI is almost complete and no more features are being added for the first release (freeze). I'm still looking at the code to make it better in some places, but on the whole it looks good already.
So, after I've made the sf::Rect changes to the library, I'll finish the last pages of documentation and will then hopefully be able to give this beast out to you guys. ;)
Thank you for your interest.
-
Hi there,
@Tank, what's up with the documentation and the download link ? :-°
The features list look interesting but I'd like to see the documentation and source code to make my own opinion.
Do you have any release date ?
Thanks,
Ceylo
-
I'd like to see the documentation and source code to make my own opinion
Googling gives the following source location: http://github.com/TankOs/SFGUI. Press the button [Download source] and get the code (rather dated though). As for docs, - doxygen is our friend for ever. :)
-
Thanks you very much dunce!
I had a look at the sources and I'm.. stunned. It's very clean, allows simple use, can support different skins, and has all the basic essential widgets. Just looks great (I didn't test it though).
In other words, the GUI library I've always dreamed to do, without succeeding in doing so. Great, really.
Congratulations to Tank !
I'm now really looking forward to downloading and using the first official release :) .
PS: hum.. I tried to build SFUI but... I get this :
cc1plus: error: unrecognized command line option "-std=c++0x"
I actually didn't even know this standard was already supported (as of GCC 4.3 as I read, but I'm using GCC 4.2 :/). I'll have to update..
Anyway there is no SFML 2.0 support for Mac OS X right now, so I'll test it on Windows.
Edit: I'm wondering... Tank, do you plan to make an interface editor ? If not, I'mma try to do one, that'll be my contribution (besides you already support interface loading from files, so it'll be easier).
-
Hey again there,
I do have my first criticism to do :P : 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.
-
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..
-
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... ;)
-
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).
-
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!
-
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 :P ).
-
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 (http://github.com/TankOs/SFGUI/blob/master/src/WidgetFactory.cpp). For registering your own factories, you'd have to call sfg::GUI::RegisterFactory<Type>(), as done here (http://github.com/TankOs/SFGUI/blob/master/src/GUI.cpp#L28) 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 (http://github.com/TankOs/SFGUI/blob/master/samples/Avatar/Avatar.cpp#L11) to see what has changed -- however sfg::Connect will be renamed to sfg::Slot -- be warned again ;)).
-
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 :
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..
nm /usr/local/lib/libsfml-graphics.so.2.0
It says :
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.
-
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.
-
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).
-
Good point(s) 8)
-
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
-
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.
-
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..
-
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 ?
-
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.
I use Visual Studio 2008-2010. I can make the projects for you :-P
-
I use C::B under Windows and Linux ;)
-
Thanks a lot, your help is very appreciated. :)
You'd have said 1-2 weeks
True, but there've been some real life issues that had to be fixed. ;) However, I think it's better that a release takes more time to just make it better than releasing in time with glitches/bugs/whatever.
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 ?
That has been possible since the beginning of SFGUI. Just download/clone the sources from http://github.com/TankOs/SFGUI and try it out. Keep in mind that the IDE project files are not up-to-date. So, if anyone updates those or creates new ones, please let me know so I can push them into the repository (and also tell me your name if you like for an entry in the CONTRIB file).
Windows users must pay attention at pre-processor directives: Like SFML, SFGUI also needs a defined macro when linking dynamically, namely "SFGUI_DYNAMIC".
Some words to the progress: I'm still facing the documentation, the features are almost complete, so nothing new gets added until release (only bugfixes or critical changes when any are found).
Again, thank you very much for your effort and interest, keeps me motivated. ;)
-
Edit: Oops.. rewriting in english :mrgreen: .
Edit 2:
Okay. I tried to compile the whole stuff.. and I got 2 errors.
The first one is in GUI.inl line 5. I replaced std::auto_ptr with std::auto_ptr_ref. I absolutely don't know auto_ptr so I don't know whether what I did is correct.
The error message was :
/Users/ceylo/Development/sfgui/../../SFGUI/src/GUI.cpp:28:0 /Users/ceylo/Development/sfgui/../../SFGUI/src/GUI.cpp:28: instantiated from here
/Users/ceylo/Development/sfgui/../../SFGUI/include/SFGUI/GUI.inl:5:0 /Users/ceylo/Development/sfgui/../../SFGUI/include/SFGUI/GUI.inl:5: error: no matching function for call to 'std::auto_ptr<sfg::BaseWidgetFactory>::auto_ptr(std::auto_ptr<sfg::BaseWidgetFactory>)'
/usr/include/c++/4.2.1/memory:349:0 /usr/include/c++/4.2.1/memory:349: note: candidates are: std::auto_ptr<_Tp>::auto_ptr(std::auto_ptr_ref<_Tp>) [with _Tp = sfg::BaseWidgetFactory]
/usr/include/c++/4.2.1/memory:212:0 /usr/include/c++/4.2.1/memory:212: note: std::auto_ptr<_Tp>::auto_ptr(std::auto_ptr<_Tp1>&) [with _Tp1 = sfg::BaseWidgetFactory, _Tp = sfg::BaseWidgetFactory]
/usr/include/c++/4.2.1/memory:199:0 /usr/include/c++/4.2.1/memory:199: note: std::auto_ptr<_Tp>::auto_ptr(std::auto_ptr<_Tp>&) [with _Tp = sfg::BaseWidgetFactory]
Then I got
/usr/include/c++/4.2.1/ext/new_allocator.h:107:0 /usr/include/c++/4.2.1/ext/new_allocator.h:107: error: passing 'const std::auto_ptr<sfg::BaseWidgetFactory>' as 'this' argument of 'std::auto_ptr<_Tp>::operator std::auto_ptr_ref<_Tp1>() [with _Tp1 = sfg::BaseWidgetFactory, _Tp = sfg::BaseWidgetFactory]' discards qualifiers
Same file, same line. This time I dunno what to do ^^
Note that I get this error with and without my previous change.
Otherwise, I'mma try to add functions for saving the GUI in a YAML file.
Edit 3: after some searches in your stuff, looks like the YAML classes are for read purposes only. So I'm a bit stuck... did you remove the writing part yourself or is it really read only ?
Besides, I don't understand why you do your own parsing in Skin.cpp as you have a YAML class ?
-
Make sure that you always pull the latest commit from the Git repository. The auto_ptr problem has been fixed some days before (got replaced by raw pointers). I used auto_ptr wrongly, but g++ didn't complain about that. ;)
Regarding to the skin definition files:
Yeah, that's still one of the "glitches" I was talking about in a previous post. There's already test code that uses YAML skin definition files. I guess that is one change that will make it into the first release (everything else would be kinda dumb: switching such a distinctive thing after a first release).
YAML can be also emitted to a file, not only read. Since SFGUI uses the yaml-cpp library, check out the proper manual page here: http://code.google.com/p/yaml-cpp/wiki/HowToEmitYAML
I won't implement emitting YAML code from widgets to SFGUI, since saving a GUI's state doesn't really belong to a GUI library, but more to a designer tool. However, it should be very easy to extend yaml-cpp to be able to save SFGUI widget's properties.
If you like, I can extend sfg::GUI by a method like "GetWidgets()" or better "GetTopWidget()" (the container that's used as the parent by sfg::GUI) to be able to get a full list of all added widgets.
Thanks for your input.
-
Hum.. how am I supposed to get the latest sources with an existing Git cloned directory ? I dunno whether there's something like "svn update". I actually did "git checkout" in the git repository and it looked fine so.. I thought that was it, but seems like I was wrong.
Okay, I'll let you fix this "glitch" then ^^.
As for YAML writing.. I didn't see the Emitter class, thank you !!
And as for the GUI, don't bother with this now (until you need it for yourself), I need to do some more thinking on how the UI'll be stored/loaded by the user application/designer (even considering you already support UI loading, I need to have a closer look at your work :P ).
Edit: I found "git pull" to update my files :) .
Edit 2: it now compiles fine except the linking step :) (that is because there is no SFML 2 on Mac OS X).
-
So.. I've had a closer look at your work and I must say it's quite comprehensive and well designed. I noticed some very simple ways to do tricky concepts :) .
I also looked at how you handle events, how you process the rendering and how you load the YAML files. From what I read, you can programmatically add widgets, and sub-widgets in these parent widgets. But your YAML loader does only support flat loading, I mean it doesn't support creating the sub-widgets. Am I wrong ?
If I'm not, is it what you wanted/chose ? Or is it because you want to keep the things simple on the YAML loader for the first release ? Or is it because you don't know for now how to represent the child-parent relationship in the YAML file ?
It doesn't look really tricky to implement but.. if you think it's better to keep this work for the next version, I'd understand. Flat hierarchy is already more than enough for simple GUIs.
Ceylo
-
So.. I've had a closer look at your work and I must say it's quite comprehensive and well designed. I noticed some very simple ways to do tricky concepts :) .
Thank you! :)
From what I read, you can programmatically add widgets, and sub-widgets in these parent widgets. But your YAML loader does only support flat loading, I mean it doesn't support creating the sub-widgets. Am I wrong ?
You're right, up to now there's only a flat hierarchy possible -- but that doesn't mean it's final for the first release.
I'm currently working on this and the hierarchy will later look like this:
Widgets:
-
Type: Container
Children:
-
Type: Container
Children:
-
Type: Button
...
Implementing that is rather easy, just some recursive stuff.
It doesn't look really tricky to implement but.. if you think it's better to keep this work for the next version, I'd understand. Flat hierarchy is already more than enough for simple GUIs.
Yeah, there exist workarounds if SFGUI wouldn't be able to load deep hierarchies. But those workarounds would be annoying (loading one YAML file, then loading the children and providing the wanted widget as parent to LoadYAML()). So you can definitely count on that feature for the first release.
I hope that makes the thing a bit clearer why SFGUI won't be released in 1-2 weeks. Stuff like that still needs to be improved, and like I said, I don't want to release unfinished stuff or make compromises (or even leave bugs inside ;)).
However, thank you very much for your feedback. Don't hesitate to point out things that aren't good (or complete crap) in your eyes. I'm always thankful for opinions of other people.
-
Well.. I already told you all I've noticed as far as features are concerned. One other point I can think of is your code lacks some comments. You put some but not enough to my mind. It makes your code a bit tricky to understand sometimes.
And.. you already know what I told you about delegating the widget serialization/deserialization in the concerned widget's code instead of doing so in the widget factory (especially because the widget factory would become bigger and bigger as you add widgets and probably harder to maintain). But I think that's fine for now (considering the size of your library) and you should just keep that in mind for later (or convince me it's absolutely useless ^^). The other issue with this that I can think of now... is the user forgetting to update its widget factory according to his changes to the widget. That's not much but, it'd make the things easier (and I suppose your purpose is to provide an easy-to-use library :P ).
Edit: forgot to comment on the YAML file : I'd need to do real tests but it does look fine to me.
Edit 2: one point I thinked of too is not processing the YAML loading through the GUI class. I'd rather think of a specific YAML loader/writer class (just because it doesn't really fit the GUI class's role to my mind, and because it would ease my work (working both on the same class looks like a mess to me, especially if it's not required)).
-
Edit 2: one think I thinked of too is not processing the YAML loading through the GUI class. I'd rather think of a specific YAML loader/writer class (just because it doesn't really fit the GUI class's role to my mind, and because it would ease my work (working both on the same class looks like a mess to me, especially if it's not required)).
Yes, like an interface. This would easily permit to use other file format than YAML if someone want to.
-
One other point I can think of is your code lacks some comments. You put some but not enough to my mind. It makes your code a bit tricky to understand sometimes.
I put comments everywhere I had the feeling of "Okay, this can be confusing when being read in the future again". Of course other people have different feelings and didn't write the code (thus having another understanding). I'll try to keep the level up.
And.. you already know what I told you about delegating the widget serialization/deserialization in the concerned widget's code instead of doing so in the widget factory
I don't like this idea much, since widgets shouldn't be concerned with any type of serialization. That's the task of other instances. Also this would eliminate the possibility to exchange the serialization driver (or would make it at least at lot more painful to implement/increase complexity).
(especially because the widget factory would become bigger and bigger as you add widgets and probably harder to maintain).
That's something where you can't do anything against it. If you put the serialization code into the single classes, it's still there, no matter if it's inside the widget's class or a big factory class. The advantage is however that the code is completely separated, which makes it indeed better to maintain.
One thing you could do is splitting up your custom factory code into more classes and register each via sfg::GUI::RegisterFactory(). You can even create one factory class for each custom widget *and* put the deserialization code into the widget's class if you like that approach. ;)
The other issue with this that I can think of now... is the user forgetting to update its widget factory according to his changes to the widget. That's not much but, it'd make the things easier (and I suppose your purpose is to provide an easy-to-use library :P ).
I guess that'd be a plain PEBKAC. ;) I just like the idea to have a single instance that's responsible for deserializing widgets.
Edit 2: one think I thinked of too is not processing the YAML loading through the GUI class. I'd rather think of a specific YAML loader/writer class (just because it doesn't really fit the GUI class's role to my mind, and because it would ease my work (working both on the same class looks like a mess to me, especially if it's not required)).
You're right, I'll separate the YAML loading stuff from sfg::GUI. This is easily possible, because sfg::GUI's public interface provides everything that an external loader class needs.
Good points, keep it goin'! :)
-
One other point I can think of is your code lacks some comments. You put some but not enough to my mind. It makes your code a bit tricky to understand sometimes.
I put comments everywhere I had the feeling of "Okay, this can be confusing when being read in the future again". Of course other people have different feelings and didn't write the code (thus having another understanding). I'll try to keep the level up.
This is useful especially if you don't want to have to maintain SFGUI for the remaining years of your life *joke*. More seriously, it would allow people to help you more easily (and notice the bad points faster btw).
And.. you already know what I told you about delegating the widget serialization/deserialization in the concerned widget's code instead of doing so in the widget factory
I don't like this idea much, since widgets shouldn't be concerned with any type of serialization. That's the task of other instances. Also this would eliminate the possibility to exchange the serialization driver (or would make it at least at lot more painful to implement/increase complexity).
Do you mean changing the way the widgets are (de)serialized ?
If I'm right.. then you should just use an abstraction layer (baaaaaah *abstraction is evil* *gets out*). Okay that's still more work (I could work on it myself), but that would fix this point.
The other reason is... imagine you have several people working on 3-4 different new widgets. Is it easier to work on the same factory widget or working only on ones part ?
(especially because the widget factory would become bigger and bigger as you add widgets and probably harder to maintain).
That's something where you can't do anything against it. If you put the serialization code into the single classes, it's still there, no matter if it's inside the widget's class or a big factory class. The advantage is however that the code is completely separated, which makes it indeed better to maintain.
Yes you can !! *reminds me of something..*
As you say "The advantage is however that the code is completely separated, which makes it indeed better to maintain." : that's exactly what I wanted to point out. You cannot prevent the library from growing, but you can prevent developers from having to work on big factories => don't care about what have been done before and just focus on one thing.
One thing you could do is splitting up your custom factory code into more classes and register each via sfg::GUI::RegisterFactory(). You can even create one factory class for each custom widget *and* put the deserialization code into the widget's class if you like that approach. ;)
And you get closer and closer by the idea of registering each class to be able to use a standardized (de)serialization process :) . The idea is.. as soon as a class implements the “serializable” interface, it'll be registered in the SFGUI runtime handler/global widget factory/whatever you want (let's call it Lily). And as soon as it is registered, the YAML loader (or any other format loader) knows it can look for Lily and ask her to (de)serialize the widget. Then Lily just has to use the provided interface to do her job.
(thank you Mindiell for the interface idea btw ^^)
The other issue with this that I can think of now... is the user forgetting to update its widget factory according to his changes to the widget. That's not much but, it'd make the things easier (and I suppose your purpose is to provide an easy-to-use library :P ).
I guess that'd be a plain PEBKAC. ;) I just like the idea to have a single instance that's responsible for deserializing widgets.
PEBKAC is everywhere ^^, and you'll need more than a "I just like the idea" to convince me :-° *gets out before getting whipped*
Edit 2: one think I thinked of too is not processing the YAML loading through the GUI class. I'd rather think of a specific YAML loader/writer class (just because it doesn't really fit the GUI class's role to my mind, and because it would ease my work (working both on the same class looks like a mess to me, especially if it's not required)).
You're right, I'll separate the YAML loading stuff from sfg::GUI. This is easily possible, because sfg::GUI's public interface provides everything that an external loader class needs.
Good points, keep it goin'! :)
I'll try to do so, thanks!
-
This is useful especially if you don't want to have to maintain SFGUI for the remaining years of your life *joke*. More seriously, it would allow people to help you more easily (and notice the bad points faster btw).
Yes, said nothing against it. So again: I'll try to keep the level up. :)
If I'm right.. then you should just use an abstraction layer (baaaaaah *abstraction is evil* *gets out*). Okay that's still more work (I could work on it myself), but that would fix this point.
The other reason is... imagine you have several people working on 3-4 different new widgets. Is it easier to work on the same factory widget or working only on ones part ?
Abstraction isn't a problem, since there's already a lot of it in the library (else it wouldn't be flexible enough). When more people are working on widgets, it depends on their personal strategy how they behave. I myself would go with one class and a good source code management system, but that depends. :)
As you say "The advantage is however that the code is completely separated, which makes it indeed better to maintain." : that's exactly what I wanted to point out. You cannot prevent the library from growing, but you can prevent developers from having to work on big factories => don't care about what have been done before and just focus on one thing.
That counts for both possibilities: One thing as in one factory or as in each widget.
And you get closer and closer by the idea of registering each class to be able to use a standardized (de)serialization process :) . The idea is.. as soon as a class implements the “serializable” interface, it'll be registered in the SFGUI runtime handler/global widget factory/whatever you want (let's call it Lily). And as soon as it is registered, the YAML loader (or any other format loader) knows it can look for Lily and ask her to (de)serialize the widget. Then Lily just has to use the provided interface to do her job.
Yeah, I know what you mean. That's comparible with serialization frameworks (like the Boost one, for example). Of course it's a neat thing, I'm just curious if that fits into the current design. I must admit that I'm at least thinking about it, so I guess it's 1:0 for you. ;)
PEBKAC is everywhere ^^, and you'll need more than a "I just like the idea" to convince me :-° *gets out before getting whipped*
Well, the argument that someone just forgets something isn't very strong, too. :)
And by the way, don't hesitate to push out your ideas/thoughts. That's the benefit Open Source has over other software. And I'm not the person that gets pissed, so there's no reason to hang back. :)
-
PEBKAC is everywhere ^^, and you'll need more than a "I just like the idea" to convince me :-° *gets out before getting whipped*
Well, the argument that someone just forgets something isn't very strong, too. :)
Mmmh... to sum up my reasons :
+ several user could work on several new widgets without messing up each other (but registering each class with a particular factory also solves this issue)
+ very little to add in order to make ones own widget serializable (I was doing a concrete example in the meantime and I'm gonna show you this soon)
+ restrained mistakes possibilities (=> see sample soon)
- looks like there are some restrictions due to C++ "staticness" (=> see sample too)
=============
I finished the sample draft and I'm rather... disappointed (my method is heavy and doesn't look to have a lot of interest)
What I note is... the "very little to add" is also true with your way, and I can't find where the "restrainted mistake possiblities" happens. Oh yeah.. I found the difference : you don't have to call RegisterFactory *greaaat*. That's all. Disappointing.
Maybe there are some other advantages but I can't notice them for now.
Here is the draft : Serializable.hpp (http://pagesperso-orange.fr/c.sobecki/ceylo/data/Serializable.hpp)
-
A short hint:
virtual const std::string className()
{
// using accessor to get the class name because
// there doesn't seem to exist any other reliable way
// typeid->className()'s result depends on compilers and I do not know any other way with C++
return "SampleWidget";
}
When all C++ compiler and runtime abstraction facilities fail, there's still the preprocessor to save you. :)
#define SFGUI_CLASSNAME(CLASS) \
virtual const char* ClassName() const \
{ \
return #CLASS; \
}
By the way, Tank, if you have already used Boost, might not the library Boost.Serialize be an option? At least, it contains some interesting concepts.
-
The macro is not really an option, it would fail for example for multiple class that have the same name but in different scopes (namespaces) :P
To use the preprocessor like this you'd need the fully qualified name, which means using it outside the class definition. It's technically possible with some tricks, but I think that defining the virtual function manually is the simplest solution.
-
When all C++ compiler and runtime abstraction facilities fail, there's still the preprocessor to save you. :)
Indeed, but I don't think something like "ClassName()" is necessary. When serialization is delegated to the widgets themselves, I think it's perfectly fine when they throw a class name string to the storage driver themselves (they do so for properties (which are specific and can't be read by an abstract class because they're unknown) so they can for a class name).
Okay, should better have quoted Ceylo in this case -- just too lazy to look for the proper post. ;)
By the way, Tank, if you have already used Boost, might not the library Boost.Serialize be an option? At least, it contains some interesting concepts.
Boost.Serialization would be incredible great, but that means an extra dependency. You're right, I'm using some components of Boost, but those are header-only, which means no building on target systems is necessary that makes distribution easy.
I think I'll go with a selfmade and lightweight serialization solution. However, I still have to think about the design and do some tests if that'll work out and -- more importantly -- will make the whole thing easier or not (regarding to usage *and* design).
@Ceylo:
The code looks good, but I'd choose another approach. However the concept is at least similar to yours. :) Thank you.
I'm glad that some other experienced guys are following this thread. I repeat myself, but: I'm always open for opinions. ;)
-
When all C++ compiler and runtime abstraction facilities fail, there's still the preprocessor to save you. :)
Indeed, but I don't think something like "ClassName()" is necessary. When serialization is delegated to the widgets themselves, I think it's perfectly fine when they throw a class name string to the storage driver themselves (they do so for properties (which are specific and can't be read by an abstract class because they're unknown) so they can for a class name).
Okay, should better have quoted Ceylo in this case -- just too lazy to look for the proper post. ;)
Mmmh.. I don't understand what you mean with "it's perfectly fine when they throw a class name string to the storage driver themselves". The attributes are only know from the widget itself and that's fine. But here the class name was used by the "runtime" to find which serializer should be used (by the way, the class name should fully represent the class : something like sfg.widget.control.samplewidget...).
I think I'll go with a selfmade and lightweight serialization solution. However, I still have to think about the design and do some tests if that'll work out and -- more importantly -- will make the whole thing easier or not (regarding to usage *and* design).
@Ceylo:
The code looks good, but I'd choose another approach. However the concept is at least similar to yours. :) Thank you.
Thus a third solution ?
-
What about using a metaobject system similar to Qt? A widget would declare all of its properties, then you can request and manipulate them at runtime. It allows a kind of reflection actually.
This system is much more powerful than a "hard-coded" serialization solution, because the meta-properties can then be used anywehere:
- text serialization
- object editor tree
- binding your classes to a script engine
- ...
- look at the huge list of Qt modules based on the meta-object system
If you're interested, I know a very good library which does exactly that, much better than Qt (no precompiler, uses meta-programming to generate the bindings at compile-time, only requires boost headers).
-
But here the class name was used by the "runtime" to find which serializer should be used
Okay sorry, I misread your post then. Indeed this wouldn't be really different from the current approach. I don't think it would simplify the serialization process -- it'd just be placed somewhere else.
The main problem with a "Serializable" interface is that it'll be a pain to get the widgets that can be serialized and those which can't (because some maybe don't implement "Serializable"). A solution would be to provide a virtual method in sfg::Widget, so that all widgets have at least the same interface. But I don't like this idea much, just because it forces every widget to implement a (de)serialization method, thus putting in more complexity.
What about using a metaobject system similar to Qt? A widget would declare all of its properties, then you can request and manipulate them at runtime. It allows a kind of reflection actually.
...
If you're interested, I know a very good library which does exactly that, much better than Qt (no precompiler, uses meta-programming to generate the bindings at compile-time, only requires boost headers).
I've never heard of a metaobject system, but I was at least thinking about something similar to be able to access widget's properties more generic. So your idea sounds perfect in my ears. :) Would be nice to hear from that library to see how it works in detail. I guess it would perfectly fit into the (de)serialization process for SFGUI (at least a much cleaner design).
-
Would be nice to hear from that library to see how it works in detail. I guess it would perfectly fit into the (de)serialization process for SFGUI (at least a much cleaner design).
It's an open-source library that I wrote for my company last year. We recently switched to LGPL and made the first public release. We're still working on the website so I can't give you a link, however you can already have a look at the git repository (http://github.com/tegesoft/camp), and I can send you the latest version (with precompiled libs, doc, etc.) if you want.
The website should be online in a few days though.
Don't hesitate to ask me if you need help or more information :)
-
What about using a metaobject system similar to Qt? A widget would declare all of its properties, then you can request and manipulate them at runtime. It allows a kind of reflection actually.
This system is much more powerful than a "hard-coded" serialization solution, because the meta-properties can then be used anywehere:
- text serialization
- object editor tree
- binding your classes to a script engine
- ...
- look at the huge list of Qt modules based on the meta-object system
If you're interested, I know a very good library which does exactly that, much better than Qt (no precompiler, uses meta-programming to generate the bindings at compile-time, only requires boost headers).
Does it allow to bind "function names" to "functions" ? I mean... it'd be nice to be able to set the widgets slots according to what the user set in the UI designer. Thus he wouldn't have to set these programmatically.
-
Thank you very much Laurent, I'm cloning the repository right now.
-
Does it allow to bind "function names" to "functions" ? I mean... it'd be nice to be able to set the widgets slots according to what the user set in the UI designer. Thus he wouldn't have to set these programmatically.
It allows to bind functions so that you can manipulate them by their name, yes. So you could connect signals and slots in the designer and export your setup, if that's what you mean.
-
At first thanks a lot for the pointer, Laurent.
Just built the library and read the example in the Doxygen documentation. I have to admit that it looks very promising and would definitely help in the (de)serialization task. I will play around a bit with it to see how it'll work out.
I'm just not sure if I should really take the extra dependency (which would of course be shipped with SFGUI) into SFGUI. But I'll definitely have a look.
Amusingly CAMP reminds me a lot of Python. :)
-
Does it allow to bind "function names" to "functions" ? I mean... it'd be nice to be able to set the widgets slots according to what the user set in the UI designer. Thus he wouldn't have to set these programmatically.
It allows to bind functions so that you can manipulate them by their name, yes. So you could connect signals and slots in the designer and export your setup, if that's what you mean.
Yup that's what I was thinking of, sounds great! Thanks :)
Otherwise some news from the front* Tanks ?
*I dunno whether you say that phrase in English :/
-
I dunno either, but I got the point. ;)
Yeah, I'm currently testing out some ideas for the serialization, but nothing concrete. I'll have something to test the next days, I guess.
-
Hi
Just an update about CAMP: today we published the website, forum and version 0.7.0.
http://dev.tegesoft.com/projects/camp
http://dev.tegesoft.com/projects/camp/forum/
-
Thank you for the pointer. I guess CAMP will make it into the first release -- and interested folks may now listen carefully -- which takes up some time. ;) (sometimes it seems that SFGUI is a neverending construction site, it was about to be released 4-5 times in the past ;))
-
(sometimes it seems that SFGUI is a neverending construction site, it was about to be released 4-5 times in the past ;))
Don't worry, it's always like that. Take your time :)
-
Hey, do you have some news Tank ?
-
Not yet, currently working on the serialization stuff in a local branch. However, time's currently rare. I'll keep you guys informed.
-
I've installed Redmine on my host to manage tickets, downloads etc. for SFGUI. Registration is open, so if you have ideas or found bugs, visit http://redmine.boxbox.org/projects/sfggui .
-
Hi Tank,
I plan to use your nice gui for my OAW project (see signature) because CEGUI is too big and too difficult to use, and Guichan does not correspond to my needs (ex : font support is done by image...).
So I've got the sources but I can't compile sfguy library with cmake, SFML does not seem to be linked and included in you Cmake file, so I have to add cpp files directly in my project, and that is a bit ugly...
Here are my modifications of CMakeLists :
# Modified by Pierreyoda (2010)
include_directories("F:/Prog/SFML-SVN/branches/sfml2/include")
link_directories("F:/Prog/SFML-SVN/branches/sfml2/lib/mingw")
add_library( sfml )
target_link_libraries( sfml-audio sfml-graphics sfml-window sfml-system ) # Does not work
# End of modification
But it does not work...
So is it a bad method or is it an oversight on your part?
-
Could be very likely that it's an oversight on my side. Since I've switched to CMake, I didn't test SFGUI on a Windows machine which does linking a bit different than on Linux.
The greatest thing would be if you'd come up with a solution so I can include it in the sources. What does "# Does not work" mean in detail; what's the error message?
Also try to remove the quotation marks in the parenthesis for "include_directories" and "link_directories".
-
add_library( sfml )
target_link_libraries( sfml-audio sfml-graphics sfml-window sfml-system ) # Does not work
I didn't look at the sfgui makefile, but if what you want is to link sfgui to SFML, it should rather look like this:
target_link_libraries( sfgui sfml-audio sfml-graphics sfml-window sfml-system )
Another improvement would be to use a FindSFML.cmake that will automatically find SFML, so that you can remove those absolute paths from the sfgui makefile. If a remember correctly, someone already wrote such a file, you should be able to find it on the forum.
-
Ok, thanks, I'm gonna try to do that.
-
Hey Tank, just to say that I've been starting working with sfgui, and my impressions is that it's an amazing library, very thoughtful, and that it gives a good overview of what a new GUI framework (Qt, wxWidgets) in modern C++ could be.
I've made a base class (in the style of SampleApp) whom all GUI parts (main menu, ingame GUI...) inherit.
Here is a little screenshot of WIP (NB : GUI part is of bad quality in that screenshot, "made with" SFML, don't know why) :
(http://s2.noelshack.com/uploads/images/9581634230751_cap9.png)
-
Thank you. :)
I guess the problem is related to some blending mode issue with the render-to-image feature. Please try to disable it with sfg::GUI::EnableRenderToImage( false ).
Is it possible to see some code? I had this kind of issue in the past too, but I don't remember how I solved it.
-
By doing
getGui().EnableRenderToImage(false)
the "problem" (just appears in screenshot) is solved, but I've got a crash in release mode!
I'm gonna try to recompile sfml with the latest version.... :?
EDIT : When I link to a debug version of sfml2-graphics there is no more crash... (crash in Image::saveToFile).
-
SaveToFile() isn't used by SFGUI. ;)
-
Yep, it seems to come from SFML or it dependencies... Nevermind, the problem is solved by a tiny debug linking.
By the way, is there a way of doing an horizontal ListBox (I didn't find one in documentation) ? It would be much more practical for a map editor...
And what about a list of sprites with a label next to them (Sprite+Label) ?
I guess I have to make a custom ListBox... :x
EDIT : a custom "SpriteWithLabelItemView" should work, i'm gonna try.
-
SFML2 lib files were renamed from libsfml-module.so to libsfml2-module.so. I tried to find any sfml related thing in the makefile, but didn't succeed. I finally renamed my SFML libs. Can anyone tell me how to modify the makefile?
Thanks!
-
The file you are probably looking for is "<sfgui>/samples/CMakeLists.txt" since that seems to be the only file that contains the name of the SFML libs.
Running any sample crashes with a segfault though, so not sure if theres something missing.
-
The file you are probably looking for is "<sfgui>/samples/CMakeLists.txt" since that seems to be the only file that contains the name of the SFML libs.
Running any sample crashes with a segfault though, so not sure if theres something missing.
Thanks, I finally fixed that. Now console shows this:
./avatar: error while loading shared libraries: libsfml2-system.so: cannot open shared object file: No such file or directory
Where is supposed the libs to be? They already are in /usr/local/bin.
-
You probably forgot to reload your lib cache via "ldconfig" (as root).
Regarding to the lib naming: Yep, that confused me, too. I don't know why Laurent chose to rename "libsfml*" to "libsfml2*", since the version is included in the .so name, so that the libs are now called "libsfml2-...-.so.2.0.0" ;) (maybe this has more concrete reasons on Windows systems?).
By the way, is there a way of doing an horizontal ListBox (I didn't find one in documentation) ? It would be much more practical for a map editor...
Added to my todo list, thanks.
And what about a list of sprites with a label next to them (Sprite+Label) ?
That's the reason why sfg::Listbox is highly templated. I don't have a clue what developers want to display in their listboxes, so I leave the specific implementations to their own. ;) It isn't very hard to extend it btw. Just have a look in the source code to see how the built-ins StringListbox and ImageListbox work.
An explanation of the template arguments can be found in the Doxygen description of sfg::Listbox.
-
I don't know why Laurent chose to rename "libsfml*" to "libsfml2*", since the version is included in the .so name, so that the libs are now called "libsfml2-...-.so.2.0.0" ;) (maybe this has more concrete reasons on Windows systems?).
Yep, there is no versionning on Windows : I've got a "libsfml2-[module].a" and that's all! :(
For other responses : thank you very much tank.
(Can't wait for 1.0, but actually sfgui is quite sufficient for any project! :P )
-
True, no versioning on Windows for filenames. But that does also count for SFML 1.0 to 1.6. ;) Laurent, am I right that the reason for libsfml2* is versioning? If so, is it possible to change the behaviour for Linux operating systems? I think different library names would just unnecessarily pollute the filesystem (and the .so name has been introduced for exactly such purposes).
Thanks for your words, pierreyoda.
Another thing that came to my mind is how skins are handled at the moment. Somehow I'm quite unhappy with the current solution, in detail: I don't like how images for the widgets are arranged. I think it would be much nicer to be able to split each state of a widget's graphic into a single file and have more power for defining properties (like regions for tiling).
Also, I'm going to -- yeah, again ;) -- improve the class hierarchy here and there. Presently a lot of stuff is redundant (e.g. labels/texts for several widgets).
Lastly I'm thinking about switching back from CMake to SCons. Unfortunately I don't get warm with CMake. SCons does also work on Windows and even has the ability to generate IDE project files, so I ask myself why I've switched at all.
-
SCons seems much easier (still not found how to link sfml with Cmake...).
Personally I'm satisfied by the current skin system, but of course if you can make it much powerful...
PS : Solved the bug by saving the screenshot into *.jpg file (instead of *.png) :lol:
-
Check the CMake manual at http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:target_link_libraries .
The upstream repository of SFGUI has been updated to use SCons again. Also I committed some minor changes: Alignments for sfg::Label (generally another behaviour), deactivated render-to-image by default.
Currently I'm investing some time in using CAMP for deserialization. Not so easy though with the current implemention, but it's definitely worth it.
-
Why not use boost::serialization?
It's a bit intrusive but no need to bind something, that's the choice I've made for my project. And you're already using boost...
-
Because CAMP is rather lightweight and brings in code reflection. However I think it's missing some relevant features, so I still need some more testing to see which library fits most.
-
Laurent, am I right that the reason for libsfml2* is versioning? If so, is it possible to change the behaviour for Linux operating systems? I think different library names would just unnecessarily pollute the filesystem (and the .so name has been introduced for exactly such purposes)
I know that this is unnecessary on Linux, but then the linker options would be inconsistent with Windows (-lsfml-xxx on Linux, -lsfml2-xxx on Windows).
I still don't know whether I should keep this naming convention or not, I don't really like having the major version number in the filename, but things would be too messy on Windows without it. We can discuss it in a new topic if you want.
Lastly I'm thinking about switching back from CMake to SCons
May I ask why (I don't know SCons at all)?
However I think it's missing some relevant features, so I still need some more testing to see which library fits most.
Don't hesitate to do feature requests ;)
-
Lastly I'm thinking about switching back from CMake to SCons
May I ask why (I don't know SCons at all)?
Sure. :) I think the best reason is the personal liking. For example I can't get warm with CMake's syntax for its CMakeLists.txt files, it's not intuitive in my eyes.
With SCons I have the full support of Python (a language I'm very used to) and also the possibility to generate project files for various IDEs (even though those aren't up-to-date). I just find it easier to maintain and create SCons setups than CMake ones.
Will create two threads for versioning and the CAMP thing -- but not here, of course. ;)
-
Ok, thanks :)
-
Major design update for SFGUI:
As I was pretty unhappy about the fact that widgets are only able to render sf::Images (with the "boxing" method), I thought about possible alternatives. And because the library is inspired by GTK, I took another look of how they implemented the rendering separation, namely engines and themes. GTK separetes the look by providing a rendering engine that actually renders the visuals and a theme that modifies various settings in that engine (e.g. colors). The big advantage is: You can modify how widgets look *completely* by switching the engine.
I think getting such a design into SFGUI would be more than neat. My current design is as follows:
The widgets do not render them themselves anymore. Instead they use a rendering engine that encapsulates the rendering. This engine produces sf::Drawables that each widget caches and renders upon redraw. Besides the engine, there're themes just like in GTK: I will provide a basic theme loader that loads in some properties that can be used by the rendering engine. For example -- of course depending on the engine! -- you can adjust colors and special effects here (shadows, animations, w/e).
SFGUI will come with a standard engine called "BREW" that will mostly do what the current "static" rendering in SFGUI also does: Rendering images. However, it will provide more functions like tiling images, stretching them, "boxing" (like it's done at the moment) and using animations.
Rendering engines for SFGUI are of course written in C++. That means if you want to change the look and feel of widgets dramatically, you'll have to provide your own. But for most users this isn't needed, since BREW will already give you enough features to build up your GUI.
Theme files will look like this:
* {
color: #000000;
background-color:#ffffff;
}
Button.States.Normal {
image: button.png;
method: box;
}
Button.States.Hover {
image: button_hover.png;
method: box;
frames: 3;
delay: 100;
}
Editbox {
padding: 5 5;
}
Looks familiar? Right! Most users know how to write CSS, so I chose a similar syntax for themes to make writing them easier and more intuitive than the current implementation. I guess maybe it's also easier for pure designers who're already familiar with CSS.
Phew, much to do, but I'm sure it will pay off. So stay tuned. :)
-
Well, what a little revolution! :D
Yep, skin files will be easier to personalize with that syntax!
Good luck :lol:
-
Sounds great ! o_o
Good luck indeed :)
-
Thank you guys. However implementing this forces me to change a lot of stuff all over the place. In other words: It'll take time. ;)
-
So it won't be finished in the near future, eh? :D Cause I want to use it for my project. :D (Hmmm.... maybe a stupid question, but can you estimate the time needed to finish it? Roughly... or give an idea at least :))
-
Hey, you can already use that library, that's what I'm doing, the changes will be mainly internal :o
-
It's not a good idea to use this library for your projects, yet. Changes are and will be massive, so a project using SFGUI at the moment will have to do a rewrite in a lot of places.
nulloid:
I'm currently heavily designing the new architecture and implementing it step-by-step, evaluating what's good and what needs to be rewritten. ;)
Okay, to don't let you in the dark, this is what I've done so far, or better: what's still being implemented.
The way SFGUI will work in the future is by automatic layouting. Currently you have to specify positions, widths and heights to get your widgets on the screen. Everyone who already worked with useful GUI frameworks (e.g. GTK or Qt) will know the concept of "sizers" which I adapted from the GTK's implementation a lot.
That change forced me to implement some basic widgets at first which weren't there in the latest commit: Window, Container, Bin and Box:
The container is a base class for other container-like widgets.
The bin is a container widget that can hold exactly one child.
The box is a so called "box sizer" (like VBox and HBox of GTK) that automatically arranges widgets horizontally or vertically, dependant on their needed minimum size (you can specify custom sizes, too, of course, however this is not recommended because it could destroy a natural GUI).
The window is what you probably imagine, a classic graphical window, that inherits the bin widget, therefore a window can hold only one window (don't scream, that's enough and logical. Remember you can also put in sizers there ;)).
The graphical part has been completely separated into render engines for now. The render engine takes care of producing visuals for the proper widgets, i.e. how they look like. Render engines are written in C++ but can be highly customized by themes (which are basically nothing more than some properties that fine-control the render engine's behaviour).
Presently two graphical widgets are nearly done: Window and button. Also a standard rendering engine "BREW" (Basic Rendering Engine for Widgets, neat name, eh? ;)) is being enhanced as soon as new widgets arrive. BREW is very basic, which means that every widget is painted just using sf::Shapes -- thickness, colors etc. can be however adjusted via the theme.
When all that stuff is done, I'll provide another rendering engine that takes images for drawing, so you can have more pretty visuals. Besides from that, it's of course possible to write an own rendering engine that, for example, uses animated sprites or even super-uber-mega effects for the widgets. No limits here!
As you may note, the changes I just described are really huge, so the code of SFGUI currently looks like a complete rewrite and even feels like a such. I didn't mention the eventing system that has also completely changed, just like the signalling. ;)
I can understand when people who were and are interested in the "previous" SFGUI are sighing now, but I promise, give it some time to develop to a good state, and I ensure that you'll be a lot happier with the new approach than the previous one.
Stay tuned!
-
*stands in a total awe...*
Woahhh....just...woaaah... Well, this was more than enough for me, now I have an idea about release dates :D
The bin is a container widget that can hold exactly one child.
Isn't something similar in guichan?
Though I really didn't understand much, but seems promising, so... keep up the good work ;) And thanks the details :)
-
I don't know, I never really worked with guichan. However a bin-like container is available in most GUI frameworks, so I guess it's nothing special. ;)
Regarding to the release date: I've been very careful with giving any dates since I did that once with SFGUI, I was not pleased with it and couldn't hold it. But you have my guarantee that I'm currently focussing on bringing it to a state where the new stuff can be tested, because I'm surely interested in opinions. Also, I need the library for a commercial title, therefore I'm speeding things up, a bit. ;)
I will post bigger updates here and as soon as I feel like it has reached a state that could be interesting for others, I'll post the link to the Git repository. :)
Anyway, thank you very much for your interest, keeps me motivated.
-
A commercial title? Wow... does SFGUI made it's way to the commercial game market? :D Can you tell some details?
-
Not yet, too early. However SFGUI is just supporting here, not the main reason. ;)
Note that SFGUI won't cost you anything if you got that wrong. I'm even thinking about releasing it under the zlib license.
-
Note that SFGUI won't cost you anything if you got that wrong.
Don't give me a heart attack, didn't even think of that :D My point was that SFGUI's quality must be good, if it can support a commercial title :)
I'm even thinking about releasing it under the zlib license.
Go for it ;)
-
Note that SFGUI won't cost you anything if you got that wrong.
Don't give me a heart attack, didn't even think of that :D My point was that SFGUI's quality must be good, if it can support a commercial title :)
Not must be good, has to be good enough. ;)
-
Not must be good, has to be good enough. Wink
Not much of a difference... is it? :D
Just a question: will it be a widget-based library? So for example, if I were to use SFGUI, but I need, let's say, a widget, that draws a simple pong game, will I be able to create it? (Of course, I only need a widget base, and enoudh acces to that base :))
-
Yes, that's possible. The widget base class implements some defaults mainly for internal communication between widget hierarchies.
Rendering is done by creating a proper sf::Drawable. You can either declare a "wrapper" sf::Drawable that calls your Pong rendering code or override the rendering method via the signalling system. Also, SFML events are delegated all the way down in the hierarchy, so you'll be able to catch keypresses etc.
Besides of the technical possibilities, I highly doubt that a complete game should be put into a widget. ;) However, it's possible.
-
Besides of the technical possibilities, I highly doubt that a complete game should be put into a widget. ;) However, it's possible.
Hehe... I didn't intend to, just wanted to be sure and aware of the possibilities. I want some gui widgets for my project, but those are like if I'm writing a simple game :D (For example, a linear function editor)
But that game-in-widget is not that bad idea. If somebody is to write an installer in sfml, he can provide some simple timekillers, from which the user can choose :D (I saw it in the sims2 installer, and I liked the idea :))
-
That's true, there're cases in which you want a widget to display combined functionality. Even common dialogs (file and color dialogs etc.) are often re-used and need therefore a design that opens this door.
Most widgets (at least those being closer to the top of the hierarchy) are designed to get derived, so you won't run into limits here. :) The question is, however, if you want to create new widgets or *combine* widgets, which is a huge difference. Combining widgets means to put some already existing widgets into one or more containers and providing a logic for them. Creating new widgets means to derive from sfg::Widget or sfg::Container (or one of its children) and implement own
- rendering,
- event handling and
- signalling.
Both options are perfectly fine since I've always put emphasis on being able to extend SFGUI easily.
Some words about the current status:
Box sizers are completely done. You can now put widgets in horizontal or vertical sizers in a window and specify a border width and padding. Widgets can be configured to expand, where they take extra space when the sizer grows, and to fill, where they fill up the complete assigned space available. Or even none of both. :)
With the box sizers it's already possible to create some nice GUI layouts (to be honest, often I don't need more when programming with GTK ;)). Two additional sizers will be implemented in total:
- Table (widgets are organized in rows and columns, thus having equal widths/heights in each)
- Fixed (widgets can be placed at custom, absolute positions -- not recommended, though, because resizing will either destroy your layout or will make it look ugly)
-
(widgets can be placed at custom, absolute positions -- not recommended, though, because resizing will either destroy your layout or will make it look ugly)
Can one set a minimum size of a window?
Also, there is a lot of things in concrete positioning, as I see: absolute to the top-left corner, relative to window borders, relative to other widgets, specifying a ratio (for example, this widget should be at as high as the 1/3rd of the windows's height), combining these... are you planning these, or just a very simple basic set of commands, and instead focusing on automatic positioning, relying on sizers and tables?
(Sorry if I'm asking too many questions, I'm very new to GUI programming, not to mention GUI library programming :))
-
Can one set a minimum size of a window?
Absolutely, the design of the widgets allows that. Every widget has two sizes: The allocation which is the actual visible size, and the requisition that is the size requested by the widget (often referred to as a minimum size). Widgets are always put into containers, and containers are in most cases responsible for allocating the widget's size. To calculate the allocation, the container checks the requisition and either allocates exactly the same size as the requisition or allocates more space -- but never less.
However, neither setting the allocation nor requisition is recommended. In most cases you should use the automatic layouting which ensures a clean and more importantly flexible GUI. Sizers take care of allocating space when, for example, a container gets resized (e.g. a window gets resized by the user).
Also, there is a lot of things in concrete positioning, as I see: absolute to the top-left corner, relative to window borders, relative to other widgets, specifying a ratio (for example, this widget should be at as high as the 1/3rd of the windows's height), combining these... are you planning these, or just a very simple basic set of commands, and instead focusing on automatic positioning, relying on sizers and tables?
No, such "complex" positioning features are not planned and would somehow destroy the current approach. I understand that developers and even designers want to have the greatest possible power regarding their GUIs. But it's really the best idea to let the library decide the details. You as the developer/GUI designer decide WHAT gets displayed and take care of groupings and logical placements. The rest is done by the library, i.e. sizing the widgets so that they look natural and consistent.
In my past I used a couple of GUI toolkits, like Windows controls, wxWidgets, Qt and GTK+. The Windows stuff was (I don't know how it's done these days) horrible: Absolute positioning everywhere and you had to take care of resizing and repositioning the widgets. That led to inconsistent GUIs (we all know the "gold old" Shareware programs, where you wanted to puke when they were started ;)). wxWidgets does it better, because you've got sizers there, too, and you've got a bunch of standardized widgets. However, code-wise it feels very "old" and unclean IMHO. Qt is far better, the GUI part of it is properly designed but has also some facts I dislike, like the enforcement that every widget must know its parent upon construction or when it gets put into a container. GTK+ is, in my opinion, the best designed GUI toolkit out there nowadays. It makes high use of flexible layouts/sizers which are even easy to use. Also, the code is absolute clean and logic. The only problem is that it may look alien on non-Gnome environments -- of course there're solutions for that. :)
Okay, enough excursion: SFGUI is highly(!) inspired by the GTK+ toolkit. I try to adapt the clean design and functionality as good as I can, and therefore I will always recommend to use the principles GTK+ recommends. Up to now (I've been using GTK+ for some months now, also in commercial projects, even on Windows) this worked out perfectly and I've never reached a point where I felt hitting the edge. So, if you guys know how GTK works, you will know how SFGUI will work. And if you're happy with GTK+'s design, you will also love SFGUI's. ;)
(Sorry if I'm asking too many questions, I'm very new to GUI programming, not to mention GUI library programming :))
That's absolutely okay, I'm always happy to hear questions or comments, because often those lead to rethinking about some facts. ;) So if you've still got questions, feel free to write them down.
-
You should become a politician: you convinced me about thinkink "GTK+ is the best" in no time :D And if SFGUI is a way to bring it's magic into SFML, than that's the library I'm looking for :D
Well, I've ran out of questions, you answered even those which are arised in me reading the first part of your post :) Oh, wait, there is one: when will it be released? XD (don't take it seriously, just mocking ya :P Btw, you always can reply "When it's done", some noname guy is already doing that... Carmack, or who... :D)
-
Probably Carmack, but best known from the Duke Nukem: Forever guys. ;)
Release date? Don't even think of it in a short time. :) That beast needs a lot of testing by hopefully a couple of developers. But I guess that the source code repository will be published soon.
-
Probably Carmack, but best known from the Duke Nukem: Forever guys. ;)
Now you mention it... right :D
Release date? Don't even think of it in a short time. :) That beast needs a lot of testing by hopefully a couple of developers. But I guess that the source code repository will be published soon.
Looking forward to it :D Keep up the (hopefully) good work ;)
-
I wouldn't mind helping out testing it, I need a proper GUI so bad its not even funny. :?
working on a tower defense so i really don't want to roll my own when it comes to buying/upgrading menus and the interface for all that stuff.
I've been procrastinating it for months! (though I got a lot of work done on the game because of it!)
As such I'm most definitely willing to help out any way I can!
-
working on a tower defense so i really don't want to roll my own when it comes to buying/upgrading menus and the interface for all that stuff.
As such I'm most definitely willing to help out any way I can!
Thank you. The problem I see is at least that when the first bunch of work is complete for SFGUI, you'll get a library with...
a) maybe bugs,
b) maybe a changing interface and
c) a default renderer for the beginning.
The default renderer (BREW) uses sf::Shapes for visuals, and you probably want your user interface to be of a better looking than that. ;) Nevertheless a second rendering engine, that uses sf::Sprites for the visuals (and therefore images), has already been planned, but of course it will take some time.
I'm happy that at least two developers are willing to help testing the library, that's great! But please keep always in mind that SFGUI is under heavy(!) development, and the chance that things will be changed massively is there (of course I try to avoid that by designing SFGUI properly before implementing, but problems arise everywhere ;)).
Some words regarding the progress:
The box sizer is completely finished now. It supports vertical and horizontal alignment, padding between packed widgets, a border width and the flags 'expand' (use as much space as possible) and 'fill' (fill out the complete assigned size). It's tested and behaves good so far. :)
The next steps are:
- sfg::Workspace: A class that manages an SFGUI context (to activate different renderers) but is also a container for sfg::Windows (mostly you'll start by creating a workspace and adding windows to it).
- SFML event handling: Theoretically completed, needs to be implemented now. It will happen in a way where you don't have to care about SFML events at all, but just use the widget's signals to connect your functionality.
When those two fat todos are done, I'll continue by writing a theme loader for loading renderer-specific properties, 1-2 more widgets and will then publish the repository.
-
A little sneak preview of the box sizers and buttons together with BREW rendering and first draft of SFML event handling in combination with SFGUI's signalling system: http://www.youtube.com/watch?v=tazpl1ZBgvg
The most stuff is of course happening internally and you might think: "What the hell, that looked better the last time!" Yep, true, but it won't in some weeks. ;)
-
I just watched. And I want it. NOW! :D Really, I like that. Nice and neat. Congrat, and keep up the good work, Tank ;) (Except when the window oversized the screen... a part of me died then :))
-
You hopefully will never have so many widgets that a window doesn't fit onto the screen. :)
-
Amazing! Can't wait for! :D
-
- Draggable widgets implemented (up to now sfg::Window for moving it around).
- Reworked eventing for container widgets (especially event hooking that took place in sfg::Widget before).
- Basic window style/behaviour flags (titlebar, background, resizable)
I can't believe how smooth the progress is going on. If it continues like it does now, then I think I'll get something ready to test for you in a not too far future.
I will post a new screencast when per-widget style properties and proper font management is implemented. You have maybe already recognized that the buttons look rather huge because they have no clue about how large the font is set in the style properties, so they use sf::Font::GetDefaultFont() to get the text metrics. So still some design questions to solve. ;)
-
"SFGUI is released under the terms and conditions of the GNU LGPL."
O:
I was expecting BSD licensed, since SFML is also BSD licensed. Oh well.
-
I was expecting BSD licensed, since SFML is also BSD licensed
SFML uses the zlib/png license ;)
-
I was expecting BSD licensed, since SFML is also BSD licensed
SFML uses the zlib/png license ;)
Oh. Well, I tend to think of everything as BSD-style vs GPL-style, since those are the two big ones. My bad.
zlib is just as well. The big thing for me is being able to ship it with BSD-licensed systems and being able to statically link to it in a closed-source application.
-
"SFGUI is released under the terms and conditions of the GNU LGPL."
Since SFGUI hasn't been released yet, it's subject to change. :)
-
Update, additions:
- Window movement (made possible by implementing most of the eventing stuff, hooking etc. pp.)
- Per-widget properties to override the render engine's (or theme's) properties to make single widget look differently.
- Lazy update of requisition and allocation sizes to improve performance (reducing calls to render engine and other objects).
- Window styles (titlebar, movable, resizable, transparent).
- A loooot of internal modifications and additions.
For your eyes: http://www.youtube.com/watch?v=wZ7D62Vfnfk
The code used for the example (neither clean nor beautiful, be warned):
#include <SFGUI/Window.hpp>
#include <SFGUI/Button.hpp>
#include <SFGUI/Box.hpp>
#include <SFGUI/Engines/BREW.hpp>
#include <SFML/Graphics.hpp>
class SampleApp {
public:
void Run();
private:
void OnAddButtonHClick( sfg::Widget::Ptr widget );
void OnAddButtonVClick( sfg::Widget::Ptr widget );
void OnNewButtonClick( sfg::Widget::Ptr widget );
void OnToggleTitlebarClick( sfg::Widget::Ptr widget );
void OnHideWindowClicked( sfg::Widget::Ptr widget );
sfg::Window::Ptr m_wndmain;
sfg::Box::Ptr m_boxbuttonsh;
sfg::Box::Ptr m_boxbuttonsv;
};
void SampleApp::Run() {
sf::RenderWindow window( sf::VideoMode( 1024, 768, 32 ), "SFGUI test" );
sf::Event event;
//window.UseVerticalSync( true );
// Create widgets.
m_wndmain = sfg::Window::Create();
m_wndmain->SetName( "wndmain" );
m_wndmain->SetTitle( L"Example application" );
m_wndmain->SetBorderWidth( 10.f );
sfg::Button::Ptr btnaddbuttonh( sfg::Button::Create( L"Add button horizontally" ) );
sfg::Button::Ptr btnaddbuttonv( sfg::Button::Create( L"Add button vertically" ) );
sfg::Button::Ptr btntoggletitlebar( sfg::Button::Create( L"Toggle titlebar" ) );
sfg::Button::Ptr btnhidewindow( sfg::Button::Create( L"Close window" ) );
btnaddbuttonh->SetProperty<std::string>( "Button.background-color", "#ff0000" );
btnaddbuttonh->SetProperty<std::string>( "Button:prelight.background-color", "#ff9999" );
btnaddbuttonv->SetProperty<std::string>( "Button.background-color", "#000055" );
btnaddbuttonv->SetProperty<std::string>( "Button:prelight.background-color", "#5555bb" );
btnaddbuttonh->GetChild()->SetProperty<unsigned int>( "Label.font-size", 20 );
btntoggletitlebar->GetChild()->SetProperty<unsigned int>( "Label.font-size", 28 );
btntoggletitlebar->SetPadding( 15.f );
// Layout.
sfg::Box::Ptr boxtoolbar( sfg::Box::Create( sfg::Box::Horizontal ) );
boxtoolbar->SetName( "boxtoolbar" );
boxtoolbar->SetSpacing( 5.f );
boxtoolbar->Pack( btnaddbuttonh, false );
boxtoolbar->Pack( btnaddbuttonv, false );
boxtoolbar->Pack( btntoggletitlebar, false );
boxtoolbar->Pack( btnhidewindow, false );
m_boxbuttonsh = sfg::Box::Create( sfg::Box::Horizontal );
m_boxbuttonsh->SetSpacing( 5.f );
m_boxbuttonsv = sfg::Box::Create( sfg::Box::Vertical );
m_boxbuttonsv->SetSpacing( 5.f );
sfg::Box::Ptr boxmain( sfg::Box::Create( sfg::Box::Vertical ) );
boxmain->SetSpacing( 5.f );
boxmain->Pack( boxtoolbar, false );
boxmain->Pack( m_boxbuttonsh, false );
boxmain->Pack( m_boxbuttonsv, false );
m_wndmain->Add( boxmain );
// Signals.
btnaddbuttonh->OnClick.Connect( &SampleApp::OnAddButtonHClick, this );
btnaddbuttonv->OnClick.Connect( &SampleApp::OnAddButtonVClick, this );
btntoggletitlebar->OnClick.Connect( &SampleApp::OnToggleTitlebarClick, this );
btnhidewindow->OnClick.Connect( &SampleApp::OnHideWindowClicked, this );
while( window.IsOpened() ) {
while( window.GetEvent( event ) ) {
if( m_wndmain->HandleEvent( event ) == sfg::Widget::EatEvent ) {
continue;
}
if( event.Type == sf::Event::Closed ) {
window.Close();
}
}
window.Clear( sf::Color( 80, 80, 80 ) );
m_wndmain->Expose( window );
window.Display();
}
}
void SampleApp::OnAddButtonHClick( sfg::Widget::Ptr /*widget*/ ) {
sfg::Button::Ptr button( sfg::Button::Create( L"New ->" ) );
boost::shared_dynamic_cast<sfg::Label>( button->GetChild() )->SetAlignment( sf::Vector2f( 1.f, .5f ) );
button->OnClick.Connect( &SampleApp::OnNewButtonClick, this );
m_boxbuttonsh->Pack( button, true );
}
void SampleApp::OnAddButtonVClick( sfg::Widget::Ptr /*widget*/ ) {
sfg::Button::Ptr button( sfg::Button::Create( L"<- New" ) );
boost::shared_dynamic_cast<sfg::Label>( button->GetChild() )->SetAlignment( sf::Vector2f( 0.f, .5f ) );
button->OnClick.Connect( &SampleApp::OnNewButtonClick, this );
m_boxbuttonsv->Pack( button, false );
}
void SampleApp::OnNewButtonClick( sfg::Widget::Ptr widget ) {
sfg::Button::Ptr button( boost::shared_dynamic_cast<sfg::Button>( widget ) );
button->SetLabel( "Ouch" );
}
void SampleApp::OnToggleTitlebarClick( sfg::Widget::Ptr /*widget*/ ) {
m_wndmain->SetStyle( m_wndmain->GetStyle() ^ sfg::Window::Titlebar );
}
void SampleApp::OnHideWindowClicked( sfg::Widget::Ptr /*widget*/ ) {
m_wndmain->Show( !m_wndmain->IsVisible() );
}
int main() {
SampleApp app;
app.Run();
return 0;
}
-
Hellooo,
Do you have some news about SFGUI Tank ?
-
SFGUI's code design is coming to a clean and final state. Thereafter the missing widgets are being reimplemented.
I won't be able to work on it for the next ~2-3 weeks (exams at university). I'll keep you updated. :)
-
Okay thanks :) . I'mma wait for a few more weeks :p
-
I'm excited for this sucker.
-
beautiful!!!!!
any update???
-
The website are deleted? I can't read the web site of this project T_T
-
Calm down guys. ;) SFGUI is a little bit stalled at the moment due to time problems. However it's still in development.
The website (it has always been incomplete and not up-to-date) is unavailable because of a restructuring of the root server. It won't come back, btw., however there'll be a little place in the web when SFGUI's becoming more feature-complete.
Thanks for your support and interest.
-
A long time ago, whilst using SDL, I wrote a 2d gui which could render into an FBO... it was crappy and not really functional...
Recently I realized it's time to get a gui in my engine again as it's time to start making my map editor... FINALLY!
I put in a drop down console... that was fun.
So then I started writing a gui, which I find extremely daunting. So I searched and searched and found lots of opengl based guis, most of them using sdl or something else along with it, which I'd rather not clog up my engine with multiple toolkits...
Then I thought... well maybe someone wrote a gui for SFML...
BAM! here you are!
Just want to say, you have some amazing work... I bow to your code! I plan on using your gui on top of my 3d engine to make a level editor and the in game controls as well.
One question... is the git repo still up... if so, where is it?
Here's my site: http://www.palodequeso.net
-
Okay, to show some good will from my side, I've uploaded the current state of the code to GitHub. The old SFGUI code can be found in SFGUI_old, the current one in SFGUI.
Keep in mind that I wasn't able to do a lot for SFGUI the last weeks due to less time available. However I'm hoping to get some helping hands if anyone's interested.
Right now I'm trying to catch up with the code again to make progress again, so hopefully you might see some new lines of code the next days. :)
-
Many Thanks Dude! I might be able to help soon. I'll keep you posted.
-
Dude...
Your library is a thing of beauty!
It is exactly what I was looking for!
I compiled, installed, linked it to my engine, looked at your sample, made a panel and a button and fed it events.
DONE.
Works like a charm.
PS: I love you (not really)
-
Hehe, interesting. But keep in mind that the API might change massively. I do not recommend using the current state of SFGUI in a real project, yet.
Btw, I just setup a project website for SFGUI including a tracker etc. You can find it here: http://redmine.boxbox.org/projects/sfgui
In case you find bugs or have feature requests, feel free to register an account and file tickets there. Account activation happens manually, so it may take some time until it's activated.
-
I dig Scons, and I LOVE python. But since your project is all in c++, have you considered switching to CMake? It has awesome support for project generation and I'm having trouble with the Code::Blocks Generator when compiling a windows version of your GUI.
PS: I hate you windows, I wish I could just support linux, but the game community frowns on that :(
PPS: I'm gonna write you some CMake files really quick and post them here once they're working!
-
Well, the fact that SCons is written in Python and also utilizes Python for the build process doesn't mean it's not suited for C++ projects -- infact it's aimed at those. :)
I'm personally not a big fan of CMake and its weird syntax, so I think I won't make a switch there. However you can of course use your own CMake files for SFGUI and if you publish them here for other users then that'd be nice (I can even upload them to the SFGUI wiki, if you like).
What kind of problems do you exactly get when using the Code::Blocks project file? I've taken a -- maybe not perfect -- project template and am just replacing the source files there. So there might be some glitches.
-
Here's the steps I took in windows... linux works great!
- Installed Scons
- Modified the SFGUI Sconsscript just setting the codeblocks generator to 1
- Rand scons on SFGUI
- Opened the projects in code bocks
- Clicked compile
Here is my code::bocks output:
-------------- Build: Debug in SFGUI ---------------
Compiling: ..\..\src\Bin.cpp
CreateProcess(): The system cannot find the file specified.
Process terminated with status 123 (0 minutes, 0 seconds)
0 errors, 0 warnings
-
I just tried simply lettings scons build it, but it autoselected Visual C++ as the compiler, when I want to use MinGW. Is there a way to correct that?
-
Try to set the "CXX" environment variable. Either it works by invoking it with scons (like "scons CXX=...") or specifying it in a custom SCons settings file (I setup the SFGUI SConscript so that it includes custom.py).
Are you sure that the used compiler in the project file is valid? The source file shouldn't be a problem, location looks correct.
-
A small nifty update. ;)
I just implemented a theme loader for the rendering engine. Themes basically consist of simple key/value pairs that influence the rendering engine's appearance. What properties are available depends on the used engine. The standard (and included) rendering engine "BREW" for example mostly takes colors and font sizes etc. (other engines might also load images or have effects)
I tried to separate the loading code as much as possible to hang in loaders for your custom format. I did a reference implementation for the YAML file format, however it won't make it into the master branch since it needs a dependency (yaml-cpp) that I want to avoid for public releases.
Instead, a very simple theme format will be introduced, that'll look as follows:
Button.Normal.BackgroundColor = #aabbcc
...
If you're interested in seeing the YAML loader, check out the "yaml" branch (https://github.com/TankOs/SFGUI/tree/yaml) I uploaded to GitHub. How loading themes work can be seen in the sample application (https://github.com/TankOs/SFGUI/blob/yaml/samples/Test.cpp#L80).
Always keep in mind that the whole stuff will get easier in the future. SFGUI will get a "workspace" class that includes the used rendering engine and methods for loading themes more easily.
Stay tuned for the basic theme file format loader. I'd appreciate any testing or comments, so feel free to drop a line here.
-
How's the state of this project?
There are broken links on the first post:
(http://dev.boxbox.org/static/images/sfgui2.png)
The official site is at: http://dev.boxbox.org/projects/sfgui
-
I have looked into this project, but it is still in development and not ready for use. Anyway it was a good look. Inspired me to write my own GUI.
What I suggest to tank is to hide signals private since currently they are public and anyone can emit a signal.
-
@gsaurus:
The project is still active, but paused due to another project. However I will soon need a GUI for it, so I'll continue on SFGUI then.
@nefx:
Why not extend SFGUI? ;)
Regarding the public signals: I don't see a problem when the user is able to emit signals himself. Any concrete reasons not to do so?
Edit:
@Trass3r: Could you please strike-out the links in the first post?
The project website is currently located at http://redmine.boxbox.org/projects/sfgui .
-
Can I use this with SFML.NET?
-
Are you able to create windows inside the main window?
so make it like a virtual desktop?
-
@SuperV1234:
Not planned on my side. However if someone wants to create a binding, then yes. :)
@Richy19:
Not exactly like that. Windows are top-level windows. However you can create "workspaces" that you can either display or hide, which could be used to simulate virtual desktops.
-
Thanks to anttirt and binary1248, we now have sfg::Entry, which is basically a textbox widget.
Next tasks:
- Scrollbars
- Multi-column listbox
- Table layouter
-
News:
binary1248 has implemented scrollbars and sliders. This is how they look like:
(http://boxbox.org/~stefan/sfgui/sfgui_scroll_slider.png)
Also, a user called Iteem is developing a bitmap renderer (the current rendering engine (called BREW) uses sf::Shapes for visuals only) that provides fancier visuals. Check this out:
(http://boxbox.org/~stefan/sfgui/sfgRenderer_grey.png)
Rendering engines are completely replacable, even during runtime. I'm still working on sfg::Table, a table layouter.
Thanks to binary and Iteem for your contributions.
-
sfg::Table is 80% complete, multi-row/-column spanning is missing.
(http://boxbox.org/~stefan/sfgui/sfgui_table.png)
-
I've made good progress on the ListBox widget. It adapts the store/view principle of GTK, that means: On the one hand, you've got a store where your actual data is saved. On the other hand you've got the list box that utilizes the store to fetch the data it renders.
This makes everything rather flexible, because you have full control of the data types and can share stores between multiple list boxes without the need to copy data around.
Example in C++:
// Create the store for holding the actual data. The store can be used in
// multiple list boxes or anything else relying on stores.
sfg::ListStore::Ptr store = sfg::ListStore::Create();
// Setup the store's columns.
store->AddColumn<int>();
store->AddColumn<sf::String>();
store->AddColumn<bool>();
// Now create the list box and set the previously created store.
sfg::ListBox::Ptr list_box = sfg::ListBox::Create();
list_box->SetStore( store );
// Finally create the "visible" columns in the list box. We need to attach a
// "cell renderer" to each column so that list box knows how to render the
// contents. This way you can even render, for example, "bool" data as text or
// as fancy checkboxes.
// Of course cell renderers can be shared. Some renderers may have custom
// properties, so you probably have to create more than one.
sfg::TextCellRenderer::Ptr cell_renderer = sfg::TextCellRenderer::Create();
list_box->AppendColumn( sfg::Column( cell_renderer, 1, "Column 0" ) );
list_box->AppendColumn( sfg::Column( cell_renderer, 1, "Column 1" ) );
list_box->AppendColumn( sfg::Column( cell_renderer, 1, "Column 2" ) );
// Btw., the "1" means that the visible list box column refers to column 1 of
// the store.
// Now let's append some data:
store->Append()( 0 )( sf::String( L"Entry 0" ) )( false );
store->Append()( 1 )( sf::String( L"Entry 1" ) )( true );
store->Append()( 2 )( sf::String( L"Entry 2" ) )( false );
// The syntax may look confusing at first, but it makes it possible to insert
// data in a more comfortable way. Every value in each pair of parenthesis
// represents the proper column value of the store.
// Whenever you add, edit or remove data, ALL list boxes that use the store are
// updated automagically.
Results in this:
(http://dl.dropbox.com/u/10016269/sfgui/listbox.png)
The list box rendering hasn't been done, yet. So it's just a black rect without the column titles at the top.
-
Very nice work , easy to use , work fine on linux ubuntu x64, sfgui adopted !
Thank you very much.
ps: don't forget image button ! ;)
-
Thank you very much! Expect more stuff to come in the near future, 3 guys are working hard on it. ;)
Btw, can you show screenshots of it working in your project? Would love to see it in action.
-
Hello,
I recently discover SFGUI : it's a good GUI library for SFML.
I am going to use your library to create a plug-in for a french game creation freeware (Game Develop) (this freeware uses SFML for render). The plug-in will not use the layout widgets, but only the widgets like buttons, entry, scale...
I'm just waiting the developper of Game Develop to add a functionnality that allows plug-ins to access to the list of events produced by PollEvent.
Then, I will begin the plug-in developpment.
Where can I find the SFGUI logo ?
And can I use widgets without any container ?
(Sorry, if I make some english mistakes, I am only 16 and I'm French)
-
Please head over to SFGUI's new thread here for further replies, this one has been abandoned. ;-) -> http://www.sfml-dev.org/forum/viewtopic.php?t=6112
Still, here are the answers:
Where can I find the SFGUI logo ?
There isn't one yet, but someone is creating one at the moment. Hopefully he'll be done shortly. Check the thread I mentioned above to see when it's done.
And can I use widgets without any container ?
Yep, you can. However you have to render them one after each other by yourself (Expose()). Position and size can be set with AllocateSize().
With layouters it's probably much easier. Any specific reason not to use them? (you don't need to create a window at all, it works without, if that's the concern).
(Sorry, if I make some english mistakes, I am only 16 and I'm French)
Nah, it's pretty well. :)
-
This thread is now closed, please move to the new SFGUI thread:
http://www.sfml-dev.org/forum/viewtopic.php?t=6112