To much QML options in KDE!
Marco Martin
notmart at gmail.com
Sun Oct 30 12:43:25 UTC 2011
On Saturday 29 October 2011, Mark wrote:
> Hi plasma people,
>
> I was expecting some components to be available for KDE and indeed there
> are. Sadly there is to much with roughly similar names which makes it
> really inconvenient to find out which one i should or should not use..
>
> You have (in kde-runtime/plasma/declarativeimports/):
> - core (what is in there besides the background stuff?)
svg, dataengines and service access, directly and tough models, access to
theme colors/fonts, dialogs, tooltips
> - draganddrop (uhh.. ?)
does what it says, drag and you know, drop :p
> - graphicslayouts (what is this supposed to be?)
bindings for qgraphicsLinear/grid layout, and yes, quite deprecated
> - graphicswidgets (So these are the Plasma:: widgets right? Sadly they are
> currently broken and give me this error: "Type dump of C++ plugin failed.
> Parse error: 7:5: Component defenition is missing a name binding" .. I
> would like to use this one but it's not working. Could someone
> knowledgable about that one fix it please?)
seems an installation issue on your side. btw those should be really, really
really avoided at this point, unless a very valid reason to use an element
from them exist (every time those gets used, makes harder for porting to
plasma2)
> - plasmacomponents (These are the new components from GSoC right? But why
> do they look so.. different then the Plasma:: components? These do work
> btw.)
api wise they at least try to follow the standard used in symbian and meego
look/behaviour they try to look similar, is not 100% possible to have a
complete carbon copy, some other visual differences are instead wanted as in
"the way things are supposed to look in the future"
from now on those are *the* elements to use for graphical widgets
> - qtextracomponents (What is this?)
elements low in the stack in qt that don't have bindings directly, like icons,
pixmaps, qimages useful when the c++ part needs to directly have one of those
visualized
> So we have - at the very least - 2 "component" plugins. graphicswidgets
> and plasmacomponents, but which one am i supposed to use when re-creating
> the plasma panel tool box? Right now i go for plasmacomponents since it's
> working..
bits of Components and bits of Core.. ignore graphicswidgets.
actually, the plasma toolbox menu api/behaviour wise is very similar to the
"menu" component now that i think about it...
i have now implemented it as a standard QMenu, thinking about it there are
both usecases for having it done like that and use cases to have a themed on
scene one like the toolbox menu.
do you have already code for this?
i think we can try to do a component that depending from some factor (type of
the menu item? extra api?) can behave both as a qmenu or as a styled thing.
> But can't we clean this stuff up a bit, remove what we don't need and just
everything that's there is here for a reason :p
(there is so much stuff, because qml is missing that much stuff and even more
to be actually useful :p)
now, i would love to remove graphicslayouts and graphicswidgets, but it's
released api, so we can't just yank it from the kde4 series, besides
unfortunately graphicswidgets are still needed for some corner cases
> have "components" for the rest? Then a nice wiki page that explains what's
> all in the components.
a wiki pages does exist, explains only core right now, expansions are
appreciated of course ;)
Cheers,
Marco Martin
More information about the Plasma-devel
mailing list