[openbox] Possible bug with the menu and console applications
chris at dersoldat.org
Thu Aug 14 23:12:22 EDT 2003
On Thu, 2003-08-14 at 22:59, Marc Wilson wrote:
> On Thu, Aug 14, 2003 at 10:04:32PM -0400, Chris Anderson wrote:
> > <item label="vim">
> > <action name="execute"><execute>vim</execute></action>
> > </item>
> If that's meant to launch the character-mode vim, then that menu entry is
> seriously broken. You need to run it inside a terminal. How are you going
> to interact with it otherwise?
Right, refer to xterm below :)
> > When I execute this selection my keyboard no longer responds and I can
> > no longer focus on applications.
> Well, *that* shouldn't happen either, I have to say. No doubt something
> odd is happening with stdin/stdout.
> > This seems to occur with any console application I try and happens every
> > time I try.
> Well, launching a console application in this manner shouldn't lock the UI
> up, but it's certainly not a useful thing to be doing (see above). No
> console application should function properly when launched in this manner
> unless it's smart enough to start a GUI when it sees it doesn't have a
> > In the meantime I'm using `xterm -e vim` to the same effect, but that may
> > want to be classified as a bug?
> No, the invocation with xterm (or the *term of your choice) is the *right*
> way to do it. It's the UI locking up that would be a "bug", not the
> behavior of the console application.
I was meaning to say the UI lockup was the bug, not having to run xterm.
> > Oh, and I did try with "emacs" just to be sure it wasn't a vim issue, I
> > figured someone would bring that up :)
> I don't know why anyone would bother. It's obviously not the client
> application that's the problem. Let me guess, the emacs process that gets
> started is the GUI one, right?
I was referring to the console emacs, just a bit of humor
More information about the openbox