Jeff, are you okay to implement these changes on top of this patch?


On 19 February 2018 at 20:16, Wayne Stambaugh <> wrote:
> 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 <
>>> <>> 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 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 <
>>>>> <>
>>>>> <>> 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 <
>>>>>>> <>
>>>>>>> <>> 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:
>>>> Post to     :
>>>> <>
>>>> Unsubscribe :
>>>> More help   :
>>> _______________________________________________
>>> Mailing list:
>>> Post to     :
>>> <>
>>> Unsubscribe :
>>> More help   :
> _______________________________________________
> Mailing list:
> Post to     :
> Unsubscribe :
> More help   :

Attachment: 0001-Improve-Footprint-Editor-menubar-hotkeys.patch
Description: Binary data

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to