Review Request: associate an external tool to an applet

[Aaron Seigo]

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



/trunk/KDE/kdelibs/plasma/applet.h
<http://reviewboard.kde.org/r/1606/#comment1666>

    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
    
    



/trunk/KDE/kdelibs/plasma/applet.cpp
<http://reviewboard.kde.org/r/1606/#comment1667>

    you should stop the job here, no? or perhaps put it on hold and publish it so that the app can then use it?



/trunk/KDE/kdelibs/plasma/applet.cpp
<http://reviewboard.kde.org/r/1606/#comment1668>

    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.



/trunk/KDE/kdelibs/plasma/applet.cpp
<http://reviewboard.kde.org/r/1606/#comment1670>

    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.



/trunk/KDE/kdelibs/plasma/applet.cpp
<http://reviewboard.kde.org/r/1606/#comment1669>

    this is actually unecessary; KRun does all of this for you, including re-using the mimetype fetching job.


- Aaron


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
> 
>