Review Request 127827: open/fetch project: restore broken workflows after native file dialog port

[Gleb Popov]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127827/#review95667
-----------------------------------------------------------



I'll try to outline the problem.

1. We clearly need to be able to open directory as a project. Not only because someone like it, but because project manager may not require "buildsystem file" of any sort (like Generic Project manager and Custom Makefiles).
2. The decision on what dialog to use (KDE or Qt) is mostly unrelated and can be discussed later. For now i'll use `KDE_FULL_SESSION` to denote that we use KDE dialog.
3. We are really stuck on Windows, because QFileDialog uses native dialogs, which aren't able to work in "directory" and "file" modes simultaneously. This requires a solution.
4. What's the status of the problem on `!Windows && !KDE_FULL_SESSION`? If i understand it right, this would bring Gnome dialog on Gnome or OSX native dialog on OSX. If that so, we need to check every possible outcome of calling QFileDialog and find out cases in which we are stuck, like with Windows.
5. I've done some googling on Windows native dialog. It doesn't support mode desired by us since Vista and there were no changes since then. So, nothing can be fixed even on the Qt side.

The only solution i see for the "really stuck" case is to just use KDE_FULL_SESSION dialog.

- Gleb Popov


On May 4, 2016, 1:32 a.m., Sven Brauch wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127827/
> -----------------------------------------------------------
> 
> (Updated May 4, 2016, 1:32 a.m.)
> 
> 
> Review request for KDevelop and Kevin Funk.
> 
> 
> Repository: kdevplatform
> 
> 
> Description
> -------
> 
> The native dialog has two significant restrictions: it cannot be embedded, and it cannot be told to accept both a directory _or_ a file at once. The previous change to the open project dialog broke the (important) option to open a directory as a project. This fixes that through introduction of an extra step: you select the method you want to open your project with first. This has the advantage of making it more clear to the user what the options are; many users are still not aware you can simply tell KDevelop to open a folder as a project.
> 
> I'm well aware this is far from an optimal solution, but right now it's just broken and this is certainly an improvement over the current situation. Better ideas welcome.
> 
> 
> Diffs
> -----
> 
>   shell/CMakeLists.txt 83d4db0 
>   shell/openprojectdialog.h d39ff8e 
>   shell/openprojectdialog.cpp 9ccca43 
>   shell/openprojectdialog.ui PRE-CREATION 
>   shell/openprojectpage.h 1e0ff60 
>   shell/openprojectpage.cpp 42d836f 
>   shell/projectsourcepage.h a45ee19 
>   shell/projectsourcepage.cpp 43ab6e9 
>   shell/projectsourcepage.ui 79699aa 
> 
> Diff: https://git.reviewboard.kde.org/r/127827/diff/
> 
> 
> Testing
> -------
> 
> can open from CMakeLists.txt, from foo.kdev5 or from a folder; also fetch works again (before simply random stuff happened)
> 
> 
> File Attachments
> ----------------
> 
> the added dialog
>   https://git.reviewboard.kde.org/media/uploaded/files/2016/05/03/7b6cdfc2-c4d7-4394-9a39-2ccc923f28fa__Screenshot_20160504_001810.png
> 
> 
> Thanks,
> 
> Sven Brauch
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20160521/d3685a0b/attachment.html>