Re: gEDA-user: next PCB release - 1.99za vs 4.0

[Andrew Poelstra <asp11@xxxxxx>]

On Fri, Sep 10, 2010 at 01:00:34AM +0100, Peter Clifton wrote:
> 
> Gah, you perhaps saw my comments on geda-dev about that. I've got half a
> mind to bulk rename as appropriat:
> 
> max_layer -> max_copper_layer
> OR        -> max_group
>
> They happen to be the same number, but the context is different and it
> makes a lot of code confusing.
>
> There are actually max_copper_layer + 2 layers, with the last two being
> the silk layers. It sits wrong with me to see:
> 
> for (i = 0; i < max_layer + 2; i++) {
>   Layer[i]...
> }
> 
> I think "max_copper_layer + 2" is slightly less perverse.
>

It's a PITA to find and read the geda-dev archives, and given the relatively
low volume, I don't usually bother. So I missed your comments.

Having said that, I'd do you one step further, and move /all/ the layers into
their own list structure. Each layer would have flags set to indicate if it
was a copper, silk, keepout or virtual (ie, ratsnest) layer. They would also
be tagged as being always on top or always on bottom, in the case of silk
layers that we don't want ending up inside the board.

The layer-selector widget would then be little more than a pretty layer on
top of that structure.
 
> > A common theme in pcb is that limitations in the file format and our
> > data structures, show up as ugly hacks in the GUI code.
> 
> Point me some examples and I'll probably agree, but I can't think of any
> immediately.
>

Well, the fact there are exactly two silk layers, both selected in the same
way (depending on which side of the board is being viewed), and a ratsnest
layer, all of which require switch blocks throughout the layer-selector GUI
code. Also, there are weird variables like SilkActive and RatsActive that
implicitly depend on each other, and the layer array.
 
> There have been plenty of places where the core's assumption of
> rendering requirements / ordering have bitten me with the GL branches
> though. It is tricky to fix them as you can't always tell how changes
> will affect other exporters / GUIs.
> 

> 
> > > (You may notice I've started in a few places pulling common drawing code
> > > into a common_* prefix under the hid/ folder). My aim was to set it up
> > > such that the GUIs could take or leave various bits of the common
> > > rendering code as their authors desire.
> > >
> > 
> > To do this, we would have to use a single renderer, no? For example, have
> > OpenGL do the viewport drawing in all of Gtk, LessTIF, (Windows?), etc?
> 
> Not so easy as that, as there will necessarily be toolkit specific
> requirements for setting up a rendering context, and possibly even
> different strategies for managing redraw.
>

Yuck. I'll keep this in mind while doing any restructuring.


Andrew
 


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