Community Project Proposal

dsmith · #1 16-Nov-2004, 05:05

GID Community Project

INTRODUCTION
What the...? That is the question that I hope to answer here. This idea started with a small example that was posted pertaining to the FLTK forum here. It was a small example using a personal contact editor dialog box. This small sample was taken and expanded into an excellent tutorial. This example can be found here.

I really liked where this was headed and thought maybe we could make something more of it. Sort of our own GIDForums community project. It will start out small and not do a heck of a lot but ultimately, we hope to build a PIM (Personnel Information Manager) of sorts.

Every project needs a name! This one is no different. The name that has been chosen is GIM. This is a stunningly clever combination of GID and PIM (full sarcasm mode on).

GOALS
Before I list the guidelines for this project, I think it is important to list the goals for this project. This will help (hopefully) in the understanding of the guidelines that follow.

A Learning Experience
I want this to be a learning experience for everyone involved. Every added module should become a mini-tutorial in and of itself. The whole development process should end up being very well documented and easy to follow. In addition, it is a social experiment as well. Can we build something within such a loose set of guidelines?
Good Sound Programming
This project should stress sound programming techniques. The entire project should be modular and should consist of interchangeable parts. All code should be well commented and understandable.
Completely Open
This is a community project and any work that is created from it should be open to the general public.
Enjoyment
This is definitely something that should be enjoyed as that is the only satisfaction that will ever be obtained from working on this.

The following are NOT the goals of this project

Building a better PIM
This project is not meant to fill a void of something that does not exist. There are plenty of professional programs that provide a good PIM. This type of project was chosen more for its ability to be broken into small segments than to make a must have program.
Meeting a schedule
I have plenty of schedules in my life and I don't want another one. Again this should be fun, not a burden.

GUIDELINES

Golden Rule

All code shall be subject to the GPL
This is mandatory as the first part of this project will be released under the GPL. This simply assures that all derived code for this project will always be available to the public.

Rules
It is a free world, but there are some things that we won't tolerate on the forums. Breaking this may subject your post to be deleted. Obviously, due to the openness of the license, you can really do anything you want with the code - just don't do it here.

Documentation
This refers to code documentation as well as forum documentation. Remember, one of the goals is to have a learning experience for all. Also if your code is well documented you are more likely to get help from others interested in your particular module, while still following with your modules intended function.
Modular
This is not only sound programming, but makes interchangeability easy. In addition, it keeps things much simpler and allows many portions of the project to be worked on simultaneously.
Courtesy
Anyone that contributes to this in any way deserves common courtesy. That doesn't mean that you have to modify your (if you are the team leader) initial design because someone has a different idea. It means that everyone involved is here because they want to help. Keep this in mind and treat their ideas with respect.
Interface Separation
The interface must be independent of the data. Again, this falls under the modularity rule, in that it makes things much more interchangeable. In theory, we should be able to take the same interface and slap a different back-end on it by simply recompiling.

Guidelines
If you want your contribution in the "official" release, here are some guidelines to follow.

Have Fun
Again, this should not be a burden for anyone
C/C++
It would be interesting see modules written in different languages besides C/C++ and see how these could be plugged into the program. However, these won't be in the official version.
FLTK/fluid 1.1.x
Again, I encourage other GUI toolkits and I would love to see if this UI could be done differently in other toolkits. However, the official version will be done in FLTK.
Cross Compatible
This should not be a problem with the other requirements. Again, you can (and are encouraged) to make interfaces with non-cross compatible tool kits. They just won't be "official"

INITIAL START
This project by design should be wide open. That means that there will be a lot of room to operate and overall this thing will be very loosely controlled. However, to avoid it being a complete hodge podge, there must be some common ties.

There are two common threads that this project will have. The first is the concept in and of itself.

The second is a single header file. This whole project does not work if there is not a single file in common between everything. This header file will define all the data structures that are necessary for data storage. In addition, this file will prototype all the necessary data link calls. This file will grow and change depending upon the overall project needs.

Some of the initial rules for this file:

This file is to be done in pure C. It can not contain any specific C++ stuff. C++ can easily handle a C file, but it does not work the other way.
This file is to prototype only the data access part of the project not the interface part. The data portion is the server to the interface portion. Therefore, the interface should take immediate control of the program and only call the data portions necessary.
As with this whole project, the KISS principle should apply. Simplicity is the key. This file should be as small as absolutely possible. Additions and changes will be strictly controlled.

Some of the initial rules for the interface:

This needs to be compatible with FLTK/fluid 1.1.x branch. As much as I hate to limit this everyone needs to be able to work with our sources. Until 2.0.x is to a point that we can justify the change this is the way it has to be. This is for the same reason as using pure C. Both may be provided but 1.1.x will be our "official" version.
There will be standardized layouts for menus and the widgets you use. This is so any module that someone wants to compile into a final package will not clash violently with another person's module. Creativity is encouraged but I don't want to have to search to find a common menu choice or guess if a widget is selected or not. More than likely a user won't want to guess either.
There needs to be a fluid project file that is capable of writing the interface code for your module. I really don't care if you code the entire thing by hand and create this after, but when it comes time to generate the code it will have to come out of fluid. The reason for this is that if we decide to make a global change to the look of the interface I don't want to have to dig through the code for each one to make the changes.

WHAT'S NEEDED
Quite simply, everything. But in the same breath, nothing. If this doesn't crank your engine, you shouldn't participate. I want this to be enjoyable and I want it to be a learning experience for all involved. Here are just a portion of the things that I can think of:

Module creators
Any one that wants to start a thread about a module that would be desired or something they are working on. Once you start the thread though, you become the team leader of that module.
Programmers
For the obvious reasons, but also for QA reasons. Take a look at the code and don't be shy about questioning it. But keep in mind the courtesy rule.
Graphics
I am terrible at graphics. It would be great if we could get someone that would provide some icons and other graphical items that would make this feel more solid.
Ideas
This is probably the most important. Not only do we need some creative ideas, but it helps to keep people encouraged if we get ideas and suggestions.
Web design
My web designs are usually pretty bland. I would greatly welcome any help on this.
General testing
Please try and break our program. Even if you have no interest in this whatsoever, you could be a big help by just trying this out and letting us know your impressions and problems.

I am sure that there are plenty of other things. Even criticism of this idea would be welcome!

CONTACTS/LINKS
Currently there are only two people that are on board with this.

dsmith
Overall project coordinator. As cable guy says someones got to be a DIC (Dude In Charge). This may change, but for now it will be me.
cable_guy_67
Overall interface design. So this doesn't feel like a hodge-podge project, it is very important to have some controls over the overall interface design.

Home Page
www.dbcservices.com/gim.html. This is basically a place to keep the "official" repository. All development will be documented here at GIDForums™.

EDIT
Web site is up in a very rudimentary stage!

crystalattice · #2 16-Nov-2004, 20:53

Sounds like fun 8-). I've been interested in participating in some OSS projects on Sourceforge but have been leary since I really know diddly-squat. I just barely finished C and am still fighting w/ C++. This will be a good way to learn practical programming.

If this goes well I have some other group project ideas in mind; one I thought about a few weeks ago but wanted to see what I could do on my own first.

nkhambal · #3 17-Nov-2004, 01:59

Looks interesting and exciting. I would like to participate as a programmer. I think it would be fun. I am no expert in C but I can give my feedback wherever it matters. Pls let me know the proceedings. I have never worked on programming project in C before. I seek your guidance.

dsmith · #4 17-Nov-2004, 21:27

I am thrilled to see some initial interest in this. I had assumed that it would be cable_guy and myself initially until we were able to produce something. Just so you guys know this is a completely new thing to me as well. It really is a learning experience for all involved. So we need to look at each other for guidance. If you see something that doesn't make sense or will lead to problems, please speak up.

Does the original proposal make sense? Will it make more sense if we get some things started?

Also, I have been thinking that a common header text should be inluded in all of the files. Here is what I have so far:

CPP / C++ / C Code:

/**********************************************************************/
/**********************************************************************/
/* The GIM project                                                    */
/**********************************************************************/
/* FILENAME:         gim.h                                            */
/* ORIGINATION DATE: Nov. 17, 2004                                    */
/* ORIGINATOR:       dsmith                                           */
/* MODULE:           none                                             */
/* LICENSE:          gpl (www.gnu.org/copyleft/gpl.html)              */
/**********************************************************************/
/* DESCRIPTION:                                                       */
/* This is THE header file.  It forms the small common thread between */
/* the database and the user interface.  If you want to write an      */
/* user interface for GIM, you need to call these functions to access */
/* the data.  If you want to write a database, you need to implement  */
/* these functions.                                                   */
/* This file will need to be updated for each module added as well as */
/* modifications to the type of data needed for each module.          */
/* This file will be versioned and it will be necessary to match your */
/* applications with the versioning.                                  */
/**********************************************************************/
/* HISTORY:                                                           */
/*   0.0.1 - Start of contact prototyping.                            */
/**********************************************************************/
/**********************************************************************/

This is for "THE" header file.

As for versioning, here is my thoughts. We have three version numbers. The first (right-most) would indicate a change in an existing data structure or prototype. The middle would indicate a brand new addition of a structure & prototype for a completely new module. The last (left-most) would indicate a realease. So the first official release would be known as 1.0.0. Enroute to this version, at some point we would put a freeze on the middle number (no more added modules) and finally a freeze on the first number (no more changes to the header file) to prepare for an actual release.

This is only an idea. I am looking for comments, approvals, disapprovals or questions.

cable_guy_67 · #5 17-Nov-2004, 22:04

GIM Module Proposal

Module Name: Contact_List
Main file name: contact_list.cpp
Fluid interface: contact_list.cxx
Fluid header: contact_list.h
Proposed by: cable_guy_67

Concept:

A contact list manager. This is to be an extension of the tutorial FLTK && fluid part 1. The biggest difference will be removing the callback code from the interface code. You should be able to load a contacts book that can be loaded by name so you could have multiple people with their own books. The layout of the interface will be:

Name: //single line
Company : // single line
Address : // 2 lines no wrap
Phone : // single line, should format number after enter
Email : // single line
Notes : // 3 lines with word wrap
Category : // drop list that can be added to by user. Default, personal & business.

Forward and back arrows to page through the saved contacts. The ability to enter a letter in name or company and find a matching entry. Or a separate entry for finding attached to radios to "find" and entry.

I will start a thread in the FLTK forum for the interface design.

CPP / C++ / C Code:

/**********************************************************************/
/**********************************************************************/
/* The GIM project                                                    */
/**********************************************************************/
/* FILENAME:         contact_list.cpp                                 */
/* ORIGINATION DATE: Nov. 17, 2004                                    */
/* ORIGINATOR:       cable_guy_67                                     */
/* MODULE:           Contact List                                     */
/* LICENSE:          gpl ([url]www.gnu.org/copyleft/gpl.html[/url])   */
/**********************************************************************/
/* DESCRIPTION:                                                       */
/* This is the main file for the Contact List module.                 */
/* This file will include gim.h, contact_list.cxx, contact_list.h     */
/* Initial call from gim_main.cpp should be to Contact_List(string)   */
/* Sending a string arg will open the matching contact list book.     */
/* If there is no matching name or no arg a blank book will be opened.*/
/**********************************************************************/
/* HISTORY:                                                           */
/*   0.0.1 - Start of contact prototyping.                            */
/**********************************************************************/
/**********************************************************************/

crystalattice · #6 17-Nov-2004, 22:18

One thought/question: will this be handled like the Linux kernel development? That is, people can propose and write modules but they won't be implemented unless approved by a single person (probably dsmith). Or will people be able to post "willy-nilly" :-) to the project?

This may have been addressed in the opening statement and I just didn't catch it. If so I apologize.

nkhambal · #7 18-Nov-2004, 03:05

Hey Guys,

I think crystalattice has brought up a valid point. I understand that, we all are doing this project for knowledge, learning and for fun. But I think before we start with the coding part, we need to have some guidlines in place for the project. Now that we know what type of software we want to develop, lets first develop a process (or processes) to do that. This will make it easier to track our progress. I recommend we have following phases

Design Phase

Functional requirements of the software.
What we intend to acheive with this piece of software.
How it is supposed to work? What features will it support?
What are its limitations (no. of contact entries, memory etc).?

Design the different modules, APIs in the programs.
Define the purpose of each module.
Define how it is integrated within the program.
Design a pseudo code for each module.
Review it for scalability and future enhancement.
Design a program build process. Where and How code will be submitted for compiling.? Where all source code will be available.? How to build on local machines ? What is the build schedule?
Standardization on programming language for whole program or for each module.
Assign the owners to each module, based on the skills and interest.

All this can be documented in a post or can be prepared in the format of a simple word document and post it onthe forum.

Development Phase

Design a code repository for code submission for compilation. Files and Folder structure which will be used in Makefiles.
Build Frequency. Daily, Weekly, bi-weekly etc.
Code development for each module.
Code review. Post the developed module on the forum, for it to be reviewed by others.
Submit the code for build after the review. (Someone need to take ownership of building the program).
Escalation of problems in build. If the build fails due to errors in the module, respective module owners should be informed, who will inturn fix the code and resubmit it.
Post the build in a post. So that everybody can use to test it on their own machines.

Testing Phase

Design a test plan for each feature supported by the software.
Write the test cases in each test plan. Each test cases will explain how to test each feature for different types of data or other inputs and conditions.
Review and Update the test plan with others.Provide feedback on test plans.
Post the final test plan on the forum.
Test the feature.
If any bug is found, post it to the forum. The respective module incharge will fix the code and will again submit it for code review with detailed explaination of the problem and how it was fixed. Later it will be submitted for build.
Retest the bug with new builds.

All these 3 phases will be common for any release of the software. This strategy is out of my own experience and knowledge and it is open for disucssions and comments.

I also recommend the format for the post header in each phase. So we can identify ,what each post is pertaining to, easily.

In Design phase

GIM(1.0.1)

ESG <POST_NAME>

For e.g.

GIM(1.0.1)ESG: GIM-Base Software Functional Specifications

In Development Phase

GIM(1.0.1)

EVP:<POST_NAME>

For e.g.

GIM(1.0.1)EVP:Code Review <main.cpp>

In Testing Phase

GIM(1.0.1):TEST:<POST_NAME>

For e.g.

GIM(1.0.1):TEST:BUG: Segmentation Fault in module Add Contact

dsmith · #8 18-Nov-2004, 07:06

Quote:

Originally Posted by crystalattice

One thought/question: will this be handled like the Linux kernel development? That is, people can propose and write modules but they won't be implemented unless approved by a single person (probably dsmith). Or will people be able to post "willy-nilly" :-) to the project?

This may have been addressed in the opening statement and I just didn't catch it. If so I apologize.

This will be very similar to the linux kernel development (as I see it). There will be an official version of this that will be accepted by some type of control.

However, since this is licensed under the GPL anyone can use this code and "split" the development tree. So if someone wants to do something that is not "official" they are free to do so. In fact, I would actually encourage this. Every project has to have some kind of limits and goals. Someone may come up with a fabulous idea that does not fit within the goals of this project. That doesn't mean that it is a bad idea, just that it doesn't fit here.

Does that explain what I am thinking?

dsmith · #9 18-Nov-2004, 07:31

nkhambal. I like your thinking on this quite a bit.

Here are my thoughts. The program itself is fairly loose and should follow the very basic quidelines above. The individual modules should be more structured and defined. I think we should take some of your ideas and create a "GIM Module Proposal Template." People would fill this template out and submit it here for the public to approve, change or reject (for the official release). This template would basically include the things that you have detailed in the design stage.

Quote:

Originally Posted by nkhambal

Hey Guys,
Design Phase

Functional requirements of the software.
What we intend to acheive with this piece of software.
How it is supposed to work? What features will it support?
What are its limitations (no. of contact entries, memory etc).?

Design the different modules, APIs in the programs.
Define the purpose of each module.
Define how it is integrated within the program.
Design a pseudo code for each module.
Review it for scalability and future enhancement.
Design a program build process. Where and How code will be submitted for compiling.? Where all source code will be available.? How to build on local machines ? What is the build schedule?
Standardization on programming language for whole program or for each module.
Assign the owners to each module, based on the skills and interest.

I like quite a bit that you have here. Some I want to think about. I personnally don't like "build schedule." I have enough schedules and deadlines in my life that I don't meet all ready. I don't want to add another one. (again this is my opinion) Maybe just a change in terminology would help: Estimated completion date. Also, we may want to cut down on a bit of this for the original proposal. I think that each module development manager can provide a much tighter set of bounds by his/her preference. Am I making any sense?

Quote:

GIM(1.0.1)

ESG <POST_NAME>

For e.g.

GIM(1.0.1)ESG: GIM-Base Software Functional Specifications

In Development Phase

GIM(1.0.1)

EVP:<POST_NAME>

For e.g.

GIM(1.0.1)EVP:Code Review <main.cpp>

In Testing Phase

GIM(1.0.1):TEST:<POST_NAME>

For e.g.

GIM(1.0.1):TEST:BUG: Segmentation Fault in module Add Contact

Again, I really like this idea. But is this up to the module manager or a "rule". Again, my preference is to make this a guideline. I think it will help attract people to your module production if you are this organized. However, I am trying not to be so rigid as to say it must be done like this.

Thoughts?

dsmith · #10 18-Nov-2004, 07:54

Quote:

Name: //single line
Company : // single line
Address : // 2 lines no wrap
Phone : // single line, should format number after enter
Email : // single line
Notes : // 3 lines with word wrap
Category : // drop list that can be added to by user. Default, personal & business.

This is a great first module to include. I have some suggestions as to other fields to consider:

I think phone should be split into several catagories.

Business
Home
Fax
Mobile
Other

It seems that everyone has a multitude of numbers these days.

Also, I think name should be split into at least two fields. For last & first.

Also, we need to decide storage sort order. My preference is simply last name & first name.

I will start to make add this modules prototypes and structure to THE header file and post it for your comments.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Rate This Thread
Rate This Thread:

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Need help on a project for C programming	andrew410	C Programming Language	1	30-Oct-2004 07:01
more array help (simulation project..)	dilmv	CPP / C++ Forum	6	17-Oct-2004 07:51
Help with project.	anignna	C Programming Language	12	27-Apr-2004 07:51
Grub's distributed web crawling project Good for webmasters running servers	jrobbio	Search Engine Optimization Forum	4	25-Jun-2003 08:48

Community Project Proposal

GIM MOD - Contact List