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

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Thu, 2010-09-09 at 10:17 -0700, Andrew Poelstra wrote:
> On Thu, Sep 09, 2010 at 05:53:34PM +0100, Peter Clifton wrote:
> > 
> > The renderer can have non-OO helper functions too I guess, but it felt
> > odd putting that into a file with a widget implementation. I had hoped
> > to keep it one file for GDK specific, and one file for GL specific code.
> > 
> > I'm still sorely tempted to make a widget out of the PCB view area at
> > some point, but it feels difficult to detach from the core.
> >
> 
> It will be difficult, but I think it will be necessary at some point when
> we try to implement functional blocks and multiple views. For now let's
> try to widget-ize the layer selector and friends, and see what problems
> we encounter.
> 
> I've already hammered out a header file for the Layer selector widget.
> Actually filling in the code will likely be a challenge. For example, I
> want to get rid of all the special-case Silk/Via code, which could mean
> fixing all of the layer-handling code...ugh.

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.

> 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.

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.

> But if we can segregate the code for the layer selector, routing style
> selector, etc, the remaining code should be a lot easier to grok.

;)

[snip]

> > (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.

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

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)



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