[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: "Robert Knight" <robertknight () gmail ! com>
Date: 2009-03-29 22:46:43
Message-ID: 20090329224643.18163.15752 () 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?
> 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.
- Robert
-----------------------------------------------------------
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic