kicad-developers team mailing list archive
Mailing list archive
Re: Gerbview wishlist and development
On 03/11/2012 03:51 PM, Dick Hollenbeck wrote:
> On 03/10/2012 12:29 PM, Element Green wrote:
>> It seems like the current state of gerbview leaves a lot to be desired. From what I can
>> see though, its pretty close. Here are some of the lacking features which cause me to
>> resort to using gerbv (which also has its own set of limitations and issues).
>> I've added these to the Wiki here:
>> 1. Location and size information for selected geometry.
>> 2. Layer names (based on file name by default).
>> 3. Re-ordering of layers.
>> 4. Easy toggling of layer visibility (select ranges of layers to toggle, etc).
>> 5. Interactive layer offset, rotation and flip.
>> 6. Show drill holes as geometry (circles at the drill hole sizes).
>> I've started adding code for #1. So far it shows basic location and size information
>> for circles, rectangles and ovals in the status bar when an item is clicked on.
>> For items 2-4, it seems like the layer selection panel needs to be changed to a list
>> control of some sort, which allows for re-ordering, SHIFT/CTRL multi selection, right
>> click menu, etc.
> The inheritance tree from GERBVIEW_LAYER_WIDGET goes up to LAYER_WIDGET and over to
> PCB_LAYER_WIDGET. It may be necessary to break off GERBVIEW_LAYER_WIDGET so as to not
> negatively impact PCB_LAYER_WIDGET. There were several objectives I had in writing
> LAYER_WIDGET and PCB_LAYER_WIDGET, that I would not want to lose at this point. Just to
> name one:
> *) at most two clicks away from controlling anything relative to visibles. This means
> scroll bars would bother me, since I don't want to have to "look for" or reposition anything.
> (My concerns are less with GERBVIEW_LAYER_WIDGET than PCB_LAYER_WIDGET, so I would not
> easily embrace an attempted move to a list control within PCB_LAYER_WIDGET.)
> Exploring a path where you keep the existing base class, these considerations come into play:
> I think you have toggling of layer visibility now, range selection no, but single items yes.
> Other tips regarding only GERBVIEW_LAYER_WIDGET which do not entail changing base class:
> *) Much can be done with the right mouse popup menu that gets added in the derived
> classes, below LAYER_WIDGET.
> a) a "move up" and "move down" choice for re-ordering.
> b) Unload this gerber file.
> c) group visibility toggling based on file extension, which is a cheap way to get your 4)
> You would have to add mouse hit testing for specific row choices. But much is doable with
> the right mouse popup menu idea.
> *) Could keep the read only LAYER_WIDGET::ROW items at the LAYER_WIDGET level in a private
> internal member list to ease re-ordering.
> Regarding GERBVIEW itself:
> *) I had started down the path of keeping a separate display list for each gerber file.
> This is fundamentally different than PCBNEW where all graphical items are on one display
> list accessed via GetBoard(), and earmarked with a specific layer number.
> What a separate display list for each gerber file would give you is the ability to easily
> unload any particular gerber file.
And it allows you to easily alter the drawing order of the various layers, providing you
keep this order in sync with the GERBIEW_LAYER_WIDGET.
> Before I could implement this, I got distracted some
> 2-3 years ago. The only disadvantage I can see is if you are going to support rich mouse
> hit testing, then you have to search all the lists separately.
> But I think that sounds like a for loop to me, and we have a very nice COLLECTOR support
> which can and should be used to gather up items found during list walking.
> However, mouse hit testing is mostly useful if you want to do something with the selected
> item, and we are not talking about a full blown editor here. But I guess you are
> concerned about displaying something about the selected item. Full blown hit testing
> would involve the dis-ambiguating menus that we have in PCBNEW and EESCHEMA.