< Frameworks | EpicsRevision as of 21:05, 24 October 2012 by Milianw (talk | contribs)(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff) 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. Contents 1 Notes from the KDevelop Vienna Sprint 2012 1.1 Remote/Embedded Development 1.2 Better KDE Debugging 1.3 QML 1.4 Documentation 1.5 KDE/Qt Examples 1.6 Unit Testing 1.7 Launch Configurations 1.8 Project Page Notes from the KDevelop Vienna Sprint 2012 Remote/Embedded Development Someone should add a "deplyoment" concept to our launch/build tools, such that we can use e.g. CMake/QMake for cross compiling and afterwards deploy some binary blob onto a device. Better KDE Debugging It should be simpler to debug e.g. an KIO slave or a KDED plugin or a Plasmoid or ... Maybe by adding different/special launch configurations for these things or so... What about a Gammaray plugin? QML One way or the other, QML will stay and we should support it. Thus lets work on a language plugin and integrate the qmlviewer and stuff like that. Documentation Thanks to the .qch integration it should all work already. We should ensure it does. We could also think about adding a 'getting started' section to the welcome screen that has shortcuts to download the most common .qch documentations e.g. KDE/Qt Examples The new file templates stuff should help a lot here. But we could/should add a new provider for KDE and Qt examples. Also, we must ensure that these official examples have a high quality. Also we should write/extend the KDevelop examples, i.e.: toolview, language plugin, app wrapper (like quanta), ... Unit Testing The unit testing branch should be merged and we should ensure it works nicely. E.g. we want to hide unit tests from the launch configuration. Launch Configurations Once the unit testing is in, we could automatically add launch configs for targets in a project. Also (or alternatively?) we could store launch configs associated with a project target (opposed to scripts or running an absolute path) in the project.kdev4 file such that it can be shared between developers. Project Page The Project Page idea should be revived and implemented. Sharing meta data and social aspects around community projects should be cool. Retrieved from "https://community.kde.org/index.php?title=Frameworks/Epics/KDevelop_based_SDK&oldid=25809" Content is available under Creative Commons License SA 4.0 unless otherwise noted.