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

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D9344#346281 <https://phabricator.kde.org/D9344#346281>, @rjvbb wrote:
  
  > >   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.
  
  
  Sorry to say, but you want to add the feature, so you would have to scratch this itch. I as co-contributor just raise my concern about making the current code more convoluted.
  
  >> 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).
  
  But do they change things behind our back after this method has been entered? I still miss to see how m_url suddenly could be in that state latter in the method. If that happens we should rather fix this from happening, instead of covering over it here.
  
  In D9344#346362 <https://phabricator.kde.org/D9344#346362>, @rjvbb wrote:
  
  > One more thing: could establishing the project file name not simply be done by a method in the ProjectController class rather than by a dedicated class? Because, in how many different functions would you split that logic?
  
  
  I cannot foresee how complicated the complete logic and states for estimating/maintaining a proper project file name/path is. But personally I would first look into encapsulating this aspect in a simple dedicated class instead of using the general object manager class as dumping ground for "any logic related to projects".

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/20181028/52f99d5b/attachment-0001.html>