User:Dcecile: Difference between revisions
(New page: all parts of the KDE libraries need tutorial documentation. this is a survey. (note: the lists of modules could be taken from a release doc or something.....) pillars of KDE: * Solid * Ph...) |
No edit summary |
||
(11 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
(unrelated development schedule: [[Schedules/KDE4/4.0_Release_Beta_Goals]]) | |||
every part of the KDE libraries needs tutorial documentation. this is a survey. (note: the lists of modules could be taken from a release doc or something.....) tutorials should answer: "why would I use KDE over just QT?" | |||
* | |||
* | [[Development/Tutorials|tutorial directory]] | ||
* | |||
* | ===KDE glue=== | ||
* | what defines a KDE app? | ||
* | * localization | ||
* | * consistent menus, accelerators, toolbars, chrome, icons | ||
* | * transparent file access | ||
* simple, cross-platform build system | |||
* shared technology | |||
* testing | |||
* documentation | |||
* open source | |||
* inviting for new users and contributors | |||
the next step is showing prospective contributors (and active ones wanting to learn more) how to use the glue | |||
everyday tech: | ===everyday tech=== | ||
* Hello World: this is the simplest KDE app; proves your dev environment is working and gives you confidence to continue coding! | |||
** There is a [[Development/Tutorials/First program|dialog]] tutorial; why not do a single source-file KMainWindow app? (just needs to include the moc at the end) | |||
* CMake: how to create your own app; and plug in other libraries | * CMake: how to create your own app; and plug in other libraries | ||
** the first apps will introduce how to do basic stuff (and show standard KDE formatting) | |||
** can point to CMake doc itself | |||
** should document KDE CMake macros and common conventions | |||
* KActions: setting up menus, toolbars, and accelerators | * KActions: setting up menus, toolbars, and accelerators | ||
** {{class|KAction}} | |||
* Internationalization and localiazation | |||
** | |||
* QT Designer: designing a widget-based interface | * QT Designer: designing a widget-based interface | ||
** | |||
* KConfigXT: persistent app config data. making the settings dialog. using the settings | * KConfigXT: persistent app config data. making the settings dialog. using the settings | ||
** | |||
* KIO: tranparent file access. how does it work with the QT libraries? | |||
** | |||
* KPixmapCache: | * KPixmapCache: | ||
* | ** | ||
* | * ThreadWeaver: performs "jobs" that can be scheduled on non-UI threads | ||
** [http://api.kde.org/4.0-api/kdelibs-apidocs/threadweaver/html/index.html API]: can be hard to navigate; there are working examples in the source tree though | |||
===pillars of KDE4=== | |||
* Solid: getting info about hardware | |||
** [http://solid.kde.org/ homepage] | |||
** [http://api.kde.org/4.0-api/kdelibs-apidocs/solid/html/namespaceSolid.html API] | |||
** contact: Kevin Ottens | |||
** status: [[Development/Tutorials|tutorial]] | |||
* Phonon: use audio and video in your app | |||
** [http://api.kde.org/4.0-api/kdelibs-apidocs/phonon/html/index.html API]: gives a good quick overview of the library; has an undocumented full example | |||
* Strigi: find data. also how to let strigi use your filetype | |||
** [http://api.kde.org/kdesupport-api/kdesupport-apidocs/strigi/html/ API] | |||
* Plasma: creating a new desktop paradigm | |||
** | |||
* Nepomuk: relation to Strigi? file metainfo, relationships | |||
** [http://api.kde.org/4.0-api/kdelibs-apidocs/nepomuk/html/index.html API]: good description of Nepomuk's goad; but how does it fit with the user's desktop? should devs add all metainfo to the files they use? what happens when the file moves or gets transfered? | |||
* Decibel: connecting to other people | |||
** | |||
* Akonadi: communcations storage backend | |||
** | |||
* Oxygen: devs need to know how to access all of the icon and sound that this team has put together. (and maybe know how to give feedbacks or make commissions.) there should be doc about doing for yourself what the Oxygen team does | |||
* Sonnet: automatic language detection and spell-checking | |||
** [http://api.kde.org/4.0-api/kdelibs-apidocs/sonnet/html/index.html API]: main page does articulate and link to usage | |||
** status: the [[Development/Tutorials/Sonnet/SonnetTutorial|tutorial]] is bare right now | |||
===advanced=== | |||
* job progress | * job progress | ||
* D-Bus | |||
* GetHotNewStuff2 | |||
PIM stuff | ===PIM stuff=== | ||
* Khalkhi: contacts framework | * Khalkhi: contacts framework | ||
* KitchenSync | * KitchenSync | ||
* syndication | * syndication: using syndication feeds | ||
===games=== | |||
* GGZ | |||
* graphics framework | |||
** QGraphicsView, custom sprite handling... | |||
* physics | |||
** Step, Eigen2? | |||
===other languages=== | |||
* ruby, python, EMCAScript, java, c# | |||
* i have a feeling that this should be where new devs should be directed first | |||
* assuming its dead simple to get running with the language on your OS, it should be THE starting place | |||
* is there any reason to dissuade devs from using these languages? | |||
** commits to KDElibs are in C++ | |||
** performance issues? | |||
** unstable APIs? | |||
** incomplete APIs? | |||
===mystery tech=== | |||
* Soprano: pluggable framework for RDF storage and parsing | |||
** [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/ API] | |||
** how does an app dev use this? | |||
* DNSSD: discover services on the network or announce the availability of a service provided by your application | |||
** [http://api.kde.org/4.0-api/kdelibs-apidocs/dnssd/html/index.html API]: the hyperlinks aren't working :( |
Latest revision as of 16:11, 13 October 2007
(unrelated development schedule: Schedules/KDE4/4.0_Release_Beta_Goals)
every part of the KDE libraries needs tutorial documentation. this is a survey. (note: the lists of modules could be taken from a release doc or something.....) tutorials should answer: "why would I use KDE over just QT?"
KDE glue
what defines a KDE app?
- localization
- consistent menus, accelerators, toolbars, chrome, icons
- transparent file access
- simple, cross-platform build system
- shared technology
- testing
- documentation
- open source
- inviting for new users and contributors
the next step is showing prospective contributors (and active ones wanting to learn more) how to use the glue
everyday tech
- Hello World: this is the simplest KDE app; proves your dev environment is working and gives you confidence to continue coding!
- There is a dialog tutorial; why not do a single source-file KMainWindow app? (just needs to include the moc at the end)
- CMake: how to create your own app; and plug in other libraries
- the first apps will introduce how to do basic stuff (and show standard KDE formatting)
- can point to CMake doc itself
- should document KDE CMake macros and common conventions
- KActions: setting up menus, toolbars, and accelerators
- Internationalization and localiazation
- QT Designer: designing a widget-based interface
- KConfigXT: persistent app config data. making the settings dialog. using the settings
- KIO: tranparent file access. how does it work with the QT libraries?
- KPixmapCache:
- ThreadWeaver: performs "jobs" that can be scheduled on non-UI threads
- API: can be hard to navigate; there are working examples in the source tree though
pillars of KDE4
- Solid: getting info about hardware
- Phonon: use audio and video in your app
- API: gives a good quick overview of the library; has an undocumented full example
- Strigi: find data. also how to let strigi use your filetype
- Plasma: creating a new desktop paradigm
- Nepomuk: relation to Strigi? file metainfo, relationships
- API: good description of Nepomuk's goad; but how does it fit with the user's desktop? should devs add all metainfo to the files they use? what happens when the file moves or gets transfered?
- Decibel: connecting to other people
- Akonadi: communcations storage backend
- Oxygen: devs need to know how to access all of the icon and sound that this team has put together. (and maybe know how to give feedbacks or make commissions.) there should be doc about doing for yourself what the Oxygen team does
- Sonnet: automatic language detection and spell-checking
advanced
- job progress
- D-Bus
- GetHotNewStuff2
PIM stuff
- Khalkhi: contacts framework
- KitchenSync
- syndication: using syndication feeds
games
- GGZ
- graphics framework
- QGraphicsView, custom sprite handling...
- physics
- Step, Eigen2?
other languages
- ruby, python, EMCAScript, java, c#
- i have a feeling that this should be where new devs should be directed first
- assuming its dead simple to get running with the language on your OS, it should be THE starting place
- is there any reason to dissuade devs from using these languages?
- commits to KDElibs are in C++
- performance issues?
- unstable APIs?
- incomplete APIs?