cpGUI - Anyone interested in developing?

[forrestcupp]

Hey guys.  Thanks for taking this over.  It looks like you're doing a great job with it.

I basically created the whole thing by myself in about a 1-2 week period just to release some stress over getting ready to have a baby.

I realize that there is a lot that wasn't done efficiently.  I'm glad you guys took it over, though.  It would be a shame for it all to go to waste.  You have some really good ideas and plans.  Automating all of the draws is a great idea.  I don't know why I didn't think about that.  I'm sure you've already come up with a way for the user to toggle on and off whether something is drawn or not.

As for making the old API be compatible with 2.0, I don't really care what you do with it.  I was mostly referring to the fact that 1.6 was just released, and for some reason it broke cpGUI, and I didn't have time to deal with it.  I also knew that a lot of people were already using the 2.0 snapshots, and since that is the direction SFML is going, I thought cpGUI should support it at some point.  I honestly thought 2.0 would be ready way before now though, so it's not really as important as what I thought.

But all in all, I think you're doing an amazing job and planning some amazing things, and I don't care what you do from here on out.  I don't think you'll be ruining anything.  You should probably just focus on your new API now.

Thanks again.

[Recruit0]

Thanks for the support. And congrats on the baby.

Sorry I don't have much to show for it though. Most of it is in my head at the moment (I'll spend large amounts of time calculating in my head before I start spitting out code, unless it's imperative I produce code ASAP). I've been mostly calculating how to design everything and conceptual stuff like whether a block of buttons should count as a menu.

I realize that there is a lot that wasn't done efficiently.

I scanned your code and IMHO it looks like you had written it with minimal design in mind (if any), i.e. it looked like it was just thrown together (which makes sense with the 1-2 week creation period). Which is why I scrapped the current API and worked from the ground up while using your code as reference code (i.e. a "cache").

Starting from scratch made it easier to test IMO. With the old API deactivated, I didn't need to try to get the new and old to cooperate with each other (during production). And I could see how you solved certain problems (e.g. text input) and build from there.

I'm sure you've already come up with a way for the user to toggle on and off whether something is drawn or not.

Yes, widgets can connect/disconnect with a gui. Things have been designed to chain together now. There's even room for cpGUI to chain through libraries other than SFML (e.g. SDL and Allegro). Although code handling that will come much later.

I basically created the whole thing by myself in about a 1-2 week period

Someone mentioned that there's a bug with the drop down list class that allows them to select items after they've already selected one (and the menu disappears). I've yet to test it but now I know why there's a bug (you didn't finish coding it). It's no prob though, I'm currently working on the menu class and the timing is intriguing (I'll end up fixing the bug in the old code and propagating what I learn to the new).

[forrestcupp]

I scanned your code and IMHO it looks like you had written it with minimal design in mind (if any), i.e. it looked like it was just thrown together (which makes sense with the 1-2 week creation period).

It was kind of thrown together.  I did have some very minimal design, but not a whole lot before I started working on it.  Basically, I had a game in mind that I wanted to use SFML for, but I needed some form of GUI.  I wanted to get to working on the game, so I just kind of worked quickly on getting a GUI done.  I have some background in wxWidgets, so I very loosely used that as a model for an API and adapted it to how SFML works.  I originally created it just for myself, but when it ended up blowing up into something with some useful features, I thought it would be nice to make it available for some other poor souls who don't want to take the time to create a GUI from scratch.

A rework in structure is probably a really good thing.  I'm glad my code is helping to save some time with implementation.

Someone mentioned that there's a bug with the drop down list class that allows them to select items after they've already selected one (and the menu disappears). I've yet to test it but now I know why there's a bug (you didn't finish coding it). It's no prob though, I'm currently working on the menu class and the timing is intriguing (I'll end up fixing the bug in the old code and propagating what I learn to the new).

That's kind of strange, because I thought I had that bug fixed.  That was one I fixed pretty early on.  Unless there is a different type of bug that has to do with that.

That's cool that you have a goal to get it to work with SDL, etc.  Maybe someday I'll use SDL and get to use cpGUI with it.

Anyway, thanks again, and good luck.

[nfries88]

So long as it remains under a liberal license like zlib or BSD, I would be more than glad to assist.

For background on myself;
I'm 21 right now and have been programming since I was 15 (so 6 years now). Most of that was done in C and C++.
I've written my own GUI using OpenGL when I was still learning, so I've done stuff like this before.
I've also helped with the GLICT GUI library that a friend of mine made, although my contributions there have been minor.
Most of my development time has been on a GPL-licensed MMORPG clone called "Open-Tibia", but very little of my code is actually in the project (unfortunately my programming style does not agree with theirs', nor does my preference on licensing -- I've been trying to get them to switch to BSD-style licensing for years now). Within Open-Tibia I mostly worked on "Yet Another Tibia Client", which is obviously the graphical side of Open-Tibia.
Like Recruit0, I'm very stubborn about coding style; but I'm usually pretty adaptable so long as you don't do pointless things.
I'm also in the Navy right now, so my time is a little limited. But programming is my hobby and I like to do it, so you can be sure I'll commit something from time to time.

I will look at the source code right now and see what I make of it.

EDIT:
After a 5 minute evaluation:
1) You use namespace cp, but still precede all widget names with "cp". So using the widget is cp::cpWidget. This redundancy is ugly and pointless.

2) It would integrate much better with SFML if you implemented widgets as sf::Drawable. Example, class cp::Object : public sf::Drawable {...};

3) There does not appear to be a standard interface for handling an sf::Event. This enables the library's user to easily implement his or her own widgets, which is an important feature for any GUI library. Simply attempting to implement every last widget the user may wish for in his application would result in cpGUI being a massive library.

4) cpObject does not define a parent widget, just the sf::Window it is a part of. The sf::Window should be part of cpGuiContainer; another cpObject or cpGuiContainer should be the widget's parent.

That's all for now.

[Recruit0]

1) You use namespace cp, but still precede all widget names with "cp". So using the widget is cp::cpWidget. This redundancy is ugly and pointless.

2) It would integrate much better with SFML if you implemented widgets as sf::Drawable. Example, class cp::Object : public sf::Drawable {...};

3) There does not appear to be a standard interface for handling an sf::Event. This enables the library's user to easily implement his or her own widgets, which is an important feature for any GUI library. Simply attempting to implement every last widget the user may wish for in his application would result in cpGUI being a massive library.

4) cpObject does not define a parent widget, just the sf::Window it is a part of. The sf::Window should be part of cpGuiContainer; another cpObject or cpGuiContainer should be the widget's parent.

You are referring to the old version. I fixed #1 a long time ago.

You can get the latest code through github (see project page). I think it references pdusen's repo. Mine (recruit0) should have the latest code though. The skeleton/framework should be pretty much done. All that's left is to implement the widgets (and fix existing ones, e.g. text_box works but is glitchy so is not done).

[nfries88]

Okay then, I'm checking out github now.

Can't say I'm a fan of the boost dependency. Boost is an awfully large library to have to download for such a comparatively small one. Boost's build system is also prone to issues with MinGW, at least in my experience; although IIRC boost::reference_wrapper<> is implemented in header files.
I think a custom implementation (or just including the header for boost::reference_wrapper<> in the repository, since the boost license is fairly permissive) would be better, and realistically such a thing is very unnecessary anyway.
The dependency on boost::gil for colors and on boost int types is just unnecessary, #include <cstdint>.

I also see you're using boost-style naming conventions for classes and functions now, as opposed to the SFML naming conventions. Although it's your call, I would recommend using SFML naming conventions because it makes life easier on the developer using your library. Personally, though, I prefer the naming convention you're using; it's what I use myself.

Of course, this is what's in the repository right now. You said your local copy is more complete, so who knows what changes you've made.

[pdusen]

Okay then, I'm checking out github now.

Check out recruit0's branch for something reasonably up-to-date; mine is supposed to be the "master", but I haven't given it the attention it deserves.

Can't say I'm a fan of the boost dependency. Boost is an awfully large library to have to download for such a comparatively small one.

Boost is not a library so much as a collection of much smaller libraries. Frankly, it's nearly as close to standard and portable as the STL itself. Unless there is a known issue, I make a point of taking advantage of Boost's facilities whenever appropriate; development time is a premium. Looking at the amount of boost usage currently in the repo, I assume recruit0 agrees.

Boost's build system is also prone to issues with MinGW, at least in my experience;

If there is any valid criticism of boost, unfortunately, this is it; the build system leaves much to be desired.

although IIRC boost::reference_wrapper<> is implemented in header files.

The majority of boost is implemented in header files, for a variety of reasons.

I think a custom implementation (or just including the header for boost::reference_wrapper<> in the repository, since the boost license is fairly permissive) would be better, and realistically such a thing is very unnecessary anyway.

It is always preferable to use existing, well-tested code rather than reimplementing it yourself.

The dependency on boost::gil for colors and on boost int types is just unnecessary, #include <cstdint>.

There might be some merit to your suggestion for boost::gil, but <cstdint> is not included in all modern C++ distributions. As we depend on Boost anyway, it is safer to make use of Boost.Integer. If I recall correctly, when the compiler provides it, Boost merely wraps around <cstdint> anyway.

I also see you're using boost-style naming conventions for classes and functions now, as opposed to the SFML naming conventions. Although it's your call, I would recommend using SFML naming conventions because it makes life easier on the developer using your library. Personally, though, I prefer the naming convention you're using; it's what I use myself.

Recruit0 and I discussed this at length when we took over the project. My position is that language libraries should try to adhere to the conventions of the language standard; Boost uses the same naming conventions as the STL, and we adhere to that as well. By my reckoning, it is libraries such as SFML that make life more difficult by using conventions that do not adhere to C++ styling (although their technical merits alone more than make up for it).

[nfries88]

Okay then, I'm checking out github now.

Check out recruit0's branch for something reasonably up-to-date; mine is supposed to be the "master", but I haven't given it the attention it deserves.

I did after posting (I've never used github before, so I didn't realize it was like that) and all criticisms stick.

Can't say I'm a fan of the boost dependency. Boost is an awfully large library to have to download for such a comparatively small one.

Boost is not a library so much as a collection of much smaller libraries. Frankly, it's nearly as close to standard and portable as the STL itself. Unless there is a known issue, I make a point of taking advantage of Boost's facilities whenever appropriate; development time is a premium. Looking at the amount of boost usage currently in the repo, I assume recruit0 agrees.

Boost.Threads, Boost.ASIO, Boost.Function, and Boost.Date_Time are the most useful libraries in boost. Nearly everything else is not very useful for 99% of computer applications (ie Boost.Graph, Boost.Spirit) or provide a wrapping over something that already exists in common form on most/all C implementations (ie Boost.Integer, Boost.Python).

I think a custom implementation (or just including the header for boost::reference_wrapper<> in the repository, since the boost license is fairly permissive) would be better, and realistically such a thing is very unnecessary anyway.

It is always preferable to use existing, well-tested code rather than reimplementing it yourself.

Generally, I would agree. In the case of things as simple as functors, reference wrappers, containers, and strings; I would disagree. The advantage to using those is primarily in saving a handful of hours of development time, not in probability of flaws existing in your implementation.

The dependency on boost::gil for colors and on boost int types is just unnecessary, #include <cstdint>.

There might be some merit to your suggestion for boost::gil, but <cstdint> is not included in all modern C++ distributions. As we depend on Boost anyway, it is safer to make use of Boost.Integer. If I recall correctly, when the compiler provides it, Boost merely wraps around <cstdint> anyway.

Allow me.

Code: [Select]

typedef unsigned char uint8_t;
typedef signed char sint8_t;
typedef unsigned short uint16_t;
typedef signed short sint16_t;
typedef unsigned long uint32_t;
typedef signed long sint32_t;

typedef struct {
    uint8_t red;
    uint8_t green;
    uint8_t blue;
    uint8_t alpha;
}Color_RGBA32;

Less than 20 lines of code to remove a dependency; it's well worth it.

I also see you're using boost-style naming conventions for classes and functions now, as opposed to the SFML naming conventions. Although it's your call, I would recommend using SFML naming conventions because it makes life easier on the developer using your library. Personally, though, I prefer the naming convention you're using; it's what I use myself.

Recruit0 and I discussed this at length when we took over the project. My position is that language libraries should try to adhere to the conventions of the language standard; Boost uses the same naming conventions as the STL, and we adhere to that as well. By my reckoning, it is libraries such as SFML that make life more difficult by using conventions that do not adhere to C++ styling (although their technical merits alone more than make up for it).

At least you've got a good reason for it. I won't pester you about this anymore.

[pdusen]

Boost.Threads, Boost.ASIO, Boost.Function, and Boost.Date_Time are the most useful libraries in boost. Nearly everything else is not very useful for 99% of computer applications (ie Boost.Graph, Boost.Spirit) or provide a wrapping over something that already exists in common form on most/all C implementations (ie Boost.Integer, Boost.Python).

I can only respond to this with a list of libraries I make frequent use of, off the top of my head: Array, Bind, Conversion, Foreach, Lambda, Lexical Cast, Math, Multi-Array, Operators, Pointer Container, Program Options, Property Tree, Random, Ref, Regex, Serialization, Singals, Smart Ptr, Test, Tuple, Unordered, Utility.

Allow me.

Code: [Select]

typedef unsigned char uint8_t;
typedef signed char sint8_t;
typedef unsigned short uint16_t;
typedef signed short sint16_t;
typedef unsigned long uint32_t;
typedef signed long sint32_t;

typedef struct {
    uint8_t red;
    uint8_t green;
    uint8_t blue;
    uint8_t alpha;
}Color_RGBA32;

Less than 20 lines of code to remove a dependency; it's well worth it.

This is not portable. You incorrectly assume that, for example, signed short is always a 16-bit integer. This is not guaranteed by the standard and may vary by compiler; otherwise there would be no reason for cstdint to exist in the first place. Please see here.

At least you've got a good reason for it. I won't pester you about this anymore.

Not at all. These kinds of discussions are very important to ensure that our development decisions are well thought-out.

[Silvah]

Allow me.

Code: [Select]

typedef unsigned char uint8_t;
typedef signed char sint8_t;
typedef unsigned short uint16_t;
typedef signed short sint16_t;
typedef unsigned long uint32_t;
typedef signed long sint32_t;

typedef struct {
    uint8_t red;
    uint8_t green;
    uint8_t blue;
    uint8_t alpha;
}Color_RGBA32;

Less than 20 lines of code to remove a dependency; it's well worth it.

This is not portable.

Strictly speaking, neither is cstdint (it is portable for most purposes, though):
 - int8_t and the like are guaranteed to be defined only if they're meaningful on the platform we're compiling for. If they're not meaningful, int8_t is just an undeclared identifier.
 - int8_least_t, int16_least_t unsoweiter are simply redundant, char, short, long and long long are guaranteed to be at least 8, 16, 32 and 64 bits long, respectively.
 - int8_fast_t and its friends aren't better, either: the meaning of "fast" is implementation-defined.

[pdusen]

 - int8_least_t, int16_least_t unsoweiter are simply redundant, char, short, long and long long are guaranteed to be at least 8, 16, 32 and 64 bits long, respectively.

Not exactly. From the standard:

There are five standard signed integer types : signed char, short int, int, long int, and long long int. In this list, each type provides at least as much storage as those preceding it in the list.

It is entirely plausible for all of these types to be, for example, 8-bits long.

[Silvah]

Not exactly. From the standard:

There are five standard signed integer types : signed char, short int, int, long int, and long long int. In this list, each type provides at least as much storage as those preceding it in the list.

It is entirely plausible for all of these types to be, for example, 8-bits long.

No, it's not. From the standard:

5.2.4.2.1 Sizes of integer types <limits.h>
The values given below shall be replaced by constant expressions suitable for use in #if preprocessing directives. [...] Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.

UCHAR_MAX 255
USHRT_MAX 65535
UINT_MAX 65535
ULONG_MAX 4294967295
ULLONG_MAX 18446744073709551615

[nfries88]

So it isn't. But I do know it works on Win32, Win64, Linux 32-bit, and Mac 32-bit. O_o

[Recruit0]

pdusen seems to have covered most of everything in regards to the previous discussion. I believe that there is more in the design that nfries88 has not seen yet but I don't have time to enumerate everything. I will respond to the design issues that nfries88 brought up when I have more time. I spent a lot of time designing (thinking about) the skeleton of the new API and talked w/ pdusen over email. I can send a copy if anyone wants to read in on what we discussed (and with pdusen's approval). We've yet come up with a public-disclosure style of communication (rather than private e-mail).

I also wanted to add that, in reference to my repository being more up to date than pdusen's (which is technically the master repo), basically I'm "coding" this thing while pdusen is sort of my "senior advisor" (who has actual experience in the field and such). He setup the build system and taught me how to use Git (among other things). Just in case anyone was wondering what's going on with that.

Also wanted to give an update from my end. I became less interested in the project after completing the framework/skeleton. The widgets are sort of trivial IMHO. Everything else should be able to just plug into the new API with minimal changes (to the API).

I'm primarily concerned about the design/API of the project. If I have time I will finish developing the widgets. I'm in college, CS major, senior year and don't think I'll be able to contribute much more but I do want to watch over the design of the project as it progresses (e.g. to make sure any contributed widgets work properly when integrated into the system). I'll post a more detailed response about the issues that nfries88 brought up when I have time. I didn't notice any issues concerning the way the GUI actually works so any API changes in regards to the issues brought up should be minimal.