Frameworks/Epics/KDevelop based SDK: Difference between revisions
< Frameworks | Epics
No edit summary |
No edit summary |
||
| Line 4: | Line 4: | ||
* Examples: are those enough? How do we comple one of those separatedly? | * Examples: are those enough? How do we comple one of those separatedly? | ||
* QtQuick: How far should KDevelop integrate such language? | * QtQuick: How far should KDevelop integrate such language? | ||
Probably at the moment KDevelop is quite optimal when it comes to the day to day development of a C++ developer/KDE Hacker. Making an SDK on top of KDevelop, I think it would mean to fulfill the following use cases: | Probably at the moment KDevelop is quite optimal when it comes to the day to day development of a C++ developer/KDE Hacker. Making an SDK on top of KDevelop, I think it would mean to fulfill the following use cases: | ||
Revision as of 15:17, 15 October 2012
Things to be figured out:
- Documentation: Do we want to go for the *.qch road?
- Templates: Are the ones we have in kdesdk/kapptemplates enough?
- Examples: are those enough? How do we comple one of those separatedly?
- QtQuick: How far should KDevelop integrate such language?
Probably at the moment KDevelop is quite optimal when it comes to the day to day development of a C++ developer/KDE Hacker. Making an SDK on top of KDevelop, I think it would mean to fulfill the following use cases:
- Easily debug KDE plugins (e.g. KIO, kded, plasmoids)
- Reduce discoverability of KDE technologies. Good examples and templates integration.
- Integrate as much as possible the official set of technologies while developing a project. Those would be: C++, Qt, KF5 and QtQuick/QML.