SFML community forums
General => SFML projects => Topic started by: forrestcupp on April 22, 2010, 03:25:43 pm
-
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. :)
-
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:
-
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.
-
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).
-
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 :D)
-
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 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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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).
-
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? :)
-
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.
-
Thanks for the support. :D 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).
-
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.
-
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.
-
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).
-
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.
-
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).
-
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.
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.
-
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.
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 (http://stackoverflow.com/questions/589575/c-size-of-int-long-etc).
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.
-
Allow me.
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.
-
- 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.
-
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
-
So it isn't. But I do know it works on Win32, Win64, Linux 32-bit, and Mac 32-bit. O_o
-
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.