[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Review Request: Upgrade TerminalInterface to V2 and add two more
From:       "David Nolden" <zwabel+reviewboard () gmail ! com>
Date:       2009-03-29 22:58:39
Message-ID: 20090329225839.18365.38410 () localhost
[Download RAW message or body]



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


[prev in list] [next in list] [prev in thread] [next in thread]