dictionary widget QML

[Marco Martin]

On Sun, Feb 5, 2012 at 3:49 PM, Shaun Reich <shaun.reich at kdemail.net> wrote:
> On Sun, Feb 5, 2012 at 8:58 AM, Marco Martin <notmart at gmail.com> wrote:
>> On Sun, Feb 5, 2012 at 2:46 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
>>>> if you want to make this choseable by the kcm it would have to become
>>>> a (partly) c++ plasmoid
>>>
>>> assuming that it is unnecessary, even unwanted (different instances of the
>>> plasmoid -> different dicts?), this could in theory be done straight from the
>>> plasmoid. but this is where (again) the KConfigXt+Qt Designer pair let us down;
>>
>> uh, and forgotted to add: in this case yes, doing it directly from the
>> plamoid would be a sensible enough workflow:
>> * click the dict icon (that right now doesn't do anything)
>> * in the results area it shows the list of available dicts
>> * select one
>
> what widget should it use to select the thingies? you want iti to be
> clear that they -can- be choosen.

just a listview, with the usual highlight item on mouse over to show
it can be selected.

> i can't believe the kconfig/qtdesigner "let us down". does it not
> allow bidirectional communication, like populating a listview and
> choosing it; it would only allow e.g. selecting buttons. man, we
> really need a goof fiix for that.

it's by design almost useless without c++.

with kconfigxt is possible to map some simple things, like booleans to
checkboxes and strings to text fields, but nothing more complex.
for instance pupulating lists you really can't get away with
qtdesigner without dedicated imperative code.

so while it's good for what it is, i don't think we want here not even
a temporary fix for it. (while it theory is possible to write qwidget
qml bindings that don't involve qgraphicsview or proxy widgets at all,
would be batshit crazy to even attempt a monstrosity like that :p)

>
> i suppose it could look even better for plasmoids to have as much
> config as possible inside them. if it's at all feasible. though you
> get the issue with popup applets doing their thing.

popupapplet just work.
the problem is when you need a popup applet that doesn't have an icon
but draws its own thing.
in this case a Dialog has to be managed by hand.

looking at the current set of plasmoids, some of them will be possible
some not, some only as in part C++, and that's fine.
anyways having 100% of the default applets in pure qml is a very long
term plan, since on the desktop plasma2 would continue to use a legacy
compatible version with qgraphicsview for a (probably) long time


Cheers,
Marco Martin