kicad-developers team mailing list archive
Mailing list archive
Re: GitHub Plugin (my nemesis)
I am no expert, but this question is out of the scope of this thread.. For downloading, gut applies compression anyway.
I respect the people having slow Internet lines.. However as shown a few posts backwards, the whole footprints and symbol library is like 100 megabytes without the 3d models. If think the benefit of a single repo outways the ability to download only a selection of libraries... By a LOT.
Am 2. Oktober 2017 10:22:10 MESZ schrieb Andrey Kuznetsov <kandrey89@xxxxxxxxx>:
>Is it possible to keep the 3d models ZIPed or RARed on disk and KiCAD
>unpacks them on the fly as needed/used during the session/etc?
>I am seeing 10x reduction in size when I pack the files whether they
>7.5MB or 120KB, both were reduced to 750KB and 10KB respectively.
>That's a lot of space wasted if we're thinking of the poor designers
>limited disk space.
>On Mon, Oct 2, 2017 at 1:03 AM, Carsten Schoenert
>> Am 02.10.2017 um 06:14 schrieb David Godfrey:
>> > Bernhard hit the nail on the head here.
>> > For normal Users, ALL of the git functionality should be hidden
>> > basic KiCad GUI features.
>> A "normal" user doesn't need any git functions. He expects to have a
>> working solution if he is using KiCad or $whatever software. The
>> part is on the software developers side, they need to take care about
>> full functional additional components for the normal users.
>> > However, for Users and Librarians that want to manage, add, edit at
>> > least a basic knowledge of whatever tooling is used behind the
>> > a HARD REQUIREMENT.
>> But such things are additional extras on the current situation. I
>> the intent of this whole thread was to improve the current situation
>> the library handling inside KiCad. I think this should be focused on
>> first as this increases the usability on the user side significantly.
>> > These days git is probably one of the best documented, and most
>> > supported in the greater community.
>> > That alone makes it a very good choice of backend.
>> > Handling of submodules can be slightly tricky, but a few simple
>> > scripts (for LedgerSMB project we use a Makefile with a few targets
>> > as "submodules" which updates all submodules to the current repo
>> > commit references to them)
>> Mhh, I never have seen that any body is really happy about git
>> submodules as they are always problematic. The reasons for this are
>> already written here in this thread.
>> I always look at the Linux kernel development model which is quite
>> larger and bigger than the KiCad project.
>> All parts in the development there don't use git submoduls for good
>> reasons. All people involved always use the full tree. Sorry, I don't
>> see a real need and gain for using git submoduls. And even if you
>> some scripting on top you need to teach the people how to use this.
>> is *always* overhead I'd avoid.
>> As written here also, a complete git repository about all of the
>> schematics with a stable and development branch and tagged releases
>> would be fine and enough. The l10n and documentation part is already
>> using this model.
>> Carsten Schoenert
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help : https://help.launchpad.net/ListHelp
>Remember The Past, Live The Present, Change The Future
>Those who look only to the past or the present are certain to miss the
>Live Long and Prosper,