> On July 22, 2014, 3:59 p.m., Aleix Pol Gonzalez wrote:
> > src/scriptengines/qml/plasmoid/appletinterface.cpp, line 555
> > <https://git.reviewboard.kde.org/r/119409/diff/1/?file=291856#file291856line555>
> >
> >     Why can't you just call the method? You're not delaying it
> 
> Marco Martin wrote:
>     ah, no, because that thig is a bit hackish..
>     is not a method of corona, just a slot of desktopcorona.
>     not proud of it at all, but that doesn't really belong to the base 
> corona, but i think creating and showing the ui is a very shell thing..
> 
> Aleix Pol Gonzalez wrote:
>     I'd say that if it's generic enough for plasma-framework, then it can be 
> in corona. I can see it being useful for plasma kpart, for example.
>     
>     Also if it's only available on some shells, maybe you only want to add 
> the action on those?
> 
> Marco Martin wrote:
>     I don't think as a method, but as corona has the signal
>     void configureRequested(Plasma::Applet *applet); it may have a similar 
> behaving signal appletAlternativesRequested(Applet*), it would make a nice 
> symmetry (in this case the creation of the action may even go down in Applet).
>     
>     about the action, yeah, would be nice to only have it on some shells, 
> tough i can't add it from within the shell (since i would have to iterate all 
> applets and add it when a containment appears) so i think it may have to stay 
> there for all of them.
> 
> Aleix Pol Gonzalez wrote:
>     Maybe it would make sense to have something like:
>     virtual void Corona::configureApplet(Applet* a)
>     
>     So that shells could set up actions as they pleased.
> 
> Marco Martin wrote:
>     hmm, this would make possible to move almost everything of this in the 
> shell, and would be nice, like the idea.
>     wonder if it's not giving it too much control tough

ABI means you can't add a virtual (easily), which sucks. 

A signal appletAdded(Applet*) might be more generic and still allow the same 
functionality. This could just be forwarding the signal that containment has 
anyway so not providing any new control, just making it easier for people to 
inject actions and alike.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119409/#review62891
-----------------------------------------------------------


On July 22, 2014, 4:10 p.m., Marco Martin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119409/
> -----------------------------------------------------------
> 
> (Updated July 22, 2014, 4:10 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> -------
> 
> this is the little part in plasma-framework for the applet alternatives 
> chooser.
> works together the branch mart/alternativesConfig of plasma-workspace and 
> plsma-desktop.
> for how it looks and why, see the vdg forum thread:
> https://forum.kde.org/viewtopic.php?f=285&t=122067&p=315919#p315919
> 
> still possible problems:
> * the branch in framework is kinda screwed, too many merges, is probably 
> better to push this diff as a single commit
> * I'm not sure about using a new desktop file entry X-Plasma-Provides, 
> *maybe* Categories could be enough, but it may produce many false positives 
> as well
> 
> 
> Diffs
> -----
> 
>   src/plasma/data/servicetypes/plasma-applet.desktop b75c3d6 
>   src/scriptengines/qml/plasmoid/appletinterface.h fe50825 
>   src/scriptengines/qml/plasmoid/appletinterface.cpp e5f7985 
> 
> Diff: https://git.reviewboard.kde.org/r/119409/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Reply via email to