However, in the last proposal the only change other than menus is to add a
Library selector to the New Footprint dialog.
> On 19 Feb 2018, at 17:39, Wayne Stambaugh <stambau...@gmail.com> 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.
>>> On 19 Feb 2018, at 13:21, Rene Pöschl <poesc...@gmail.com
>>> <mailto:poesc...@gmail.com <mailto:poesc...@gmail.com>>> 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 <poesc...@gmail.com
>>>>> <mailto:poesc...@gmail.com <mailto:poesc...@gmail.com>>> 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?
>>> 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 : firstname.lastname@example.org
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help : https://help.launchpad.net/ListHelp
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : email@example.com
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
Mailing list: https://launchpad.net/~kicad-developers
Post to : firstname.lastname@example.org
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp