3d3beac449
* upon using the accessor i disocvered they didn't actually do anything except set the member variable; no changes actually took place in the dialogs. eventually, we should probably consider moving the application name to a central location in libplasma, e.g. a Plasma::setMainComponent(KComponentData&) that initializes itself to the app's mainComponent()... there's too many of these app name things around also, when the item model updates itself, the view in the dialog doesn't. i've added a hack in AppletBrowser::setApplication to re-set the item model on the view. maybe Ivan you could take a look at that sometime? it's not overly critical as it works for now due to the hack. CCMAIL:lfranchi@gmail.com CCMAIL:ivan.cukic+kde@gmail.com svn path=/trunk/KDE/kdebase/workspace/libs/plasma/; revision=733614
libplasma
Commit Rules:
* If your patch is not an obvious or trivial bug fix, have it peer reviewed
by another Plasma developer
* All code MUST follow the kdelibs coding style, as found at:
http://techbase.kde.org/Policies/Kdelibs_Coding_Style
* All new public API MUST have apidox written before committing
Unit tests are next to godliness. (Though as you can see, right now libplasma
is hellbound.)
This directory contains the classes making up libplasma, which provides the
core framework used by Plasma and its components. This includes applet and
extension definitions and loading, common GUI elements, etc.
Domain specific sets of functionality, e.g. for network awareness or sensors,
are not found here but in one of the Plasma Engines.
Please refer to the Plasma website (http://plasma.kde.org) and Plasma wiki
(http://techbase.kde.org/Projects/Plasma) for API documentation and design
documents regarding this library.