"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