Re: [Kicad-developers] Project save as

2019-11-12 Thread Eeli Kaikkonen
ti 12. marrask. 2019 klo 17.43 Jeff Young (j...@rokeby.ie) kirjoitti:

> FWIW, the old generated files are not outdated — the paths in them are
> updated.
>
>
I was thinking for example gerbers which often (usually?) have project name
and revision as graphics in some layer. Whatever the reason of using Save
As was, at least some layers are probably outdated and can't be used
without being regenerated after modifying the board file.

Eeli Kaikkonen
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-12 Thread Jeff Young
FWIW, the old generated files are not outdated — the paths in them are updated.

> On 11 Nov 2019, at 23:06, Eeli Kaikkonen  wrote:
> 
> 
> 
> ti 12. marrask. 2019 klo 0.02 Jon Evans (j...@craftyjon.com 
> ) kirjoitti:
> I question the value of creating this amount of complex UI around "save as".
> 
>  In that case I personally would prefer minimal functionality, copying only 
> the necessary project files. More likely than not the generated files aren't 
> needed or are outdated because of the name change (for example having the old 
> project name inside them). But if a large amount of files is renamed and 
> copied I would like to have control over it when it's done. Going though the 
> files afterwards is more difficult.
> 
> Anyways, renaming the necessary files of the project to form a new functional 
> project is the really needed feature and it's great to have it, with or 
> without complex additions.
> 
> Eeli Kaikkonen
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-11 Thread Eeli Kaikkonen
ti 12. marrask. 2019 klo 0.02 Jon Evans (j...@craftyjon.com) kirjoitti:

> I question the value of creating this amount of complex UI around "save
> as".
>

 In that case I personally would prefer minimal functionality, copying only
the necessary project files. More likely than not the generated files
aren't needed or are outdated because of the name change (for example
having the old project name inside them). But if a large amount of files is
renamed and copied I would like to have control over it when it's done.
Going though the files afterwards is more difficult.

Anyways, renaming the necessary files of the project to form a new
functional project is the really needed feature and it's great to have it,
with or without complex additions.

Eeli Kaikkonen
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-11 Thread Jon Evans
I guess ultimately this is up to Jeff since he's implementing it, but I
think this is going way above and beyond what any user should expect of an
application.  I have never used any software that tried this hard to handle
the "save as" feature without any chance of the user needing to take some
follow-up actions such as deleting old auto-generated files, etc.  I
question the value of creating this amount of complex UI around "save as".

On Mon, Nov 11, 2019 at 4:44 PM Eeli Kaikkonen 
wrote:

> Here's a rough idea of what a confirmation dialog could do:
>
> [image: image.png]
>
> I think something like that would be flexible enough to help the user with
> most workflows and left the responsibility to the user while being simple
> and easy enough to use (although a bit more work to implement, of course).
>
> Eeli Kaikkonen
>
> ma 11. marrask. 2019 klo 23.20 Jeff Young (j...@rokeby.ie) kirjoitti:
>
>> Limiting it to a dash is just because that’s all Kicad generates.  The
>> user could indeed use anything.
>>
>> So should we rename any file that starts with the old project name?  I
>> did have a version that did that, but it seemed too aggressive to me.
>>
>> On 11 Nov 2019, at 20:56, Eeli Kaikkonen 
>> wrote:
>>
>>
>>
>> ma 11. marrask. 2019 klo 22.41 Jeff Young (j...@rokeby.ie) kirjoitti:
>>
>>> Yes, the current algorithm renames files that either match the project
>>> name (with any extension), or start with the project name followed by a
>>> dash.
>>>
>>
>> Limiting the following character to dash seems arbitrary. Underscore is
>> used often, and why it should be limited at all?
>>
>> Here's one more possible solution. The current file dialog is kept, but
>> if any generated or unknown files which begin with the project name are
>> found, a new dialog asks if the user wants to rename and copy them or not
>> to copy them at all, or maybe copy them as is.
>>
>> On the other hand, what to do with other files which don't begin with the
>> project name? Should they be confirmed and copied (as is), too?
>>
>> What about the backup files?
>>
>> I can see two use cases: rename the project (replace the old one); and
>> copy the project to be a base for a new one. In the former case renaming
>> and keeping about everything could be desired. In the latter case all but
>> the basic project files would probably be ditched.
>>
>> In the case of renaming I'm also interested in knowing how it affects
>> version control, for example git, if the project is a repository. That must
>> be tested, I think.
>>
>> Eeli Kaikkonen
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-11 Thread Eeli Kaikkonen
Here's a rough idea of what a confirmation dialog could do:

[image: image.png]

I think something like that would be flexible enough to help the user with
most workflows and left the responsibility to the user while being simple
and easy enough to use (although a bit more work to implement, of course).

Eeli Kaikkonen

ma 11. marrask. 2019 klo 23.20 Jeff Young (j...@rokeby.ie) kirjoitti:

> Limiting it to a dash is just because that’s all Kicad generates.  The
> user could indeed use anything.
>
> So should we rename any file that starts with the old project name?  I did
> have a version that did that, but it seemed too aggressive to me.
>
> On 11 Nov 2019, at 20:56, Eeli Kaikkonen  wrote:
>
>
>
> ma 11. marrask. 2019 klo 22.41 Jeff Young (j...@rokeby.ie) kirjoitti:
>
>> Yes, the current algorithm renames files that either match the project
>> name (with any extension), or start with the project name followed by a
>> dash.
>>
>
> Limiting the following character to dash seems arbitrary. Underscore is
> used often, and why it should be limited at all?
>
> Here's one more possible solution. The current file dialog is kept, but if
> any generated or unknown files which begin with the project name are found,
> a new dialog asks if the user wants to rename and copy them or not to copy
> them at all, or maybe copy them as is.
>
> On the other hand, what to do with other files which don't begin with the
> project name? Should they be confirmed and copied (as is), too?
>
> What about the backup files?
>
> I can see two use cases: rename the project (replace the old one); and
> copy the project to be a base for a new one. In the former case renaming
> and keeping about everything could be desired. In the latter case all but
> the basic project files would probably be ditched.
>
> In the case of renaming I'm also interested in knowing how it affects
> version control, for example git, if the project is a repository. That must
> be tested, I think.
>
> Eeli Kaikkonen
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-11 Thread Jeff Young
Limiting it to a dash is just because that’s all Kicad generates.  The user 
could indeed use anything.

So should we rename any file that starts with the old project name?  I did have 
a version that did that, but it seemed too aggressive to me.

> On 11 Nov 2019, at 20:56, Eeli Kaikkonen  wrote:
> 
> 
> 
> ma 11. marrask. 2019 klo 22.41 Jeff Young (j...@rokeby.ie 
> ) kirjoitti:
> Yes, the current algorithm renames files that either match the project name 
> (with any extension), or start with the project name followed by a dash. 
> 
> Limiting the following character to dash seems arbitrary. Underscore is used 
> often, and why it should be limited at all?
> 
> Here's one more possible solution. The current file dialog is kept, but if 
> any generated or unknown files which begin with the project name are found, a 
> new dialog asks if the user wants to rename and copy them or not to copy them 
> at all, or maybe copy them as is.
> 
> On the other hand, what to do with other files which don't begin with the 
> project name? Should they be confirmed and copied (as is), too?
> 
> What about the backup files?
> 
> I can see two use cases: rename the project (replace the old one); and copy 
> the project to be a base for a new one. In the former case renaming and 
> keeping about everything could be desired. In the latter case all but the 
> basic project files would probably be ditched.
> 
> In the case of renaming I'm also interested in knowing how it affects version 
> control, for example git, if the project is a repository. That must be 
> tested, I think.
> 
> Eeli Kaikkonen
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-11 Thread Jeff Young
But even doing that is going to be more work, as they’re going to have to 
delete a whole pile of old files….

I have several old projects that I haven’t opened since the 4.0.x days.  I may 
want to move them, but regenerating the Gerbers wouldn’t necessarily generate 
the same files.  (It might if I was careful not to refill zones, but I’d still 
rather not find out, and if I knew less about the code I’d be even more 
reticent.)

> On 11 Nov 2019, at 20:42, Ian McInerney  wrote:
> 
> I agree, we should only be transferring and renaming the non-generated files 
> rather than trying to account for every possible file under the sun. If the 
> user wants the generated files, they can regenerate them from the new project.
> 
> -Ian
> 
> On Mon, 11 Nov 2019, 20:30 Jon Evans,  > wrote:
> In my opinion we should not rename any generated files.  This matches my 
> experience with other tools.
> 
> On Mon, Nov 11, 2019 at 3:28 PM Seth Hillbrand  > wrote:
> On 2019-11-11 11:42, Jeff Young wrote:
> 
> > A... I didn't notice that.  We are indeed failing to look for the 
> > Protel extensions.
> 
> Are we renaming generated files?  If we stick with base project files, 
> it's easy to explain where the cut-off is.  Once we go down into 
> generated files, this gets harder and harder especially as we start 
> implementing more exports (IPC-2581, D-365, XY files, etc) where we 
> don't control the extensions.
> 
> -Seth
> 
> 
> Seth Hillbrand
> KiCad Services Corporation
> https://www.kipro-pcb.com 
> +1 530 302 5483 | +1 212 603 9372
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-11 Thread Eeli Kaikkonen
ma 11. marrask. 2019 klo 22.41 Jeff Young (j...@rokeby.ie) kirjoitti:

> Yes, the current algorithm renames files that either match the project
> name (with any extension), or start with the project name followed by a
> dash.
>

Limiting the following character to dash seems arbitrary. Underscore is
used often, and why it should be limited at all?

Here's one more possible solution. The current file dialog is kept, but if
any generated or unknown files which begin with the project name are found,
a new dialog asks if the user wants to rename and copy them or not to copy
them at all, or maybe copy them as is.

On the other hand, what to do with other files which don't begin with the
project name? Should they be confirmed and copied (as is), too?

What about the backup files?

I can see two use cases: rename the project (replace the old one); and copy
the project to be a base for a new one. In the former case renaming and
keeping about everything could be desired. In the latter case all but the
basic project files would probably be ditched.

In the case of renaming I'm also interested in knowing how it affects
version control, for example git, if the project is a repository. That must
be tested, I think.

Eeli Kaikkonen
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-11 Thread Ian McInerney
I agree, we should only be transferring and renaming the non-generated
files rather than trying to account for every possible file under the sun.
If the user wants the generated files, they can regenerate them from the
new project.

-Ian

On Mon, 11 Nov 2019, 20:30 Jon Evans,  wrote:

> In my opinion we should not rename any generated files.  This matches my
> experience with other tools.
>
> On Mon, Nov 11, 2019 at 3:28 PM Seth Hillbrand  wrote:
>
>> On 2019-11-11 11:42, Jeff Young wrote:
>>
>> > A... I didn't notice that.  We are indeed failing to look for the
>> > Protel extensions.
>>
>> Are we renaming generated files?  If we stick with base project files,
>> it's easy to explain where the cut-off is.  Once we go down into
>> generated files, this gets harder and harder especially as we start
>> implementing more exports (IPC-2581, D-365, XY files, etc) where we
>> don't control the extensions.
>>
>> -Seth
>>
>>
>> Seth Hillbrand
>> KiCad Services Corporation
>> https://www.kipro-pcb.com
>> +1 530 302 5483 | +1 212 603 9372
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-11 Thread Jeff Young
Yes, the current algorithm renames files that either match the project name 
(with any extension), or start with the project name followed by a dash.  We 
don’t need to know the extension in either case.

This feels right to me, but I’m open to discussion.

Cheers,
Jeff.

> On 11 Nov 2019, at 20:29, Jon Evans  wrote:
> 
> In my opinion we should not rename any generated files.  This matches my 
> experience with other tools.
> 
> On Mon, Nov 11, 2019 at 3:28 PM Seth Hillbrand  > wrote:
> On 2019-11-11 11:42, Jeff Young wrote:
> 
> > A... I didn't notice that.  We are indeed failing to look for the 
> > Protel extensions.
> 
> Are we renaming generated files?  If we stick with base project files, 
> it's easy to explain where the cut-off is.  Once we go down into 
> generated files, this gets harder and harder especially as we start 
> implementing more exports (IPC-2581, D-365, XY files, etc) where we 
> don't control the extensions.
> 
> -Seth
> 
> 
> Seth Hillbrand
> KiCad Services Corporation
> https://www.kipro-pcb.com 
> +1 530 302 5483 | +1 212 603 9372
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-11 Thread Andy Peters

> On Nov 11, 2019, at 1:28 PM, Seth Hillbrand  wrote:
> 
> On 2019-11-11 11:42, Jeff Young wrote:
> 
>> A... I didn't notice that.  We are indeed failing to look for the Protel 
>> extensions.
> 
> Are we renaming generated files?  If we stick with base project files, it's 
> easy to explain where the cut-off is.  Once we go down into generated files, 
> this gets harder and harder especially as we start implementing more exports 
> (IPC-2581, D-365, XY files, etc) where we don't control the extensions.

Unless I’m mistaken, isn’t the use case for “Project Save As” to fork a new 
project from one that exists? In that case, the generated files, like Gerbers 
and the net list, are immediately invalid as soon as the user starts to make 
modifications to the project. Nobody keeps the .o files around after the 
application is built … 

And regarding the use of “Project Save As,” consider the plight of users who 
keep projects in a source-code control repository. I realize that this is a can 
of worms. 

-a
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-11 Thread Jon Evans
In my opinion we should not rename any generated files.  This matches my
experience with other tools.

On Mon, Nov 11, 2019 at 3:28 PM Seth Hillbrand  wrote:

> On 2019-11-11 11:42, Jeff Young wrote:
>
> > A... I didn't notice that.  We are indeed failing to look for the
> > Protel extensions.
>
> Are we renaming generated files?  If we stick with base project files,
> it's easy to explain where the cut-off is.  Once we go down into
> generated files, this gets harder and harder especially as we start
> implementing more exports (IPC-2581, D-365, XY files, etc) where we
> don't control the extensions.
>
> -Seth
>
>
> Seth Hillbrand
> KiCad Services Corporation
> https://www.kipro-pcb.com
> +1 530 302 5483 | +1 212 603 9372
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-11 Thread Seth Hillbrand

On 2019-11-11 11:42, Jeff Young wrote:

A... I didn't notice that.  We are indeed failing to look for the 
Protel extensions.


Are we renaming generated files?  If we stick with base project files, 
it's easy to explain where the cut-off is.  Once we go down into 
generated files, this gets harder and harder especially as we start 
implementing more exports (IPC-2581, D-365, XY files, etc) where we 
don't control the extensions.


-Seth


Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-11 Thread Jeff Young
A… I didn’t notice that.  We are indeed failing to look for the Protel 
extensions.

> On 11 Nov 2019, at 19:35, Eeli Kaikkonen  wrote:
> 
> ma 11. marrask. 2019 klo 20.39 Jeff Young (j...@rokeby.ie 
> ) kirjoitti:
> I want to address the Gerber issue first.  In this case Eeli was expecting 
> the old name to get updated if it occurred anywhere in the filename.  My 
> expectation was that it would only get updated if the file name started with 
> the old name.
> 
>  
> It's not that. It's reasonable to expect that the project name is in the 
> beginning of the file name, especially with KiCad generated files. Try Save 
> As with the attached project. I plotted the gerbers with and without protel 
> extensions. When I Save As with name "test_saveas_plotted" or something like 
> that it renames only part of the files.
> 
> Eeli Kaikkonen
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-11 Thread Jeff Young
Next for the folder or file question.

New project does indeed ask for the name of the project file and also asks if 
you want a directory auto-created.  I hate that, but I’ll admit it’s clearer 
than the Save As… case where you’re not sure which it’s asking for.

We have our own dialog for selecting folders for something. (3D paths?  
Import?)  While I can’t remember what, I do remember that it gets a lot of hate 
mail.

I’m open to suggestions.  (Including “just make it like New for now”.)

Cheers,
Jeff.


> On 11 Nov 2019, at 17:03, Eeli Kaikkonen  wrote:
> 
> More problems...
> 
> First, two complaints about error dialog. First, it's not resizable and the 
> file path text is shortened in the middle. Not good. Second, text can't be 
> copied (I think this is the case with all error dialogs? Very old and very 
> basic usability bug.)
> 
> 
> 
> The actual problem is that the file can't be copied for some reason. It's 
> inside the project folder in a project specific library. The project is 
> attached.
> 
> Eeli Kaikkonen
> 
> ma 11. marrask. 2019 klo 17.53 Eeli Kaikkonen (eeli.kaikko...@gmail.com 
> ) kirjoitti:
> I hope you don't mind I give some first impressions here. I can move these to 
> bug database if needed.
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-11 Thread Jeff Young
I want to address the Gerber issue first.  In this case Eeli was expecting the 
old name to get updated if it occurred anywhere in the filename.  My 
expectation was that it would only get updated if the file name started with 
the old name.

Either is easy to implement, but I’d rather not have a preference.  Is one much 
more likely to be expected than the other?

Cheers,
Jeff.

> On 11 Nov 2019, at 17:03, Eeli Kaikkonen  wrote:
> 
> More problems...
> 
> First, two complaints about error dialog. First, it's not resizable and the 
> file path text is shortened in the middle. Not good. Second, text can't be 
> copied (I think this is the case with all error dialogs? Very old and very 
> basic usability bug.)
> 
> 
> 
> The actual problem is that the file can't be copied for some reason. It's 
> inside the project folder in a project specific library. The project is 
> attached.
> 
> Eeli Kaikkonen
> 
> ma 11. marrask. 2019 klo 17.53 Eeli Kaikkonen (eeli.kaikko...@gmail.com 
> ) kirjoitti:
> I hope you don't mind I give some first impressions here. I can move these to 
> bug database if needed.
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-11 Thread Eeli Kaikkonen
ma 11. marrask. 2019 klo 18.07 Wayne Stambaugh (stambau...@gmail.com)
kirjoitti:

> Isn't this this the same behavior as File->New?  We should keep the path
> creation behavior consistent.
>

It should be possible to use the same customized dialog then, right? Now
it's different.

Eeli Kaikkonen
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-11 Thread Wayne Stambaugh
Isn't this this the same behavior as File->New?  We should keep the path
creation behavior consistent.

On 11/11/19 10:56 AM, Jon Evans wrote:
> FWIW, we are considering moving to the "create a folder for the project"
> to be a requirement rather than an option, in case that impacts this
> feature.
> Or rather, it would be a requirement that there be one KiCad project per
> folder, not necessarily that automatically creating a folder would be a
> requirement.
> 
> -Jon
> 
> On Mon, Nov 11, 2019 at 10:54 AM Eeli Kaikkonen
> mailto:eeli.kaikko...@gmail.com>> wrote:
> 
> I hope you don't mind I give some first impressions here. I can move
> these to bug database if needed.
> 
> Before trying it's unclear what the file dialog selects. I created a
> new directory (with the name of the new project), went inside it and
> gave the project name in the dialog. "All files *.*" filter was
> available there. That is a hint that we are talking about a file.
> However, KiCad created a new directory inside the selected one and
> placed the renamed files there. I would like to see unambiguous
> information about what KiCad is going to do.
> 
> In my opinion a dedicated dialog would be better. It would have:
> - A textbox and folder selection icon for the folder path.
> - A textbox for the new project name (only the name, no path, no
> file extensions).
> - Checkbox for "create a new folder with the project name". This
> would create a new folder inside the folder which was selected above.
> 
> Maybe it would be best to have checkboxes for "copy and rename
> generated and unknown files". My use case this time is that I'm
> going to reuse part of the old project as a template. None of the
> generated files, backups etc. are used there.
> 
> The current result is here (embedded picture). As you can see, it's
> uneven. Some gerber files were renamed, some not.
> (...Handle_Mainboard is the original name, ...TOF is the new).
> 
> image.png
> 
> Eeli Kaikkonen
> 
> su 10. marrask. 2019 klo 0.31 Jeff Young (j...@rokeby.ie
> ) kirjoitti:
> 
> He he… I know our users.  I can be sure of a bug report even if
> I get it right. ;)
> 
> 
> I never make reports about something which is done right :)
>  
> 
> > This is exactly why I never tackled this one.  Anytime your
> are trying
> > to deal with complex relative path changes, the code gets
> rather messy.
> > I doubt this will affect many users but you can be rest
> assured of a
> > bug report if you get it wrong.
> >
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-11 Thread Jon Evans
FWIW, we are considering moving to the "create a folder for the project" to
be a requirement rather than an option, in case that impacts this feature.
Or rather, it would be a requirement that there be one KiCad project per
folder, not necessarily that automatically creating a folder would be a
requirement.

-Jon

On Mon, Nov 11, 2019 at 10:54 AM Eeli Kaikkonen 
wrote:

> I hope you don't mind I give some first impressions here. I can move these
> to bug database if needed.
>
> Before trying it's unclear what the file dialog selects. I created a new
> directory (with the name of the new project), went inside it and gave the
> project name in the dialog. "All files *.*" filter was available there.
> That is a hint that we are talking about a file. However, KiCad created a
> new directory inside the selected one and placed the renamed files there. I
> would like to see unambiguous information about what KiCad is going to do.
>
> In my opinion a dedicated dialog would be better. It would have:
> - A textbox and folder selection icon for the folder path.
> - A textbox for the new project name (only the name, no path, no file
> extensions).
> - Checkbox for "create a new folder with the project name". This would
> create a new folder inside the folder which was selected above.
>
> Maybe it would be best to have checkboxes for "copy and rename generated
> and unknown files". My use case this time is that I'm going to reuse part
> of the old project as a template. None of the generated files, backups etc.
> are used there.
>
> The current result is here (embedded picture). As you can see, it's
> uneven. Some gerber files were renamed, some not. (...Handle_Mainboard is
> the original name, ...TOF is the new).
>
> [image: image.png]
>
> Eeli Kaikkonen
>
> su 10. marrask. 2019 klo 0.31 Jeff Young (j...@rokeby.ie) kirjoitti:
>
>> He he… I know our users.  I can be sure of a bug report even if I get it
>> right. ;)
>>
>>
> I never make reports about something which is done right :)
>
>
>> > This is exactly why I never tackled this one.  Anytime your are trying
>> > to deal with complex relative path changes, the code gets rather messy.
>> > I doubt this will affect many users but you can be rest assured of a
>> > bug report if you get it wrong.
>> >
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-11 Thread Eeli Kaikkonen
I hope you don't mind I give some first impressions here. I can move these
to bug database if needed.

Before trying it's unclear what the file dialog selects. I created a new
directory (with the name of the new project), went inside it and gave the
project name in the dialog. "All files *.*" filter was available there.
That is a hint that we are talking about a file. However, KiCad created a
new directory inside the selected one and placed the renamed files there. I
would like to see unambiguous information about what KiCad is going to do.

In my opinion a dedicated dialog would be better. It would have:
- A textbox and folder selection icon for the folder path.
- A textbox for the new project name (only the name, no path, no file
extensions).
- Checkbox for "create a new folder with the project name". This would
create a new folder inside the folder which was selected above.

Maybe it would be best to have checkboxes for "copy and rename generated
and unknown files". My use case this time is that I'm going to reuse part
of the old project as a template. None of the generated files, backups etc.
are used there.

The current result is here (embedded picture). As you can see, it's uneven.
Some gerber files were renamed, some not. (...Handle_Mainboard is the
original name, ...TOF is the new).

[image: image.png]

Eeli Kaikkonen

su 10. marrask. 2019 klo 0.31 Jeff Young (j...@rokeby.ie) kirjoitti:

> He he… I know our users.  I can be sure of a bug report even if I get it
> right. ;)
>
>
I never make reports about something which is done right :)


> > This is exactly why I never tackled this one.  Anytime your are trying
> > to deal with complex relative path changes, the code gets rather messy.
> > I doubt this will affect many users but you can be rest assured of a
> > bug report if you get it wrong.
> >
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-09 Thread Jeff Young
He he… I know our users.  I can be sure of a bug report even if I get it right. 
;)

> This is exactly why I never tackled this one.  Anytime your are trying
> to deal with complex relative path changes, the code gets rather messy.
> I doubt this will affect many users but you can be rest assured of a
> bug report if you get it wrong.
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-09 Thread Wayne Stambaugh
On 11/9/2019 2:18 PM, Jeff Young wrote:
> Hi Wayne,
> 
>> On 9 Nov 2019, at 19:05, Wayne Stambaugh  wrote:
>>
>> Hey Jeff,
>>
>> On 11/9/2019 12:06 PM, Jeff Young wrote:
>>> I’m working through the project Save As feature.
>>>
>>> I currently have it renaming the top-level files, updating the symbol and 
>>> footprint lib tables, updating paths in Gerber job files, and updating 
>>> paths and filenames in the netlist.  
>>>
>>> A couple of questions:
>>>
>>> 1) The netlist I’m handling is a .net file which contains s-expressions.  
>>> Are there other formats I need to worry about?  Do they also use .net, or 
>>> some other extension(s)?
>>
>> I don't think you need to copy files that are generated by KiCad such as
>> netlist, gerber, and 3D model files.  These can all be regenerated from
>> the new project.
> 
> Yeah, I thought about that (particularly in the case of a DRC report file).  
> I was sort of thinking it would be nice to keep them when we can, but not in 
> the case of the DRC (as we can’t guarantee that there aren’t non-discriminate 
> cases in the save-as algorithm, and we don’t want to certify a board as 
> having passed DRC in that case).
> 
>>
>>>
>>> 2) Mention was made of updating sheet paths in .sch files.  However, those 
>>> never refer to the top-level schematic, do they?  If other sheet paths are 
>>> absolute then we shouldn’t update them, and if they’re relative then we 
>>> don’t need to update them.  Or am I missing something?
>>
>> Relative paths will need to be updated if they are not contained in the
>> current project path and the new saved project path is at a different
>> branch depth in the path tree.  Example: a sheet schematic path is
>> ../some_other_path/some_other.sch and the project is saved to
>> ../one_node_deeper/project_saved_as/, the sheet schematic path would
>> have to be adjusted to ../../some_other_path/some_other.sch in order for
>> the schematic to load correctly.  This is the primary reason this
>> feature does not exist yet.  It's not as trivial as it would seem to
>> implement unless you don't care about breaking the saved as project.
> 
> I really don’t think we want to touch paths with “..” in them.  How do we 
> know the user isn’t cloning a whole tree, and that the target of the relative 
> path is also getting saved-as and they want to keep the relative path the 
> same?  We won’t generate that path automatically, so the user “owns” it.

This is exactly why I never tackled this one.  Anytime your are trying
to deal with complex relative path changes, the code gets rather messy.
 I doubt this will affect many users but you can be rest assured of a
bug report if you get it wrong.

> 
> Cheers,
> Jeff.
> 
>>
>>>
>>> 3) What about legacy schematic and/or board files?  Any paths in those?
>>
>> Any relative 3D model paths suffer from the same problem described
>> about.  I'm not sure the 3D path code allows for relative 3D model paths.
>>
>> That's all I can think of at the moment but that doesn't mean there are
>> not other issues that I've missed.
>>
>>>
>>> Thanks,
>>> Jeff.
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-09 Thread Jeff Young
Hi Wayne,

> On 9 Nov 2019, at 19:05, Wayne Stambaugh  wrote:
> 
> Hey Jeff,
> 
> On 11/9/2019 12:06 PM, Jeff Young wrote:
>> I’m working through the project Save As feature.
>> 
>> I currently have it renaming the top-level files, updating the symbol and 
>> footprint lib tables, updating paths in Gerber job files, and updating paths 
>> and filenames in the netlist.  
>> 
>> A couple of questions:
>> 
>> 1) The netlist I’m handling is a .net file which contains s-expressions.  
>> Are there other formats I need to worry about?  Do they also use .net, or 
>> some other extension(s)?
> 
> I don't think you need to copy files that are generated by KiCad such as
> netlist, gerber, and 3D model files.  These can all be regenerated from
> the new project.

Yeah, I thought about that (particularly in the case of a DRC report file).  I 
was sort of thinking it would be nice to keep them when we can, but not in the 
case of the DRC (as we can’t guarantee that there aren’t non-discriminate cases 
in the save-as algorithm, and we don’t want to certify a board as having passed 
DRC in that case).

> 
>> 
>> 2) Mention was made of updating sheet paths in .sch files.  However, those 
>> never refer to the top-level schematic, do they?  If other sheet paths are 
>> absolute then we shouldn’t update them, and if they’re relative then we 
>> don’t need to update them.  Or am I missing something?
> 
> Relative paths will need to be updated if they are not contained in the
> current project path and the new saved project path is at a different
> branch depth in the path tree.  Example: a sheet schematic path is
> ../some_other_path/some_other.sch and the project is saved to
> ../one_node_deeper/project_saved_as/, the sheet schematic path would
> have to be adjusted to ../../some_other_path/some_other.sch in order for
> the schematic to load correctly.  This is the primary reason this
> feature does not exist yet.  It's not as trivial as it would seem to
> implement unless you don't care about breaking the saved as project.

I really don’t think we want to touch paths with “..” in them.  How do we know 
the user isn’t cloning a whole tree, and that the target of the relative path 
is also getting saved-as and they want to keep the relative path the same?  We 
won’t generate that path automatically, so the user “owns” it.

Cheers,
Jeff.

> 
>> 
>> 3) What about legacy schematic and/or board files?  Any paths in those?
> 
> Any relative 3D model paths suffer from the same problem described
> about.  I'm not sure the 3D path code allows for relative 3D model paths.
> 
> That's all I can think of at the moment but that doesn't mean there are
> not other issues that I've missed.
> 
>> 
>> Thanks,
>> Jeff.
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Project save as

2019-11-09 Thread Wayne Stambaugh
Hey Jeff,

On 11/9/2019 12:06 PM, Jeff Young wrote:
> I’m working through the project Save As feature.
> 
> I currently have it renaming the top-level files, updating the symbol and 
> footprint lib tables, updating paths in Gerber job files, and updating paths 
> and filenames in the netlist.  
> 
> A couple of questions:
> 
> 1) The netlist I’m handling is a .net file which contains s-expressions.  Are 
> there other formats I need to worry about?  Do they also use .net, or some 
> other extension(s)?

I don't think you need to copy files that are generated by KiCad such as
netlist, gerber, and 3D model files.  These can all be regenerated from
the new project.

> 
> 2) Mention was made of updating sheet paths in .sch files.  However, those 
> never refer to the top-level schematic, do they?  If other sheet paths are 
> absolute then we shouldn’t update them, and if they’re relative then we don’t 
> need to update them.  Or am I missing something?

Relative paths will need to be updated if they are not contained in the
current project path and the new saved project path is at a different
branch depth in the path tree.  Example: a sheet schematic path is
../some_other_path/some_other.sch and the project is saved to
../one_node_deeper/project_saved_as/, the sheet schematic path would
have to be adjusted to ../../some_other_path/some_other.sch in order for
the schematic to load correctly.  This is the primary reason this
feature does not exist yet.  It's not as trivial as it would seem to
implement unless you don't care about breaking the saved as project.

> 
> 3) What about legacy schematic and/or board files?  Any paths in those?

Any relative 3D model paths suffer from the same problem described
about.  I'm not sure the 3D path code allows for relative 3D model paths.

That's all I can think of at the moment but that doesn't mean there are
not other issues that I've missed.

> 
> Thanks,
> Jeff.
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp