Rename of libedit aliases from tree

[Stephen Bernhoeft]

EESchema, Component Library Editor | Edit Component Properties | Alias
At present it is impossible to "edit" aliases. To "edit" an exiting entry one must delete the entry, then re-enter the amended details.
Better if each entry was editable.

[Stephen Bernhoeft (reg-abelgratis)]

I've just come across this annoyance again - when I started to add the Wishlist, the sytem reminded me of my previous report.

It looks like "easy, but low priority". Is that right?

Q: Do the older reports (like this one) get reviewed?

[Wayne Stambaugh (stambaughw)]

I have this on my list. It's just such a low priority that I don't know
when I'll get to it. I agree with your original assessment that you
should be able to direct edit the text in the control rather than using
the add/delete buttons.

On 1/14/2015 5:25 AM, Stephen Bernhoeft wrote:
> I've just come across this annoyance again - when I started to add the
> Wishlist, the sytem reminded me of my previous report.
>
> It looks like "easy, but low priority". Is that right?
>
> Q: Do the older reports (like this one) get reviewed?
>

[Stephen Bernhoeft (reg-abelgratis)]

Thanks for the update Wayne. I don't know if the same issue does crop up elsewhere - but if it does, I think the priority should (then) be raised a little.

[Wayne Stambaugh (stambaughw)]

Your welcome. As always, there is more to do than I have time to get
done. Right now I am prioritizing things for the next stable release
which means fixing bugs first then if time permits look at wishlist items.

On 1/14/2015 12:57 PM, Stephen Bernhoeft wrote:
> Thanks for the update Wayne. I don't know if the same issue does crop up
> elsewhere - but if it does, I think the priority should (then) be raised
> a little.
>

[Jeff Young (jeyjey)]

I played around with this a bit, and wxWidgets in-place-editing is a real pain. We'd need to wrap up some of there stuff in classes of our own to handle sizing, event processing, etc.

I also don't think it makes sense to support in-place-editing here before things like the pin table, the libedit component tree, etc.

All that being said, an Edit button would certainly be easier than Delete / Add....

[Jeff Young (jeyjey)]

Note: must be committed AFTER patch in https://bugs.launchpad.net/kicad/+bug/1744656

[Maciej Suminski (orsonmmz)]

I tested and read the patch and it seems fine to me. I am not really sure whether we should treat it as a new feature, so I will leave the decision to Wayne. In case he agrees, I attach a rebased patch, as I modified slightly the patch from lp:1744656 before committing.

[Maciej Suminski (orsonmmz)]

Apologies, this is the patch I meant.

[Wayne Stambaugh (stambaughw)]

@Jeff, this patch no longer cleanly applies. Please rebase it when you get a chance so I can apply it for testing. Thanks.

[Wayne Stambaugh (stambaughw)]

@Jeff, never mind. Wrong patch!

[Jeff Young (jeyjey)]

@Wayne, while rebasing (I got your second message too late) I had merge conflicts in:

"Fix code review issues in exchange footprints dialog" [1]

So if you could commit that before it needs rebasing then I won't ever have to sort out the merge. :)

[1] https://bugs.launchpad.net/kicad/+bug/1466857

[Wayne Stambaugh (stambaughw)]

I just tested this patch and there is something strange going on here. When I edit an existing symbol alias, it triggers an immediate library save which fails if you are messing around with read only libraries. I don't now if this is directly related to this patch but the symbol library file save shouldn't happen until the user expressly saves the edits.

On a related note, there is a bug report that is indirectly related to this which I commented on earlier. I would rather we just completely get rid of the add/remove/edit/remove all buttons and just use the edit list control directly to edit the list of aliases. Why we feel the need to open a dozen dialogs to edit something that could be done in place is mind boggling to me.

[Jeff Young (jeyjey)]

He he... because wxWidgets in-place editing is not ready for prime-time. See comment #5.

(It could be done, mind you. It's just that we'd have to write a bunch of it on top of wxWidgets.)

[KiCad Janitor (kicad-janitor)]

Fixed in revision f88c4ccb0277a2944cf5f0b5a4f2df000669df62
https://git.launchpad.net/kicad/patch/?id=f88c4ccb0277a2944cf5f0b5a4f2df000669df62

[Wayne Stambaugh (stambaughw)]

@Jeff, I pushed this patch. Interestingly, all have to do is open the
symbol library editor and when I go to close it, it complains about not
being able to write the project symbol library table which makes no
sense. Why would the project symbol library table be written when
closing the symbol editor?

On 01/27/2018 11:22 AM, Jeff Young wrote:
> @Wayne, while rebasing (I got your second message too late) I had merge
> conflicts in:
>
> "Fix code review issues in exchange footprints dialog" [1]
>
> So if you could commit that before it needs rebasing then I won't ever
> have to sort out the merge. :)
>
> [1] https://bugs.launchpad.net/kicad/+bug/1466857
>

[Wayne Stambaugh (stambaughw)]

That figures. Oh well, maybe the version of wx will make our lives
easier. Not holding my breath on that one.

On 01/27/2018 01:10 PM, Jeff Young wrote:
> He he... because wxWidgets in-place editing is not ready for prime-time.
> See comment #5.
>
> (It could be done, mind you. It's just that we'd have to write a bunch
> of it on top of wxWidgets.)
>

[Jeff Young (jeyjey)]

Odd; I can’t reproduce this on OSX. I tried opening the symbol library editor from the project (main KiCad app) and from a schematic (which was in turn opened from the project). Is there some other way you’re getting to it?

> On 28 Jan 2018, at 00:28, Wayne Stambaugh <email address hidden> wrote:
>
> @Jeff, I pushed this patch. Interestingly, all have to do is open the
> symbol library editor and when I go to close it, it complains about not
> being able to write the project symbol library table which makes no
> sense. Why would the project symbol library table be written when
> closing the symbol editor?
>

[Wayne Stambaugh (stambaughw)]

@Jeff, are you sure the project symbol library table is not being rewritten. The reason I am getting an error is that is trying to write to a read only project path. If you have write permission to the project path, then you wouldn't see this error. Try opening the symbol library editor and closing it and check if the project sym-lib-table file time stamp has changed.

[Jeff Young (jeyjey)]

@Wayne, yes, you're right, it was being updated.

This commit:

https://github.com/KiCad/kicad-source-mirror/commit/dfcd42f5ef7a04dd09ee5598d58434a9dbc638a8

saves the table if saveAllLibraries() returns true. But saveAllLibraries() returns true if either (a) none are dirty, or (b) the user answers either "yes" or "no" to they "save libraries?" dialog. It only returns false if the user answers "cancel" and the window should be left open.

I'd assume this was an oversight, but Orson committed both routines on the same day, which makes me think maybe not....

[Wayne Stambaugh (stambaughw)]

@Orson, can you elaborate on why the symbol library table is always
being saved when the symbol library editor is closed. I would think the
only time this would happen is when the user added a new library to the
project.

On 01/28/2018 12:04 PM, Jeff Young wrote:
> @Wayne, yes, you're right, it was being updated.
>
> This commit:
>
> https://github.com/KiCad/kicad-source-
> mirror/commit/dfcd42f5ef7a04dd09ee5598d58434a9dbc638a8
>
> saves the table if saveAllLibraries() returns true. But
> saveAllLibraries() returns true if either (a) none are dirty, or (b) the
> user answers either "yes" or "no" to they "save libraries?" dialog. It
> only returns false if the user answers "cancel" and the window should be
> left open.
>
> I'd assume this was an oversight, but Orson committed both routines on
> the same day, which makes me think maybe not....
>

[Maciej Suminski (orsonmmz)]

Wayne, you are right. I modified the code to save sym-lib-table only when a library is added (either existing or new).

[Wayne Stambaugh (stambaughw)]

@Orson, the problem is that that is being saved even when nothing is modified so if the project is in a read-only folder, you get an error every time you close the symbol editor. The symbol library table should only be saved if libraries are added and/or removed. Do you want me to file a separate bug report?

[Maciej Suminski (orsonmmz)]

Wayne, I have not expressed myself clearly enough. I agreed that sym-lib-table should only be saved when you add/remove a library, therefore I changed to code to follow your recommendation (commit 0668cd9d).

[Wayne Stambaugh (stambaughw)]

Thanks for the quick fix!

On 1/31/2018 8:29 AM, Maciej Suminski wrote:
> Wayne, I have not expressed myself clearly enough. I agreed that sym-
> lib-table should only be saved when you add/remove a library, therefore
> I changed to code to follow your recommendation (commit 0668cd9d).
>