SFML community forums
General => SFML projects => Topic started by: Sergi on August 08, 2014, 03:59:46 pm
-
Hi!
I've been working lately on an expansion of SFML in C++ intended to make the process of creating and managing UI layouts easier. It's not a full GUI, but a set of classes and methods aimed towards helping you make your own according to the needs of your game/application.
While I was starting the development of a game a few months ago, I realised that some of the functionality I needed to implement was general enough so it could be useful for reuse in future projects, so I decided to create a stand-alone library expanding SFML in the ways I needed for my own layouts (and other ways that I could potentially need in future projects). Because it's usual when developing a game to create our own objects (as opposed to limiting ourselves to those offered by SFML and other libraries), I deemed it best to make the library heavy on polymorphism at its core, so it could be further expanded with minimal extra code.
The default classes in SFML_Layout implement:
- An easy way of handling position, size, and alignment of layout elements (including nested layouts).
- Multiple predefined layout distributions: horizontal, vertical, table, and the more customisable free layout.
- Management of sprites as element backgrounds. Backgrounds can have their own alignment inside their frame, and one of three distinct drawing modes: crop, adjust to fit the frame, or fill the frame by tessellation (cropping on the borders if needed). The chosen mode can be different for each axis.
- A sprite element: a layout element intended to have a sprite as its content. Until I write a detailed guide about that, this class can be easily used as an example on how to expand the library in order to create custom elements.
- An integrated event system. Elements can have different events associated to them, which in turn contain pointers to condition and effect methods designed by the user (although a couple of commonly used conditions are included in the library). Those methods can accept any number of arguments of any type, which can be provided in different ways.
- An element handler class which allows grouping elements together in order to trigger events simultaneously for all of them (for instance, activating all events labelled as "onClick" for a series of layout elements, with their conditions checking that the mouse cursor is over their associated element).
- Other layout-related logic, like the depth management for different layout elements, their visibility, or the number of slots in a layout. Elements and layouts can also be easily cloned and destroyed.
- For many functions, two versions exist: one applying only to the element or layout itself, and another one applying recursively to all nested layouts and elements.
In addition to the library itself (layout.hpp, layout.cpp, SFMLLayout.hpp, SFMLLayout.cpp), the repository also contains:
- example.cpp: a short program illustrating some of the functionality built in the library. It consists of a simple sprite viewer, allowing to switch between a list of sprites with "Previous" and "Next" buttons, and a "Close" button to quit. Some screenshots here: http://imgur.com/a/3C7wo#0 (http://imgur.com/a/3C7wo#0).
- Assets folder: image files used in example.cpp. One of the images was borrowed from Deviantart, so there is also a text file linking to the source.
I've done my best with the in-code documentation, but even with that and the example it may still be a bit tricky to take full advantage of the library without thoroughly understanding it. At the moment I'm working on a detailed guide on how to use and expand SFML_Layout, but until then (and also afterwards, I guess) you can contact me for any doubt/bug report/request/quarrel you have about it here in the comments, or through e-mail at sergi (at) protonmail (dot) ch.
Link to repository: https://github.com/SergiSalvadorLozano/SFML_Layout (https://github.com/SergiSalvadorLozano/SFML_Layout).
Latest release: https://github.com/SergiSalvadorLozano/SFML_Layout/releases/tag/v1.0.1 (https://github.com/SergiSalvadorLozano/SFML_Layout/releases) (2014/08/10).
-
Hi there,
I am not that experienced with programming yet, but it seems to me that "LAYOUT" is a rather long and large namespace.
In case you didn't know, substituting "foo\\bar" with "foo/bar" will also work on windows, at least I can guarantee it does on my windows pc e.g. loadFromFile("Assets/quit.png").
As I said, I am not an expert, but I believe you could use enums instead of declaring a bunch of ints for your different modes for example in DRAW or ALIGNMENT.
Overall, I think this is an interesting project, because I have already struggled with making a nice ui, fitting the game's theme.
Kind Regards,
Raincode
-
but it seems to me that "LAYOUT" is a rather long and large namespace.
You can always use a namespace alias (http://en.cppreference.com/w/cpp/language/namespace_alias) to shorten it in your own code :)
-
but it seems to me that "LAYOUT" is a rather long and large namespace.
You can always use a namespace alias (http://en.cppreference.com/w/cpp/language/namespace_alias) to shorten it in your own code :)
Ah thanks, I didn't know about that ;)
-
Yeah, I think that my attempts to make my code "self-explaining" often lead to me using names for namespaces, classes, and methods which may seem too long. I will try to address that on future work, but for now, if this is a common opinion, I can shorten the namespace name to something like "LA" or "LT".
I didn't know about Unix path names working on Windows SFML, so thank you! I will try it out and if it works I will change it for the next version.
I will study the use of "enums", too. As there is no arithmetic for those int the change will probably not break anything. That will require some testing, though.
-
Yeah, I think that my attempts to make my code "self-explaining" often lead to me using names for namespaces, classes, and methods which may seem too long.
I don't think that's a problem. Descriptive names are good. And, as I pointed out above, users can just declare shorter aliases themselves.
I didn't know about Unix path names working on Windows SFML, so thank you! I will try it out and if it works I will change it for the next version.
That's not SFML specific. "/" works for include paths in any C++ program and "/" works for path names in any C++ program and also in your Windows cmd "shell" - just try it ;)
I will study the use of "enums", too. As there is no arithmetic for those int the change will probably not break anything.
I'd advice to use the new strongly typed C++11 "enum class" - read here: http://en.cppreference.com/w/cpp/language/enum and here: http://www.cprogramming.com/c++11/c++11-nullptr-strongly-typed-enum-class.html
-
Just tried to change the path names and it works just fine :). I will inform myself about the enum class so I can change that for the next version.
Thanks for the feedback!
EDIT: Done. Released a new version with those changes.