Notes from "Async and representation"

Mark Gaiser markg85 at gmail.com
Wed Jan 15 15:43:43 UTC 2014


On Tue, Jan 14, 2014 at 11:35 PM, Marco Martin <notmart at gmail.com> wrote:
> On Wednesday 15 January 2014 00:01:35 Mark Gaiser wrote:
>> Hi Marco,
>
> First, to be clear is not *my* proposal per se, is the proposal we came up at
> the sprint.
>
>> So if i get it right you propose that every plasmoid - in QML - will
>> at the very least have this:
>>
>> Item {
>>
>>   Applet {
>>     minimumWidth: ...
>>     minimumHeight: ...
>>     ...
>>   }
>> }
>>
>> right?
>
> no,
> it would be
> Applet {
>      minimumWidth: ...
>      minimumHeight: ...
>      compactRepresentation: Component {...}
>      fullRepresentation: Component  {...}
> }
>
> no root Item, and is a qobject, non visual

And based on "some magic" either the compactRepresentation or the
fullRepresentation is loaded and displayed i suppose?

>
>> If that's the case then i'd like to suggest to figure out how to do
>> that in the root object which will make it look as follows:
>>
>> Item {
>>
>>   minimumWidth: ...
>>   minimumHeight: ...
>>   ...
>> }
>
> that's exactly how is now apart that you have to declare the properties too,
> so
> Item {
>      property int minimumWidth:...
>      ....
> }
>
> that's what we want to get away from ;)

But why?
What's the reasoning behind that?

If you learn QML from scratch you start with:
Item {
  ...
}

or

Rectangle {
  ...
}

Or if you make a application to look native with the controls:
ApplicationWindow {
  ...
}

I don't think KDE should add another one:
Applet {
  ...
}

Sure, it works and probably serves a need that i don't fully see yet,
but it also makes it less obvious for people starting developing
plasmoids.
They will first have to figure out how to call their root object and
why it's not Item{} but Applet{}.

If you can, you should try to prevent that.

As for the Applet name. Why that name? I'm making a plasmoid, right?
So name it as such:
Plasmoid {
  ...
}

That is also easier to explain to a user:
"To create a plasmoid you have to create a root QML item named
Plasmoid { ... } which must contain the following properties ... bla
bla, you get the point."

Then yet another note.
You say users must provide a:
minimumWidth: ...
minimumHeight: ...

which is being defined in the root item (whatever it ends up being).
But why there? I mean, the compactRepresentation and
fullRepresentation are likely to have their own different minimal
width/height. It "could" be the same, yes. But it could also be wildly
different. An example. Imagine someone makes a plasmoid madia player.
With the compact representation displaying just some play/stop buttons
and the full representation displaying a full blown gui with audio
visualization and playlist. The minimum dimensions of both
representations will obviously be different yet it cannot be set in
your initial proposal. Unless you make the minimal size as small as
the smallest minimal (likely compactRepresentation) but then it's just
a bogus value for the other one (likely fullRepresentation).


I hope you find my feedback valuable and not nitpicking :)

>
>> That seems cleaner to me. Specially because Applet doesn't seem to do
>> much or anything else. Just a container of some "must be provided"
>> properties. I know you can inspect QML from the C++ code and figure
>> out if a property is set. How, i don't know :)
>>
>> Why are there minimal requirements anyway? Won't a plain simple QML file
>> like: Item {
>>   width: 100
>>   height: 100
>> }
>>
>> Would the above stop to work when loaded through plasma? If so it
>> would seem very odd to me. If those "must be provided" properties are
>> not set then just threat it as a desktop plasmoid.
>
> the properties don't "have" to be provided, but size hints are needed in order
> for the applet to corretcly resize in a panel for instance
>
> --
> Marco Martin
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel


More information about the Plasma-devel mailing list