Review Request: associate an external tool to an applet

[Marco Martin]

> On 2009-09-15 04:32:47, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/applet.cpp, lines 1985-1987
> > <http://reviewboard.kde.org/r/1606/diff/2/?file=11441#file11441line1985>
> >
> >     this is actually unecessary; KRun does all of this for you, including re-using the mimetype fetching job.

hmm, but i actuall need to fetch the mimetype no? runurl wants it as arameter, so it doesn't try to understand it by itself no?


> On 2009-09-15 04:32:47, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/applet.cpp, line 1850
> > <http://reviewboard.kde.org/r/1606/diff/2/?file=11441#file11441line1850>
> >
> >     is this synchronous? i think it is; probably should create a KRun object and connect to its signals (or just ignore the result, even?) so that it isn't synchronous and holding up the application.

ok


> On 2009-09-15 04:32:47, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/applet.cpp, line 1848
> > <http://reviewboard.kde.org/r/1606/diff/2/?file=11441#file11441line1848>
> >
> >     you should stop the job here, no? or perhaps put it on hold and publish it so that the app can then use it?

hmm, not sure it would be useful published?


> On 2009-09-15 04:32:47, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/applet.cpp, line 1980
> > <http://reviewboard.kde.org/r/1606/diff/2/?file=11441#file11441line1980>
> >
> >     you know what would be dreadfully cool? if there was an external tool manager that, when an app was triggered, it would see if that resulted in a window popping up. if so, then it could track that window and as long as that window existed, it could become associated with the widget?
> >     
> >     might not work so hot, i suppose, if you open an image in a viewer, navigate to another image in the viewer, and then click the widget's "run" icon again. hmm...
> >     
> >     another benefit of having a manager for these would be that instead of having an extra set of members in the applet's dptr regardless of whether or not it uses this feature, there would only be one manager and only as many objects in memory as there are widgets using this feature.

a singleton? accessible in the public api? and it should avoid to launch the app two times?


> On 2009-09-15 04:32:47, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/applet.h, lines 631-637
> > <http://reviewboard.kde.org/r/1606/diff/2/?file=11440#file11440line631>
> >
> >     external -> associated?
> >     tool -> application?
> >     
> >     we will need to have a non-KService version of the tool definer method since not all apps will be registered in that manner. i think we could probably just take a string and figure out ourselves internally if it's a service or an executable.
> >     
> >     as for arguments ... hm. use cases could be:
> >     
> >     * command line arguments (e.g. konsole -e ls -lR)
> >     * URLs
> >     * ...?
> >     
> >     probably needs more use case thinking. 
> >     
> >     if it does remain limited to URLs (and i think an API that makes launching apps with urls would be a good idea), then that might be a more generic sort of thing: associatedUrls()? 
> >     
> >     it will need to support url lists.
> >     
> >     a "does this applet have a valid associated app?" convenience method would be nice
> >     
> >

ok, so it should take a string and then try to obtain a service out of it.
if it fails it gets executed as a command... i wasn't really sure about that since i wanted to avoid people passing absolute urls and then complainig it's broken, but well, their bad..

for the list of urls i'm wondering if the app is not present would make sense to try to run all of them, it could be massive...


- Marco


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1606/#review2367
-----------------------------------------------------------


On 2009-09-14 15:04:43, Marco Martin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1606/
> -----------------------------------------------------------
> 
> (Updated 2009-09-14 15:04:43)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> -------
> 
> first implementation of an idea discussed @tokamak: add api to assign the execution of something to an applet. the rationale is to launch an app that is the "full version" of that applet, where the applet serves as little preview.
> it is possible to assign a kservice (usually used with kservice::servicefromdesktopfile("app name")) and an optional argument.
> if the service is missing and the argument url is present the url will be opened based on its mimetype.
> an applethandle icon and a context menu entry will be added to launch that external tool
> now there are roe rough edges:
> -api: pass kservice and url or just strings to make bindings easier?
> -urls: right now there is only one parameter: maybe having support for a list?
> -naming: now all the names are talking about an "external tool", the applet handle uses the "maximize" icon, calling it maximize everywhere? i would leave external tool in the api and call maximize the action and the action text, that is what is presented to the user..
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdelibs/plasma/applet.h 1023331 
>   /trunk/KDE/kdelibs/plasma/applet.cpp 1023331 
>   /trunk/KDE/kdelibs/plasma/containment.cpp 1023331 
>   /trunk/KDE/kdelibs/plasma/private/applet_p.h 1023331 
>   /trunk/KDE/kdelibs/plasma/private/applethandle.cpp 1023331 
>   /trunk/KDE/kdelibs/plasma/private/applethandle_p.h 1023331 
> 
> Diff: http://reviewboard.kde.org/r/1606/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Marco
> 
>