[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gEDA-dev: gschem modifications



Peter --

Everything you're doing sounds ultra-cool.  Thanks for tackling this
project.  Please be sure to get onto #geda during our upcoming code
sprint this Sunday (from 10:00 US EST until whenever).

Some comments:

*  Component manager:  Others here have begged for a facility like
DxDataBook.  This is a fine program, and is worth emulating.  If you
don't know what it is, DxDataBook is a GUI front end for a database
which makes it easy to do parametric searches of your component's
attributes.  It presents you with a list of components which meet your
search  criteria, and you can double-click on one and place it into
your schematic.

*  I do think that a database-driven component manager/selector should
be a separate app to gschem.  That is, it should be its own process
and be able to run stand-alone (until you wnat to place a component,
that is).  If you try to graft it into gschem, then gschem's code base
will grow to a grotesque size.  

As for how to get the component manager/selector (gselect?)  to
communicate with gschem:  That's what pipes or IPC is for.  Dan
McMahill can help you understand how to use pipes wiht gschem.  :-)

*  When instantiating a symbol into the schematic, the component
manager/selctor should just take a stock symbol, and stuff the
attributes into it and place the attributes at the schematic level.  I
am a strong believer that attributes should live in the schematic, not
in the symbol.   That also plays nicely with gattrib, which does
attribute editing at the schematic level.

*  This means that the database holds all attributes fo the part, and
only a pointer to the symbol -- not the symbol itself.  This helps a
lot since later you can imagine having several possible symbols for a
single part -- for example, the same resistor part can have be used
with a box symbol for Europeans, and a zig-zag symbol for Americans. 

We'll communicate more during the code sprint, I hope.  

Cheers,

Stuart




> 
> [ WOOPS, SENT TO USER LIST BY MISTAKE FIRST.. WILL SEND APPOLOGY ]
> 
> Hi,
> 
> Back again after a few weeks in Scotland doing some other work.
> 
> If you recall, I am working to make improvements to the gEDA suite for
> use in undergraduate teaching at Cambridge Univ. Engineering Department.
> 
> Over the past weeks, I've been becoming more familiar with the codebase,
> and now have some local changes made which I think it would be good to
> submit for re-integration before the code-sprint.
> 
> As I'm not familiar with CVS, the work I've been doing is as follows:
> 
> Checkout CVS (annonnymous) (I did this on Tues, 18th July):
> 
> Compile, modify, compile.. from within the resulting geda/gaf directory.
> 
> 
> I'd appreciate advice on better working practices, as to seperate out my
> changes, I now need to checkout the new CVS, make a diff between that
> and my work (after cleaning the build files (.o etc) out), then sort out
> the chances which I have made, so I can then end up with a patch for
> each group of new functionality / changed behaviour I've been working
> on.
> 
> I'm sure this will be a lesson to think more clearly about how I'm going
> to seperate my mods from the CVS download!
> 
> 
> The changes I've made for our use (some of which should will be useful
> back in CVS I hope):
> 
> Mouse behaviour:
> ---------------
> 
>  * Added option to allow mouse panning on middle mouse button, as well
> as RH button.
> 
>  * Changed pan "gain" to 1, rather than 5, so when panning with the
> mouse, the schematic page moves as if you had actually grabbed the page
> at the point when you start panning from
> 
>  * (Hardcoded), scroll wheel behaviour to zoom in/out, with LEFT/RIGHT,
> UP/DOWN with a "shift" / "control" modifier
> 
>  * Slightly modified the preview widget / event handler code to allow
> mouse scroll zooming with the same event handler as the main schematic
> view
> 
> We now have a gschem, where the mouse scroll wheel is able to zoom, pan
> by dragging, and pan LR / UD by scrolling with modifier keys - basically
> making it a navigation button / wheel.
> 
> Re-layed out component picker:
> -----------------------------
> 
>  * Eventually, I would like to see the component picker able to dock as
> a side pane along the left or right of the schematic page view. I've
> re-layed out the dialog in a more vertical way, and removed the
> superfluous "Apply" and "Close" buttons.
> 
>  * Split out component selection code from x_fileselect.c into a new
> file, x_compselect.c
> 
>  * Modified preview widget code to allow it to resize with available
> space
> 
> Superficial cosmetic:
> --------------------
> 
>  * First attempt at an icon for gschem ( from a photo of an 8pin SOIC ),
> mainly so I can identify which window is gschem easily in my "Alt-Tab"
> window switcher.
> 
>  * Code to set the icon is a bug hard-coded hack, and needs someone who
> knows how to assist in its proper implementation. (Getting automake /
> whatever to install the icon in the right place, and getting gschem to
> find it - rather than my hard-coded path method).
> 
> Bugs noted:
> ----------
> 
>  * Some odd behaviour I'm noticing when zooming the window after a
> resize, which can jump the mouse-pointer off the screen, put the
> schematic page origin in a funny place, allow components to be placed
> above the origin.
> 
>  * A crash I saw once - in the autosave code, in s_page_autosave(), from
> libgeda/src/s_page.c. Unfortunatly, I lost the stack dump (which wasn't
> helpful anyway), but the problem appeared to be that toplevel->page_head
> was not equal to NULL, but was not pointing at valid memory.
> 
> I note that this callback is an auto-save system called from a g_timeout
> or something. This timeout is never cancelled once it is setup, so is
> there a possibility that it gets called concurrently with the active
> page being free'd?
> 
> I never saw the crash again (and presuming it could be an unrelated
> memory corruption which caused it), stopped digging at the auto-save
> code.
> 
> 
> 
> Any ideas on how to seperate these patched functionalities out, and
> which bits are suitable / useful for upstream inclusion?
> 
> 
> I'm keen to hear more about people's thoughts on a component manager /
> database for light -> heavy symbol work on a per company / project
> basis, as this is exactly what I'm wanting to implement as part of this
> project.
> 
> As some will recall, a new project manager is on the cards, although
> I've not yet spent much time working out how it should work, either GUI
> or backend wise.
> 
> 
> Regards,
> 
> Peter Clifton
> 
> 
> 
> 
> 
> _______________________________________________
> 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