SFGUI (0.4.0 released)

[eXpl0it3r]

You need to be a bit more specific if you want to have valuable help. Most of use are not developers on a Mac so it's not too easy to understand your problems.

For example you should tell us the exacte CMake error and what do you mean with 'point the source code part'?

[The Terminator]

I'm sorry I'm being vague, I'm very new to Cmake and I'm not very familiar with it. What I am talking about, is when I try to build SFGUI on my Mac, I point the source to the main directory of SFGUI, and I point where to build the binaries is a folder that I created inside of it called "build". But, when I try to generate it using Xcode, it gives me an error that says CMake Error: The source directory does not appear to contain CMakeLists.txt. I am very frustrated and I really want to use SFGUI in my adventure game. Any help with this would be IMMENSELY appreciated.

[eXpl0it3r]

If you clone the SFGUI repository there should be a CMakeList.txt in the root folder of SFGUI. If you set the source path to the root folder of SFGUI then you should get such an error.

Btw SFGUI has it's own forum, so you maybe better of asking questions there: http://sfgui.sfml-dev.de/forum/

[The Terminator]

Thanks for the help, but I've officially given up on SFGUI. I cannot figure out how to include it into my original Xcode project or anything like that. I've tried all day, but I guess I'm stuck with plain old SFML....

[Mars_999]

Yeah it would be nice to get SFGUI to an actual release and was drop in a play easy... Someday....

[Hiura]

Thanks for the help, but I've officially given up on SFGUI. I cannot figure out how to include it into my original Xcode project or anything like that. I've tried all day, but I guess I'm stuck with plain old SFML....

Have you tried to drag and drop the binaries into your project ?

I don't use SFGUI (yet), but I guess you can build it like any other library. (Maybe frameworks build is not available because it's often a pain in the neck to find how to do that with auto-tools. But dylibs build should be available at least.) Now, like any library you need to install it. ... with your bare hands paragraph should give you a hint on the installation process.

[Tank]

Yeah it would be nice to get SFGUI to an actual release and was drop in a play easy... Someday....

Some things left before a release can be made:

- Some widgets still missing.
- Waiting for SFML2 to get stable (as in stable *release*), if we decide to keep sticking with it...
- Documentation.

Regarding SFGUI and OSX: We're sorry if it doesn't work properly, but unfortunately we can't test it at all, because nobody of the SFGUI developers owns a Mac. We once received a patch from someone who fixed the CMakeLists.txt to make SFGUI build on OSX, so we assumed that it works.

The Terminator, the best would be to describe what problems you exactly experienced. Even if you're not planning to use SFGUI anymore, it might be of interest for other OSX users.

[Mars_999]

Yeah it would be nice to get SFGUI to an actual release and was drop in a play easy... Someday....

- Waiting for SFML2 to get stable (as in stable *release*), if we decide to keep sticking with it...

And by that you mean? You will be using something else? Just curious...

[eXpl0it3r]

And by that you mean? You will be using something else? Just curious...

SFGUI is already highly depending on OpenGL itself and there are only a 'few' things that keep SFGUI tied to SFML (so I've been told on IRC), so in future they may change those dependecies too and become a GUI library which doesn't depend on any other library directly, but don't worry they won't abandon SFML but rather restructur the rendering engine to be even more modular, so it could be possible to connect the GUI with other graphics libraries. (Although I think the modular renderer could take a bit more time than those 'few' changes, I'm not sure so you should wait for a official statement.)

But with changes ahead a fixed release could again get pushed further back.
Although I don't really see the big advantage of a stable release. Sure for distribution & updates it can be nice to have something that doesn't change anymore and for software security (i.e. that nothing crashes with a new version) it's also good, but I haven't seen a single SFML/SFGUI project that would heavily depend on any of those reasons and personally don't think that there will be on in the new few weeks/month.
The community and popularity has first to grow more, maybe this will happen largly with SFML 2, we'll see.

[Mars_999]

Ok, I agree abstract out the input, logic side of the SFGUI lib, but you don't need to abstract out the rendering engine unless you want to have BREW, and allow the user to make their own engine, which IMO just keep using OpenGL as the rendering API as it is the only cross platform API, as your time is limited already and would be a waste to change that.

PLEASE, please finish up the drop down box multi line scroll bar I sent in moths ago as a feature before you head off on that direction I been patiently waiting for it.....

Thanks!

[Tank]

Infact dropping SFML at least for the rendering part gives us some benefits: We don't have to pay attention at SFML's limitations/ways of doing certain things. The renderer already has nearly nothing in common with SFML's rendering abstraction layer, so it's just logical to drop the dependency completely (as eXpl0it3r said, SFGUI can be used in other OpenGL-powered games/programs too then). However this is not very high on the todo list.

Of course we don't drop the OpenGL dependency -- not sure if you were asking that.

PLEASE, please finish up the drop down box multi line scroll bar I sent in moths ago as a feature before you head off on that direction I been patiently waiting for it.....

Multiline dropdown box? That doesn't make much sense. I guess you just mean a scrollbar for dropdown box lists that are too large to fit on the screen?

[Mars_999]

Infact dropping SFML at least for the rendering part gives us some benefits: We don't have to pay attention at SFML's limitations/ways of doing certain things. The renderer already has nearly nothing in common with SFML's rendering abstraction layer, so it's just logical to drop the dependency completely (as eXpl0it3r said, SFGUI can be used in other OpenGL-powered games/programs too then). However this is not very high on the todo list.

Of course we don't drop the OpenGL dependency -- not sure if you were asking that.

PLEASE, please finish up the drop down box multi line scroll bar I sent in moths ago as a feature before you head off on that direction I been patiently waiting for it.....

Multiline dropdown box? That doesn't make much sense. I guess you just mean a scrollbar for dropdown box lists that are too large to fit on the screen?

Correct, e.g.is when I have a video mode selection drop downbox, there are  a lot of screensizes to choose from... need to have the ability to scroll.

And yes, my point was DO not drop OpenGL as the rendering API. I would like to see you drop SFML as the drawing API as you could move to GLEW as it should be...

[Tank]

Well, GLEW is only an extension loader library to have access to OpenGL features that either aren't included in core yet or not supported on evil platforms by "design", like on Windows.

We are currently using GLee to load extensions, because we've been having issues properly linking both to GLEW and SMFL (I don't remember the details exactly). So yeah, we are already using OpenGL extensions for the renderer.

SFML is mostly used for loading textures, texts, input and utility classes.

[FRex]

Are there any news about sfg::ListBox ? Last post on your forum I found is from half a year ago.
Or at least

a scrollbar for dropdown box lists that are too large to fit on the screen

[binary1248]

Tank told me he was working on it... a while ago... I don't know what the status on it is right now . He'll have to get back to you on that. It seems like he has so many other things to do he hasn't had the time to finish it. We're always looking for new developers, all the time. People seem scared to start contributing even if what they want is easy to implement and they know how to do it themselves. Over the history of the project many people have contributed already, even if they wrote a fix for 1 line of code, it made a difference. As such we would be thankful if there is a submission for a ListBox widget from someone. It seems like a widget many people need .