Review Request: Upgrade TerminalInterface to V2 and add two more functions that needed by dolphin. 1. Apps can query if a sub process is running in terminal. 2. Apps can query if there is any input text on command prompt that waits for a RETURN key.

[David Nolden]

> On 2009-03-29 04:38:13, David Nolden wrote:
> > Would it be technically possible to add a signal "foregroundProcessStarted(pid, name, cmdline)", and adding a function QString foregroundProcessCmdLine()?
> > 
> > cmdline = command line = command used for starting the process, for example "ls *.h" = cmdline, "ls" = name
> > 
> > Another very  useful feature would be something like "processWaitsForUserInput()", together with a signal. The use-case would be that a command could be launched with the konsole window hidden, and it would only  be shown when some user-input is needed. Is this implementable?
> 
> Rahman Duran wrote:
>     Nope, dude :) I digged it too much. It's simply impossible to implement such features, not even hard. It can be implemented only in the underlying shell program like bash, sh etc. They don't tell us whats going in them.
> 
> Robert Knight wrote:
>     > The use-case would be that a command could be launched with the konsole window hidden, and it would only  be shown when some user-input is needed
>     
>     The Ubuntu installer will do this if a package tries to ask a question during installation - which is against the rules but some bad packages still do.  I have a feeling that this is based on a timeout though.  Check with jriddell
>     
>     > Would it be technically possible to add a signal "foregroundProcessStarted(pid, name, cmdline)"
>     
>     Not one that is guaranteed to work reliably as far as I know.  In Konsole a crude heuristic is used that when the user types into a shell we check which process is controlling the terminal a couple of seconds later and update the tab titles accordingly.  We could emit a signal at that point which would probably be okay if you just wanted to update the UI when a program was started in the terminal but not good enough for all use cases.
>     
>     > cmdline = command line = command used for starting the process, for example "ls *.h" = cmdline, "ls" = name
>     
>     We can give you the command-line for foreground process, that's just a matter of reading the /proc/PID/cmdline file and there is code to do that in Konsole.  However, the functionality of extracting information from a process really shouldn't go in TerminalInterface.  Once you have got the PID of the process it would be better if you could pass this to some kdelibs library class which provides information about a process with a given ID.  In Konsole there is a ProcessInfo class which has implementations for Linux and Solaris.
> 
> David Nolden wrote:
>     @Robert Knight: Yeah the idea would be that this is kind of platform-independent(at least the interface), but if that ProcessInfo was moved into kdelibs, that would be even more useful, and the cmdline thing would not be needed.
>     
>     For the foregroundProcessStarted signal: One could put into the documentation that it is not 100% reliable, and or has some delay(though that should be kept short). But it's better having that hack within kdelibs and being able to improve it globally than having to do even uglier hacks within all client applications.
>     
>     In KDevelop for example I would use this to automatically process the output of make commands called by the user.
>     
>     For the processWaitsForUserInput: Yeah I remember that the Adept package manager did that. Would be interesting to know how. Just a general guess: Couldn't it be possible to get the stdin file-descriptor of the foreground-process, and to get some kind of notification when the foreground process does a read on that file-descriptor?
> 
> Robert Knight wrote:
>     > In KDevelop for example I would use this to automatically process the output of make commands called by the user.
>     
>     That requires some method to get the output from a particular process as well - easy if KDevelop invokes the process itself but not easy to do with an arbitrary command invoked by the user in a terminal.  If you really needed this functionality it would be easier if you provided your own 'shell' instead of trying to parse the output from a normal terminal - that way you know when commands are invoked and which output belongs to which command.
>     
>     My concern with adding crappy hacks for something like this is that if they don't work reliably - users won't understand why and it will appear to fail 'randomly', giving the impression of a half-finished application.  In this case it would be better not to have the feature at all.

Yeah true.. well maybe creating an own shell(or at least a direct wrapper around bash or something like that) would be the safer approach


- David


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


On 2009-03-28 15:58:08, Rahman Duran wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/444/
> -----------------------------------------------------------
> 
> (Updated 2009-03-28 15:58:08)
> 
> 
> Review request for kdelibs and Konsole.
> 
> 
> Summary
> -------
> 
> This is a new interface that extends the old ones functionality. 
> 
> 
> Diffs
> -----
> 
>   trunk/KDE/kdelibs/interfaces/terminal/CMakeLists.txt 945618 
>   trunk/KDE/kdelibs/interfaces/terminal/kde_terminal_interface_v2.h PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/444/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Rahman
> 
>