← Back to team overview

kicad-developers team mailing list archive

Re: Project file '' not found on first execution of Kicad

 

Hi everyone,

Attached is a patch that quiets the noname.pro error in the situation that
the last history item isn't loadable, as well as on first load of kicad on
a machine where the history doesn't exist yet.

If someone could test on Linux in both of those cases, that'd be awesome.
Thanks!


Adam Wolf
Cofounder and Engineer
W&L

On Mon, Jan 5, 2015 at 10:49 AM, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>
wrote:

> The only time I have a strong preference is on first load--when you have
> no preference files or anything.  Then I really, really, don't want to show
> an error message.  I'm fine if we show a message, but I don't want the word
> "error" or red or exclamation points or 'warning" to pop up.
>
> I will take this on, and post a patch that should quiet the popups for
> noname.pro.
>
> Adam Wolf
> Cofounder and Engineer
> W&L
>
> On Mon, Jan 5, 2015 at 9:21 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
> wrote:
>
>> On 1/5/2015 9:43 AM, Adam Wolf wrote:
>> > Thanks for the insight, Wayne.  This is exactly what I was hoping to get
>> > out of my too long email.
>> >
>> > I will investigate what happens now in that case.
>> >
>> > In the case of "kicad was opened without a path/to/project.pro
>> > <http://project.pro> and doesn't have a valid history entry we can
>> > open", what do you think should happen?
>> >
>> > Should we just not open the error box?
>>
>> Some users might prefer not showing the error dialog and just create the
>> dummy noname.pro file.  I don't have a strong preference one way or
>> another.  Interestingly, LibreOffice removes all files that don't exist
>> from the recent list so you cannot select a non-existent file.  On the
>> other hand, MS Excel give a error message stating that you may have
>> moved or deleted the file.  In either case, the next action is to open
>> an empty file which would be noname.pro in our case.
>>
>> >
>> > Should it open the "new project" dialog?  If it does that, how would
>> > people start a new project from a template?  Should it have a different
>> > dialog with three buttons, "new project" and "new project from
>> > template", and cancel (which would just open the normal interface but
>> > with no project file opened)?
>>
>> I think this might be overkill.  If the open from last project history
>> fails, I would just show the dummy noname.pro and let the user decide
>> the next course of action.
>>
>> >
>> > Adam Wolf
>> >
>> > On Mon, Jan 5, 2015 at 8:33 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx
>> > <mailto:stambaughw@xxxxxxxxx>> wrote:
>> >
>> >     On 1/4/2015 8:42 PM, Adam Wolf wrote:
>> >     > Hi folks,
>> >     >
>> >     > Right now, when a user installs KiCad successfully on an OS X
>> system,
>> >     > and they start Kicad, the first thing they see is an error box.
>> >     >
>> >     > It states
>> >     >
>> >     > 'Error
>> >     >
>> >     > Project file '' not found'
>> >     >
>> >     > I do not think new users should get an error immediately upon
>> opening Kicad.
>> >     >
>> >     > I tried to fix this today, but I ran into some conceptual issues,
>> so
>> >     > hopefully I can get them cleared up and submit a patch for this.
>> >     >
>> >     > First, there appears to be code to prevent this from happening.
>> >     >
>> >     > in kicad/prjconfig.cpp:
>> >     >     wxString prj_filename = GetProjectFileName();
>> >     >     xString nameless_prj = NAMELESS_PROJECT  wxT( ".pro" );
>> >     >
>> >     >     // Check if project file exists and if it is not noname.pro <
>> http://noname.pro>
>> >     > <http://noname.pro>
>> >     >     if( !wxFileExists( prj_filename ) && !prj_filename.IsSameAs(
>> >     > nameless_prj ) )
>> >     >     {
>> >     >         wxString msg = wxString::Format( _(
>> >     >                 "KiCad project file '%s' not found" ),
>> >     >                 GetChars( prj_filename ) );
>> >     >
>> >     >         DisplayError( this, msg );
>> >     >         return;
>> >     >     }
>> >     >
>> >     > (NAMELESS_PROJECT is set to "noname" in include/common.h).
>> >     >
>> >     > This checks to see if GetProjectFileName() exists as a file, and
>> if it
>> >     > doens't, it checks to see if it is "noname.pro <http://noname.pro
>> >
>> >     <http://noname.pro>", and
>> >     > if not, it pops up an error.
>> >     >
>> >     > In kicad/kicad.cpp,
>> >     >
>> >     >     if( App().argc > 1 )
>> >     >         frame->SetProjectFileName( App().argv[1] );
>> >     >
>> >     >     else if( GetFileHistory().GetCount() )
>> >     >     {
>> >     >         wxString last_pro = GetFileHistory().GetHistoryFile( 0 );
>> >     >
>> >     >         if( !wxFileExists( last_pro ) )
>> >     >         {
>> >     >             GetFileHistory().RemoveFileFromHistory( 0 );
>> >     >
>> >     >             wxFileName namelessProject( wxGetCwd(),
>> NAMELESS_PROJECT,
>> >     >                                         ProjectFileExtension );
>> >     >
>> >     >             frame->SetProjectFileName(
>> namelessProject.GetFullPath() );
>> >     >         }
>> >     >         else
>> >     >         {
>> >     >             // Try to open the last opened project,
>> >     >             // if a project name is not given when starting Kicad
>> >     >             frame->SetProjectFileName( last_pro );
>> >     >
>> >     >             wxCommandEvent cmd( 0, wxID_FILE1 );
>> >     >
>> >     >             frame->OnFileHistory( cmd );
>> >     >             prjloaded = true;    // OnFileHistory() loads the
>> project
>> >     >         }
>> >     >     }
>> >     >
>> >     >
>> >     > we check if we have any command line arguments, and if we don't,
>> we
>> >     > check to see if we have a history, and if we can't load the top
>> history
>> >     > result, we set the project filename to the current working
>> directory /
>> >     > noname.pro <http://noname.pro> <http://noname.pro>.
>> >     >
>> >     > I see two potential issues here:
>> >     >
>> >     > 1) The situation where we have no history isn't handled
>> explicitly,
>> >     > which is part of what causes this issue for new users, I think.
>> >     >
>> >     > 2) When there is a history, but it can't find the top result, it
>> sets
>> >     > the project filename to the current working directory /
>> noname.pro <http://noname.pro>
>> >     > <http://noname.pro>.  Over in prjconfig.cpp, when we check for
>> >     > noname.pro <http://noname.pro> <http://noname.pro>, we check if
>> >     the whole string is
>> >     > "noname.pro <http://noname.pro> <http://noname.pro>".
>> >     >
>> >     > My gut feeling is to do something like the following:
>> >     >
>> >     >     if( App().argc > 1 )
>> >     >         // if there was a path specified, i.e. "kicad
>> >     > path/to/project.pro <http://project.pro> <http://project.pro>"
>> >     >         frame->SetProjectFileName( App().argv[1] );
>> >     >
>> >     >     else if( ! GetFileHistory().GetCount() )
>> >     >     {
>> >     >         // if there wasn't a .pro specified, and there is no
>> history
>> >     >         wxFileName namelessProject( NAMELESS_PROJECT,
>> >     >                                     ProjectFileExtension );
>> >     >
>> >     >         frame->SetProjectFileName( namelessProject.GetFullName()
>> );
>> >     >     }
>> >     >     else
>> >     >     {
>> >     >         // if there wasn't a .pro specified, and there is a
>> history
>> >     >
>> >     >         wxString last_pro = GetFileHistory().GetHistoryFile( 0 );
>> >     >
>> >     >         if( !wxFileExists( last_pro ) )
>> >     >         {
>> >     >             GetFileHistory().RemoveFileFromHistory( 0 );
>> >     >
>> >     >             wxFileName namelessProject( NAMELESS_PROJECT,
>> >     >                                         ProjectFileExtension );
>> >     >
>> >     >             frame->SetProjectFileName(
>> namelessProject.GetFullName() );
>> >     >         }
>> >     >         else
>> >     >         {
>> >     >             // Try to open the last opened project,
>> >     >             // if a project name is not given when starting Kicad
>> >     >             frame->SetProjectFileName( last_pro );
>> >     >
>> >     >             wxCommandEvent cmd( 0, wxID_FILE1 );
>> >     >
>> >     >             frame->OnFileHistory( cmd );
>> >     >             prjloaded = true;    // OnFileHistory() loads the
>> project
>> >     >         }
>> >     >     }
>> >     >
>> >     > But on the other hand, I don't know if this breaks assumptions
>> other
>> >     > places by having the ProjectFileName just be "noname.pro <
>> http://noname.pro>
>> >     > <http://noname.pro>".  Would it be better to change the check to
>> >     see if
>> >     > the project filename ends with "/noname.pro <http://noname.pro>
>> >     <http://noname.pro>"? I hope
>> >     > to get a better feel for things like this as I gain familiarity
>> with the
>> >     > extensive codebase.
>> >     >
>> >     > Also, Wayne, March 16th 2014, we discussed something like this on
>> the
>> >     > list, and you mentioned you use a custom default project file and
>> want
>> >     > to be alerted when that isn't found.  I am not familiar with how
>> that
>> >     > workflow works.  Would it be broken by this fix?
>> >
>> >     What used to happen was if a new project was created, the kicad.pro
>> >     <http://kicad.pro> file
>> >     saved in the /usr/share/kicad/template folder was copied to the new
>> >     project folder using project_name.pro <http://project_name.pro> as
>> >     the file name.  This allowed
>> >     the user to create a custom kicad.pro <http://kicad.pro> file for
>> >     project customization
>> >     purposes.  A failed attempt to open an existing project is a
>> different
>> >     behavior.  The noname.pro <http://noname.pro> file used to trigger
>> a
>> >     file save as dialog to
>> >     allow the user to rename the project file and save it to a preferred
>> >     path.  Since the kiway work, I'm not sure how this changed or if
>> this
>> >     has always been broken  Changing the fail to open existing project
>> >     behavior should not impact the new project project file behavior.
>> The
>> >     file code paths may be the same so you may have to do some testing.
>> >
>> >     >
>> >     > Adam Wolf
>> >     > Cofounder and Engineer
>> >     > W&L
>> >     >
>> >     >
>> >     > _______________________________________________
>> >     > Mailing list: https://launchpad.net/~kicad-developers
>> >     > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> >     > Unsubscribe : https://launchpad.net/~kicad-developers
>> >     > More help   : https://help.launchpad.net/ListHelp
>> >     >
>> >
>> >
>> >     _______________________________________________
>> >     Mailing list: https://launchpad.net/~kicad-developers
>> >     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> >     Unsubscribe : https://launchpad.net/~kicad-developers
>> >     More help   : https://help.launchpad.net/ListHelp
>> >
>> >
>>
>>
>> _______________________________________________
>> 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
>>
>
>

Attachment: hush_noname_pro.patch
Description: Binary data


Follow ups

References