«

On 2:59 PM, Lawrence D'Oliveiro wrote:
> In message
> <mailman.154.1287832721.2218.python->, Dave Angel wrote:
>
>> Presumably the original pythonw.exe was called that because it's marked
>> as a windows-app. In win-speak, that means it has a gui. Applications
>> that are not so-marked are console-apps, and get a console created if
>> they weren't already started from one. That's where stdin/stdout/stderr
>> get pointed.
> Which is completely backwards, isn’t it?
>
No. GUI programs are marked as win-app, so w stands for "Windows". Non
GUI programs run in the console. Non-gui programs came first, so that's
the type that doesn't need any tags. No event loop, no window handlers.
GUI programs are the exception.

DaveA

In message <mailman.187.1287916654.2218.python->, Dave Angel
wrote:

> On 2:59 PM, Lawrence D'Oliveiro wrote:
>>
>> In message
>> <mailman.154.1287832721.2218.python->, Dave Angel wrote:
>>
>>> Presumably the original pythonw.exe was called that because it's marked
>>> as a windows-app. In win-speak, that means it has a gui. Applications
>>> that are not so-marked are console-apps, and get a console created if
>>> they weren't already started from one. That's where stdin/stdout/stderr
>>> get pointed.
>>
>> Which is completely backwards, isn’t it?
>>
> No. GUI programs are marked as win-app, so w stands for "Windows". Non
> GUI programs run in the console.

You mean “GUI console�. So non-GUI apps get a GUI element whether they want
it or not, while GUI ones don’t. That’s completely backwards.

On 25/10/2010 02:19, Lawrence D'Oliveiro wrote:
> In message<mailman.187.1287916654.2218.python->, Dave Angel
> wrote:
>
>> On 2:59 PM, Lawrence D'Oliveiro wrote:
>>>
>>> In message
>>> <mailman.154.1287832721.2218.python->, Dave Angel wrote:
>>>
>>>> Presumably the original pythonw.exe was called that because it's marked
>>>> as a windows-app. In win-speak, that means it has a gui. Applications
>>>> that are not so-marked are console-apps, and get a console created if
>>>> they weren't already started from one. That's where stdin/stdout/stderr
>>>> get pointed.
>>>
>>> Which is completely backwards, isn’t it?
>>>
>> No. GUI programs are marked as win-app, so w stands for "Windows". Non
>> GUI programs run in the console.
>
> You mean “GUI console�. So non-GUI apps get a GUI element whether they want
> it or not, while GUI ones don’t. That’s completely backwards.

No, it's not. The fact that the console is also a GUI window is an
implementation detail: it happens to be displayed within a GUI
environment.

On 10/24/2010 9:40 PM, MRAB wrote:
> On 25/10/2010 02:19, Lawrence D'Oliveiro wrote:
>> In message<mailman.187.1287916654.2218.python->, Dave
>> Angel
>> wrote:
>>
>>> On 2:59 PM, Lawrence D'Oliveiro wrote:
>>>>
>>>> In message
>>>> <mailman.154.1287832721.2218.python->, Dave Angel wrote:
>>>>
>>>>> Presumably the original pythonw.exe was called that because it's
>>>>> marked
>>>>> as a windows-app. In win-speak, that means it has a gui. Applications
>>>>> that are not so-marked are console-apps, and get a console created if
>>>>> they weren't already started from one. That's where
>>>>> stdin/stdout/stderr
>>>>> get pointed.
>>>>
>>>> Which is completely backwards, isn’t it?
>>>>
>>> No. GUI programs are marked as win-app, so w stands for "Windows". Non
>>> GUI programs run in the console.
>>
>> You mean “GUI console�. So non-GUI apps get a GUI element whether they
>> want
>> it or not, while GUI ones don’t. That’s completely backwards.
>
> No, it's not. The fact that the console is also a GUI window is an
> implementation detail: it happens to be displayed within a GUI
> environment.

and, in fact, the console is only a GUI window in a windowed system. It
might be one of the console emulation windows that init starts under
linux, or even a terminal connected to a computer by a serila line, for
heavens sake.

Let's not go overboard looking for things to disagree about

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon 2011 Atlanta March 9-17 http://us.pycon.org/
See Python Video! http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/

In message <mailman.208.1287970911.2218.python->, MRAB wrote:

> On 25/10/2010 02:19, Lawrence D'Oliveiro wrote:
>
>> In message<mailman.187.1287916654.2218.python->, Dave
>> Angel wrote:
>>
>>> No. GUI programs are marked as win-app, so w stands for "Windows". Non
>>> GUI programs run in the console.
>>
>> You mean “GUI console�. So non-GUI apps get a GUI element whether they
>> want it or not, while GUI ones don’t. That’s completely backwards.
>
> No, it's not. The fact that the console is also a GUI window is an
> implementation detail ...

It is not an implementation detail. It is intrinsic to the way Windows
works. No other OS does it backwards like this.

In message <mailman.216.1287980107.2218.python->, Steve
Holden wrote:

> and, in fact, the console is only a GUI window in a windowed system. It
> might be one of the console emulation windows that init starts under
> linux, or even a terminal connected to a computer by a serila line, for
> heavens sake.

But now you’re no longer talking about Windows. Windows is the only one that
gets it backwards like this, forcing the creation of GUI elements for non-
GUI-based programs, and not for GUI-based ones.

More reasonably-designed systems, such as you describe above, make no such
distinction between “GUI� and “non-GUI� programs. There is no difference
based on the name of your executable, how it is built, or what libraries it
links to; the only difference is in its run-time behaviour, whether it
invokes any GUI functions or not.

On 10/26/2010 2:08 AM, Lawrence D'Oliveiro wrote:
> In message <mailman.208.1287970911.2218.python->, MRAB wrote:
>
>> On 25/10/2010 02:19, Lawrence D'Oliveiro wrote:
>>
>>> In message<mailman.187.1287916654.2218.python->, Dave
>>> Angel wrote:
>>>
>>>> No. GUI programs are marked as win-app, so w stands for "Windows". Non
>>>> GUI programs run in the console.
>>>
>>> You mean “GUI console�. So non-GUI apps get a GUI element whether they
>>> want it or not, while GUI ones don’t. That’s completely backwards.
>>
>> No, it's not. The fact that the console is also a GUI window is an
>> implementation detail ...
>
> It is not an implementation detail. It is intrinsic to the way Windows
> works. No other OS does it backwards like this.

I really don't understand what you are trying to say here. Could you
please explain? I know you to be a capable and sensible person, but this
sounds like nonsense to me, so I must be misunderstanding.

regards
Steve

--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon 2011 Atlanta March 9-17 http://us.pycon.org/
See Python Video! http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/

On Tue, 26 Oct 2010 02:38:43 -0400, Steve Holden wrote:

>
> I really don't understand what you are trying to say here. Could you
> please explain? I know you to be a capable and sensible person, but this
> sounds like nonsense to me, so I must be misunderstanding.
>
I think he's saying that on a Linux desktop, if you define a launcher for
an application the default assumption is that its a graphical
application. If so, all you need to do is to tell the launcher the
program name, what icon to use and what text to put under it. If the
application isn't graphical, you do the same as above and also tell the
launcher that the program must run in a console window. Simple. Logical.
Concise.

I assume that what I've just described applies to OS X and virtually all
other graphical desktops: I wouldn't know from personal experience
because I don't use them.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

On 2010-10-26, Lawrence D'Oliveiro <_zealand> wrote:
> In message <mailman.216.1287980107.2218.python->, Steve
> Holden wrote:
>
>> and, in fact, the console is only a GUI window in a windowed system. It
>> might be one of the console emulation windows that init starts under
>> linux, or even a terminal connected to a computer by a serila line, for
>> heavens sake.
>
> But now you're no longer talking about Windows. Windows is the only
> one that gets it backwards like this, forcing the creation of GUI
> elements for non- GUI-based programs,

I've been following this entire thread, and I'm afraid I have no clue
at all waht you mean by that last phrase "forcing the creation of GUI
elements for non-GUI-based programs".

> and not for GUI-based ones.

In Windows the default for python applications is that they run in a
console session with stdin/stdout/stderr attached to a terminal
emulator. The application itself may or may not create GUI windows on
its own -- that's independent of whether it's attached to a terminal
emulator or not.

> More reasonably-designed systems, such as you describe above, make no
> such distinction between GUI and non-GUI programs.

Sure they do. When you create a launcher item or menu item in most
desktops, there's a setting that says whether you want the program run
in a terminal window or not. That's exactly the same thing you're
controlling under Windows when you set the filename to .py or .pyw.

> There is no difference based on the name of your executable, how it
> is built, or what libraries it links to; the only difference is in
> its run-time behaviour, whether it invokes any GUI functions or not.

No, we're not talking about whether apps invoke GUI functions or not.
That's completely orthogonal to the issue at hand. We're talking
about whether desktop manager should run the program with
stdin/stdout/stderr connected to /dev/null or connected to a terminal
emulator.

The windows desktop determines that (like it determines other things)
by looking at the filename. Other desktops generally have that
information associated with the icon/button/menu-entry, not with the
executable's filename.

--
Grant Edwards grant.b.edwards Yow! And then we could sit
at on the hoods of cars at
gmail.com stop lights!

On Tue, 26 Oct 2010 10:53:02 +0000 (UTC), Martin Gregorie
<> declaimed the following in
gmane.comp.python.general:

> On Tue, 26 Oct 2010 02:38:43 -0400, Steve Holden wrote:
>
> >
> > I really don't understand what you are trying to say here. Could you
> > please explain? I know you to be a capable and sensible person, but this
> > sounds like nonsense to me, so I must be misunderstanding.
> >
> I think he's saying that on a Linux desktop, if you define a launcher for
> an application the default assumption is that its a graphical
> application. If so, all you need to do is to tell the launcher the
> program name, what icon to use and what text to put under it. If the
> application isn't graphical, you do the same as above and also tell the
> launcher that the program must run in a console window. Simple. Logical.
> Concise.

Which would be the point of divergence for Windows... Windows is
willing to try launching /anything/ WITHOUT first creating a
"launcher"... But applications that weren't linked as "GUI environment
-- application will handle all user interaction" trigger the opening of
a terminal/console for stdio.

I've not done enough programming at that level on Windows -- the
mere fact that, as I recall, a "GUI" program needs to have a WinMain()
rather than the common C main() is a turn-off... If the executable does
not have a WinMain... ta da, must be console application, open a console
for it.

(The Amiga made it simple -- a shell invocation received a non-zero
argc, with command line parameters in argv; a "clicked" invocation
received argc of 0, and argv pointed to a structure containing the
information from the associated .info file [Workbench only displayed
icons from .info files, unlike Windows displaying everything]).
--
Wulfraed Dennis Lee Bieber AF6VN
HTTP://wlfraed.home.netcom.com/