--===============5710315405037222021== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107086/#review21786 ----------------------------------------------------------- About bug 275405: I just posted a patch there, can you try it? > Does it make sense to provide that workaround for binary executable? It i= s of course valid, but might be seen as overkill and strange in practice. As long as it's "opt in", i.e. people need to choose this menuitem explicit= ely, I like having it for all types of executables. Someone who wants to se= e the debug output of a GUI app will be able to do it that way, instead of = launching a terminal first and then the app from there, so this sounds usef= ul. > * Is there something called application/x-executablescript, that falls b= etween the range of x-executable and x-shellscripts ? No, the freedesktop spec uses multiple inheritance (from x-executable and t= ext/plain) to represent scripts. But that's hard to specify in a MimeType= =3D field, no support for predicates there :-) > * Should application/x-desktop be also added into "MimeType"? = Can't hurt; same reasoning as for the first question. As to application desktop file or servicemenu... if we decide this only mak= es sense inside dolphin/konqueror, then it's a servicemenu. If we want to l= et people associate other mimetypes with it externally, then it could be a = hidden application. I guess one could try if the application desktop file a= llows to make this work inside folderview too, for instance... desktop/run-in-konsole.desktop Unnecessary field desktop/run-in-konsole.desktop That's the default, so this line is unnecessary. = However I suppose you tried Terminal=3Dtrue instead of Exec=3Dkonsole -= -hold -e %f? It's supposed to do the same (but uses the user's configured t= erminal emulator). Doesn't that work? = Of course it would mean changing the Name from "Run In Konsole" to "Run= in terminal window" (to match the label of the checkbox in krunner). - David Faure On Oct. 31, 2012, 12:45 p.m., Jekyll Wu wrote: > = > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107086/ > ----------------------------------------------------------- > = > (Updated Oct. 31, 2012, 12:45 p.m.) > = > = > Review request for Dolphin, Konsole and David Faure. > = > = > Description > ------- > = > @David, I'd like to know your idea of this workaround, because I think it= s usefulness will influence or be influenced by how bug 275405 will be fina= lly resolved. = > = > = > The current situation of clicking an executable shell script in dolphin/k= onqueror: > = > 1. It is always executed, instead of being opened by the preferred applic= ation according to its mimetype. (bug 275405) > = > 2. It is executed in a silent way, without invoking konsole to provide a = running environment (bug 225563). That means at least two issues: > = > a). There is no feedback and no easy way for user to know whether tha= t script has been started. He/She need use ps or ksysguard to verify it. > = > b). interactive script just doesn't work. > = > = > This patch *doesn't* really solve any of the above two problems. It just = provides the possibility for users to run an executable script in konsole w= hen using dolphin/konqueror. > = > It adds two .desktop files: = > = > applications/kde4/run-in-konsole.desktop, which can be used in the "O= pen with" submenu > ServiceMenus/konsolerun.deksotp, which can be used in the "Actions" s= ubmenu > = > I'm not sure which solution is better, so I just provide both :) > = > = > Known issue: = > = > using application/x-shellscript means this workaround only applies to she= ll scripts, so it does not provide help for perl/python scripts. But using= applicaiton/x-executable means it will also apply to binary executables. = So : > = > * Does it make sense to provide that workaround for binary executable= ? It is of course valid, but might be seen as overkill and strange in pract= ice. > = > * Is there something called application/x-executablescript, that fall= s between the range of x-executable and x-shellscripts ? > = > * Should application/x-desktop be also added into "MimeType"? = > = > = > As you see, this patch in the current form is still a rough idea. > = > = > This addresses bugs 225563 and 275405. > http://bugs.kde.org/show_bug.cgi?id=3D225563 > http://bugs.kde.org/show_bug.cgi?id=3D275405 > = > = > Diffs > ----- > = > desktop/CMakeLists.txt 0fe39d2 = > desktop/konsolerun.desktop PRE-CREATION = > desktop/run-in-konsole.desktop PRE-CREATION = > = > Diff: http://git.reviewboard.kde.org/r/107086/diff/ > = > = > Testing > ------- > = > = > Thanks, > = > Jekyll Wu > = > --===============5710315405037222021== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
This is an automatically generated e-mail. To reply, visit: http://git.revie= wboard.kde.org/r/107086/ 

About bug =
275405: I just posted a patch there, can you try it?

> Does it make sense to provide that workaround for binary executable? I=
t is of course valid, but might be seen as overkill and strange in practice.

As long as it's "opt in", i.e. people need to choose this men=
uitem explicitely, I like having it for all types of executables. Someone w=
ho wants to see the debug output of a GUI app will be able to do it that wa=
y, instead of launching a terminal first and then the app from there, so th=
is sounds useful.

>  * Is there something called application/x-executablescript, that fall=
s between the range of x-executable and x-shellscripts ?

No, the freedesktop spec uses multiple inheritance (from x-executable and t=
ext/plain) to represent scripts. But that's hard to specify in a MimeTy=
pe=3D field, no support for predicates there :-)

>   * Should application/x-desktop be also added into "MimeType&quo=
t;? =


Can't hurt; same reasoning as for the first question.

As to application desktop file or servicemenu... if we decide this only mak=
es sense inside dolphin/konqueror, then it's a servicemenu. If we want =
to let people associate other mimetypes with it externally, then it could b=
e a hidden application. I guess one could try if the application desktop fi=
le allows to make this work inside folderview too, for instance...

= =
desktop/run-in-konsole.desktop (Diff revision 2) 


  

 

  

    
    

    3
    
Version=3D1.0

  


 





Unnecessary field

















 =

 =




 

 
  

   
    desktop/run-in-konsole.desktop
    

     (Diff revision 2)

    
   
  

 

 
  


   


  

 

  

    
    

    8
    
Terminal=3Dfalse

  


 





That's the default, so this line is unnecessary.

However I suppose you tried Terminal=3Dtrue instead of Exec=3Dkonsole --hol=
d -e %f? It's supposed to do the same (but uses the user's configur=
ed terminal emulator). Doesn't that work?

Of course it would mean changing the Name from "Run In Konsole" t=
o "Run in terminal window" (to match the label of the checkbox in=
 krunner).









- David






On October 31st, 2012, 12:45 p.m., Jekyll Wu wrote:









 

  


Review request for Dolphin, Konsole and David Faure.


By Jekyll Wu.




Updated Oct. 31, 2012, 12:45 p.m.








Descripti=
on 

 

 

  
   
@David, I'd like to know your idea of this workaround, b=
ecause I think its usefulness will influence or be influenced by how bug 27=
5405 will be finally resolved. =




The current situation of clicking an executable shell script in dolphin/kon=
queror:

1. It is always executed, instead of being opened by the preferred applicat=
ion according to its mimetype. (bug 275405)

2. It is executed in a silent way, without invoking konsole to provide a ru=
nning environment (bug 225563). That means at least two issues:

    a). There is no feedback and no easy way for user to know whether that =
script has been started. He/She need use ps or ksysguard to verify it.

    b). interactive script just doesn't work.


This patch *doesn't* really solve any of the above two problems. It jus=
t provides the possibility for users to run an executable script in konsole=
 when using dolphin/konqueror.

It adds two .desktop files: =


    applications/kde4/run-in-konsole.desktop, which can be used in the &quo=
t;Open with" submenu
    ServiceMenus/konsolerun.deksotp, which can be used in the "Actions=
" submenu

I'm not sure which solution is better, so I just provide both :)


Known issue: =


using application/x-shellscript means this workaround only applies to shell=
 scripts, so it does not provide help for perl/python scripts.  But using a=
pplicaiton/x-executable means it will also apply to binary executables.  So=
 :

    * Does it make sense to provide that workaround for binary executable? =
It is of course valid, but might be seen as overkill and strange in practic=
e.

    * Is there something called application/x-executablescript, that falls =
between the range of x-executable and x-shellscripts ?

    * Should application/x-desktop be also added into "MimeType"? =



As you see, this patch in the current form is still a rough idea.


  		
 









 Bugs: 


 225563, =


 275405







Diffs=
 


    

 
  • desktop/CMakeLists.txt (0fe39d2)

 
  • desktop/konsolerun.desktop (PRE-CREATION)<=
/span>
    • 

 
  • desktop/run-in-konsole.desktop (PRE-CREATI=
ON)
    • 





View Diff





  		
 











  

 



--===============5710315405037222021==--