Author Topic: SFGUI (0.4.0 released) (Read 393345 times)

Tank · « **on:** October 17, 2011, 05:36:34 pm »

SFGUI is a GUI (Graphical User Interface) C++ library especially designed for programs and games that use SFML for rendering.

The library has been designed with flexibility and performance in mind. Several features get you started really quick and make using the library easy: The automatic layout takes care of positioning and sizing widgets properly. Even if you have to deal with different screen resolutions, SFGUI will always try to pick the best layout.

Included are a lot of widgets, like buttons, toggle buttons, check buttons, radio buttons, drop down boxes, entries, scrollbars and some more. At any time you can extend the library by custom widgets.

The widgets' visuals are completely separated from their implementations. SFGUI makes use of so called "widget rendering engines" to create the visuals. One engine is included in the release, called BREW, which uses simple shapes and solid colors to paint the widgets. The shapes, colors, fonts etc. can be modified by setting style properties, which can be done directly in C++ or by loading external theme files, which look similar to CSS.

Features

Basic widgets: Window, Button, Entry, Scrollbar, Scale, ScrolledWindow, Label, ToggleButton, CheckButton, ProgressBar, ComboBox.
Layouters: Bin, Box, Table, Fixed
Replaceable widget rendering engines that decide how widgets are rendered.
Properties with selectors similar to CSS (e.g. "Window#main > Button.fancy").
Consistent size and positioning procedures, no need to manually fiddle around with positioning and (re)sizing your forms.
Custom OpenGL renderer for great performance.

Download
Download from here.

Contact
Website: https://github.com/TankOs/SFGUI/wiki

Nexus · « **Reply #1 on:** October 17, 2011, 07:57:56 pm »

Good to hear of SFGUI again!

I have downloaded the Git version a few days ago, and from what I've seen until now, its features as well as the code look very nice!

A minor issue: Compile times are relatively high, I think you could reduce them by using less #includes. For example, Button only depends on sf::String by name (i.e. forward declaration is enough). If you wrote shared_ptr<Label> instead of Label::Ptr, you could also remove the Label dependency. You already got rid of two #include directives, even without the use of Pimpl

By the way, I recently came across Header Hero, a nice tool to find dependency bottlenecks.

Tank · « **Reply #2 on:** October 17, 2011, 09:41:35 pm »

Thanks for your reply. I'm glad you like it. You're well-known as a superb C++ guy, so I'm kinda proud you like the code design. ;-)

You're absolutely right about the compile times. I already have a local Git branch where I try to get rid of includes just to reach typedefs. Using shared_ptr directly is a good solution, unfortunately it appears as such in the docs. Not a big deal, but I'd prefer the consistent "Ptr"/"PtrConst" style. In terms of effectivity it's no real option.

Thanks for the Header Hero hint, haven't read about it before and going to check it out. Also thanks for your GitHub issue contrib, solved a build issue. ;-)

OniLinkPlus · « **Reply #3 on:** October 18, 2011, 12:10:20 am »

Quote from: "Tank"

Thanks for the Header Hero hint, haven't read about it before and going to check it out. Also thanks for your GitHub issue contrib, solved a build issue. ;-)

Header Hero just came out a few days ago, so it makes sense you never heard of it.

Tank · « **Reply #4 on:** October 18, 2011, 12:43:42 am »

Unfortunately it doesn't run on Linux.

I'll see if it will by installing all those .NET stuff in Wine.

OniLinkPlus · « **Reply #5 on:** October 18, 2011, 12:51:09 am »

Quote from: "Tank"

Unfortunately it doesn't run on Linux. I'll see if it will by installing all those .NET stuff in Wine.

It's .NET, so it should. It's VERY useful. Cut down my total header size (counting includes) by >50%

victorlevasseur · « **Reply #6 on:** October 19, 2011, 11:32:25 am »

Quote from: "victorlevasseur"

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)

I have to use widgets separatly because the freeware (Game Develop) use an "object" concept. So I will create a Entry Object, a Button Object...

Tank · « **Reply #7 on:** October 19, 2011, 12:31:47 pm »

Quote from: "victorlevasseur"

I have to use widgets separatly because the freeware (Game Develop) use an "object" concept. So I will create a Entry Object, a Button Object...

I think I got it now. So by container you don't mean widget containers like the layouters in SFGUI, but managing classes, right?

If so: Widgets are created directly in SFGUI, so it should be fine for your game development tool.

victorlevasseur · « **Reply #8 on:** October 19, 2011, 12:40:43 pm »

Not exactly, GD (Game Develop) allows the user to create objects which are placed on a scene by him with absolute positions.

Game Develop is not my software, it is developped by Florian Rival (4ian) : http://www.en.compilgames.net/?file=kop1.php for further informations

Tank · « **Reply #9 on:** October 19, 2011, 01:06:55 pm »

Well, you can place a layouter at an absolute position and let it handle the rest.

victorlevasseur · « **Reply #10 on:** October 19, 2011, 04:16:14 pm »

I don't know how to explain that.
For example, this software is provided with Sprite object, Text Object, Light Object and many over. So I create other kinds of objects using SFGUI. The user can only place them himself, they cannot be placed by others objects.

If you want, I can show you what my future plug-in will do in the software. :wink: (I just wait for 1 week : the new version of Game Develop)

You show a picture of the window drawn by the Bob Render Engine. Where is Bob ?

Tank · « **Reply #11 on:** October 19, 2011, 07:49:55 pm »

Let's do an example:
Say you have "Box" (a layouter) and "Button" exported to Game Develop. Then you create a Box object and a Button object. If Game Develop is able to call something on objects, you can pack the button into the box. If not, then you really must use completely separated widgets.

Bob has not yet been applied to the master branch. You can check the current state here: https://github.com/Iteem/SFGUI/tree/Bob

victorlevasseur · « **Reply #12 on:** October 19, 2011, 08:15:52 pm »

Quote from: "Tank"

Say you have "Box" (a layouter) and "Button" exported to Game Develop. Then you create a Box object and a Button object. If Game Develop is able to call something on objects, you can pack the button into the box. If not, then you really must use completely separated widgets. Smile

Yes, but I don't think it was really user friendly (the users of Game Develop don't know programmation and the use of layouts). But, i will certainly add this later.

Quote

Bob has not yet been applied to the master branch. You can check the current state here: https://github.com/Iteem/SFGUI/tree/Bob

It's strange, it doesn't appear in the TankOs/SFGUI branches list.

Tank · « **Reply #13 on:** October 20, 2011, 04:22:51 pm »

Quote

It's strange, it doesn't appear in the TankOs/SFGUI branches list.

Yep, it's not maintained by me, but by a guy called Iteem. Just follow the link, you can clone it then. Or you go with the default rendering engine "BREW" as long as Bob is not applied to the master branch (you don't need to do anything to "activate" it; it's there by default).

Tank · « **Reply #14 on:** October 20, 2011, 04:40:17 pm »

*** Update ***

The new properties system has just been applied to SFGUI's mainline. Some flaws are still present (not all widgets are 100% compatible), but in general it works very good and convenient.

So, what's the new property system all about?

Previously you were able to set widget properties in the rendering engine AND in each widget. This was not acceptable, because properties only affect rendering in the most cases, so there's no reason to store them in widgets.

Also it was not possible to select special widgets for custom properties very easily. SFGUI lacked a nice selection feature. That's now included.

Imagine you want to change the text color of a label that's on a button. You do:

Code: [Select]

SetProperty<sf::Color>( "Button > Label", "Color", sf::Color::Red )

Those who wrote/read CSS will like the syntax of the selector.

Widgets can now also be identified by IDs and classes. Say we have a special quit button that we want to style differenty:

Code: [Select]

SetProperty<sf::Color>( "Button#quit", "BackgroundColor", sf::Color::Black );
SetProperty<sf::Color>( "Button#quit > Label", "Color", sf::Color::Red );

SetProperty<sf::Color>( "Button#quit:Prelight", "BackgroundColor", sf::Color::White );
SetProperty<sf::Color>( "Button#quit:Prelight > Label", "Color", sf::Color::Black );

Those 4 lines do the following:

Set background color of button with ID "quit" to black.
Set label color of button with ID "quit" to red.
Set background color of button with ID "quit" that's in prelight state to white.
Set label color of button with ID "quit" that's in prelight state to black.

Those rules can be applied to all available widgets. Btw., the "prelight state" is usually the state when the user moves his mouse pointer over the proper widget.

Here's a screenshot (using BREW as the rendering engine):