kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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:
>> http://wiki.xtronics.com/index.php/Kicad#Gerb_View
>>
>> Wishlist:
>> 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.