D9344: [KDevelop] : consistent use of the project name (WIP!)

[René J.V. Bertin]

rjvbb added a comment.


  In `ProjectDialogProvider::askProjectConfigLocation()`:
  
    qCWarning(SHELL) << "selected project:" << projectFileUrl << "selectedUrl=" << dlg->selectedUrl()
        << "projectName=" << dlg->projectName() << "projectManager=" << dlg->projectManager();
  
  and in `equalProjectFile()`:
  
    qWarning() << Q_FUNC_INFO << "configPath=" << configPath << "defaultName=" << defaultName
        << "cfg.Name=" << grp.readEntry( "Name", QString() ) << "projectName=" << dlg->projectName();
  
  gives the following observations:
  
  1: Opening an existing project of which I renamed the .kdev4 files manually in the past, project dir `kdevelop-git-5`:
  
    kdevplatform.shell: selected project: QUrl("file:///home/bertin/cworks/Scratch/KDE/KF5/kdevelop-git-5/kf5-kdevelop-5.kdev4")
            selectedUrl= QUrl("file:///home/bertin/cworks/Scratch/KDE/KF5/kdevelop-git-5/kf5-kdevelop-5.kdev4")
            projectName= "kdevelop-git-5" projectManager= "<built-in>"
  
  2: Creating new project, closing it, reopening it (project dir `kcompl-git`, no shouldAsk dialog):
  
    kdevplatform.shell: selected project: QUrl("file:///home/bertin/cworks/Scratch/KDE/KF5/kcompl-git/kcompl-git.kdev4")
        selectedUrl= QUrl("file:///home/bertin/cworks/Scratch/KDE/KF5/kcompl-git/kcompl-git.kdev4")
        projectName= "kcompl-git" projectManager= "KDevCMakeManager"
    bool KDevelop::equalProjectFile(const QString &, KDevelop::OpenProjectDialog *) configPath= "/home/bertin/cworks/Scratch/KDE/KF5/kcompl-git/kcompl-git.kdev4"
        defaultName= "kcompl-git" cfg.Name= "kcompl-git" projectName= "kcompl-git"
  
  3: After renaming it to 5:kcompl-git, on-disk and inside 5:kcompl-git.kdev4 (NO shouldAsk dialog posted):
  
    kdevplatform.shell: selected project: QUrl("file:///home/bertin/cworks/Scratch/KDE/KF5/kcompl-git/5:kcompl-git.kdev4")
        selectedUrl= QUrl("file:///home/bertin/cworks/Scratch/KDE/KF5/kcompl-git/5:kcompl-git.kdev4")
        projectName= "kcompl-git" projectManager= "<built-in>"
  
  4: Creating as 5:kcompl-git.kdev4 from scratch (= lines 322,3 in hunk 2 above NOT commented-out):
  
    kdevplatform.shell: selected project: QUrl("file:///home/bertin/cworks/Scratch/KDE/KF5/kcompl-git/5:kcompl-git.kdev4")
        selectedUrl= QUrl("file:///home/bertin/cworks/Scratch/KDE/KF5/kcompl-git/CMakeLists.txt")
        projectName= "5:kcompl-git" projectManager= "KDevCMakeManager"
  
  5: reloading 5:kcompl-git after closing (a shouldAsk dialog IS posted):
  
    kdevplatform.shell: selected project: QUrl("file:///home/bertin/cworks/Scratch/KDE/KF5/kcompl-git/5:kcompl-git.kdev4")
        selectedUrl= QUrl("file:///home/bertin/cworks/Scratch/KDE/KF5/kcompl-git/5:kcompl-git.kdev4")
        projectName= "kcompl-git" projectManager= "KDevCustomBuildSystem"
    bool KDevelop::equalProjectFile(const QString &, KDevelop::OpenProjectDialog *) configPath= "/home/bertin/cworks/Scratch/KDE/KF5/kcompl-git/5:kcompl-git.kdev4"
        defaultName= "kcompl-git" cfg.Name= "5:kcompl-git" projectName= "kcompl-git"
  
  I can see the difference between 3 and 5 and why 5 would post a dialog, but don't see the difference between 1 and 5 (also why `equalProjectFile()` appears not to be called).
  
  The real question here might be why an override dialog should be posted at all when the user reopens a .kdev4 file. That makes sense if you select a (C)Makefile or .pro file but it probably is the wrong question to ask when the user opens an existing .kdev4 file. Especially when only a single such file exists. Wouldn't it be enough in that case to verify if .kdev4 filename and the Name property stored therein correspond?

REPOSITORY
  R32 KDevelop

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

To: rjvbb
Cc: kdevelop-devel, vbspam, njensen, geetamc, Pilzschaf, akshaydeo, surgenight, arrowdodger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20171215/abab8eb6/attachment.html>