kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Seth,

This is mostly historical baggage.  In my view, there should have been a
SYMBOL_LIB_SCREEN to store and manipulate LIB_ITEM objects.
Technically, LIB_ITEM objects should not be stored in an SCH_SCREEN
object.  The only reason we got away with it is both SCH_ITEM and
LIB_ITEM are derived from EDA_ITEM.  It was like this before I started
with the project.  I'm guessing it would be a lot of work to implement
it this way but this would separate out the event handling differences
between the schematic and symbol library editor and viewer.

Cheers,

Wayne

On 12/18/2017 2:21 PM, Seth Hillbrand wrote:
> ​Oliver noticed an issue with the double-click handling as it is
> implemented in the Library Editor.  The bug report is at
> https://bugs.launchpad.net/bugs/1738694
> 
> The issue comes down to the differences in how the library editor was
> tracking the current item as opposed to how this is done in the
> schematic editor and pcbnew.  I posted a proposed patch to the bug
> report that harmonizes how the library editor handles its current item
> with the schematic editor and pcbnew.  This resolves the bug issue but
> it is fairly invasive in that is changes most of the command handling
> routines.
> 
> Thus my question:  Often these sorts of odd corners where one
> implementation is different exist historically for a reason.  Is there a
> reason that the current item handling in the library editor is different
> that I might be subtly breaking by ​pushing the current item tracking up
> to the base_screen? 
> 
> Thanks!
> Seth
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>