This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: xterm is a console program?


On Tue, 20 May 2003, 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.

sigh. 

It was said a hundred times before. You either have a console application or
a gui application. 

The console application has a console (which it may detach, but this also 
detaches it from the running cmd.exe)
The GUI window has no own console but can create one. But this is not connected 
to the starting cmd.exe.

On linux the output of the program goes either to a logfile, the console from
where the X11 session was started or to /dev/null. On linux this very easy.

> 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.

The evil hack is to include the code into the X11 library. This is the last 
place where I want to see code that detaches the console. The correct place 
is in cygwin1.dll, in the startup code. And this issue should be discussed
on the cygwin-devel mailing list.

> 
> 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.



bye
	ago
-- 
 Alexander.Gottwald@s1999.tu-chemnitz.de 
 http://www.gotti.org           ICQ: 126018723


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]