[GIM][MODULE]Contact List

cable_guy_67 · #1 21-Nov-2004, 20:39

GIM Module Contact List

A GIM add-in Module

I have created the interface of the first module for GIM. There have been no callbacks created yet and nothing but the layout and names of the widgets have been created. The reason for this is there is no reason to create any more until we are sure that the information will be needed. At this point feel free to jump in and make any suggestions about the interface. All the widgets should be self explanatory but questions are always welcome. There are still a few things that could be added. For one, I liked the suggestion to be able to add pictures or graphical representations for the information being presented. Now that there is something to look at perhaps these will be easier to expand on. I'll walk through each of the necessary files and what their purpose will be. For now, some are merely mock-ups so the chain will be maintained as these files are fleshed out.

Anyone who read my tutorial FLTK && fluid In Motion know I get a kick out of this guy so let's get started on an up swing...

Main File - gim.cpp

CPP / C++ / C Code:

/**********************************************************************/
/**********************************************************************/
/* The GIM project                                                    */
/**********************************************************************/
/* FILENAME:         gim.cpp                                          */
/* ORIGINATION DATE: Nov. 21, 2004                                    */
/* ORIGINATOR:       cable_guy_67  [catv]                             */
/* MODULE:           none                                             */
/* LICENSE:          gpl ([url]www.gnu.org/copyleft/gpl.html[/url])              */
/**********************************************************************/
/* DESCRIPTION:                                                       */
/* This is THE main GIM file.  It launches all modules and includes   */
/* gim.h as well as any modules that will be compiled with GIM thru   */
/* the file gim_modules.h which will have all the module main file    */
/* names that the user wants to compile into their final GIM          */
/**********************************************************************/
/* HISTORY:                                                           */
/*   0.0.1 - Start of contact_list prototyping.                       */
/*  we should probably have a versioning CONSTANT in the future       */
/**********************************************************************/
/**********************************************************************/

#include <string>  // I could definitely use some advice on code for avoiding 
                   // including something that has already been included.
//#include "gim.h" // This will point to THE header when it is available. ;)
#include "gim_modules.h"  // The list of dependencies for the user chosen Modules
using namespace std;

int main(){

    contact_list_main("mark");  // This should be dredged out of the db somehow but
                                // I am passing a name just because I would like to
                                // send the last book name to Contact List when a user
                                // opens it.
    return(0);
}

That's it. As we grow GIM this will be the launcher code but there will really not be that much to it. The first file it includes will be gim.h that will be our hook to all the data we generate. The second is gim_modules.h that will be the list of the modules a user would like to include in the compilation process. We will look at that next.

User Desired Modules - gim_modules.h

CPP / C++ / C Code:

/**********************************************************************/
/* FILENAME:         gim_modules.h                                    */
/* ORIGINATION DATE: Nov. 21, 2004                                    */
/* ORIGINATOR:       cable_guy_67  [catv]                             */
/* MODULE:           none                                             */
/* LICENSE:          gpl ([url]www.gnu.org/copyleft/gpl.html[/url])              */
/**********************************************************************/
/* DESCRIPTION:                                                       */
/* This is where the end user will list all the modules that they     */
/* want to include with their version of GIM.  It would also be a     */
/* good place to define any CONSTANTS that will be used as defaults   */
/* by a module.                                                       */
/**********************************************************************/
/* HISTORY:                                                           */
/*   0.0.1 - Start of contact_list prototyping.                       */
/*  we should probably have a versioning CONSTANT in the future       */
/**********************************************************************/
/**********************************************************************/

#include "contact_list.cpp"

Boy, isn't programming fun.

I know I am being horribly monotonous but as this grows it will be worth it. (I hope) Let's slog along and check out contact_list.cpp which is the first real part of the module. This should be named as the module is to keep things simple.

Main Module Code - contact_list.cpp

CPP / C++ / C Code:

/**********************************************************************/
/**********************************************************************/
/* The GIM project                                                    */
/**********************************************************************/
/* FILENAME:         contact_list.cpp                                 */
/* ORIGINATION DATE: Nov. 21, 2004                                    */
/* ORIGINATOR:       cable_guy_67  [catv]                             */
/* 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 contact_list.cxx the code that is generated */
/* for the interface by fluid.                                        */
/* Initial call from gim.cpp should be to contact_list_main(string)   */
/* Sending a string arg will open the matching contact list book.     */
/* If there is no matching name a blank book will be opened.          */
/* This is also where we will put our callback code to keep it        */
/* separate from the interface code.  Modularity is the key!          */
/**********************************************************************/
/* HISTORY:                                                           */
/*   0.0.1 - Start of contact prototyping.                            */
/**********************************************************************/
/**********************************************************************/

#include "contact_list.cxx"

using namespace std;

int contact_list_main(string book_name){

    Fl_Double_Window  *contactwin;       // This is a bare bones FLTK main
    contactwin = make_window();          // function.  It will continue
    contactwin->show();                  // until the main window is closed


    return Fl::run();  // where the FLTK magic happens and then lets our
                       // launcher know what happened
}

GAWHHH. I really need an offline post composer.

One more rung on the ladder and we finally get to some code that does something. The next file that is included is a fluid generated code file that should use the format of module_name.cxx. In this case it is contact_list.cxx. In the past I had changed this in fluid (fluid will gladly output any name you want) but I would like to keep the .cxx extension so we know it has come out of fluid and not hand-coded.

Main fluid Generated Code - contact_list.cxx

CPP / C++ / C Code:

// generated by Fast Light User Interface Designer (fluid) version 1.0105

#include "contact_list.h"

Fl_Double_Window *contact_list=(Fl_Double_Window *)0;

Fl_Menu_Bar *menu_contact_list=(Fl_Menu_Bar *)0;

Fl_Menu_Item menu_menu_contact_list[] = {
 {"Project", 0,  0, 0, 64, 0, 0, 14, 56},
 {"New", 0,  0, 0, 0, 0, 0, 14, 56},
 {"Open", 0,  0, 0, 0, 0, 0, 14, 56},
 {"Save", 0,  0, 0, 0, 0, 0, 14, 56},
 {"Save As", 0,  0, 0, 0, 0, 0, 14, 56},
 {"Quit", 0,  0, 0, 0, 0, 0, 14, 56},
 {0,0,0,0,0,0,0,0,0},
 {"Type", 0,  0, 0, 64, 0, 0, 14, 56},
 {"Personal", 0,  0, 0, 8, 0, 0, 14, 56},
 {"Buisness", 0,  0, 0, 8, 0, 0, 14, 56},
 {"Other", 0,  0, 0, 8, 0, 0, 14, 56},
 {0,0,0,0,0,0,0,0,0},
 {"Security", 0,  0, 0, 64, 0, 0, 14, 56},
 {"Lock", 0,  0, 0, 2, 0, 0, 14, 56},
 {"Unlock", 0,  0, 0, 0, 0, 0, 14, 56},
 {0,0,0,0,0,0,0,0,0},
 {"Password", 0,  0, 0, 64, 0, 0, 14, 56},
 {"Assign", 0,  0, 0, 0, 0, 0, 14, 56},
 {"Remove", 0,  0, 0, 0, 0, 0, 14, 56},
 {0,0,0,0,0,0,0,0,0},
 {"About", 0,  0, 0, 64, 0, 0, 14, 56},
 {"Contact List", 0,  0, 0, 0, 0, 0, 14, 56},
 {"GIM", 0,  0, 0, 0, 0, 0, 14, 56},
 {"GNU", 0,  0, 0, 0, 0, 0, 14, 56},
 {0,0,0,0,0,0,0,0,0},
 {0,0,0,0,0,0,0,0,0}
};

Fl_Group *group_name=(Fl_Group *)0;

Fl_Input *name_last=(Fl_Input *)0;

Fl_Input *name_first=(Fl_Input *)0;

Fl_Input *name_mi=(Fl_Input *)0;

Fl_Group *group_contactinfo=(Fl_Group *)0;

Fl_Input *contact_home=(Fl_Input *)0;

Fl_Input *contact_work=(Fl_Input *)0;

Fl_Input *contact_mobil=(Fl_Input *)0;

Fl_Input *contact_fax=(Fl_Input *)0;

Fl_Input *contact_other1=(Fl_Input *)0;

Fl_Input *contact_other2=(Fl_Input *)0;

Fl_Input *contact_email=(Fl_Input *)0;

Fl_Input *contact_www=(Fl_Input *)0;

Fl_Group *group_address=(Fl_Group *)0;

Fl_Input *address_address1=(Fl_Input *)0;

Fl_Input *address_address2=(Fl_Input *)0;

Fl_Input *address_state=(Fl_Input *)0;

Fl_Input *address_zipcode=(Fl_Input *)0;

Fl_Input *address_country=(Fl_Input *)0;

Fl_Text_Editor *edit_notes=(Fl_Text_Editor *)0;

Fl_Output *book_name=(Fl_Output *)0;

Fl_Output *contact_type=(Fl_Output *)0;

Fl_Counter *record_change=(Fl_Counter *)0;

Fl_Double_Window* make_window() {
  Fl_Double_Window* w;
  { Fl_Double_Window* o = contact_list = new Fl_Double_Window(531, 486, "GIM Contact List");
    w = o;
    o->box(FL_UP_BOX);
    { Fl_Menu_Bar* o = menu_contact_list = new Fl_Menu_Bar(0, 0, 530, 20);
      o->menu(menu_menu_contact_list);
    }
    { Fl_Group* o = group_name = new Fl_Group(5, 35, 520, 35, "Name");
      o->box(FL_ENGRAVED_FRAME);
      o->labeltype(FL_EMBOSSED_LABEL);
      o->align(FL_ALIGN_TOP_LEFT);
      name_last = new Fl_Input(45, 40, 185, 25, "Last :");
      name_first = new Fl_Input(275, 40, 180, 25, "First :");
      name_mi = new Fl_Input(485, 40, 30, 25, "MI :");
      o->end();
    }
    { Fl_Group* o = group_contactinfo = new Fl_Group(5, 85, 520, 125, "Contact Info");
      o->box(FL_ENGRAVED_FRAME);
      o->labeltype(FL_EMBOSSED_LABEL);
      o->align(FL_ALIGN_TOP_LEFT);
      contact_home = new Fl_Input(65, 90, 185, 25, "Home :");
      contact_work = new Fl_Input(325, 90, 185, 25, "Work :");
      contact_mobil = new Fl_Input(65, 120, 185, 25, "Mobil :");
      contact_fax = new Fl_Input(325, 120, 185, 25, "Fax :");
      contact_other1 = new Fl_Input(65, 150, 185, 25, "Other :");
      contact_other2 = new Fl_Input(325, 150, 185, 25, "Other :");
      contact_email = new Fl_Input(65, 180, 185, 25, "Email :");
      contact_www = new Fl_Input(325, 180, 185, 25, "WWW :");
      o->end();
    }
    { Fl_Group* o = group_address = new Fl_Group(5, 225, 520, 95, "Address");
      o->box(FL_ENGRAVED_FRAME);
      o->labeltype(FL_EMBOSSED_LABEL);
      o->align(FL_ALIGN_TOP_LEFT);
      address_address1 = new Fl_Input(85, 230, 425, 25, "Address 1 :");
      address_address2 = new Fl_Input(85, 260, 425, 25, "Address 2 :");
      address_state = new Fl_Input(85, 290, 85, 25, "State/Prov :");
      address_zipcode = new Fl_Input(255, 290, 85, 25, "Zip Code :");
      address_country = new Fl_Input(425, 290, 85, 25, "Country :");
      o->end();
    }
    { Fl_Text_Editor* o = edit_notes = new Fl_Text_Editor(5, 335, 520, 75, "Notes");
      o->box(FL_DOWN_BOX);
      o->labeltype(FL_EMBOSSED_LABEL);
      o->align(FL_ALIGN_TOP_LEFT);
      o->when(FL_WHEN_ENTER_KEY);
    }
    book_name = new Fl_Output(85, 415, 170, 25, "Book Name:");
    contact_type = new Fl_Output(350, 415, 175, 25, "Contact Type:");
    { Fl_Counter* o = record_change = new Fl_Counter(80, 455, 390, 25, "Record Number");
      o->labeltype(FL_EMBOSSED_LABEL);
      o->minimum(1);
      o->maximum(1000);
      o->step(1);
      o->value(1);
      o->align(FL_ALIGN_TOP);
    }
    o->end();
  }
  return w;
}

This file in turn includes the header information that is also generated by fluid. The naming convention is the same as above with a .h instead of .cxx. Here is contact_list.h

CPP / C++ / C Code:

// generated by Fast Light User Interface Designer (fluid) version 1.0105

#ifndef contact_list_h
#define contact_list_h
#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>
extern Fl_Double_Window *contact_list;
#include <FL/Fl_Menu_Bar.H>
extern Fl_Menu_Bar *menu_contact_list;
#include <FL/Fl_Group.H>
extern Fl_Group *group_name;
#include <FL/Fl_Input.H>
extern Fl_Input *name_last;
extern Fl_Input *name_first;
extern Fl_Input *name_mi;
extern Fl_Group *group_contactinfo;
extern Fl_Input *contact_home;
extern Fl_Input *contact_work;
extern Fl_Input *contact_mobil;
extern Fl_Input *contact_fax;
extern Fl_Input *contact_other1;
extern Fl_Input *contact_other2;
extern Fl_Input *contact_email;
extern Fl_Input *contact_www;
extern Fl_Group *group_address;
extern Fl_Input *address_address1;
extern Fl_Input *address_address2;
extern Fl_Input *address_state;
extern Fl_Input *address_zipcode;
extern Fl_Input *address_country;
#include <FL/Fl_Text_Editor.H>
extern Fl_Text_Editor *edit_notes;
#include <FL/Fl_Output.H>
extern Fl_Output *book_name;
extern Fl_Output *contact_type;
#include <FL/Fl_Counter.H>
extern Fl_Counter *record_change;
Fl_Double_Window* make_window();
extern Fl_Menu_Item menu_menu_contact_list[];
#define submenu_project (menu_menu_contact_list+0)
#define menuitem_new (menu_menu_contact_list+1)
#define menuitem_open (menu_menu_contact_list+2)
#define menuitem_save (menu_menu_contact_list+3)
#define menuitem_saveas (menu_menu_contact_list+4)
#define menuitem_quit (menu_menu_contact_list+5)
#define menu_type (menu_menu_contact_list+7)
#define menuitem_personal (menu_menu_contact_list+8)
#define menuitem_buisness (menu_menu_contact_list+9)
#define menuitem_other (menu_menu_contact_list+10)
#define menu_security (menu_menu_contact_list+12)
#define menuitem_lock (menu_menu_contact_list+13)
#define menuitem_unlock (menu_menu_contact_list+14)
#define submenu_password (menu_menu_contact_list+16)
#define menuitem_assign (menu_menu_contact_list+17)
#define menuitem_remove (menu_menu_contact_list+18)
#define submenu_about (menu_menu_contact_list+20)
#define menuitem_aboutcontactlist (menu_menu_contact_list+21)
#define menuitem_aboutgim (menu_menu_contact_list+22)
#define menuitem_aboutgnu (menu_menu_contact_list+23)
#endif

Last but not least I will give the .fld file that I used to generate the two previous files. If you load it into fluid and use the write code ability of fluid those files will be created for you. For consistency here is contact_list.fld

Code:

# data file for the Fltk User Interface Designer (fluid)
version 1.0105 
header_name {.h} 
code_name {.cxx}
Function {make_window()} {open
} {
  Fl_Window contact_list {
    label {GIM Contact List} open
    xywh {450 190 531 486} type Double box UP_BOX visible
  } {
    Fl_Menu_Bar menu_contact_list {open
      xywh {0 0 530 20}
    } {
      submenu submenu_project {
        label Project open
        xywh {0 0 100 20}
      } {
        menuitem menuitem_new {
          label New
          xywh {0 0 100 20}
        }
        menuitem menuitem_open {
          label Open
          xywh {10 10 20 20}
        }
        menuitem menuitem_save {
          label Save
          xywh {30 30 100 20}
        }
        menuitem menuitem_saveas {
          label {Save As}
          xywh {40 40 100 20}
        }
        menuitem menuitem_quit {
          label Quit
          xywh {50 50 100 20}
        }
      }
      submenu menu_type {
        label Type open
        xywh {0 0 100 20}
      } {
        menuitem menuitem_personal {
          label Personal
          xywh {0 0 100 20} type Radio
        }
        menuitem menuitem_buisness {
          label Buisness
          xywh {10 10 100 20} type Radio
        }
        menuitem menuitem_other {
          label Other
          xywh {20 20 100 20} type Radio
        }
      }
      submenu menu_security {
        label Security open
        xywh {0 0 100 20}
      } {
        menuitem menuitem_lock {
          label Lock
          xywh {0 0 100 20} type Toggle
        }
        menuitem menuitem_unlock {
          label Unlock
          xywh {10 10 100 20}
        }
      }
      submenu submenu_password {
        label Password open
        xywh {0 0 100 20}
      } {
        menuitem menuitem_assign {
          label Assign
          xywh {0 0 100 20}
        }
        menuitem menuitem_remove {
          label Remove
          xywh {10 10 100 20}
        }
      }
      submenu submenu_about {
        label About open
        xywh {0 0 100 20}
      } {
        menuitem menuitem_aboutcontactlist {
          label {Contact List}
          xywh {0 0 100 20}
        }
        menuitem menuitem_aboutgim {
          label GIM
          xywh {10 10 100 20}
        }
        menuitem menuitem_aboutgnu {
          label GNU
          xywh {20 20 100 20}
        }
      }
    }
    Fl_Group group_name {
      label Name open
      xywh {5 35 520 35} box ENGRAVED_FRAME labeltype EMBOSSED_LABEL align 5
    } {
      Fl_Input name_last {
        label {Last :}
        xywh {45 40 185 25}
      }
      Fl_Input name_first {
        label {First :}
        xywh {275 40 180 25}
      }
      Fl_Input name_mi {
        label {MI :}
        xywh {485 40 30 25}
      }
    }
    Fl_Group group_contactinfo {
      label {Contact Info} open
      xywh {5 85 520 125} box ENGRAVED_FRAME labeltype EMBOSSED_LABEL align 5
    } {
      Fl_Input contact_home {
        label {Home :}
        xywh {65 90 185 25}
      }
      Fl_Input contact_work {
        label {Work :}
        xywh {325 90 185 25}
      }
      Fl_Input contact_mobil {
        label {Mobil :}
        xywh {65 120 185 25}
      }
      Fl_Input contact_fax {
        label {Fax :}
        xywh {325 120 185 25}
      }
      Fl_Input contact_other1 {
        label {Other :}
        xywh {65 150 185 25}
      }
      Fl_Input contact_other2 {
        label {Other :}
        xywh {325 150 185 25}
      }
      Fl_Input contact_email {
        label {Email :}
        xywh {65 180 185 25}
      }
      Fl_Input contact_www {
        label {WWW :}
        xywh {325 180 185 25}
      }
    }
    Fl_Group group_address {
      label Address open
      xywh {5 225 520 95} box ENGRAVED_FRAME labeltype EMBOSSED_LABEL align 5
    } {
      Fl_Input address_address1 {
        label {Address 1 :}
        xywh {85 230 425 25}
      }
      Fl_Input address_address2 {
        label {Address 2 :}
        xywh {85 260 425 25}
      }
      Fl_Input address_state {
        label {State/Prov :}
        xywh {85 290 85 25}
      }
      Fl_Input address_zipcode {
        label {Zip Code :}
        xywh {255 290 85 25}
      }
      Fl_Input address_country {
        label {Country :}
        xywh {425 290 85 25}
      }
    }
    Fl_Text_Editor edit_notes {
      label Notes selected
      xywh {5 335 520 75} box DOWN_BOX labeltype EMBOSSED_LABEL align 5 when 8
    }
    Fl_Output book_name {
      label {Book Name:}
      xywh {85 415 170 25}
    }
    Fl_Output contact_type {
      label {Contact Type:}
      xywh {350 415 175 25}
    }
    Fl_Counter record_change {
      label {Record Number}
      xywh {80 455 390 25} labeltype EMBOSSED_LABEL align 1 minimum 1 maximum 1000 step 1 value 1
    }
  }
}

Now all that is needed is to put all the files in the same directory and compile. I use GNU's g++ from bash and here is my command line. If you use something else, make the needed adjustments.

g++ gim.cpp `fltk-config --ldflags --cxxflags` -o contact

Well, that is all there is to it. Please let me know if you encounter any problems or make any comments or suggestions here. I may create another thread in the C/C++ forum if the coding seems to warrant it. Other than that, GIM has a module to start.

I've had it for tonight. Contact me if you have any questions.

Oh yeah, for the truly severe, I realize I misspelled Business, it will be corrected.

cable_guy_67 · #2 22-Nov-2004, 13:46

Since I don't seem to have the juice to edit the last post here is the zip of all the files that were talked about. Just kind of spaced it out last night.

dsmith · #3 23-Nov-2004, 20:02

I love the layout. It is very well done. It also compiled very cleanly (as it should since there is no call backs

).

Here are my questions/suggestions:

What is the book name?
How do I add/delete or update a contact?
In the menus up top - what is the project?
Is the type a filter?
What is the security lock and how is that to work? Explain the checkbox by security.
Can you assign a seperate password to a contact or is this for the entire list?
This is an add on but I think there should also be a view where all of the contacts (names only?) are shown in a list with the ability to filter and search.
I like the contact_list.txt. My advice though is to stick an m in front of it (I renamed it to mcontact) and just put in the compile command. It is a cheap and easy way to make a quick makefile.
Is the security something that is for read-only access?
Why about GNU? Not a terrible idea, but in this case maybe about FLTK would be more fitting?

I really like this layout. Don't take my comments as criticism. I am just trying to get your vision as I will be starting the data server part of this.

cable_guy_67 · #4 23-Nov-2004, 21:02

Quote:

Originally Posted by dsmith

I love the layout. It is very well done. It also compiled very cleanly (as it should since there is no call backs

).

Thanks for the feedback. I wouldn't have posted it if I didn't want them.

I like the layout of the window as well and the menu's are subject to change.

Quote:

Originally Posted by dsmith

Here are my questions/suggestions:

What is the book name?

The book name will be the base name of the list of contacts. This way, you could have a book named dsmith, mrsdsmith, littledmith etc. Each would have their own set of contacts. You know, little black book.

The name would be displayed in the output only 'book name' field (no input).

Quote:

Originally Posted by dsmith

How do I add/delete or update a contact?

You would do this by having the contact record displayed and changing the contents of the input field. This would hinge on whether or not the lock checkbox is checked or unchecked.

Quote:

Originally Posted by dsmith

In the menus up top - what is the project?

This actually should be file to conform to windows style unless someone has a better idea I guess. Project was the old amiga initial sub-menu and I was deep in an old style guide while I was working on it.

Quote:

Originally Posted by dsmith

Is the type a filter?

Type is the contact type that can be set by the radio buttons in the submenu type. It is display only (no input).

Quote:

Originally Posted by dsmith

What is the security lock and how is that to work? Explain the checkbox by security.

The security lock goes hand in hand with the checkbox. If you set the checkbox the input fields will be effectively locked from change. You would have to uncheck the box to be able to change text in a field.

Quote:

Originally Posted by dsmith

Can you assign a seperate password to a contact or is this for the entire list?

The password will be to lock the book. If you assign a password to a book you will have to enter the password to view the book. The password will be unassigned to start. If the user does not want to use it they don't have to or can remove an existing password using the password/remove menu item. If there is an assigned password the user would need to enter the old password to change the password or assign it to nothing. If it is assigned the user will have to enter it to open the book for access. If you attempt to load a book that is password protected you will get a dialog prompting the user for the password before loading it.

Quote:

Originally Posted by dsmith

This is an add on but I think there should also be a view where all of the contacts (names only?) are shown in a list with the ability to filter and search.

This could be done. Would the user like to have a table that displays the entire book like a spreadsheet that could then be sorted by column. This might be nice if we get print support. That way you could click on the column corresponding to last name (most likely), first name (possibly some might want this) and order the list accordingly. First click and order in descending order. Click again and it could be reversed.

Quote:

Originally Posted by dsmith

I like the contact_list.txt. My advice though is to stick an m in front of it (I renamed it to mcontact) and just put in the compile command. It is a cheap and easy way to make a quick makefile.

Oddly enough this never occurred to me. I just put it in for ease of co-conspirators.

I like your idea better.

Quote:

Originally Posted by dsmith

Is the security something that is for read-only access?

Answered above, you got it hammer to nail head, 16 penny buried in one shot.

Quote:

Originally Posted by dsmith

Why about GNU? Not a terrible idea, but in this case maybe about FLTK would be more fitting?

I would say it needs an additional item FLTK. This will be of course about the module. About the GIM project with contact info. Licensing info about FLTK (not there yet) with contact to full license. Licensing about GNU tools and contact to full license. The contacts will be web addresses (no need to launch) so the user could see all info if they so desire. I just wanted to make it easy for people to find and not break the Golden Rule

Quote:

Originally Posted by dsmith

I really like this layout. Don't take my comments as criticism. I am just trying to get your vision as I will be starting the data server part of this.

Criticism smiticism. We don't need no steekin' batches.

This is my side (interface) and I am trying to find an attractive slightly unique (hence the embossed labels for the groups) look that will eventually set standards for the 'official' look and feel. This was a well thought out list of questions. Some I had not thought about and some I had in my head. Gotta follow the documentation rule unless there is a psychic in the house. I hope this gives you a better idea of how I envision the interface to interact with the user now.

Mark

edit: One thing I just realized looking at the interface through someone else's eyes. I forgot a company name field. Do'h!

dsmith · #5 23-Nov-2004, 22:29

Just a reminder to anyone, this project started out as simply an idea. What we are going through right now is shaping what this project will be. This is a community project, so I encourage anyones comments. If it is not obvious cable_guy and I are stabbing in the dark to find something that works.

That said->

The add/delete/modify idea you have is about 180 degrees from what I have. This is something that we need to think on. I don't think that the interface should ever have direct access to the data. It should request the data and it will be transferred to it.

My idea on this. Have a menu item or buttons that have "new contact" and "delete contact". The delete contact would obviously just remove the entire record.

The new contact would present the user with a blank form. Any changes made would trigger a "modified" flag. In any callback that leaves the form (next entry, exit, etc.) the data would be posted. Perhaps we could have a setting that would either confirm all posting or just automatically post.
I like the security, but I like better a single box labeled read-only that can be checked or unchecked.
The "book" for you would relate to "database/file" for me. Do you concur? (according to gim.h)
I think the list can be a seperate module. However, (and this is up for future debate), I think that the list mode would come up by default when the user calls this contact module. Again future consideration.
We are both thinking of security considerations. However, my login was global based upon a database idea. This needs more thought on my part unless you have an exact idea of what level we do this at.

One other idea. Could you post your binary for our friends that are fltk-less (for shame!). I would just like to have everyone that is interested be able to see this without having to install fltk if they don't want to.

cable_guy_67 · #6 24-Nov-2004, 08:32

Quote:

Originally Posted by dsmith

Just a reminder to anyone, this project started out as simply an idea. What we are going through right now is shaping what this project will be. This is a community project, so I encourage anyones comments. If it is not obvious cable_guy and I are stabbing in the dark to find something that works.

Mr Moderator, dsmith is pickin' on me.
Oh, that won't work now will it. 8-)

Enough of that nonsense. I would like to second the above statement. The hardest part for me is to separate myself from my original thought when building a user interface. One of the major positives with doing all this in a community setting is to get as much feedback on things you don't like or would like to act differently. As you can see from my previous post when D put forth a list of questions I had almost immediate answers for all of them. I could have bypassed many by posting a "how the silly thing will work" section so everyone will have an idea what the team leader intends for the interface elements. That being said I need to get my baseball bat and do a few laps with these silly questions below.

Quote:

Originally Posted by dsmith

That said->

The add/delete/modify idea you have is about 180 degrees from what I have. This is something that we need to think on. I don't think that the interface should ever have direct access to the data. It should request the data and it will be transferred to it.

My idea on this. Have a menu item or buttons that have "new contact" and "delete contact". The delete contact would obviously just remove the entire record.

The new contact would present the user with a blank form. Any changes made would trigger a "modified" flag. In any callback that leaves the form (next entry, exit, etc.) the data would be posted. Perhaps we could have a setting that would either confirm all posting or just automatically post.

To start, I will need to add an edit submenu for this. Without some way to do this there is currently no way to add a new contact. How thoughtless of me. I guess I only have one friend and had no need for it. Who knew.

The edit submenu will need:

The ability to add a contact. This should be at the end of the existing records. So if there are 0 records it will be set to record 1 (or 0 in computer speak) if there are 10 then to 11.
The ability to delete a contact. This should prompt the user to make sure this is what they really want to do. Don't want to be deleting Santa's private email address after all that searching for it.
As for the modify, I prefer using the read only method you talked about. If all contacts are by default read only then to change a modify contact menu item would change the flag (at the same time setting a modified flag) so the user could make adjustments. Before the user changes records they would need to be asked if they want to make the changes permanent. If the user answers 'yes' then the record is posted to the db and the flags are set back to read only and the modified flag is cleared. If the user answers no the record should be restored from the db.

Quote:

Originally Posted by dsmith

I like the security, but I like better a single box labeled read-only that can be checked or unchecked.

Back to the KISS principle. Based on the edit changes this submenu is redundant and could be removed entirely. Records will ALL be read-only until the user choses to modify them.

Quote:

Originally Posted by dsmith

The "book" for you would relate to "database/file" for me. Do you concur? (according to gim.h)

Me and my big mouth. I ask for gim.h and now I have to follow along with it. This is a no brainer. "concur"

Quote:

Originally Posted by dsmith

I think the list can be a seperate module. However, (and this is up for future debate), I think that the list mode would come up by default when the user calls this contact module. Again future consideration.

(Getting out the bat)

This really does need to be debated. "I" would prefer the interface I have shown for normal operation. That of course does not mean everyone would. Perhaps this should be up the user entirely. This interface could be only used when someone wants to modify and always looks at a list type form. Weigh in people, this is the basis of the interaction. You can either:

Side with crazy dsmith.
Take the side of reason like cable_guy. 8-)
Propose something we have not thought of yet.

I'm sure we can hash this out like reasonable weapon toting adults.

Quote:

Originally Posted by dsmith

We are both thinking of security considerations. However, my login was global based upon a database idea. This needs more thought on my part unless you have an exact idea of what level we do this at.

This is not the same as the db login I don't think. I was thinking more of using some type of encryption method on the final file that relates to the specific database. Let's leave this be for now (I'll ghost the submenu) and work on some of the other ideas first. I think gim.h can handle running into an unreadable db already and the security may need to be a totally separate module that could be used by any module that desires security. So this is not the same as the header describes. At least I don't think so.

Quote:

Originally Posted by dsmith

One other idea. Could you post your binary for our friends that are fltk-less (for shame!). I would just like to have everyone that is interested be able to see this without having to install fltk if they don't want to.

There are people that don't have FLTK!
"AHhhhhhh! I'm comin' Elizabeth! It's the big one!"
:-)
Done and Done. I compiled a windows version that has no dependencies on the CygWin dll and it is in the zip below. But just in case here are the file's dependencies:

Code:

$ cygcheck ./contact.exe
.\contact.exe
  C:\WINNT\system32\msvcrt.dll
    C:\WINNT\system32\KERNEL32.dll
      C:\WINNT\system32\ntdll.dll
  C:\WINNT\system32\GDI32.dll
    C:\WINNT\system32\USER32.dll
  C:\WINNT\system32\OLE32.dll
    C:\WINNT\system32\RPCRT4.dll
      C:\WINNT\system32\ADVAPI32.DLL
  C:\WINNT\system32\SHELL32.DLL
    C:\WINNT\system32\SHLWAPI.dll
    C:\WINNT\system32\COMCTL32.dll
  C:\WINNT\system32\WSOCK32.DLL
    C:\WINNT\system32\WS2_32.DLL
      C:\WINNT\system32\WS2HELP.DLL

One other thing to note. I updated my local cvs to 1.1.6 and rebuilt locally so that is what I am using as of today. With a static build it should not matter anyhow but if anyone sees something hinkey let me know.

Hey D, if you want to add a linux version knock yourself out and if there is anyone that wants a CygWin version I can whip one up with some minor adjustments. You do have to have your own CygWin dll's though, I know there are some issues about that but this is noncommercial so I will have to look back into that.

Mark

Download the windows version here

dsmith · #7 24-Nov-2004, 09:24

I think we are pretty darn close to being on the same page. I will start posting my data implementation in another thread. There are some UI design differences, but I think at the common tie point we are sufficiently together to make this work.

The reason that I am so critical on a seperation between data implementation and user interface is that I want to do the data portion in at least two different ways. The first is simply a file loaded into a doubly linked list.

The second is a client/server database that I have created through an IP Socket interface, so that your data could be accessed from anywhere. This will be down the road a bit, but I want to keep the door open for this.

Again, any comments, suggestions, blatant criticisms would be welcome.

cable_guy_67 · #8 24-Nov-2004, 10:01

Quote:

Originally Posted by dsmith

I think we are pretty darn close to being on the same page. I will start posting my data implementation in another thread. There are some UI design differences, but I think at the common tie point we are sufficiently together to make this work.

I would be much more concerned if there were no opposing views. Thanks D for breaking the trail. We want GIM to be unsmashable, uncrushable, uncrashable and pretty darn clever to boot so for anyone out there reading this I only have one thing to say:

Let me set up my soapbox for a moment.

"The best thing you can do for GIM is to tell the team leader why you think this is a piece of junk. Not that it is junk, but why it doesn't work for you. Positive reactions are nice but constructive criticism will build a stronger more robust product. Make the team leaders work with the end user since that is who we intend to create for. List your objections clearly and succinctly and get ready for the responses. I, as a team leader and a GID member have been shown that there are two basic truths. One is, remember to put on your thick skinned sweatshirt, and two, humble pie don't taste so bad when the end result is in everyones best interest and there is enough to go around. I don't think we started doing this just because individuals want something for their own use. I personally feel that it has been started because there are a lot of people here that like to do things that others will benefit from. It might sound goofy or self-righteous but I know from first hand experience that there are people here who feel the same way."

OK, now that I have THAT out of my system...

Quote:

Originally Posted by dsmith

The reason that I am so critical on a seperation between data implementation and user interface is that I want to do the data portion in at least two different ways. The first is simply a file loaded into a doubly linked list.

The second is a client/server database that I have created through an IP Socket interface, so that your data could be accessed from anywhere. This will be down the road a bit, but I want to keep the door open for this.

Again, any comments, suggestions, blatant criticisms would be welcome.

This is the nice thing about there only being this module to start with. We can concentrate on the process to create while making sure the rules will work. I personally don't fully grasp the client/server process fully yet. Now that I have seen the beginnings of gim.h I am starting to see but full understanding is still a ways off.
Even if you have no intention of participating in the creation of either side of the GIM project you can be a HUGE help by trying out the software as it grows. We will try to make sure it won't do anything horrible to you. The team leaders had better have compiled, tested, changed, recompiled, tested and tested a little more but there is no way they can possibly catch everything. We really do need the input from the community here to make this as cool as it can be. I for one can't wait to see how far the data side can be taken. The tools are free and at our fingertips. What gets done with them is up to the craftsmen(and women) out there.

For as little as zero dollars you can be an amazing help.

Mark

Whew, that dude is wacked. 8-)

cable_guy_67 · #9 01-Dec-2004, 21:32

I have made a few changes to the interface and am starting the callbacks. The newest source and binaries can be found at the GIM home page. There is also a description of how each widget should react and interact. I will post hunks of that here as I work on the code for each.

Mark

WaltP · #10 04-Dec-2004, 12:19

Quote:

Originally Posted by dsmith

The reason that I am so critical on a seperation between data implementation and user interface is that I want to do the data portion in at least two different ways. The first is simply a file loaded into a doubly linked list.

I completely agree. See my post for my view.

IMHO, the 'guts' of the module simply
1) receives task info from an input buffer,
2) loads an output buffer with the requested data

The info passed back it easily tested via a console main(). Strip out the main() and you have your module.

The GUI
1) loads the module input buffer with a request,
2) a dummy 'module' loads the output buffer
3) the GUI displays the dummy data.

Strip out the dummy routine, you have your GUI.

Compile them together, a program!

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
Insert problem in Linked list

[GIM][MODULE]Contact List

Crazy Cable Guy ranting and raving

version 0.0.1b