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

Jump to: navigation, search
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.

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