kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

I'm fine with this change.  What kind of time frame are we talking
about?  I can push this off to rc2 if necessary.  As soon as Orson
pushes his Eagle label fix, I'm going branch v5 and tag rc1.  Whatever
is left will have to go into rc2.  I'm also going to push the UI string
freeze to rc2 since there is obviously more UI work being done than I
expected.

Cheers,

Wayne

On 2/19/2018 12:56 PM, Jeff Young wrote:
> Understood, Wayne.
> 
> However, in the last proposal the only change other than menus is to add
> a Library selector to the New Footprint dialog.
> 
> Cheers,
> Jeff.
> 
> 
>> On 19 Feb 2018, at 17:39, Wayne Stambaugh <stambaughw@xxxxxxxxx
>> <mailto:stambaughw@xxxxxxxxx>> wrote:
>>
>> This is starting to blur the line between bug fixing and bike shedding.
>> I have no great fondness for the current library metaphor either but we
>> are talking about making significant changes in the way the footprint
>> library editor works.  I really don't want to make too many changes here
>> because we are going to rework the footprint library editor to behave
>> like the symbol library editor at some point in the future.  If we
>> continue at this rate, version 5 will never get released.  I'm fine with
>> minor tweaks to menu and toolbar layouts but changes in behavior need to
>> be justified as to why I should risk allowing the stable 5 release to
>> slip to accommodate these changes.
>>
>> On 2/19/2018 9:16 AM, Jeff Young wrote:
>>> I logged https://bugs.launchpad.net/kicad/+bug/1750374 for the
>>> (non-intentional) removal of library filters.
>>>
>>> I imagine we’ll fix that in the Place Symbol browser.  Since we don’t
>>> have a Place Footprint browser yet (not to be confused with the current
>>> Footprint Viewer we use in that context), removal of the active library
>>> concept no longer sounds like a 5.0 thing.
>>>
>>> However, that’s no reason to leave it as Byzantine as it currently is.
>>>  A footprint belongs to a Library.  It doesn’t matter what the active
>>> library is.  If you Save, it gets saved in its library.  If you do a
>>> New, you need to tell it what library to put it in.  If you want to move
>>> it to a different library we’ll add a Save As… (with a New… button in it
>>> similar to the filesystem’s New Folder, which will allow us to dump Save
>>> in a New Library… item).
>>>
>>> And we’ll need to put Set Active Library… back at the top and not treat
>>> it like it is an Open Library… command.  (We already messed that up with
>>> the icons, but if we move New Library to the Save As… and Set Active
>>> Library… dialogs then we can dispose of it on the toolbar and in the
>>> menus.)
>>>
>>> It’s a bit involved, but I think it will make a huge improvement.
>>>
>>> Thoughts?
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>> On 19 Feb 2018, at 13:21, Rene Pöschl <poeschlr@xxxxxxxxx
>>>> <mailto:poeschlr@xxxxxxxxx>
>>>> <mailto:poeschlr@xxxxxxxxx>> wrote:
>>>>
>>>> On 19/02/18 13:16, Jeff Young wrote:
>>>>> Hi Rene,
>>>>>
>>>>> Comments in-line:
>>>>>
>>>>>> On 19 Feb 2018, at 12:07, Rene Pöschl <poeschlr@xxxxxxxxx
>>>>>> <mailto:poeschlr@xxxxxxxxx>
>>>>>> <mailto:poeschlr@xxxxxxxxx>> wrote:
>>>>>>
>>>>>> On 19/02/18 12:14, Jeff Young wrote:
>>>>>>> The Open / List All button is much faster on all libraries than it
>>>>>>> used to be, and it’s a bit of a step-child to Search by Keyword and
>>>>>>> Select by Browser anyway.
>>>>>>>
>>>>>>> So, I’m going to propose that we add a Library selection widget to
>>>>>>> New Footprint..., Export Library... and Save As... and otherwise
>>>>>>> abandon the active library concept.
>>>>>> If you remove the active library concept from the "list all" stuff
>>>>>> then you might want to add a way to filter (by library) after that
>>>>>> dialog opened.
>>>>>> The live filtering of the list all dialog is much more powerful then
>>>>>> the filter by keyword button. (I personally never use the search by
>>>>>> keyword feature as i in most cases know in what lib a footprint
>>>>>> resides. Otherwise i can use search all without having an active lib.)
>>>>> I have no issue against this in principal, but why not just use the
>>>>> Select by Browser then?  It’s not only got the by-library
>>>>> organisation, but it has better filtering across libraries, and it
>>>>> shows nice images.
>>>>>
>>>>> Hmmm… I suppose the Browser is missing the Filter option….
>>>>
>>>> For both the lib and footprint ;) (See next point)
>>>>>
>>>>>> One use-case where filtering by a specific lib might be helpful is
>>>>>> library maintenance. The maintainer might have multiple different
>>>>>> versions of the same lib in their system. (I have three copies of
>>>>>> the footprint library added to my review project. Differentiated by
>>>>>> a prefix to the library nickname. Results in >300 libs active in
>>>>>> this project.)
>>>>>>
>>>>>> The save button should also have a way to remember in which lib the
>>>>>> currently edited footprint resides and offer a one click save. (Fill
>>>>>> out the target lib and footprint name such that by default the
>>>>>> current footprint is overwritten.)
>>>>>> The use-case for "i want to edit a footprint" is much more common
>>>>>> then "i want to copy a footprint to a different lib/name". (At least
>>>>>> for me.)
>>>>> Indeed, that’s the root motivation behind getting rid of the active
>>>>> library concept.
>>>>
>>>> To clarify: i use the select active lib dialog to filter the lib name
>>>> (it has live filtering of library names which the footprint browser
>>>> lacks) This allows me to reduce the set of libs from >300 to ~3 in
>>>> most cases. (example entering JST results in a list of the 3 different
>>>> versions of the Connector_JST lib i have on my system. For a normal
>>>> user it would result in one lib.)
>>>>
>>>> After that, the list all dialog allows filtering for footprints (in
>>>> the active lib)
>>>> To continue the JST example: Entering 1x02 will lists all JST single
>>>> row connectors with two pins. (If either filtering option is missing,
>>>> this use-case becomes a lot harder.)
>>>>>> A bonus would be if the selection of the target lib is made easy via
>>>>>> some live filtering option. (The official lib already has >100
>>>>>> footprint libs)
>>>>>>
>>>>>> And please do not remove the lib browser! This is the only way of
>>>>>> checking a large number of footprints in a fast way. This feature
>>>>>> has already been removed for symbols. (By removing the symbol
>>>>>> selector with the preview.) Don't make the same mistake on the
>>>>>> footprint side.
>>>>> Could you say more about this?  Do you mean the Footprints view in
>>>>> the Symbol Selector?  (You can re-enable that through preferences.)
>>>>>  Or something else?
>>>>>
>>>>> Cheers,
>>>>> Jeff.
>>>>>
>>>> I fear this might be considered derailing the conversation. (It has
>>>> currently nothing to do with footprints.) I just miss a way to browse
>>>> symbols in a fast manner (use the arrow keys to see a preview of many
>>>> symbols in a short amount of time)
>>>>
>>>> This has been previously provided by the select symbol dialog in the
>>>> symbol editor. (To emulate this behavior in the tree view, one would
>>>> need a way to filter the available symbol libs and a way to navigate
>>>> symbols in that lib by using arrow keys. Plus fast symbol preview
>>>> without further user action.)
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>