kicad-developers team mailing list archive

[Roman Pavelka <roman.pavelka.asi@xxxxxxxxx>]

>> Very good work, screenshot in attachment...
>
> Thanks :) Is the footprint specifications overlapping other things
> something that's in the original design, or something eeshow did ?

That is OK, it is auto-generated circuit (from single instance make
multichannel)
and I did not implemented nice placement of text fields yet. It looks same
as
in eeschema...

>> Possible enhancements
>> * eeshow -h, eeshow --help prints usage
>
> But ... doesn't it do this ? Admittedly while complaining about
> the unrecognized option :)

You are right, but I consider these to be standard without complains.

>> * eeshow without parameters shows Open file dialog on start
>
> Hmm yes, some day I'll have to tackle that, too. I hate file
> dialogs (as a user), and haven't quite figured out yet how to
> properly use the ones in Gtk (as a developer) ...

This is of very low priority of course, but I remember it is pretty
straightforward:

https://developer.gnome.org/gtk3/stable/GtkFileChooserDialog.html

>> * accept a directory argument and find the *.pro to allow "eeshow ."
>>   - complain if more found
>
> Hmm, not sure if this is something eeshow needs to do. You're
> normally just a few keystrokes away from the *.pro anyway, and
> then you get a consistent interface, not one that changes
> depending on context (i.e., when there are > 1 *.pro).

Well, I sometimes have projects like below, so this can be nice shortcut.

├── 201606-Smart_fixture
│   ├── board
│   └── firmware
│       ├── bootloader
│       └── libs

>>   - implement multi project directory hierarchy browsing (beware of
>> both hard and symlinks lurking in the darkness of some filesystems, I
>> like to have them disabled to follow and option to enable them)
>
> Yes, this is something I eventually want to add. However, it
> depends on some infrastructure features that still need writing,
> e.g., the ability to more freely associate the pages used in a
> diff, and to somehow remember such choices.

I understand that primary motivation for your project is to quickly navigate
complicated schematics both in hierarchy (sch/subsch) and in time (git
commits)
and see the changes (visual git diff).

But I see there another use case, possibly with much bigger outreach: To be
able
to simply browse through your projects, i.e. you are looking for that LED
driver with
two adjustable voltage fan drivers buried in dozen of projects called
driver...oh my,
which one was that? :D

IMHO being able to be such a browser would be killer feature even without
git support and diffs.

> And yes, "links" are very interesting, be they in the form of
> symlinks or as relative paths in *.pro or a subsheet.
>
> E.g., assume two repos, /home/a and /home/b, and a path
> /home/a/foo where "foo" is a symlink, committed today, pointing
> to ../b/bar.pro
>
> When we follow this link, we find that /home/b/bar.pro is from
> last week, and the /home/a/foo from that time pointed somewhere
> else. What to do ?
>
> This may seem contrived, but it's quite easy to run into such
> things with libraries coming from a separate repo. This will be
> fun :)

I see you know this sort of fun too :)

My choice is usually to not follow, ignore and be safe by default,
with options both to follow only file links and then to follow directories
also.

Roman