Re: Great SWT Program

On Nov 15, 4:38 pm, b...@xxxxxxxxxxx (Bent C Dalager) wrote:
In article <a4448347-5043-4a7b-9dcd-3c9d84370...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,

<twerpina...@xxxxxxxxx> wrote:
On Nov 14, 12:46 pm, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx>
wrote:
I've written myself a little shell script that makes it easy to
start up vim on only the files that contain specified text

That has one obvious problem: you can't launch multiple interactive
apps simultaneously in the same terminal.

Of course you can. You use screen.

You misunderstand me -- deliberately again, I expect.

A script running in a terminal that's actually one branch of a screen
session would not have any awareness of the others and could not
launch copies of vi in them.

Screen is a crude early approximation to a proper window interface
anyway. Essentially it's a window system with every window maximized,
no mouse support (not that it matters when you can't avoid the windows
perfectly overlapping one another!), no taskbar or equivalent, and
bugs, besides. (I recall using a text-mode system a decade or so ago
which had no X or similar. Multitasking was a definite plus so screen
it was, but screen had a tendency to hang from time to time. This was
a remote dial-in system and when screen locked up it became
unresponsive to any shell escape/aborts, necessitating actually
hanging up and dialing back in, logging in again, and ... well, for
the user it had exactly the same effect as using the early Windoze 3.x
of the time and getting an unrecoverable BSOD from time to time, only
without the BSOD. It just wedged when it went. Since I could log back
in promptly I knew the remote machine hadn't completely wedged, only
my session had, and the only thing running in it at the top level
aside from the login process was screen, so it wasn't too hard to
identify the culprit. Of course sometimes it seemed to wedge and it
was just flow control and C-q woke it up again, but sometimes it was
genuinely in doornail mode.)

Of course there's another problem with screen: it captures some
keystrokes that might also be bound in other applications. ISTR C-w
being one of these, used for its version of alt-tab. So much for using
C-w in emacs then, eh?

Windows apps are designed with the expectation that the system will
intercept things like alt-tab, so they don't bind important
functionality to it themselves. MS-DOS apps tended to eschew alt-based
bindings entirely, so MS-DOS apps in a DOS box under Windoze also
don't tend to suffer. Unix text-mode apps bind anything and
everything, every one of them with its own idiosyncratic set of
bindings, and there's no set of bindings a screen-like program could
use that wouldn't mask something useful in some app or another you
might run from inside it. At minimum you end up with awkward
workarounds such as rebinding stuff, which tends to be nontrivial when
it's possible. At worst, with inaccessible functionality.

I've seen only a few rare cases of badly-behaved Windows apps somehow
binding keys globally, capturing them even when other apps have the
focus. ICQ was one of these, and rendered some binding (ctrl-shift-I
perhaps?) in some other application unusable by eating the relevant
input and grabbing focus if the user entered it. Those apps manage to
cause a fair bit of havoc sometimes. Ultimately the solution is
standardization plus only letting the window manager or equivalent
bind keys globally (i.e. independently of what has focus).
.

Relevant Pages

  • Re: Great SWT Program
    ... apps simultaneously in the same terminal. ... different screen windows. ... bindings, and there's no set of bindings a screen-like program could ...
    (comp.lang.java.programmer)
  • Re: OS/2 mentioned in a Vista review
    ... Although other applications can continue to paint themselves (no window message blocking), I'm sure a rogue app can still claim ownership of the mouse and keyboard and not give it back. ... Consider full-screen apps. ... Audio subsystem doesn't sound like anything better than DSound or DART (OS/2) in terms of resolution and response time. ... I'm doing more with my computers than ever before. ...
    (comp.os.os2.misc)
  • Re: OSX on Intel Could Destroy Microsoft
    ... >> advanced client-side functionality seamlessly integrates with the server. ... gives everyone more options, and keeps clients light-weight, which is ... >> does provide a new way of thinking about how to design and deliver apps, ... >> a viewer window, and a timeline window, and clips window, and an ...
    (comp.sys.mac.advocacy)
  • Re: OSX on Intel Could Destroy Microsoft
    ... >>> Online Shopping interface that web sites could adhere to. ... AJAX is a way ... But most of the web apps out there can, ... Well, sure, because you can put anything you want in a window in a ...
    (comp.sys.mac.advocacy)
  • Re: Windows randomly switching window focus on top application
    ... This link here did absolutely nothing to resolve it, as well as running 3 different virus scans, 2 registry scans from 2 different apps, and 3 spyware scans from 3 different apps. ... What happens is if I have 1 or more applications of windows of any application open like this and I'm in the application typing or what not suddenly for no apparent reason I'm still typing however I hear clunk clunk clunk each time I hit a key stroke. ... I am a video editor as well and notice this in my video app as well like while just watching the timeline play and not touching anything I'll go to hit the space bar which should stop the play line, it just keeps going as my system somehow has pushed that window behind something. ...
    (microsoft.public.windowsxp.general)