[openbox] Possible bug with the menu and console applications

Chris Anderson 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
> terminal.
> > 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 mailing list