Re: Notes from "Async and representation"
On Tuesday 28 January 2014, Marco Martin wrote: > Hi all, > > New prototype, completely different direction :) (and that's one i > actually like) > > mart/AppletAttached branch. If someone wants to test, mart/AppletAttached in kde-workspace has almost all the applet ported to this (we should do a grand round up of fullRepresentation stuff, since for compatibility i made it optional) for what i tested so far most of the stuff works... except the systray of course, is disabled for now, porting that will be a grand fun for the whole family :p Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Wednesday 29 January 2014, Marco Martin wrote: > On Wednesday 29 January 2014, David Edmundson wrote: > > Parts I don't understand: > > > > In compactRepresentationCheck > > when we are loading the compact version we still call > > createFullRepresentationItem(). I assumed we wanted to avoid that. > > yeah, good catch, that has to be corrected. > > > It would be better if we could just pass the QQmlComponent to the > > compactExpanderItem properties, and only create the items when we do > > the popup. I guess this could be done at a later date. > > yep, that as well good idea those two things should be fixed -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Wednesday 29 January 2014, David Edmundson wrote: > Parts I don't understand: > > In compactRepresentationCheck > when we are loading the compact version we still call > createFullRepresentationItem(). I assumed we wanted to avoid that. yeah, good catch, that has to be corrected. > It would be better if we could just pass the QQmlComponent to the > compactExpanderItem properties, and only create the items when we do > the popup. I guess this could be done at a later date. yep, that as well good idea -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Tue, Jan 28, 2014 at 9:14 PM, Marco Martin wrote: > Hi all, > > New prototype, completely different direction :) (and that's one i actually > like) The parts I like: - a split of AppletInterface acting just as an interface and a new class handing the QtQuick UI. - The relevant properties are now auto-documented \o/ - Use of attached Layouts. - fullRepresentation being loaded asynchronously. - switchWidth/Height being separate from sizeHints of either object; it implicitly solves the milou case of always wanting to use compact mode in the panel (personally, I would just drop the switching completely anyway) Parts I don't understand: In compactRepresentationCheck when we are loading the compact version we still call createFullRepresentationItem(). I assumed we wanted to avoid that. It would be better if we could just pass the QQmlComponent to the compactExpanderItem properties, and only create the items when we do the popup. I guess this could be done at a later date. David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Wednesday, January 29, 2014 10:49:38 Marco Martin wrote: > On Wednesday 29 January 2014, Sebastian Kügler wrote: > > On Wednesday, January 29, 2014 00:06:45 Marco Martin wrote: > > > So, the import of the applet can have its own containment instance (not > > > even a qml containment, just a dumb containment = new > > > Plasma::Containment()) > > > > > > then if we manage to make its configgroup child of the systray config > > > group, all should be just fine. > > > > So the configuration ends up as a "top level" containment in the config > > file then, automatically, or do we need to wire that up somehow as well? > > > > Otherwise, good read. > > if the containment is just created and not added with > corona::addContainment, then corona doesn't know anything about it, and > you can manually call save, savecontents, they have a configgroup as > parameter, so should be possible to save it anywhere in the config, even > under the systray's group But how do we get the config group (from the AppletInterface object of the systray plasmoid) into the containment (which is owned by the import)? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Wednesday 29 January 2014, Sebastian Kügler wrote: > On Wednesday, January 29, 2014 00:06:45 Marco Martin wrote: > > So, the import of the applet can have its own containment instance (not > > even a qml containment, just a dumb containment = new > > Plasma::Containment()) > > > > then if we manage to make its configgroup child of the systray config > > group, all should be just fine. > > So the configuration ends up as a "top level" containment in the config > file then, automatically, or do we need to wire that up somehow as well? > > Otherwise, good read. :) if the containment is just created and not added with corona::addContainment, then corona doesn't know anything about it, and you can manually call save, savecontents, they have a configgroup as parameter, so should be possible to save it anywhere in the config, even under the systray's group -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Wednesday, January 29, 2014 00:06:45 Marco Martin wrote: > So, the import of the applet can have its own containment instance (not even > a qml containment, just a dumb containment = new Plasma::Containment()) > > then if we manage to make its configgroup child of the systray config > group, all should be just fine. So the configuration ends up as a "top level" containment in the config file then, automatically, or do we need to wire that up somehow as well? Otherwise, good read. :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Tuesday 28 January 2014, Sebastian Kügler wrote:
> Hey,
>
> On Tuesday, January 28, 2014 21:14:10 Marco Martin wrote:
> > New prototype, completely different direction :) (and that's one i
> > actually like)
> >
> > mart/AppletAttached branch.
> > the root item of an applet can still be whatever item one wants, just as
> > current master, but plasmoid becomes an attached property, so it would be
> > possible to do things like Item {
> >
> > Plasmoid.title: i18n("stuff")
> > Plasmoid.onFormFactorChanged: {...}
> >
> > }
> >
> > besides not having a weird Applet component that may be instantiable from
> > anywhere, another advantage is that the porting can be scriptable,since
> > Property Item compactRepresentation: can be replaced with
> > Plasmoid.compactRepresentation property int minimumWidth with
> > Layout.minimumWidth and so on.
> >
> > I would make a fullRepresentation property available as well, but to
> > fallback to consider the root object the full representation if not
> > provided. this way less porting is needed and containments' main.qml
> > won't look completely stupid.
>
> A more logical cases would be to do it the other way around. The full
> representation is in our default cases for the panel only needed once the
> applet is opened / popup'ed from the panel. The compactRepresentation
> should be loaded first, so we can delay loading the more complex
> interfaces.
yeah, that's how i would like to do. using the root object as full
representation btw is pretty much for retrocompatibility (and removing
boilerplate in some cases)
then if instead Plasmoid.fullRepresentation is provided, that's not loaded
until the popup is open, as one would expect.
> That said, I like the AppletAttached version especially for its small code
> footprint.
>
> The AppletComponent branch seems quite large, and it's actually breaking
> everything, with the AppletAttached branch, everything still works here.
> This is pretty important since I'm feeling more and more uneasy about
> bringing in larger changes at this point.
>
> With the AppletComponent approach, we end up with more boilerplate for easy
> cases, which we hope to offset by more flexibility (but, given the code in
> the new branch, do we actually win that much here? Even with the current
> approach, it's about one Loader away to achieve very similar results.
now the attached version grown a bit as well, since i'm using the appletloader
class as well there for propagating Layout, but at least should be more
readable (compactRepresentationCheck() was the evil;)
but in the end i see that you pretty much have the same feelings as i have on
that code, it was an interesting experiment but it shown its limitations.
So i'll finish up the appletattached branch, and will update the porting
script since luckily in that case changes are regexp-able ;)
> > in any case both if this one or the other one is chosen, the systray will
> > have to be quite refactored, but i *may* have an idea to remove
> > completely appletinterface from the systray implementation
>
> With the systemtray, one actual problem with the design is that we "fake"
> an Applet, which isn't actually there. That means that
>
> I'm interested in what you can come up with. :)
It came to my mind tonight while i was writing the appletattached branch:
in plasma2, containments are just qobjects that contain applets, that are
again just qobjects, so no graphics involved there, pure model.
So, the import of the applet can have its own containment instance (not even a
qml containment, just a dumb containment = new Plasma::Containment())
then if we manage to make its configgroup child of the systray config group,
all should be just fine.
all the applets have already a dynamic property set, "graphicsObject" that
is.. oh right, AppletInterface :p
so i still have to think about how to control "create the full
representation", "create the compact representation, maybe even more than one"
bit, since all you have there is a QObject * so you can do not much more than
blind property reading and slot invocation.
But i think it can work... worst case scenario, the class that right now is
called appletloader that is a superclass of appletinterface could go in
libplasmaquick, so would become more controllable, while still not having the
full mess of appletinterface as public api
Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
Hey,
On Tuesday, January 28, 2014 21:14:10 Marco Martin wrote:
> New prototype, completely different direction :) (and that's one i actually
> like)
>
> mart/AppletAttached branch.
> the root item of an applet can still be whatever item one wants, just as
> current master, but plasmoid becomes an attached property, so it would be
> possible to do things like Item {
> Plasmoid.title: i18n("stuff")
> Plasmoid.onFormFactorChanged: {...}
> }
>
> besides not having a weird Applet component that may be instantiable from
> anywhere, another advantage is that the porting can be scriptable,since
> Property Item compactRepresentation: can be replaced with
> Plasmoid.compactRepresentation property int minimumWidth with
> Layout.minimumWidth and so on.
>
> I would make a fullRepresentation property available as well, but to
> fallback to consider the root object the full representation if not
> provided. this way less porting is needed and containments' main.qml won't
> look completely stupid.
A more logical cases would be to do it the other way around. The full
representation is in our default cases for the panel only needed once the
applet is opened / popup'ed from the panel. The compactRepresentation should
be loaded first, so we can delay loading the more complex interfaces.
That said, I like the AppletAttached version especially for its small code
footprint.
The AppletComponent branch seems quite large, and it's actually breaking
everything, with the AppletAttached branch, everything still works here. This
is pretty important since I'm feeling more and more uneasy about bringing in
larger changes at this point.
With the AppletComponent approach, we end up with more boilerplate for easy
cases, which we hope to offset by more flexibility (but, given the code in the
new branch, do we actually win that much here? Even with the current approach,
it's about one Loader away to achieve very similar results.
> in any case both if this one or the other one is chosen, the systray will
> have to be quite refactored, but i *may* have an idea to remove completely
> appletinterface from the systray implementation
With the systemtray, one actual problem with the design is that we "fake" an
Applet, which isn't actually there. That means that plasmoidprotocol.(h|cpp)
tries to do both, AppletInterface and Applet, which duplicates code from both.
It should do, however:
(0) hold the QML ui in small and expanded representation
(1) forward some properties of Applet (location)
It does (0) now in a slightly different way than the scriptengine's
appletinterface, and it only does (1) partly. One notably missing thing is
configuration. Systray plasmoids are at this point not configurable, for two
reasons: the configuration loading mechanism isn't included in the plasmoid
protocol (that's yet another thing which I think we would end up duplicating).
So maybe the following would work:
The plasmoid protocol provides items which each:
- are backed by an Applet (which we put maybe into an invisible Containment,
or use it without?). same plasmoid or Plasmoid attached properties.
- QQuickItem* compactRepresentation() (or even the root item)
- QQuickItem* configurationUI() (which uses the plasmoid.configuration stuff)
- QQuickItem* expandedRepresentation() (optional, content for the popup)
I'm interested in what you can come up with. :)
Cheers,
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
Hi all,
New prototype, completely different direction :) (and that's one i
actually like)
mart/AppletAttached branch.
the root item of an applet can still be whatever item one wants, just as
current master,
but plasmoid becomes an attached property, so it would be possible to do
things like
Item {
Plasmoid.title: i18n("stuff")
Plasmoid.onFormFactorChanged: {...}
}
besides not having a weird Applet component that may be instantiable from
anywhere, another advantage is that the porting can be scriptable,since
Property Item compactRepresentation: can be replaced with
Plasmoid.compactRepresentation
property int minimumWidth with Layout.minimumWidth and so on.
I would make a fullRepresentation property available as well, but to
fallback to consider the root object the full representation if not
provided. this way less porting is needed and containments' main.qml won't
look completely stupid.
in any case both if this one or the other one is chosen, the systray will
have to be quite refactored, but i *may* have an idea to remove completely
appletinterface from the systray implementation
Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
That QML demo seems to work awesomely \o/ I also fully support trying to get rid of AppletInterface. Code comments on the cpp. (I know it's a work in progress, but I like to stalk you) You have compactRepresentation properties twice. I assume the second one is meant to be the compactRepresentationExpander. In compactRepresentationCheck when iconified you still call QQuickItem *fullItem = qobject_cast(fullRepresentationItem()); which creates the fullRepresentation. I was under the impression we wanted to avoid loading the full representation when we're not using it. I don't fully understand what the compactRepresentationExpander is for. in compactRepresentation check we have: full = m_preferredRepresentation.data() == m_fullRepresentation.data(); which means, if the preferredRepresentation is the fullRepresentation, it will always be in full mode. If it is a more than just a preference would: full = m_compactRepresentation.isNull() be better? It will also be worth having a guard that that we're actually changing representations. Some sort of if (item != m_currentRepresentationItem). Otherwise we're setting a lot of things on every geometry change ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Friday 17 January 2014, Eike Hein wrote: > General comment: Please note that these size hints aren't only > there so the shell can decide which representation to pick, but > at times also do things like: on how the size hints would go and get propagated: I would use the "Layout" attached property from QtQuickControls layouts, so that's an official api I've done a quick qml-only sketch there: http://notmart.org/misc/appletmock.tar.bz2 just type qmlscene TestLayout.qml one thing i would like to achieve is to have that applet component use all the properties of the global plasmoid object, so AppletInterface would go away. Yes, having a global object *and* another component as root object bothers me so much that i consider it a dealbreaker for providing that applet component at all. A drawback however is that while it's probably possible, then containments would have to be a different component, so they would have to provide *two* main files, one for when it's an applet, one for when it's a containment. one good point, would be that it would probably simplify the mechanics of the systray a bit(moot point if the systray becomes a containment). -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Sat, Jan 18, 2014 at 3:17 PM, Martin Graesslin wrote: > On Saturday 18 January 2014 14:31:41 Mark Gaiser wrote: >> On Sat, Jan 18, 2014 at 8:58 AM, Martin Graesslin > wrote: >> > On Saturday 18 January 2014 01:11:54 Mark Gaiser wrote: >> >> I guess my arguments for going with the "Plasmoid" name rather then >> >> "Applet" are just ignored then? >> >> Sebas did gave "some" (few lines) explanation before my bunch of >> >> arguments. Yet i still think "Plasmoid" would suit it better. >> > >> > I think the name got mentioned in this thread: Applet was the name already >> > used in the C++ world, see [1]. So for anyone doing porting from a C++ >> > applet to a QML applet, the name Applet will be more reasonable. >> > >> > Personally I think Applet is a way better name as it is more generic and >> > people know what is meant with it, but Plasmoid is a domain specific name >> > people have to know. In the same way I went for Switcher in KWin although >> > our internal name is TabBox. The one is generic the other is domain >> > specific (and yes my QML code was first TabBox, then I thought about it >> > and renamed all of it). Of course Plasma already uses the name plasmoid >> > in the API and honestly I think that this is a mistake in the API. >> > >> > Cheers >> > Martin >> >> But your case to go for Switcher rather then TabBox is logical. Or to >> me it is :) >> The name "KWin.Switcher" tells me what it's going to do so it's chosen >> wisely. >> >> The name "Applet" doesn't tell me one thing. The name "Plasmoid" does. >> Since plasmoids are those visible things on the plasma desktop, i'd >> expect a plasmoid to be something visual on my desktop. Applet might >> indeed be more generic, but it doesn't tell me if it will be visible >> on the plasma desktop. Which it will most likely be! Thus i think >> "Plasmoid" is the better name since the name alone will give you the >> idea that it's something that will appear on the plasma desktop. >> >> Or am i completely wrong now? > > Take a step back and imagine you wouldn't know that these "thingies" are > called Plasmoid. E.g. your a developer who wants to provide an "app" for > Plasma Active. What would sound more logical to you? Applet or Plasmoid? I > assume everybody can understand what an applet is supposed to be and knows > them from other areas, too. But Plasmoid... I am taking a step back and am coming up with the name "Plasmoid". That is marketed to the outside world. Applet isn't. With Applet i think of java applets. Actually, if i really take a step FAR back i would call them "Widget". ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Saturday 18 January 2014 14:31:41 Mark Gaiser wrote: > On Sat, Jan 18, 2014 at 8:58 AM, Martin Graesslin wrote: > > On Saturday 18 January 2014 01:11:54 Mark Gaiser wrote: > >> I guess my arguments for going with the "Plasmoid" name rather then > >> "Applet" are just ignored then? > >> Sebas did gave "some" (few lines) explanation before my bunch of > >> arguments. Yet i still think "Plasmoid" would suit it better. > > > > I think the name got mentioned in this thread: Applet was the name already > > used in the C++ world, see [1]. So for anyone doing porting from a C++ > > applet to a QML applet, the name Applet will be more reasonable. > > > > Personally I think Applet is a way better name as it is more generic and > > people know what is meant with it, but Plasmoid is a domain specific name > > people have to know. In the same way I went for Switcher in KWin although > > our internal name is TabBox. The one is generic the other is domain > > specific (and yes my QML code was first TabBox, then I thought about it > > and renamed all of it). Of course Plasma already uses the name plasmoid > > in the API and honestly I think that this is a mistake in the API. > > > > Cheers > > Martin > > But your case to go for Switcher rather then TabBox is logical. Or to > me it is :) > The name "KWin.Switcher" tells me what it's going to do so it's chosen > wisely. > > The name "Applet" doesn't tell me one thing. The name "Plasmoid" does. > Since plasmoids are those visible things on the plasma desktop, i'd > expect a plasmoid to be something visual on my desktop. Applet might > indeed be more generic, but it doesn't tell me if it will be visible > on the plasma desktop. Which it will most likely be! Thus i think > "Plasmoid" is the better name since the name alone will give you the > idea that it's something that will appear on the plasma desktop. > > Or am i completely wrong now? Take a step back and imagine you wouldn't know that these "thingies" are called Plasmoid. E.g. your a developer who wants to provide an "app" for Plasma Active. What would sound more logical to you? Applet or Plasmoid? I assume everybody can understand what an applet is supposed to be and knows them from other areas, too. But Plasmoid... Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Sat, Jan 18, 2014 at 8:58 AM, Martin Graesslin wrote: > On Saturday 18 January 2014 01:11:54 Mark Gaiser wrote: >> >> I guess my arguments for going with the "Plasmoid" name rather then >> "Applet" are just ignored then? >> Sebas did gave "some" (few lines) explanation before my bunch of >> arguments. Yet i still think "Plasmoid" would suit it better. > > I think the name got mentioned in this thread: Applet was the name already > used in the C++ world, see [1]. So for anyone doing porting from a C++ applet > to a QML applet, the name Applet will be more reasonable. > > Personally I think Applet is a way better name as it is more generic and > people know what is meant with it, but Plasmoid is a domain specific name > people have to know. In the same way I went for Switcher in KWin although our > internal name is TabBox. The one is generic the other is domain specific (and > yes my QML code was first TabBox, then I thought about it and renamed all of > it). Of course Plasma already uses the name plasmoid in the API and honestly I > think that this is a mistake in the API. > > Cheers > Martin But your case to go for Switcher rather then TabBox is logical. Or to me it is :) The name "KWin.Switcher" tells me what it's going to do so it's chosen wisely. The name "Applet" doesn't tell me one thing. The name "Plasmoid" does. Since plasmoids are those visible things on the plasma desktop, i'd expect a plasmoid to be something visual on my desktop. Applet might indeed be more generic, but it doesn't tell me if it will be visible on the plasma desktop. Which it will most likely be! Thus i think "Plasmoid" is the better name since the name alone will give you the idea that it's something that will appear on the plasma desktop. Or am i completely wrong now? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Sat, Jan 18, 2014 at 10:56 AM, Marco Martin wrote: > On Saturday 18 January 2014, Mark Gaiser wrote: > >> > ___ >> > Plasma-devel mailing list >> > Plasma-devel@kde.org >> > https://mail.kde.org/mailman/listinfo/plasma-devel >> >> I guess my arguments for going with the "Plasmoid" name rather then >> "Applet" are just ignored then? >> Sebas did gave "some" (few lines) explanation before my bunch of >> arguments. Yet i still think "Plasmoid" would suit it better. > > possibly, but right now wether calling it Applet, Plasmoid or Bob is kinda the > last of the problems. > No, it is not. I will explain that down below. > personally i would prefer plasmoid as well, but if and only if the component > can be merged with AppletInterface, that is providing the "plasmoid" object at > the moment. otherwise wou have two "plasmoid" things that do two completely > different things. > As i said, that should be resolvable. However, i lack the knowledge (not a plasma developer!). You or the other folks replying in here do have that hat on and probably know very well if this is a problem or not. > what i'm interested at the moment is about a strategy to correctly switch > between representations, to correctly propagate size hints while keeping an > intuitive, as small as possible api. That is indeed important as well :) > > bikeshedding about the name won't make it happen. > looking at, and experimenting with the code will :p > Oh sure. I can make patches for you and send them to you. Code isn't the issue. However, i'm not a plasma dev and don't know what implications it might have so it obviously isn't a good idea if i start refactoring something this fundamental. As for the "I will explain that down below". You folks - plasma - have a big opportunity right now. Plasma 2 is basically re-developed from the ground up so now is the best time to fix inconsistency issues. To the outside world you call the small plasma applications "plasmoids" so i'd expect the naming to start moving to a consistent manner and name it as such in the important places. Just be consistent! If you go for applet then call it applet from now on. There is only one time when you can move in a more naming consistency manner without worrying about backwards compatibility and for plasma that is right now. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Saturday 18 January 2014, Mark Gaiser wrote: > > ___ > > Plasma-devel mailing list > > Plasma-devel@kde.org > > https://mail.kde.org/mailman/listinfo/plasma-devel > > I guess my arguments for going with the "Plasmoid" name rather then > "Applet" are just ignored then? > Sebas did gave "some" (few lines) explanation before my bunch of > arguments. Yet i still think "Plasmoid" would suit it better. possibly, but right now wether calling it Applet, Plasmoid or Bob is kinda the last of the problems. personally i would prefer plasmoid as well, but if and only if the component can be merged with AppletInterface, that is providing the "plasmoid" object at the moment. otherwise wou have two "plasmoid" things that do two completely different things. what i'm interested at the moment is about a strategy to correctly switch between representations, to correctly propagate size hints while keeping an intuitive, as small as possible api. bikeshedding about the name won't make it happen. looking at, and experimenting with the code will :p -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Saturday 18 January 2014 01:11:54 Mark Gaiser wrote: > > I guess my arguments for going with the "Plasmoid" name rather then > "Applet" are just ignored then? > Sebas did gave "some" (few lines) explanation before my bunch of > arguments. Yet i still think "Plasmoid" would suit it better. I think the name got mentioned in this thread: Applet was the name already used in the C++ world, see [1]. So for anyone doing porting from a C++ applet to a QML applet, the name Applet will be more reasonable. Personally I think Applet is a way better name as it is more generic and people know what is meant with it, but Plasmoid is a domain specific name people have to know. In the same way I went for Switcher in KWin although our internal name is TabBox. The one is generic the other is domain specific (and yes my QML code was first TabBox, then I thought about it and renamed all of it). Of course Plasma already uses the name plasmoid in the API and honestly I think that this is a mistake in the API. Cheers Martin [1] http://api.kde.org/4.x-api/kdelibs-apidocs/plasma/html/classPlasma_1_1Applet.html signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Saturday 18 January 2014 01:11:54 Mark Gaiser wrote: > I guess my arguments for going with the "Plasmoid" name rather then > "Applet" are just ignored then? Mark, I doubt Marco meant any disrespect; discussing the name just isn't really a priority while we're trying to work out the semantics. Keep in mind "how do we name it" is a classic bike- shed topic - it's easy to have an opinion on and so it's easy for people to feel compelled to voice one. Given finite time pushing out a test approach to play with has higher priority. Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Fri, Jan 17, 2014 at 9:25 PM, Marco Martin wrote:
> On Friday 17 January 2014, Marco Martin wrote:
>> Applet {
>>
>> compactRepresentation: Component {
>> PlasmaComponents.Button {
>> text: i18n("Click me")
>> onClicked: plasmoid.expanded = !plasmoid.expanded
>> }
>> }
>>
>> fullRepresentation: Component {
>> PlasmaComponents.Label {
>> SizeHint.minimumHeight: 300
>> SizeHint.minimumWidth: 200
>> //PlasmaCore.SizeHint.minimumHeight: 300
>> text: i18n("Hello world")
>> }
>> }
>> }
>>
>
> so, to recap, this is implemented-ish in the branch mart/AppletComponent
> and the applet compactrepresentation in examples/ uses it.
>
> to everybody, please take a look at the code, and play with it.
> i need ideas on how to do it, to see if is clunky to use, if covers needed use
> cases etc.
>
> Cheers,
> Marco Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
I guess my arguments for going with the "Plasmoid" name rather then
"Applet" are just ignored then?
Sebas did gave "some" (few lines) explanation before my bunch of
arguments. Yet i still think "Plasmoid" would suit it better.
Remember, i did take the time to thoroughly look at it. I expect at
least a constructive answer.
You folks asked feedback after all!
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Friday 17 January 2014, Marco Martin wrote:
> Applet {
>
> compactRepresentation: Component {
> PlasmaComponents.Button {
> text: i18n("Click me")
> onClicked: plasmoid.expanded = !plasmoid.expanded
> }
> }
>
> fullRepresentation: Component {
> PlasmaComponents.Label {
> SizeHint.minimumHeight: 300
> SizeHint.minimumWidth: 200
> //PlasmaCore.SizeHint.minimumHeight: 300
> text: i18n("Hello world")
> }
> }
> }
>
so, to recap, this is implemented-ish in the branch mart/AppletComponent
and the applet compactrepresentation in examples/ uses it.
to everybody, please take a look at the code, and play with it.
i need ideas on how to do it, to see if is clunky to use, if covers needed use
cases etc.
Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Friday 17 January 2014, Eike Hein wrote:
> General comment: Please note that these size hints aren't only
> there so the shell can decide which representation to pick, but
> at times also do things like:
>
> * Set useful default sizes (e.g. for popups from panels) *before*
> appearance.
> * Affect interaction behavior (e.g. lock down resizing in one
> axis but allow it in the other, by setting min/max accordingly).
> * Programmatically resize things while shown.
>
> Consider the Homerun Kicker launcher menu:
>
> http://i.imgur.com/eiq6D5w.png
> http://i.imgur.com/h9Y5jH2.png
> http://i.imgur.com/o3s3Bzk.png
> http://i.imgur.com/KG2R98u.png
>
> Here's a collection of things it does with sizing:
>
> * Not shown on the screenshot, but the compact representation
> shown on the panel supports custom non-square images that it
> scales while preserving aspect ratio, so it needs to hint
> that to the panel layout.
>
> * When the popup opens with the full representation inside,
> it's default size is optimized for its content.
>
> * It lets you adjust the height of the popup, but not the
> width ... which actually feels really nice when resizing,
> but is actually just a side-effect (more on this later).
>
> * It programmatically resizes its popup depending on the
> appearance of thos extra search result columns.
>
> Let's please avoid getting side-tracked with discussion over
> whether those specific use cases are things that should be
> done; the more interesting point is that someone ended up
> doing them in the real world, and that the set of legitimate
> use cases is at least conceivably really that wide.
>
> The other thing is that this was actually pretty hard to pull
> off in Plasma 1. There are some redundant APIs in the
> plasmoid API in Plasma 1 - some prop-based, some procedural -
> and not all of them actually work. There are syncing and
> ordering problems with applying the root props to the popup
> applet, which e.g. necessitated locking down the horizontal
> axis to also be able to do the programmatic resize. I also got
> the feeling that props on the root vs. props on the compact
> repr were getting confused depending on the order in which
> things were set ... but I don't remember the details, sorry,
> I should have kept more extensive notes.
>
> I think the guiding principle for redesigning this stuff in
> Plasma 2 should be "explicit is better than implicit". Let's
> try to avoid doing magic props that mean this thing in this
> circumstance and this other thing in this other circumstance,
> it's better to be expressive and be able to specify the props
> for each circumstance and give applet authors control. There
> is always another pressure acting on them not to abuse the
> control: Users don't like crap UI that does dumb things, so
> policing these things hard often isn't necessary and ends up
> limiting use cases instead.
so, at the moment, in my branch things are something like that:
root object is called Applet, so it has "real" properties
compactRepresentation/fullRepresentation
those two components support an attached property called SizeHint,
so you have something like:
Applet {
compactRepresentation: Component {
PlasmaComponents.Button {
text: i18n("Click me")
onClicked: plasmoid.expanded = !plasmoid.expanded
}
}
fullRepresentation: Component {
PlasmaComponents.Label {
SizeHint.minimumHeight: 300
SizeHint.minimumWidth: 200
//PlasmaCore.SizeHint.minimumHeight: 300
text: i18n("Hello world")
}
}
}
dimensions of the applet in the panel or the dimensions of the pospup should
follow size hints
to correctly switch it would also need something like a
switchHeight/switchWidth properties in Applet, since fullRepresentation may
not exist
this should cover most of the things you wrote about
(like a compactRepresentation that has minimumWidth: height*ratio should work
just fine)
another thing that will be necessary is a way to make applets providing a
single representation, like the taskbar doesn't have a compact one
only thing i'm afraid of, it becomes cooomplex, code-wise and for new
developers to understand
Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
General comment: Please note that these size hints aren't only there so the shell can decide which representation to pick, but at times also do things like: * Set useful default sizes (e.g. for popups from panels) *before* appearance. * Affect interaction behavior (e.g. lock down resizing in one axis but allow it in the other, by setting min/max accordingly). * Programmatically resize things while shown. Consider the Homerun Kicker launcher menu: http://i.imgur.com/eiq6D5w.png http://i.imgur.com/h9Y5jH2.png http://i.imgur.com/o3s3Bzk.png http://i.imgur.com/KG2R98u.png Here's a collection of things it does with sizing: * Not shown on the screenshot, but the compact representation shown on the panel supports custom non-square images that it scales while preserving aspect ratio, so it needs to hint that to the panel layout. * When the popup opens with the full representation inside, it's default size is optimized for its content. * It lets you adjust the height of the popup, but not the width ... which actually feels really nice when resizing, but is actually just a side-effect (more on this later). * It programmatically resizes its popup depending on the appearance of thos extra search result columns. Let's please avoid getting side-tracked with discussion over whether those specific use cases are things that should be done; the more interesting point is that someone ended up doing them in the real world, and that the set of legitimate use cases is at least conceivably really that wide. The other thing is that this was actually pretty hard to pull off in Plasma 1. There are some redundant APIs in the plasmoid API in Plasma 1 - some prop-based, some procedural - and not all of them actually work. There are syncing and ordering problems with applying the root props to the popup applet, which e.g. necessitated locking down the horizontal axis to also be able to do the programmatic resize. I also got the feeling that props on the root vs. props on the compact repr were getting confused depending on the order in which things were set ... but I don't remember the details, sorry, I should have kept more extensive notes. I think the guiding principle for redesigning this stuff in Plasma 2 should be "explicit is better than implicit". Let's try to avoid doing magic props that mean this thing in this circumstance and this other thing in this other circumstance, it's better to be expressive and be able to specify the props for each circumstance and give applet authors control. There is always another pressure acting on them not to abuse the control: Users don't like crap UI that does dumb things, so policing these things hard often isn't necessary and ends up limiting use cases instead. Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Thu, Jan 16, 2014 at 12:59 PM, Sebastian Kügler wrote:
> On Wednesday, January 15, 2014 20:36:24 Mark Gaiser wrote:
>> On Wed, Jan 15, 2014 at 6:19 PM, Marco Martin wrote:
>> > On Wednesday 15 January 2014 16:43:43 Mark Gaiser wrote:
>> >> 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."
>> >
>> > i would call it Plasmoid if i can merge it with the plasmoid object, that
>> > is now an object registered in the root context. i'm not sure it's
>> > possible, would like to tough.
>>
>> From my "relative outsider view" Plasmoid {} seems far more obvious
>> then Applet {} so if the plasma folks agree on that then i would go
>> for that.
>
> Applet is the API name for this, so it should be called Applet, cf.
> Plasma::Applet, which is what this really implements. Plasmoid is more like
> the package format we ship these things in.
I disagree with that.
Look at it from an outsider perspective. I am a relative outsider when
it comes to plasma.
If i want to make a QML application for plasma i would assume it's
called "plasmoid" since it's called like that in KDE and on kde-look
as well. If i would want to make one i would probably search for
something like "creating plasmoid in qml" or "plasmoid qml example".
Do you see the common word? I never ever even think of "applet" yet
somehow the root of a plasmoid object is... Applet {..}. This just
seems vague to me.
If you search for kde applets (on google) the very first link you get
is explaining plasmoids!
http://techbase.kde.org/Projects/Plasma/Plasmoids
Everything just leads me to think that it should be called "Plasmoid".
Applet seems vague to me.
So please, do thoroughly reconsider calling it Applet { .. }. If you
persist with Applet then you might as well call it "Widget". Since the
common name for this stuff is widgets [1] anyhow. It which even seems
to have a web standard nowadays [2]. And a real novice user that
doesn't know plasmoids "might" just know the term "widgets" since that
is more commonly used and would thus search for something like
"widgets for kde" which funnily enough brings you to plasma's
predecessor "superkaramba" [3] which even more funnily calls the
plasmoids "Plasma widgets" on that very same page.
> The point of having minimum* in the Applet object is easy: it's the Item's
> size (as allowed by the containment) fits within minumum*, fullRepresentation
> is loaded and rendered (and parented to the surrounding Item, if not,
> compactRepresentation is used. Only one of them is loaded, reducing overhead
> in many cases.
Sorry, but i don't understand what you're trying to say here.
I've re-read your text at least a dozen times (seriously!).
What do you mean by: "it's (if) the Item's size (as allowed by the
containment) fits within minumum*"?
Please stick to the naming we're discussing here. Since now we're
using another name for the same thing: "item".. I'm getting really
confused right now!
- "as allowed by the containment" .. What do you mean?
- "if not"... I don't even get the first condition.
[1] http://www.apple.com/downloads/dashboard/
[2] http://www.w3.org/TR/widgets/
[3] http://www.kde.org/applications/utilities/superkaramba/
>
>> Now i'm starting to like it since - to me - it now makes sense.
>> For those two representations. I would say that one must exist.
>> Neither is mandatory on it's own, but one must be there at all time.
>
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Wednesday, January 15, 2014 20:36:24 Mark Gaiser wrote:
> On Wed, Jan 15, 2014 at 6:19 PM, Marco Martin wrote:
> > On Wednesday 15 January 2014 16:43:43 Mark Gaiser wrote:
> >> 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."
> >
> > i would call it Plasmoid if i can merge it with the plasmoid object, that
> > is now an object registered in the root context. i'm not sure it's
> > possible, would like to tough.
>
> From my "relative outsider view" Plasmoid {} seems far more obvious
> then Applet {} so if the plasma folks agree on that then i would go
> for that.
Applet is the API name for this, so it should be called Applet, cf.
Plasma::Applet, which is what this really implements. Plasmoid is more like
the package format we ship these things in.
> As for the current Plasmoid in the root context.. That can go and be
> merged in this Plasmoid {}. You always need to have that object anyway
> thus the result will be the same. Only now it will be created
> "because" you defined it and not just injected in the root context :)
>
> Sounds like a win/win to me.
>
> The only downside is required refactoring :p
>
> >> 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
The idea is that compactrepresentation does not have a minimum size, it's the
fallback when things don't fit. Applets don't control their own size, they
have to deal with the space they get.
> > good point, compactRepresentation and fullRepresentation should export
> > those as attached properties, and the root object should not.
>
> Just so that it's clear. So you just basically decided that the bare
> minimum for a plasmoid (in plasma 2) is likely going to look like
> this:
>
> Plasmoid {
> compactRepresentation: Component {
> minimumWidth: ...
> minimumHeight: ...
> }
> fullRepresentation: Component {
> minimumWidth: ...
> minimumHeight: ...
> }
> }
>
> right?
Nope, even simpler:
Applet {
mininumWidth: ...
minimumHeight: ...
compactRepresentation: Component { }
fullRepresenation: Component { }
/* shared logic goes here, for example: */
DataSource {
...
}
function fooMyBar(argument) {
...
}
}
The point of having minimum* in the Applet object is easy: it's the Item's
size (as allowed by the containment) fits within minumum*, fullRepresentation
is loaded and rendered (and parented to the surrounding Item, if not,
compactRepresentation is used. Only one of them is loaded, reducing overhead
in many cases.
> Now i'm starting to like it since - to me - it now makes sense.
> For those two representations. I would say that one must exist.
> Neither is mandatory on it's own, but one must be there at all time.
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Wed, Jan 15, 2014 at 6:19 PM, Marco Martin wrote:
> On Wednesday 15 January 2014 16:43:43 Mark Gaiser wrote:
>
>> 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."
>
> i would call it Plasmoid if i can merge it with the plasmoid object, that is
> now an object registered in the root context. i'm not sure it's possible,
> would like to tough.
>From my "relative outsider view" Plasmoid {} seems far more obvious
then Applet {} so if the plasma folks agree on that then i would go
for that.
As for the current Plasmoid in the root context.. That can go and be
merged in this Plasmoid {}. You always need to have that object anyway
thus the result will be the same. Only now it will be created
"because" you defined it and not just injected in the root context :)
Sounds like a win/win to me.
The only downside is required refactoring :p
>
>>
>> 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
>
> good point, compactRepresentation and fullRepresentation should export those
> as attached properties, and the root object should not.
Just so that it's clear. So you just basically decided that the bare
minimum for a plasmoid (in plasma 2) is likely going to look like
this:
Plasmoid {
compactRepresentation: Component {
minimumWidth: ...
minimumHeight: ...
}
fullRepresentation: Component {
minimumWidth: ...
minimumHeight: ...
}
}
right?
Now i'm starting to like it since - to me - it now makes sense.
For those two representations. I would say that one must exist.
Neither is mandatory on it's own, but one must be there at all time.
>
>> 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 :)
>
> all feedback is ;)
>
> --
> Marco Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Wednesday 15 January 2014 16:43:43 Mark Gaiser wrote:
> 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."
i would call it Plasmoid if i can merge it with the plasmoid object, that is
now an object registered in the root context. i'm not sure it's possible,
would like to tough.
>
> 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
good point, compactRepresentation and fullRepresentation should export those
as attached properties, and the root object should not.
> 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 :)
all feedback is ;)
--
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Wed, Jan 15, 2014 at 4:43 PM, Mark Gaiser wrote:
>
> 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{}.
>
However, plasmoids are not "just QML", they are pieces of the shell and as
such I think it's perfectly fine it's a bit different - the whole purpose
of plasmoids is slightly different.
Also, related to that, that's why we need good docs and/or tutorial where
it is explained or simply pointed out. You /need/ to read docs to start
developing components of anything anyway, so imho introducing another
thing, different from plain QML, is perfectly fine :)
I hope you find my feedback valuable and not nitpicking :)
Every feedback is great, thanks for it ;)
Cheers
--
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Wednesday 15 January 2014 16:43:43 Mark Gaiser wrote:
> I don't think KDE should add another one:
> Applet {
> ...
> }
and in KWin I recently added:
KWin.Switcher {
...
}
and I love it. So much cleaner code base. Exactly same thing as proposed here:
non-visual QObject as root element.
Cheers
Martin
signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Tue, Jan 14, 2014 at 11:35 PM, Marco Martin 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@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
Code comment:
Make sure you default m_minimumWidth and the others to something in
the ctor and check your usage of width when you mean height :)
It might be a good idea to have a default property of type
QmlListProperty so that Applets can have child objects in the
QML for all their models/shared data without having to declare random
properties to store children. Danger is people might randomly add in
GUI items and then get confused that nothing shows. I'm not sure.
I think on the applet object:
- minimumSize is useless (if the layout makes us super small, we'll
load the compact representation and then automatigally use the minimum
size of that and re-layout)
- maximumSize is useless (if the layout makes us super huge, we'll
load the full representation, and then the maximumSize will be loaded
from that and relayout)
- implicitSize becomes the default size when you add a plasmoid to
the desktop - at which point we can kill that from the
fullRepresentation (I'm not super sure on that?)
Obviously we want to avoid re-layouts as they're expensive, but right
now that's kinda unavoidable unless we happen to have the same values
in applet and in compact/full which will be hard to enforce. It will
be no worse than the current setup.
Maybe we want:
MyCompactRepresentation
{
property size minimumSize
property size implicitSize
}
MyFullRepresentation
{
property size maximumSize
}
Applet {
property size defaultSize
property size smallestCompactSize
}
Lets have a discussion tomorrow with the whiteboard and lots of scribbling.
David
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
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
> 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 ;)
> 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@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Tue, Jan 14, 2014 at 8:14 PM, Marco Martin wrote:
> Hi all,
> those are some notes in a probable API change that will probably happen (let's
> discuss!) on how QML plasmoids are written.
>
> The problem:
> * plasmoids needs some properties in the root object, such as minimumWidth,
> maximumWidth, compactRepresentation..
> * the user has to declare *and* implement them: completely magic, the bad
> magic
> * we want async loading as much as possible: ifwe are in a popup, the "main"
> applet area should be loaded only when the popup opens. this is right now
> possible but has to be made quite explicitly with the ConditionalLoader
> component
>
> The proposal:
> * force plasmoids implementations to implement a new component, called Applet
> or something like that
> * this component is a simple QObject, so it can't contain any UI
> * it exports explicitly the properties we need: minimumWidth/height other
> sizes, compactRepresentation..
> * and a new component: fullRepresentation: it will contain the stuff that are
> intended to go in the full applet, so the popup contents or the full view in
> the desktop.
> * both compact and full representation are created on demand when needed, so
> are *not* guaranteed to always exist.
> * everything that needs to always exist is stuff like model and dataengines
> (therefore not graphical) this will have to be child of the root Applet item.
> (another proposal was to make another property that contains it)
> * another thing i was thinking about is that some AppletInterface
> functionalities can be moved there (can be "plasmoid" the root object? i am
> not sure how much technically feasible, it may be experimented tough)
>
>
> Pros:
> * allows experiments: one day we may have a "mediacenterrepresentation" and so
> on
> * neat api
>
> Cons:
> * may not make fully sense in containments: compactRepresentation is
> meaningless here
> * will break *all* plasmoids, will be necessary to adapt everything, how much
> will delay?
>
> a draft of the Appelt api can be found in the branch mart/AppletComponent in
> plasma-framework
>
> Cheers,
> Marco Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
Hi Marco,
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?
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 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.
Cheers,
Mark
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from "Async and representation"
On Tuesday 14 January 2014 20:14:55 you wrote: > * everything that needs to always exist is stuff like model and dataengines > (therefore not graphical) this will have to be child of the root Applet > item. (another proposal was to make another property that contains it) > * another thing i was thinking about is that some AppletInterface > functionalities can be moved there (can be "plasmoid" the root object? i am > not sure how much technically feasible, it may be experimented tough) Another thing that David just pointed to me: minimum/preferred/implicitwidth will have to be exported by compact/fullRepresentation as well, and since at least those should be any arbitrary item, so it should be an attached property, just as Layout of QtControls layouts. http://qt-project.org/doc/qt-5.1/qtquicklayouts/qml-qtquick-layouts1-layout.html at this point it may be an attached property in the Applet component as well. (everything may be an attached property and the applet component not be there if we push it, but it may look weird) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Notes from "Async and representation"
Hi all, those are some notes in a probable API change that will probably happen (let's discuss!) on how QML plasmoids are written. The problem: * plasmoids needs some properties in the root object, such as minimumWidth, maximumWidth, compactRepresentation.. * the user has to declare *and* implement them: completely magic, the bad magic * we want async loading as much as possible: ifwe are in a popup, the "main" applet area should be loaded only when the popup opens. this is right now possible but has to be made quite explicitly with the ConditionalLoader component The proposal: * force plasmoids implementations to implement a new component, called Applet or something like that * this component is a simple QObject, so it can't contain any UI * it exports explicitly the properties we need: minimumWidth/height other sizes, compactRepresentation.. * and a new component: fullRepresentation: it will contain the stuff that are intended to go in the full applet, so the popup contents or the full view in the desktop. * both compact and full representation are created on demand when needed, so are *not* guaranteed to always exist. * everything that needs to always exist is stuff like model and dataengines (therefore not graphical) this will have to be child of the root Applet item. (another proposal was to make another property that contains it) * another thing i was thinking about is that some AppletInterface functionalities can be moved there (can be "plasmoid" the root object? i am not sure how much technically feasible, it may be experimented tough) Pros: * allows experiments: one day we may have a "mediacenterrepresentation" and so on * neat api Cons: * may not make fully sense in containments: compactRepresentation is meaningless here * will break *all* plasmoids, will be necessary to adapt everything, how much will delay? a draft of the Appelt api can be found in the branch mart/AppletComponent in plasma-framework Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
