<table><tr><td style="">rjvbb added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D9344">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">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.</pre></div></blockquote>

<p>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.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>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</p>

<div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">if( !urlInfo.isDir ) {
    m_url = m_url.adjusted(QUrl::StripTrailingSlash | QUrl::RemoveFilename);
}</pre></div>

<p>earlier should handle this, no?</p></blockquote>

<p>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).<br />
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.<br />
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).</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>Doing any bad case handling at this point seems to be like we missed something before.</p></blockquote>

<p>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).<br />
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.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R32 KDevelop</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D9344">https://phabricator.kde.org/D9344</a></div></div><br /><div><strong>To: </strong>rjvbb, KDevelop, mwolff, kossebau<br /><strong>Cc: </strong>kossebau, arrowd, mschwarz, kfunk, mwolff, kdevelop-devel, glebaccon, antismap, iodelay, vbspam, geetamc, Pilzschaf, akshaydeo, surgenight<br /></div>