In D3424#90759, @antonanikin wrote:In D3424#87489, @mwolff wrote:Any update on this? Sounds like a useful feature
Hi, Milian, I have an updated version, but it not finished. The current state is:
- If we doesn't want to provide docsets loading the plugin can be quickly adapted to current master.
- Zeal's author doesn't provide it's infrastructure for docsets downloading :(
- I have quick-and-dirty version of scripts which downloads docsets information from github repositories and convert them in "compressed" form, which currently hosted on my server. The docsets repo author agrees to provide it's stuff for our plugin with providing copyright information.
Now I don't know which way is better. Some peoples also suggests to provide library/kioslave for docsets support. All this possible but with different time cost. I also agree with Rene when he suggest to add ability for external-app documentation viewer, because the internal is far from ideal :(
Personally for me the ideal situation is provide "full stack" solution with our docsets information distribution server and downloading/updating docsets independently from Zeal (but if we can share docsets with Zeal it may be useful) with creating some external app (something like KDevDoc, Zeal/Dash inspired), which supports all types of documentation (Qt, man, cmake, dash docsets, etc) and provides an API to integrate it with KDevelop as internal or external viewer (user choice).
- Queries
- All Stories
- Search
- Advanced Search
Feed Advanced Search
Advanced Search
Advanced Search
Nov 28 2021
Nov 28 2021
Jun 5 2020
Jun 5 2020
Petross404 added a comment to D17908: kdevelop-msvc.bat finds VS-2017 based on a registry key on Windows..
In D17908#674686, @sredman wrote:I suspect it's not necessary to ship with KDevelop: Either Visual Studio >= 2017 is installed, in which case the vswhere tool should be on the path, or VS is not installed, in which case the tool wouldn't do us any good.
I have installed Build Tools for VS2019 and the installation is at
C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools
I found this string inside HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\1eb19443 which honestly doesn't seem the proper key to extract this value but anyway.
Petross404 added a comment to D17908: kdevelop-msvc.bat finds VS-2017 based on a registry key on Windows..
In D17908#492410, @sredman wrote:Actually, a pleasant surprise for today is that this whole mess of registry keys and environment variables is mostly unnecessary as of VS 2017, since Microsoft provides a tool which does all the locating work for us: https://github.com/microsoft/vswhere
Sep 23 2019
Sep 23 2019
In D23905#536196, @mlaurent wrote:I rebased it and fixed conflict but it changed owner... why ??? How I can change it ?
Sep 22 2019
Sep 22 2019
In D23905#535610, @mlaurent wrote:Did you have commit access?
Sep 17 2019
Sep 17 2019
Minimum cmake version is bumped to 3.1.0.
Sep 14 2019
Sep 14 2019
Some wrong tabs and spaces are fixed.
set(CMAKE_CXX_STANDARD_REQUIRED ON)
is added.
In D23905#530765, @davidre wrote:Also CMAKE_CXX_STANDARD_REQUIRED to also set it as a requirement
Sep 13 2019
Sep 13 2019
In the top level CMakelists.txt I added build system support for C++14 which was necessary for the qOverload macro.
Sep 12 2019
Sep 12 2019
In D23905#530132, @mlaurent wrote:You need to add
"set(CMAKE_CXX_STANDARD 14)" if you want to use C++14 in CMakeLists.txt (at toplevel)
Aug 23 2019
Aug 23 2019
Petross404 added a comment to D22854: Added support for configurable font styles for syntax highlighting.
This functionality would be great.
Jul 11 2019
Jul 11 2019
In D21589#492408, @sredman wrote:Actually, there is a bit of a problem... The version of the file currently on master is bugged :(
Petross404 added a comment to D17908: kdevelop-msvc.bat finds VS-2017 based on a registry key on Windows..
In D17908#492404, @sredman wrote:@Petross404 are you still around? Do you have any documentation references for how Microsoft expects the registry to look with regard to which key should contain the Visual Studio installation path? (I don't know if such documentation even exists...)
Jun 10 2019
Jun 10 2019
brauch is referring to this
echo Define which compiler for VS2017 to use. Possible architectures are:
Jan 29 2019
Jan 29 2019
Petross404 added inline comments to D17908: kdevelop-msvc.bat finds VS-2017 based on a registry key on Windows..
Petross404 added a comment to D17908: kdevelop-msvc.bat finds VS-2017 based on a registry key on Windows..
In D17908#401595, @mwolff wrote:you can pick whatever you prefer for the reviews for now.
do you have commit rights? if so, please feel free to push this directly, otherwise someone from us can take care of that for you
Jan 28 2019
Jan 28 2019
Petross404 updated the diff for D17908: kdevelop-msvc.bat finds VS-2017 based on a registry key on Windows..
Upload the minimum diff.
Jan 1 2019
Jan 1 2019
Petross404 requested review of D17908: kdevelop-msvc.bat finds VS-2017 based on a registry key on Windows..
Oct 25 2018
Oct 25 2018
Petross404 added a comment to D15976: Fix KDevelop's detection for Visual Studio 2017 compiler and tools..
In D15976#347700, @kfunk wrote:@Petross404 If you want to reapply the registry-reading on top of that, feel free to do so. Sorry, but I dont think I'll have time to test that. :(
Oct 12 2018
Oct 12 2018
I hate tο be a naysayer here, but shouldn't we not assume that VS2017 is installed in C:\Program Files (x86) so that we don't hardcode it's path? I remember my self installing VS once in another drive, because C:\ was tiny and full.
This batch file seems very clean and simple, I like it. Unfortunately I can't help reviewing this patch as I no longer have access to Windows machines and I don't a dual-boot system :(
Oct 9 2018
Oct 9 2018
Petross404 updated the diff for D15976: Fix KDevelop's detection for Visual Studio 2017 compiler and tools..
Our script now initializes the environment correctly (at least for VS2017) even if the user doesn't run it from Developers Command Prompt. It reads Registry to find the path under which VS2017 is installed (I fear that I read the wrong variable from the Registry).
Petross404 added a comment to D15976: Fix KDevelop's detection for Visual Studio 2017 compiler and tools..
Can a windows user with VS installed, give me the content of HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\SxS\VS7?
Petross404 added a comment to D15976: Fix KDevelop's detection for Visual Studio 2017 compiler and tools..
People with Visual Studio other than Community Edition, please consider trying out these changes. If a typo or a bug exists, it should be found early.
Petross404 updated the diff for D15976: Fix KDevelop's detection for Visual Studio 2017 compiler and tools..
- The script (sadly) uses hardcoded paths for vcvarsall.bat, instead of needing VS150COMNTOOLS. This way it can be found and executed, without the need of Developer's Command Prompt.
Oct 8 2018
Oct 8 2018
Petross404 added a comment to D15976: Fix KDevelop's detection for Visual Studio 2017 compiler and tools..
@kfunk As I already have mentioned, clicking the script (finding it in Start menu) doesn't initialize correctly the environment. It has to be run from within Developer Command Prompt or the complete path of MSCV binaries (for the wanted target) has to be in %PATH%.
Oct 6 2018
Oct 6 2018
Petross404 added a comment to D15976: Fix KDevelop's detection for Visual Studio 2017 compiler and tools..
Not sure about x64 part. What if user wants x32 project? Or that is arch of the toolchain itself?
Oct 5 2018
Oct 5 2018