Frameworks/Epics/KDevelop based SDK: Difference between revisions
< Frameworks | Epics
No edit summary |
No edit summary |
||
| Line 8: | Line 8: | ||
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: | ||
* Easily debug KDE plugins (e.g. KIO, kded, plasmoids) | * Easily debug KDE plugins (e.g. KIO, kded, plasmoids) | ||
* | * Improve 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. | * Integrate as much as possible the official set of technologies while developing a project. Those would be: C++, Qt, KF5 and QtQuick/QML. | ||
Revision as of 15:52, 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)
- Improve 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.