Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Unix-head needs to Windows-ize his Python script (II)

Reply
Thread Tools

Unix-head needs to Windows-ize his Python script (II)

 
 
Dave Angel
Guest
Posts: n/a
 
      10-24-2010
On 2:59 PM, Lawrence D'Oliveiro wrote:
> In message
> <(E-Mail Removed)>, 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, isnt 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


 
Reply With Quote
 
 
 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      10-25-2010
In message <(E-Mail Removed)>, Dave Angel
wrote:

> On 2:59 PM, Lawrence D'Oliveiro wrote:
>>
>> In message
>> <(E-Mail Removed)>, 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.
 
Reply With Quote
 
 
 
 
MRAB
Guest
Posts: n/a
 
      10-25-2010
On 25/10/2010 02:19, Lawrence D'Oliveiro wrote:
> In message<(E-Mail Removed)>, Dave Angel
> wrote:
>
>> On 2:59 PM, Lawrence D'Oliveiro wrote:
>>>
>>> In message
>>> <(E-Mail Removed)>, 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.
 
Reply With Quote
 
Steve Holden
Guest
Posts: n/a
 
      10-25-2010
On 10/24/2010 9:40 PM, MRAB wrote:
> On 25/10/2010 02:19, Lawrence D'Oliveiro wrote:
>> In message<(E-Mail Removed)>, Dave
>> Angel
>> wrote:
>>
>>> On 2:59 PM, Lawrence D'Oliveiro wrote:
>>>>
>>>> In message
>>>> <(E-Mail Removed)>, 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/

 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      10-26-2010
In message <(E-Mail Removed)>, MRAB wrote:

> On 25/10/2010 02:19, Lawrence D'Oliveiro wrote:
>
>> In message<(E-Mail Removed)>, 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.
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      10-26-2010
In message <(E-Mail Removed)>, 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.
 
Reply With Quote
 
Steve Holden
Guest
Posts: n/a
 
      10-26-2010
On 10/26/2010 2:08 AM, Lawrence D'Oliveiro wrote:
> In message <(E-Mail Removed)>, MRAB wrote:
>
>> On 25/10/2010 02:19, Lawrence D'Oliveiro wrote:
>>
>>> In message<(E-Mail Removed)>, 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/

 
Reply With Quote
 
Martin Gregorie
Guest
Posts: n/a
 
      10-26-2010
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 |
 
Reply With Quote
 
Grant Edwards
Guest
Posts: n/a
 
      10-26-2010
On 2010-10-26, Lawrence D'Oliveiro <(E-Mail Removed)_zealand> wrote:
> In message <(E-Mail Removed)>, 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!
 
Reply With Quote
 
Dennis Lee Bieber
Guest
Posts: n/a
 
      10-26-2010
On Tue, 26 Oct 2010 10:53:02 +0000 (UTC), Martin Gregorie
<(E-Mail Removed)> 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://www.velocityreviews.com/forums/(E-Mail Removed) HTTP://wlfraed.home.netcom.com/

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Unix-head needs to Windows-ize his Python script gb345 Python 9 10-21-2010 09:39 AM
Your true traveler finds boredom rather agreeable than painful. It isthe symbol of his liberty -- his excessive freedom. He accepts his boredom,when it comes, not merely philosophically, but almost with pleasure. senthilind@gmail.com Computer Support 0 03-02-2008 08:23 AM
Software Developer earning his Doctorate needs help Tim Dore ASP .Net 0 04-20-2004 06:43 PM
Software Developer earning his Doctorate needs help Tim Dore ASP .Net 0 04-17-2004 05:35 PM



Advertisments