D9344: [KDevelop] : [fixed] consistent use of the project name allowing to create multiple projects in a single source tree

[René J.V. Bertin]

rjvbb added a comment.


  >   The current patch I still cannot oversee (though also due to the existing code), so I would have to grab the -1 sign for now if on the jury.
  
  Question is: are you, and should the refactoring be done before or after this change? I'm quite sure I won't have time for a serious overhaul the coming few weeks.
  
  > Thanks for adding the comment to the code, but I am still wondering by the code how this situation can happen. If a user selected an existing file with that extension and thus m_url is "/path/to/projectSrc/projectSrc.kdev", the very
  > 
  >   if( !urlInfo.isDir ) {
  >       m_url = m_url.adjusted(QUrl::StripTrailingSlash | QUrl::RemoveFilename);
  >   }
  > 
  > earlier should handle this, no?
  
  That's what I also thought in the beginning, and it is indeed what happens with cmake-based projects (for which I developed this patch initially).
  Then someone reported that other project managers caused other behaviour, including saving the project file in the parent directory and creating a directory under the project file's name.
  I think this must be due to the different ways different project managers leverage the import wizard, notably the fact that not all use all of the wizard's dialogs (pages).
  
  > Doing any bad case handling at this point seems to be like we missed something before.
  
  I think that the underlying problem here is that a lot is going on while the import dialog(s) are open, which means the code has to be written so it works when called iteratively (the one validating the project name at each key strike, for instance).
  Things would be a lot easier if user input were obtained first, and the derived variables were set afterwards. But I don't know to what extent such an implementation could support the entire current feature set, including backing up to a previous stage etc.

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D9344

To: rjvbb, #kdevelop, mwolff, kossebau
Cc: kossebau, arrowd, mschwarz, kfunk, mwolff, kdevelop-devel, glebaccon, antismap, iodelay, vbspam, geetamc, Pilzschaf, akshaydeo, surgenight
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20181020/fc932a7e/attachment.html>