Re: gEDA-dev: gnetlist as one way path?

[Steve Meier <smeier-at-NOSPAMalchemyresearch_dot_com>]

Yes, I moved stuff like this from out of my latest
libgeda/include/struct.h into a gschem/include/struct.h

And now I am thinking that they belong in a gtk_hid_struct.h file.

  // main window widgets 

  GtkWidget *main_window;
  GtkWidget *drawing_area;
  GtkWidget *menubar;
  GtkWidget *popup_menu;
  GtkWidget *h_scrollbar;
  GtkWidget *v_scrollbar;    
  GtkObject *h_adjustment;
  GtkObject *v_adjustment;

.
.
.


But to open a libgeda method discussion some of the more fundimental
methods that I use are.


from my libgeda o_basic.h


OBJECT *o_object_new();

void o_object_init(OBJECT *this_obj, char obj_type, BOOL selected,
			 BOOL visible, BOOL locked);

//-------------------------------------------------------------------
// if the reference count is zero free the object otherwise just 
// decrement the reference count
void o_object_free(OBJECT *this_obj);

//-------------------------------------------------------------------
// get a reference to this object and increment the reference count 
OBJECT *o_object_get_reference(OBJECT *this_obj);



and from o_arc_basic.h


ARC *o_arc_new( );

void o_arc_init(ARC *this_arc, 
		POINT center, int radius, int start_angle, int
		end_angle, COLOR * color, int width, LINE_STYLE style );

void o_arc_free(ARC *this_arc);


from libgeda there doesn't seem to exist an explicit creation of an
OBJECT instead there are a number of variations of

OBJECT *o_arc_add(TOPLEVEL *w_current, OBJECT *object_list, char type,
	 int color, int x, int y, int radius, int start_angle, 
	 int end_angle);

OBJECT *o_complex_add(TOPLEVEL *w_current, OBJECT *object_list, 
		      GList **object_glist, char type, int color, 
		      int x, int y, int angle, int mirror, char *clib, 
		      char *basename, int selectable, 
			int attribute_promotion);




In my version I tend to do create objects then create the sub-object and
attach it to the object and then attach the object to one of the lists
in a page.


OBJECT *new_obj = NULL;
ARC *new_arc = NULL;

new_obj = o_object_new();

if (new_object) {
	o_object_init(new_object, OBJ_ARC, ...., );

	new_arc = o_arc_new();

	if (new_arc) {
	  o_arc_init(new_arc,...);

	  new_object->data.arc = new_arc;

	  this_page->objects = g_list_append(this_page->objects,
		 		 new_object);
	}
}




On Tue, 2007-05-29 at 20:26 +0100, Peter Clifton wrote:
> On Tue, 2007-05-29 at 11:52 -0700, Steve Meier wrote:
> 
> [snip]
> 
> > Peter Clifton,
> > 
> > You asked about by my netlist and modified libgeda. Yep both my version
> > of the netlister and backnet link against the modified libgeda. This is
> > one reason I want to open the discussion about methods. I would like to
> > make my work track yours in the hope of eventually reconnecting with
> > main stream geda.
> 
> As I've not got immediate free time for a major project, I've been
> working on other less intrusive changes recently.
> 
> Discussion of methods would be good, and so far I've not really
> considered API requirements of libgeda, just possible modifications to
> the data-structure for on-the-fly nesting (with hierarchy).
> 
> Is there anything wrong with the current API (in principle?)
> 
> If I recall, your modified libgeda has cut most of the non-electrical
> things from data-structures. (A good move in the most part). Obviously
> gschem is a CAD program, so needs graphical data to be stored in the
> data-structures, but GUI stuff can and should be moved into gschem.
> 
> Regards,
> 
> Peter C.
> 
> 
> 
> 
> _______________________________________________
> geda-dev mailing list
> geda-dev@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev



_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev