Re: plans for Plasma Desktop default containment in QML
On Wednesday, October 24, 2012 11:39:59 Marco Martin wrote: > about qml containments, a thing that is not uber pretty that i encountered > working on the one for active is that while plasmoids have only a limited > acces to theyr Applet* trough AppletInterface, plasmoids have direct access > to Applet* pointers of their plasmoids, so paradoxically more access to > others than to themselves > is something that we want to keep?/do something about? yes, for a containment this is fine imho ... -- Aaron J. Seigo 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: plans for Plasma Desktop default containment in QML
On Monday, October 22, 2012 13:33:45 Sebastian Kügler wrote: > My overall thinking is that I'd like the infrastructural work to be complete > for the 4.10 release (which seems achievable to me if we don't run into > architectural problems) so that Plasma 4.10 brings everything needed to run > full-featured QML containments. We can then invite users to try the new > default containment, give us feedback and give it a couple of iterations > until perfection. (As the new containment is a pure QML package, our group > of testers is not limited to those being able to wield a compiler.) > > You can find the code in kde-workspace's plasma/sebas/desktop-qml branch, > you'll also need kde-runtime's plasma/sebas/desktop-qml branch for the > bindings extensions and bugfixes that are still in process of being merged. > Be aware that it's really work-in-progress and that anything could change, > anytime. I'm concentrating on getting the toolbox to work in all aspects, > then will likely move to the Applethandle. After a little huddle on IRC with Marco and Aaron, we've come up with the following strategy for handling actions in context menu and toolbox: - new import org.kde.plasma.containments in kde-runtime - new AbstractContainment class exported to QML - exposes actions as properties: contextualActions, toolBoxActions - actions come from Corona, Containment, ToolBox and ContainmentActions and are sorted, filtered by their kind - toolbox uses action from Containment.toolBoxActions and is otherwise it's an implementation detail - context menu uses contextualActions() (but is handled in Corona right now, so will stay as-is) I'm hacking on implementing this. 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: plans for Plasma Desktop default containment in QML
Hey, On Wednesday, October 24, 2012 11:39:59 Marco Martin wrote: > On Monday 22 October 2012, Sebastian Kügler wrote: > > being merged in the process), some are things that we have been shipping > > in the MobileComponents QML module for some time. (MobileComponents has > > somehow grown to be a dumping ground for "stuff that didn't fit well > > elsewhere", and we're in the process of cleaning that up, moving pieces of > > it to places which fit better (PlasmaExtras has gotten some, for example.) > > One of those pieces is the AppletContainer, but there's also the odd thing > > that we have just no solution for right now (for example KAuthorized calls > > if the user's allowed to log out). I'm trying to find sensible places for > > what i would like is another import, like org.kde.plasma.containments > > that contains only stuff intended to be a toolkit for containments: > AppletContainer can be one, then default applethandles would go there as > well, as toolboxes (replacing them with qml may require a bit more of > architectural change, so that may need to be delayed) I've actually implemented the toolbox as part of the containment, but that can surely be moved out into our new import. > one thing that we may even do at some point is to install them somewhere > else compared to the others, so that import folder would be included only > in containments, being inaccessible for plasmoids and apps. Ok, something for later, once we have a basic working set, but still before many others are going to use it -- 4.11 timeframe? > about qml containments, a thing that is not uber pretty that i encountered > working on the one for active is that while plasmoids have only a limited > acces to theyr Applet* trough AppletInterface, plasmoids have direct access > to Applet* pointers of their plasmoids, so paradoxically more access to > others than to themselves Not sure I understand what you mean here? > is something that we want to keep?/do something about? 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: plans for Plasma Desktop default containment in QML
On Monday 22 October 2012, Sebastian Kügler wrote: > being merged in the process), some are things that we have been shipping > in the MobileComponents QML module for some time. (MobileComponents has > somehow grown to be a dumping ground for "stuff that didn't fit well > elsewhere", and we're in the process of cleaning that up, moving pieces of > it to places which fit better (PlasmaExtras has gotten some, for example.) > One of those pieces is the AppletContainer, but there's also the odd thing > that we have just no solution for right now (for example KAuthorized calls > if the user's allowed to log out). I'm trying to find sensible places for what i would like is another import, like org.kde.plasma.containments that contains only stuff intended to be a toolkit for containments: AppletContainer can be one, then default applethandles would go there as well, as toolboxes (replacing them with qml may require a bit more of architectural change, so that may need to be delayed) one thing that we may even do at some point is to install them somewhere else compared to the others, so that import folder would be included only in containments, being inaccessible for plasmoids and apps. about qml containments, a thing that is not uber pretty that i encountered working on the one for active is that while plasmoids have only a limited acces to theyr Applet* trough AppletInterface, plasmoids have direct access to Applet* pointers of their plasmoids, so paradoxically more access to others than to themselves is something that we want to keep?/do something about? Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plans for Plasma Desktop default containment in QML
On Monday, October 22, 2012 17:19:32 todd rme wrote: > Can you submit it to kde-look.org in the meantime? Does plasma > support installing containments through GHNS? There has been no such integration yet; all the client-side stuff is there (e.g. plasmapkg), but there is no scripted containments category on kde-look and there is no "get new layouts" button in the UI... so it is easily possible, but is not currently there. -- Aaron Seigo 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: plans for Plasma Desktop default containment in QML
On Monday, October 22, 2012 17:19:32 todd rme wrote: > Can you submit it to kde-look.org in the meantime? Does plasma > support installing containments through GHNS? Sure, and I don't know. :) I'll roll a package once I've got a few more features in, and when feedback starts making sense (i.e. != "yeah, I didn't get to that, yet") in the meantime you can get it freshly from Git. -- 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: plans for Plasma Desktop default containment in QML
On Mon, Oct 22, 2012 at 1:33 PM, Sebastian Kügler wrote: > Hi fellow Plasma devs, > > I've been working on a QML port of our default desktop containment. It's still > very immature, and a few feature are lacking, but it lead me to think about > how we could go about replacing the default desktop with this eventually. > > Now it won't be ready (in sufficient quality) for the 4.10 feature freeze, but > I'd like to give our users a way to provide feedback before we actually > replace the current C++ containment. > > About the containment itself, it's of course supposed to be on feature-parity > with the current containment, and I'm aiming for having it look at least as > polished as that one. My current work is loosely based on Marco's Activity > Screen containment which is in use for quite some time in Plasma Active, > though it only reuses its applet placing mechanism. > > This work goes along with a number of merges, some of which are bugfixes (not > much to talk about, I'm filing review requests as we go, they're being merged > in the process), some are things that we have been shipping in the > MobileComponents QML module for some time. (MobileComponents has somehow grown > to be a dumping ground for "stuff that didn't fit well elsewhere", and we're > in the process of cleaning that up, moving pieces of it to places which fit > better (PlasmaExtras has gotten some, for example.) One of those pieces is the > AppletContainer, but there's also the odd thing that we have just no solution > for right now (for example KAuthorized calls if the user's allowed to log > out). I'm trying to find sensible places for those (for example some of them > can go into the containment bindings as that's what they're used for), filing > reviewrequests for those things in the process so we can decide on a case-by- > case basis. > > My overall thinking is that I'd like the infrastructural work to be complete > for the 4.10 release (which seems achievable to me if we don't run into > architectural problems) so that Plasma 4.10 brings everything needed to run > full-featured QML containments. We can then invite users to try the new > default containment, give us feedback and give it a couple of iterations until > perfection. (As the new containment is a pure QML package, our group of > testers is not limited to those being able to wield a compiler.) > > You can find the code in kde-workspace's plasma/sebas/desktop-qml branch, > you'll also need kde-runtime's plasma/sebas/desktop-qml branch for the > bindings extensions and bugfixes that are still in process of being merged. Be > aware that it's really work-in-progress and that anything could change, > anytime. I'm concentrating on getting the toolbox to work in all aspects, then > will likely move to the Applethandle. > > So, just a heads-up of current plans and impressions. Feedback is naturally > welcome. :) > > Cheers, > -- > sebas Can you submit it to kde-look.org in the meantime? Does plasma support installing containments through GHNS? -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
