xterm is a console program?

[Harold L Hunt II]

Early,

I read your response below.

In general reply, could you repost (in a new thread) a description of 
your work-around and any source code involved?  The source code doesn't 
have to be readily compilable (i.e., we don't need a Makefile), but I 
would like to see it to be able to evaluate the nature of the solution.

This thread has a pretty low signal-to-noise ratio, so lets try this 
again in a new one :)

Harold

Early Ehlinger wrote:

> "Alexander Gottwald" <Alexander.Gottwald@s1999.tu-chemnitz.de> wrote:
> 
>>Great! With this you'd break a lot of programs which output information
>>to the console like xev, xprop, showfont.
>>
>>Also this is an evil hack since X11 initalization has nothing to do with
>>the removal of the console and causes only confusion.
> 
> 
> How would it be confusing to have these programs behave the same on Windows
> as they do everywhere else?
> 
> I launched xev in a gnome session on RH 7.3 (using the
> gnome-foot-start-button-like-widget->run), and -gasp- no terminal appeared.
> Just the white window with the black box and no output to be found anywhere.
> I launched it from a terminal in the same session, and the output appeared
> in said terminal.
> 
> If I were to insert the console-hiding code I presented yesterday, I would
> get nearly identical behavior on Cygwin+Xfree.  The only difference would be
> that when xev is launched from start->run, a terminal would flash on the
> screen and then disappear.  If you launched it from a terminal, you would
> still get the output as expected.
> 
> To argue that applications like this would be broken by not having a visible
> console when they are launched from outside a terminal is somewhat onerous.
> The only obligation that X apps have is that they be able to dump their
> output to a terminal when *launched from a terminal*, which the technique I
> presented yesterday provides.
> 
> In fact, I noticed something interesting in the "run" dialog in gnome.
> There's a checkbox there that says "launch in terminal."  Care to guess what
> taking the additional step of checking that box does?  It launches a
> terminal and then has that terminal launch the program you were actually
> trying to launch.  The output from *that* program is then displayed on the
> terminal.  This is the POLAR OPPOSITE of what you have to do on
> Cygwin/Xfree, which is to take an additional step ("run") to *prevent* the
> appearance of a terminal/console.
> 
> This isn't an evil hack; it's a mechanism for hiding a design flaw in MS
> Windows - the lack of ability to connect to a pre-existing console from a
> GUI process.  I'm not entirely sure where the code should get inserted, but
> I'm confident that it should, because the current behavior is out of synch
> with both X11 on UNIX and MS-Windows.
> 
> I'm aware of "run" as a workaround, but that's all it is - a WORKAROUND.
> It's a workaround that requires user intervention to get the behavior that X
> applications should have by DEFAULT.
> 
> "run" doesn't fit very well with Windows either.  If I create a shortcut and
> configure it to launch the application as "Maximized" or "Minimized", then
> "run" starts up in that state, and the program that it runs starts up in
> whatever state it feels like.  It also fails to give the launched program
> the focus or even bring it to the foreground much of the time, whereas a
> direct shortcut to the desired application would work as expected.  Sure,
> you could patch "run" to pass along its requested state to the child
> process, but there are so many details like this on the Windows side of
> things that a number are bound to get lost.
> 
> Hiding the console when the app is its owner is also a workaround, but it's
> one that causes X apps to behave more like they do on UNIX and more like
> native Windows apps as well; if you launch an X app from a console (or
> terminal) with the console hiding code, the console remains visible and your
> output is displayed as you would expect.  If you launch an X app without a
> console, Windows will allocate one but it will not be visible to the end
> user - no human intervention needed.
> 
> --
> -- Early Ehlinger CEO, ResPower Inc - Toll-Free : 866-737-7697
> -- www.respower.com -- 500+ GHz Supercomputer Starting At USD$0.50/GHz*Hour
> 
> 
> 
>