Difference between revisions of "Frameworks/Epics/KDevelop based SDK"

Jump to: navigation, search
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)
* Reduce discoverability of KDE technologies. Good examples and templates integration.
+
* 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.

Content is available under Creative Commons License SA 4.0 unless otherwise noted.