Re: gEDA-user: wishful UI

[Andrew Poelstra <asp11@xxxxxx>]

On Fri, Aug 06, 2010 at 12:38:35PM +0100, Peter Clifton wrote:
> On Thu, 2010-08-05 at 21:08 -0700, Andrew Poelstra wrote:
> > 
> > My vision is this: the current drawing area will become a tabbed
> > drawing
> > area, with each tab a different Group. Each Group is a logically
> > connected
> > subset of the PCB - so for example, you might have a power supply
> > Group,
> > a USB port Group, an amplifier Group, etc. 
> 
> I'm not sure I personally would use this feature.. I already pretty much
> shun PCB's layer group functionality as there are not enough colours to
> render everything clearly!
> 
> However.. some thoughts:
> 
> When on a particular group, the rest of the board could perhaps be
> rendered (partially?) de-saturated (greyed out)... so the designer
> working on the PSU section is aware which areas of the board are
> available for use. Transparency is already used to good effect in my GL
> version of PCB (which I've got plans, but currently no time, to work on
> merging back into mainline).
>

Thank you and Armin for suggesting OpenGL rather than Cairo.
 
> An ever expanding internal list of layer groups is probably a bad idea.
> If we create a significant number of layer groups, it increases the
> number of layers which need to be inter checked for connectivity. I
> recall, (but could easily be wrong), that r-trees of objects are kept
> per layer, not per layer group.**
> 

Well, as you suggest below, Groups are essentially a way of tagging
different parts, so they would be completely independent of the physical
layers - and the connectivity checker.

> ** Confusingly, PCB already has "layer groups", which consist of
> multiple "layers". A layer group is what ends up physically as a plane
> of copper in your produced board. Your terminology reverses the meaning,
> with a "layer group" consisting of logically grouped parts spanning
> multiple physical layers.
> 
> I presume you intend to get rid of PCB's existing layer group
> functionality (good riddance IMO), however it would be less confusing to
> pick a new name. Perhaps "logical group".
> 

Yes, absolutely! But I cannot think of a good name :) "logical group"
is too long and ambiguous. Right now I am using "Group", but that's
even less useful.

> 
> A further design choice to make is whether to identify parts as part of
> a logical group by separating completely different data-structures for
> each group (IMO not easy), or just add on a tagging means to identify
> which group a object in a layer data-structure belongs to.
>

I was planning to do a tagging mechanism. Otherwise the "All" view would
become more difficult, and we would probably lose backward compatibility
with old .pcb files.
 
> This could then form the search key for a query from the view.. in
> database-esque pseudo-explanation:
> 
> View tab "safety critical" defined as:
> 
> render_normal_colours("SELECT * where LOGICAL_GROUP is "psu" or LOGICAL_GROUP is "safety_interlock;")
> render_desaturated_colours("SELECT * where LOGICAL_GROUP isnot "psu" and LOGICAL_GROUP isnot "safety_interlock;")
> 
> 
> View tab "all" defined as:
> render_normal_colours("SELECT *;")
> 

I like this. However, it does separate the concept of "view" from the
concept of layer groups. Which means separate "delete" commands, and
possibly user confusion as custom views could be closed, whereas the
Group views could not.

Also, I think that parts could be members of multiple Groups. That
might fiddle with your SQL syntax above, but the concept would be
the same. I can't think of any contradictions that might arise (if
a part had two Groups, and they had different DRC rules, go with
the most conservative ones).

For now I'm going to say "out of scope" for this, but I'll make a
point of not precluding it with any data structures or storage format.

> 
> You should be able to add tagging functionality to the core of PCB
> without needing to teach existing renderers too much about it. I'm
> guessing that the GUI view will be where most of the work occurs.
> 

My hope is that current copies of PCB will be able to open new files
without any trouble - except that the "All" view will be the only one
visible, of course.

> <snip>
> 
> Hope this has been of help.
> 
> Check out the OpenGL version of PCB too, if you want to play with some
> transparent rendering. Thindraw / thindraw polygon mode on a board with
> polygons is particularly pretty. (Also, try with / without the solder
> mask on, ideally with a board "outline" layer defined).
> 
> git://repo.or.cz/geda-pcb/pcjc2.git
> 
> The branch you want is probably "before_pours". "master" is also good,
> but changes polygon semantics rather a lot! (Polygon -> pour, complete
> with island removal and separate continuity checking for each broken up,
> non-islanded piece).
>

Thanks! I'll take a look.

Andrew




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