Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFGUI (old thread)  (Read 83707 times)

0 Members and 1 Guest are viewing this topic.

pierreyoda

  • Full Member
  • ***
  • Posts: 186
    • View Profile
    • http://pierreyoda.pagesperso-orange.fr/
SFGUI (old thread)
« Reply #90 on: October 15, 2010, 04:43:34 pm »
Hey, you can already use that library, that's what I'm doing, the changes will be mainly internal  :o
Projects:
- Open Rodent's Revenge (rewriting in progress)
- Open Advanced War (paused)

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI (old thread)
« Reply #91 on: October 15, 2010, 05:05:32 pm »
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!

nulloid

  • Full Member
  • ***
  • Posts: 134
    • View Profile
SFGUI (old thread)
« Reply #92 on: October 15, 2010, 06:46:13 pm »
*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

Quote
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 :)

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI (old thread)
« Reply #93 on: October 15, 2010, 07:40:55 pm »
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.

nulloid

  • Full Member
  • ***
  • Posts: 134
    • View Profile
SFGUI (old thread)
« Reply #94 on: October 15, 2010, 08:09:22 pm »
A commercial title? Wow... does SFGUI made it's way to the commercial game market? :D Can you tell some details?

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI (old thread)
« Reply #95 on: October 15, 2010, 10:50:12 pm »
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.

nulloid

  • Full Member
  • ***
  • Posts: 134
    • View Profile
SFGUI (old thread)
« Reply #96 on: October 15, 2010, 11:04:59 pm »
Quote from: "Tank"
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 :)

Quote from: "Tank"
I'm even thinking about releasing it under the zlib license.

Go for it ;)

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI (old thread)
« Reply #97 on: October 16, 2010, 12:05:01 am »
Quote from: nulloid
Quote from: "Tank"
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. ;)

nulloid

  • Full Member
  • ***
  • Posts: 134
    • View Profile
SFGUI (old thread)
« Reply #98 on: October 16, 2010, 10:05:40 pm »
Quote from: "Tank"
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 :))

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI (old thread)
« Reply #99 on: October 18, 2010, 03:30:40 pm »
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.

nulloid

  • Full Member
  • ***
  • Posts: 134
    • View Profile
SFGUI (old thread)
« Reply #100 on: October 18, 2010, 06:38:24 pm »
Quote from: "Tank"
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 :))

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI (old thread)
« Reply #101 on: October 19, 2010, 08:33:07 am »
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)

nulloid

  • Full Member
  • ***
  • Posts: 134
    • View Profile
SFGUI (old thread)
« Reply #102 on: October 19, 2010, 10:02:40 am »
Quote from: "Tank"
(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 :))

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI (old thread)
« Reply #103 on: October 20, 2010, 10:14:31 pm »
Quote from: "nulloid"
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).

Quote
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. ;)

Quote
(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.

nulloid

  • Full Member
  • ***
  • Posts: 134
    • View Profile
SFGUI (old thread)
« Reply #104 on: October 21, 2010, 12:22:54 am »
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)

 

anything