Hi,
On 04/12/2018 06:41 PM, Michael Frank wrote:
> I have just been observing this thread for a while and I’m wondering if
> (at least for *nix implementations) installing the files into a version
> specific sub-tree and putting links into the “unix/linux way”
> directories might be a solution
I have just been observing this thread for a while and I’m wondering if (at
least for *nix implementations) installing the files into a version specific
sub-tree and putting links into the “unix/linux way” directories might be a
solution - having a simple script change the links to enable a
Am 12.04.18 um 18:33 schrieb Reece R. Pollack:
> Yes, I'm going a bit off the original topic. Maybe we should start a new
> thread. But I see an issue arising in the future where people are going
> to want to install V5 but not give up V4 quite yet. For example, board
> houses that accept
On 04/12/18 11:38, Nick Østergaard wrote:
Den tor. 12. apr. 2018 17.18 skrev Reece R. Pollack >:
On 04/12/18 09:58, Carsten Schoenert wrote:
Hi,
Am 12.04.2018 um 15:47 schrieb Reece R. Pollack:
I'm a relative newbie to KiCad, but I've
Am 12.04.18 um 17:18 schrieb Reece R. Pollack:
> The KiCad 4.0.7 Debian Linux package installs files in these directories:
>
> /etc/profile.d
> /usr/bin
> /usr/lib/kicad
> /usr/lib/python2.7/dist-packages
> /usr/share/applications
> /usr/share/doc
> /usr/share/icons
> /usr/share/kicad
>
Is it usefull ?
Yes! Thank you ver much. I like to report bugs against nightly but don’t
always have time to compile and I need a fairly stable KiCad for other
work. I switched away from your daily ppa (ppa-kicad) since the schematic
lib table changes hit because I didn’t have time to deal with
Den tor. 12. apr. 2018 17.18 skrev Reece R. Pollack :
> On 04/12/18 09:58, Carsten Schoenert wrote:
>
> Hi,
>
> Am 12.04.2018 um 15:47 schrieb Reece R. Pollack:
>
> I'm a relative newbie to KiCad, but I've been a software engineer since
> the early 1980. I'd prefer to see KiCad
On 04/12/18 09:58, Carsten Schoenert wrote:
Hi,
Am 12.04.2018 um 15:47 schrieb Reece R. Pollack:
I'm a relative newbie to KiCad, but I've been a software engineer since
the early 1980. I'd prefer to see KiCad installed in a self-contained
manner, meaning all installed files end up under one
On 12/04/18 21:49, Jean-Samuel Reynaud wrote:
Perhaps this name should be configurable ("overridable" ?) by an env
variable ?
Yes I think so too. We have two proposals so far, an environment
variable, or a command line switch. Either or both would work. But
both are creeping the scope and
Hi,
Am 12.04.2018 um 15:47 schrieb Reece R. Pollack:
> I'm a relative newbie to KiCad, but I've been a software engineer since
> the early 1980. I'd prefer to see KiCad installed in a self-contained
> manner, meaning all installed files end up under one directory hierarchy
> rather than being
Perhaps this name should be configurable ("overridable" ?) by an env
variable ?
Le 12/04/2018 à 15:29, Strontium a écrit :
> kicad5
> kicad6
> etc etc works for me. I am not wedded to my suggestion, it was
> illustrative only.
>
> For backward compatibility, "kicad" would be for kicad4 because
I'm a relative newbie to KiCad, but I've been a software engineer since
the early 1980. I'd prefer to see KiCad installed in a self-contained
manner, meaning all installed files end up under one directory hierarchy
rather than being spread all over the filesystem. This is how Xilinx
ISE,
kicad5
kicad6
etc etc works for me. I am not wedded to my suggestion, it was
illustrative only.
For backward compatibility, "kicad" would be for kicad4 because that's
what it uses now, so there would be no "kicad4".
I agree that a user selectable configuration directory would be useful
I would pretty much vote to use the IMO more common naming scheme for major
package versions:
kicad (the current one installed from the repository of your choice)
kicad4 (currently: 4.0.7)
kicad5 (currently: 5.0.0-rc2-dev...)
kicad6 (tbd.)
...avoiding the ".v5" i've seen lately.
I believe
After considering my patch, what about the following proposal:
Just change the hard coded string in common.cpp (at around line 243) from:
cfgpath.AppendDir( wxT( "kicad" ) );
to
cfgpath.AppendDir( wxT( "kicad.v5" ) );
(or some other string)
Thats it. Then Kicad Version 5 will have a unique
Hell Carsten,
On 08/04/18 13:33, Carsten Schoenert wrote:
Am 07.04.18 um 17:34 schrieb Strontium:
Attached is a patch for discussion only.
Its the minimum change I could come up with to implement a unique
version specific config directory.
Nick mentioned changing XDG_CONFIG_HOME, that will
Am 07.04.18 um 17:34 schrieb Strontium:
> Attached is a patch for discussion only.
>
> Its the minimum change I could come up with to implement a unique
> version specific config directory.
>
> Nick mentioned changing XDG_CONFIG_HOME, that will not work on Windows
> or Mac.
> And on Linux, etc
Attached is a patch for discussion only.
Its the minimum change I could come up with to implement a unique
version specific config directory.
Nick mentioned changing XDG_CONFIG_HOME, that will not work on Windows
or Mac.
And on Linux, etc it will change from "~/.config/kicad" to
Does it make sense to include the major version in the package name as well,
just to give it a grab handle?
kicad4-4.0.7
kicad5-5.0.0
kicad5-nightly
See qt, gtk, ...
Regards,
Clemens
On 2018-04-06 08:01, Strontium wrote:
> Hi Wayne,
>
> I agree with you about scope creep, however I do see
Hi,
As for freecad I think it is a great idea to have v5 and kicad-nightly.
Cheers
Fabrizio
On Apr 6, 2018 8:02 AM, "Strontium" wrote:
> Hi Wayne,
>
> I agree with you about scope creep, however I do see issues for users.
>
> From an end user perspective V5 is a big
Hi Wayne,
I agree with you about scope creep, however I do see issues for users.
From an end user perspective V5 is a big change. I noticed big changes
just from missing nightly updates for 2 months. There may be an
extended period of time when a user will want to run both versions, for
We should defer this to v6 unless the fix is simple with little or no
risk of introducing new bugs. I know it would be nice to have but I
could say that about a lot of things. Scope creep will prevent us from
ever delivering v5.
Cheers,
Wayne
On 4/5/2018 12:25 PM, Seth Hillbrand wrote:
> If
On Thu, Apr 5, 2018 at 9:25 AM, Seth Hillbrand
wrote:
> If we are going to support multiple versions, on the developer side, we
> should add a preference versioning to the user configuration directory.
> Otherwise, fp-lib-table will being either pointing to v4 or v5
Le 05/04/2018 à 18:41, Nick Østergaard a écrit :
> This is a complicated topic. But I guess we can clutter the config dir as
> much as we want with
> version folders. Usually the user should not have the need to look here. I
> guess you are correct,
> that most of the "non-issue" is because the
This is a complicated topic. But I guess we can clutter the config dir as
much as we want with version folders. Usually the user should not have the
need to look here. I guess you are correct, that most of the "non-issue" is
because the fp-lib-table was only introduced in v4 and has not had a new
If we are going to support multiple versions, on the developer side, we
should add a preference versioning to the user configuration directory.
Otherwise, fp-lib-table will being either pointing to v4 or v5 footprints.
Likewise, there are a few preferences that only exist in v5 and will be
lost
On 04/04/18 18:52, Jean-Samuel Reynaud wrote:
So my questions are:
- Is it usefull ?
Having both versions be able to be installed side by side is immensely
valuable for an end user, and the development of kicad, in my opinion.
The users can "USE" the stable version for their work. They can
You can just set a different XDG_CONFIG_HOME. I think this should be left
for the user to define. Usually I have seen no significant problems running
with the same config dir. This may of course not aleays be true.
Alternatively the nightly package can provide a wrapper script that sets
this to
There might be a conflict in the settings (V4 might not be able to parse V5
settings)I've filed a bug addressing this (feature request):
https://bugs.launchpad.net/kicad/+bug/1749659
Also using V5 libs can be problematic in V4. One great thing is that at least
in the latest V4 (4.0.7) there is
I can confirm that many users would appreciate the possibility to run
several precompiled versions. It has come up in the user forums. Using a
virtual machine for that purpose has been suggested as a solution, but it's
not very convenient.
One possible problem is the configuration compatibility.
>
> If you think the package is ready to be tested by a wider group, how
> about announcing it on the kicad.info forum [1]? If you do not have an
> account there, I can post a notice there for you.
Thanks. I think I will post a message in few days if I collect more
comments. As Nick say, I think
>
> No, but I may personally prefer the term nightly over daily to be
> consistent with the terminology we have been using for quite some time.
>
Ok, I will change that before communicating...
>
> - If you test it, are you able to find some limitations/bugs ?
>
>
> I am not sure how you
2018-04-04 12:52 GMT+02:00 Jean-Samuel Reynaud :
> Dear All,
>
>
> Since I provide PPA (daily build for Ubuntu) for KiCad, I receive some
> requests about installing daily build packages in parallel with stable
> version.
> With next version (V5) I think it can be useful...
Hi Jean-Samuel,
I suppose most people on the dev mailing list compile KiCad themselves,
but I am pretty sure the users would appreciate the possibility of
having two KiCad versions installed.
If you think the package is ready to be tested by a wider group, how
about announcing it on the
34 matches
Mail list logo