kicad-developers team mailing list archive
Mailing list archive
Re: PlEditor issues
On 08/29/2013 08:02 AM, Wayne Stambaugh wrote:
> On 8/29/2013 2:16 AM, Lorenzo Marcantonio wrote:
>> On Wed, Aug 28, 2013 at 11:05:34PM +0100, Brian Sidebotham wrote:
>>> (4) When saving a page layout the .kicad_wks extension doesn't get added to
>>> the filename.
>> This is common to many file dialogs, by the way...
> This is a known problem with the GTK+ version wxWidgets 2.8. It's been
> this way since I got started with the project. I'm not sure it's been
> fixed in 2.9. The solution is to create a wxFileName object using the
> path returned from the file dialog and check if it has a file extension.
> If it doesn't, set the file extension to the appropriate value.
This is good behaviour to have in a dialog. "Extension enforcement."
We should do it more often. I vaguely remember adding it to the save board code (and its
a miracle that I remember), something like what Wayne is saying. For without that, the
user cannot know if he's working with a *.brd file or a *.kicad_pcb file, nor can KiCad
easily know next time loading.
But as I think of it now, just checking that it has an extension is probably not enough,
verifying that the extension is the correct one is more correct.
wxFileName may have the notion that the last segment after a period is the extension, when
in fact it could be part of a base filename with a period in it. So if perfection is desired:
Simply over writing the last thing falsely known as the extension within the wxFileName
would be munging the basename inappropriately. So maybe the best algorithm is to use
wxFileName to parse the filename, see if the extension *matches*, and if not, go back to
the original full filename string outside the wxFileName, and then concatonate the correct
extension. This leaves the user's full filename with more than one period in it.
Superimposing a restriction on base filenames seems inappropriate and unnecessary with the
>>> I noticed that even with the standard sheet, the legend expands to include
>>> space for all four comments. Has this always been the case? I thought that
>>> part of the page layout used to collapse if the comments weren't used and
>>> only expanded if they did?
>> Yes, initially it was so. However the new definition file can't describe
>> the 'move the line if there is no text' since that would need
> 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