cpGUI - Anyone interested in developing?

[forrestcupp]

A while back I created cpGUI to support my personal needs.  I thought maybe it would be useful for others, so I released it in the Wiki under the zlib/png license.  It's great that there has been a lot of interest in this, but with interest comes the need for support and continued development.  

Unfortunately, I no longer have the time to invest in this project.  So if there is anyone interested in taking over the lead for this project, please feel free.  The license is pretty free, but it does need to still be honored.  But that shouldn't cause any hindrances.


A few notes for anyone interested:

For some reason, cpGUI doesn't seem to work with the most recent release of SFML, even though that release wasn't supposed to break anything.

You will probably want to start porting a 2.0 version.

When you package your changes to the code, you will need to update the Wiki and find a place to host your new files for people to download.

When you make significant changes, please update the Wiki to let people know you are the one working on it so they won't try to contact me about your changes.

I really don't care what you do with it as long as you don't ruin it and blame me.

[Recruit0]

Has no one volunteered for development yet? I'm interested. Just a little intro about me:

I've been programming for 5 yrs (unprofessionally, i.e. not for a company). The current license seems fine (AFAIK). I have some experience in python, used to program in C (because I believed it was super duper fast XD) but have grown to like C++ as my main language. I can still develop C code but prefer C++ as it has more "locking mechanisms".

I may change the source code considerably to match my own style (variable names, etc...) if I do work on this. I'm sort of "strict" when it comes to coding. I spend a great deal of my time designing code rather than actually writing it. One of the things I found with SDL (stable) is it's not const correct, and I'm an advocate of const-correctness (one of C++'s many "locking mechanisms").

On a side note (if I do work on this) I don't intend to ruin it  :wink:

[pdusen]

I would also be interested in taking on a project like this, since it fills a particular need of mine and I've been looking for a project to take on.

I've been programming on a volunteer basis for the last several years. My strengths are primarily in the realm of architecture and metaprogramming techniques, but I like to think I'm becoming fairly profficient all around. I'm interested because I need a good sfml gui system for my own uses and am willing to maintain one to ensure that there's a good one I can use.

However, if anyone else really wants to take over, I certainly won't fight over it.

[Recruit0]

If possible, I think it'd be better for a team (not just one person) to take over the project. Engineering something well takes quite some time (especially software like GUIs). I have architectural skills as well but regardless of skill level it takes time to get it right. As a team we could multiply our development speed (assuming we don't waste time on bickering or other antics) ^_^

Later I'd like to draw a diagram of how everything connects together. Basically sort of a blueprint of how software layers interact and where this GUI fits in (and where SFML fits in as well). I will post it up when I get around to it.

It's getting kind of awkward talking in an unsure sense so I propose that we (everyone, the community) "get this straightened out" (i.e. formally declare what is going to happen with this project). I vote for the team taking over option (plus me being part of the team).

[nulloid]

Hmmm... this looks promising

I don't want to be a part of the team (at least not one of the main people) because the lack of my time, but I'd like to help (the good-sounding reason, because I doubt I can be much of a help , and I want to learn software designing (the real reason). (Maybe the 'observer' is the right phrase for my role )

[Recruit0]

I don't see any reason to assign statuses to people in the team (except perhaps a leader to you know, lead the way). Anyone that is able to help is welcome, and encouraged, to.

After glancing at the code I'm already thinking about redesigning the interface. I see in the example CPP file that you need to call the draw function for all of your GUI objects. Everything that can be automated (efficiently) should be. I'm guessing other things must be done manually as well but haven't fully reviewed the code.

Also I notice that some of the function parameters are using pointers instead of pass by reference. Not sure what the design decision behind that was but I'd think that pass by reference would be preferable. Example: with cpGuiContainer::Register() you could techincally push a null value into it (accidentally even). We can use pass by reference to make sure that's not possible (locking mechanism). The purpose of locking mechanisms is to prevent ourselves from making silly mistakes. :wink:

Also I'm sceptical about what the font handler does in Windows. I'm assuming that it's trying to load the default font from windows but what if the user isn't using that font? I'm wondering if SFML has a way to get the system font.

I was thinking any updates should wrap around the current "manual" methods (so as not to break anyone's current code). Then later on deprecate the "manual" methods once the automated ones are stable. Also any interface changes should leave the current interface in tact and later the older interface shifted out (deprecated). Basically all deprecated interfaces should be supported until SFML2 is stable (i.e. "okay guys new version, the interface has changed") Although this may add some bloat to the library, until a more efficient solution is found.

EDIT: I notice that as I read through the code I want to redesign more of the interface (i.e. leading to a complete rewrite of the interface). Example (from example CPP file):

cp::cpDropDownBox dropdownBox(&App, &myGUI, "Select your weapon", 450, 250, 200, 20);

Besides a "using namespace cp;", I would have stored the App inside the library. What I'd like to do is:

myGui.Add( DropDownBox( 450, 250, 200, 20 ) ); // etc, use dynamic binding

And in the main loop just call:

myGui.Draw();

[pdusen]

I don't see any reason to assign statuses to people in the team (except perhaps a leader to you know, lead the way). Anyone that is able to help is welcome, and encouraged, to.

After glancing at the code I'm already thinking about redesigning the interface. I see in the example CPP file that you need to call the draw function for all of your GUI objects. Everything that can be automated (efficiently) should be. I'm guessing other things must be done manually as well but haven't fully reviewed the code.

Also I notice that some of the function parameters are using pointers instead of pass by reference. Not sure what the design decision behind that was but I'd think that pass by reference would be preferable. Example: with cpGuiContainer::Register() you could techincally push a null value into it (accidentally even). We can use pass by reference to make sure that's not possible (locking mechanism). The purpose of locking mechanisms is to prevent ourselves from making silly mistakes. :wink:

Also I'm sceptical about what the font handler does in Windows. I'm assuming that it's trying to load the default font from windows but what if the user isn't using that font? I'm wondering if SFML has a way to get the system font.

I was thinking any updates should wrap around the current "manual" methods (so as not to break anyone's current code). Then later on deprecate the "manual" methods once the automated ones are stable. Also any interface changes should leave the current interface in tact and later the older interface shifted out (deprecated). Basically all deprecated interfaces should be supported until SFML2 is stable (i.e. "okay guys new version, the interface has changed") Although this may add some bloat to the library, until a more efficient solution is found.

EDIT: I notice that as I read through the code I want to redesign more of the interface (i.e. leading to a complete rewrite of the interface). Example (from example CPP file):

cp::cpDropDownBox dropdownBox(&App, &myGUI, "Select your weapon", 450, 250, 200, 20);

Besides a "using namespace cp;", I would have stored the App inside the library. What I'd like to do is:

myGui.Add( DropDownBox( 450, 250, 200, 20 ) ); // etc, use dynamic binding

And in the main loop just call:

myGui.Draw();

I agree pretty much with all you said. Perhaps we can get together on IRC sometime to form a team and a roadmap of some sort.

[Recruit0]

Okay, what channel? Do you have gmail? Maybe we could setup a mailing list or something as well. Basically I'd like a remote/internet (not local log) record of communications because well I tend to forget things/details. This forum is an option too (although we may end up "flooding" it with messages XD).

I'm still not satisfied with the previous deprecation technique. It adds bloat and slows down production. I think it'd be better to hack up the current (stable) version and port it to SFML2. Then drop support for it (only provide fixes to critical bugs, if any) so that we can focus more on redesigning the new interface and implementing it. That way the old/current/stable version doesn't get bloated and people have something to work with in SFML2 until the new interface arrives.

First we should code the new interface for SFML 1.x (stable). When SFML2 is officially released then we'll port the new interface there. When we do the new interface it should be labeled version 2-1.x, where the dash 1 will be dropped once SFML2 is released (and we port it over). Anyone still using cpGUI2-1.x with SFML1.x may be supported if the reported bug can be reproduced in cpGUI2.x. This upgrade method will also allow room for minor changes to the interface when we port it to SFML2 if needed (i.e. cpGUI2-1.x is a transition package between 1 and 2).

It will be a bit weird, where the new interface takes over for SFML1 and the old interface gets upgraded to SFML2 but it should work. The old interface can be used as a "testing ground" for SFML2 (so that it'll be easier to port cpGUI2 later).

I'm not sure how much of the current interface will be rewritten though because some of it might be used as low-level access. I will draw up a diagram later but the idea is that each software layer should provide low-level access to the previous layer. Propagate this idea all the way down and any layer should be able to "directly" access the hardware if necessary (i.e. there's room for speed hacks if necessary).

We need to add all the design documents (e.g. roadmap) on the wiki as well (where it can be peer reviewed so that if we miss something someone can, hopefully, inform us). Where should we host the files/source code? Sourceforge?

On a side note, I am wondering what the "cp" stands for in cpGUI?

[pdusen]

Okay, what channel? Do you have gmail? Maybe we could setup a mailing list or something as well. Basically I'd like a remote/internet (not local log) record of communications because well I tend to forget things/details. This forum is an option too (although we may end up "flooding" it with messages XD).

I can be reached at pdusen@gmail.com. I also typically idle at freenode on IRC, but my active times are somewhat irregular. I'm in favor of the mailing list idea (if I'm not mistaken, google has a mailing list service we can sign up for.)

I'm still not satisfied with the previous deprecation technique. It adds bloat and slows down production. I think it'd be better to hack up the current (stable) version and port it to SFML2. Then drop support for it (only provide fixes to critical bugs, if any) so that we can focus more on redesigning the new interface and implementing it. That way the old/current/stable version doesn't get bloated and people have something to work with in SFML2 until the new interface arrives.

First we should code the new interface for SFML 1.x (stable). When SFML2 is officially released then we'll port the new interface there. When we do the new interface it should be labeled version 2-1.x, where the dash 1 will be dropped once SFML2 is released (and we port it over). Anyone still using cpGUI2-1.x with SFML1.x may be supported if the reported bug can be reproduced in cpGUI2.x. This upgrade method will also allow room for minor changes to the interface when we port it to SFML2 if needed (i.e. cpGUI2-1.x is a transition package between 1 and 2).

It will be a bit weird, where the new interface takes over for SFML1 and the old interface gets upgraded to SFML2 but it should work. The old interface can be used as a "testing ground" for SFML2 (so that it'll be easier to port cpGUI2 later).

I'm not really sure all of that is necessary. The way I see it, when someone makes the leap from SFML1.6 to SFML2, they're already making some big changes to account for a new interface; so with that being the case, I see no reason to carry over the old cpGUI interface to SFML2. That would just be two different ports we'd have to do.

What I propose is this: let's take what currently exists for cpGUI and beat it into shape a bit (get it working on 1.6, create an actual build system, etc), then release that as an end-of-life update ("1.5.7" and so on). We then start work on "cpGUI 1.6.x", with the new interface, still based on SFML 1.6 (or whatever the current stable branch is by then). We continue doing updates in the 1.x.x series for as long as SFML2 is unreleased. Then when SFML2 is finally released (or close to release), we port our newest version to SFML2 and release it as "cpGUI 2.0.0". Of course, the naming is subject to change, this is simply my proposal.

I'm not sure how much of the current interface will be rewritten though because some of it might be used as low-level access. I will draw up a diagram later but the idea is that each software layer should provide low-level access to the previous layer. Propagate this idea all the way down and any layer should be able to "directly" access the hardware if necessary (i.e. there's room for speed hacks if necessary).

Agreed.

We need to add all the design documents (e.g. roadmap) on the wiki as well (where it can be peer reviewed so that if we miss something someone can, hopefully, inform us).

If we do this, it should probably be as a footnote on the existing cpGUI page, or on a different page entirely. We don't want new users who are just looking for an existing GUI to use to have to read through our design documents for an unreleased version, after all.

Where should we host the files/source code? Sourceforge?

I have a github account that I've used for a lot of my work. If you'd like, I can go ahead and set up a repository there. You can then sign up to github yourself and "fork" my repo (it's basically github slang for creating your own branch). Then we can easily pull each others' changes from each repo, allowing us to work independently while incorporating each others' work as well.

Incidentally, here's a wishlist of things I'd like to do; it's not comprehensive, just some things that come immediately to mind:

Remove the "cp" prefix from class names. If i'm reading the headers correctly, we're already in the "cp" namespace, so having "cp" as a prefix to class names is utterly redundant.

Set up a CMake build system. I've used CMake for a long time, and its cross-platform capabilities are amazing. Besides, laurent has expressed his wish to switch to CMake for SFML itself, so we'd be going along with that.

Add RAII. I see a few places in the code when manual new/delete memory management is used. I think it would be best to avert this, possibly replacing it with using smart pointers from Boost.

On a side note, I am wondering what the "cp" stands for in cpGUI?

I have no idea. We could always make something up. Or just go along with it.

[Recruit0]

I think google's thing is called a "google group". Will check it out later. Warning: I am typing this with only 5 hrs of sleep and have been up since 4AM so I may speak oddly (also just took a Calc 3 exam on top of that).

The carrying over old cpGUI was so that people had something to use in the current SFML2. The main reason behind this was forrestcup's request, which made it sound like people were using SFML2 already (this doesn't make sense to me, statistically, but factored that in anyway). Basically I was trying to "soft drop" support for the current API (i.e. slowly deprecate it out) as opposed to "hard drop" it (just bug fix and move on) for current users but that wasn't necessary.

I thought that the current/old API already works in 1.6 but now I see in the wiki it's "based on 1.5" so there may be some adjustments in order. So yeah, agreed (with your plan).

I'll finish my full reply later.

[pdusen]

I thought that the current/old API already works in 1.6 but now I see in the wiki it's "based on 1.5" so there may be some adjustments in order. So yeah, agreed (with your plan).

I based the suggestion on what forrestcupp said in the OP:

For some reason, cpGUI doesn't seem to work with the most recent release of SFML, even though that release wasn't supposed to break anything.

I haven't actually had a chance yet to test with SFML 1.6 to verify any problems.

[Recruit0]

The wiki should have different pages for different things (road map, intro, tutorial, diagrams, etc). What's on the wiki right now IIRC is just the intro. I'm not sure what capabilities we will have with the wiki though (implying we may need to have another site for this whole thing).

As for github I haven't used it before but sounds good.

In reference to the wishlist:
1) Agreed.
2) I don't plan on doing anything with (developing) the build system. The most I may do is make sure it compiles on my system fine (Fedora 13 x64) I'm mainly going to be using Codeblocks.
3) Agreed, although the auto_ptr already in C++ now may be enough. I'm not sure if it's because I have Boost installed already but I thought it's already integrated into the C++ library. Another thing is we may be able to eliminate most if not all pointer usage.

I noticed a lot of odd choices for data (e.g. pointers vs references). I'm considering which way we should handle this:

A) Start with the current code and modify it to a more preferred interface
B) Just rewrite everything from scratch (and using the current code as reference material)

The suggestion you're referring to, I thought he was talking about SFML2 when he said that (because he mentions SFML2 right after it). I am interested in hearing from forrestcupp. I might end up contacting him later.

Another thing besides design is I'm concerned about speed. The only way I know of how to make the interface do:

myGui.Add( DropDownBox( 450, 250, 200, 20 ) );

While still being able to only include parts of the interface that you want is with dynamic binding, which comes at a price. Runtime dereferencing isn't that cpu intensive but still, the library should use the least amount of CPU (be fast as possible) because "actual work" needs to be done (i.e. the main program needs as much of the CPU as it can get). It's not just a premature optimization either because we want to avoid changing the interface later.

I'm considering some way to hack up overloaded functions in the class so that the user can still include only parts that they want. At the moment I'm thinking #ifdef precompiler commands might do the trick. If it doesn't work out I guess dynamic binding will have to do.

[pdusen]

2) I don't plan on doing anything with (developing) the build system. The most I may do is make sure it compiles on my system fine (Fedora 13 x64) I'm mainly going to be using Codeblocks.

I can take care of the build system. Incidentally, it may interest you to know that CMake can actually be used to generate Codeblocks project files, as well as Eclipse, Visual Studio and standard makefiles.

3) Agreed, although the auto_ptr already in C++ now may be enough. I'm not sure if it's because I have Boost installed already but I thought it's already integrated into the C++ library. Another thing is we may be able to eliminate most if not all pointer usage.

We'll have to decide on a case-by-case basis. auto_ptr doesn't work very well in some circumstances. We may have to consider scoped_ptr, shared_ptr where sharing is happening, and even ptr_containers if appropriate.

I noticed a lot of odd choices for data (e.g. pointers vs references). I'm considering which way we should handle this:

A) Start with the current code and modify it to a more preferred interface
B) Just rewrite everything from scratch (and using the current code as reference material)

To be honest, unless you want to make a sweeping architectural change rather than just API changes, I'd rather make changes incrementally from what's already there; it will be easier to handle testing that way, in my opinion.

The suggestion you're referring to, I thought he was talking about SFML2 when he said that (because he mentions SFML2 right after it). I am interested in hearing from forrestcupp. I might end up contacting him later.

Well, he said "release" and "that release wasn't supposed to break anything. " Neither of those are true of SFML2 right now, but they were supposed to be true of SFML1.6

Another thing besides design is I'm concerned about speed. The only way I know of how to make the interface do:

myGui.Add( DropDownBox( 450, 250, 200, 20 ) );

While still being able to only include parts of the interface that you want is with dynamic binding, which comes at a price. Runtime dereferencing isn't that cpu intensive but still, the library should use the least amount of CPU (be fast as possible) because "actual work" needs to be done (i.e. the main program needs as much of the CPU as it can get). It's not just a premature optimization either because we want to avoid changing the interface later.

I'm considering some way to hack up overloaded functions in the class so that the user can still include only parts that they want. At the moment I'm thinking #ifdef precompiler commands might do the trick. If it doesn't work out I guess dynamic binding will have to do.

Dynamic binding seems like the obvious solution, but I can't help wondering if there's some generic programming practices we can use to try and move that work to compile-time. It's something to think about.


Anyway, I recommend we move this discussion to another medium, Google Groups or otherwise.

[Recruit0]

I sent emails to your address that you provided above. Also I PMed you my email address (so that my messages don't get caught in spam filters).

[nulloid]

Okay, what channel? Do you have gmail? Maybe we could setup a mailing list or something as well. Basically I'd like a remote/internet (not local log) record of communications because well I tend to forget things/details. This forum is an option too (although we may end up "flooding" it with messages XD).

Maybe I'm a bit geek, but what about google wave?