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

[gb345]

I have a handy Python script, which takes a few command-line
arguments, and accepts a few options. I developed it on Unix, with
very much of a Unix-mindset. Some Windows-using colleagues have
asked me to make the script "easy to use under Windows 7". I.e.:
no command-line.

Therefore, I want to adapt my script, with the minimum amount of
work, so that it can have a double-clickable icon that brings up
a small GUI to accept command-line options (including a couple of
file-selectors for input and output files).

I am Windows-illiterate, so I really would like to keep this as
barebones as possible. Where should I look to learn more about
how to do this?

(P.S. in case it matters, it's OK to assume that Python will be
installed on the Windows system; IOW, the script need not bring
with it a Python interpreter and libraries.)

Thank you all for your comments and suggestions. Here's where I
am now.

1. I first implemented a GUI using wx, but later (after reading on
of your comments)...

2. ...I re-implemented the GUI using Tkinter; (FWIW: the wx version
was infinitely easier to write, and looks much nicer too; I hope
that wx will be added to the standard library at some point);

3. Both versions of the app work fine on Windows 7, as long as
I do the following:
a. run CMD
b. cd to where the GUI script and my original script live
c. execute either

C:\Python27\python myapp_tk.py

or

C:\Python27\python myapp_wx.py


So far so good. Still missing from my goal is a clickable app that
obviates the need to do the cumbersome (for the Windows-head) steps
listed under #3.

One possibility would be to use a "batch file" script to do the
stuff in #3, but the problem is that this script would have to know
the location of the GUI script and the original script. I think
it would be too much to ask the user of this little app to edit
the batch script to make sure these paths are correct.

As far as I can tell, the only alternative left is to plunge into
py2exe.

I've looked into it, and I agree that it's not for the fainthearted.
I'd appreciate some clues for my setup.py.

My original script (I'll call it myscript.py) imports the following
standard modules:

sys, os, platform, csv, re, logging, collections, optparse

My tk-based GUI script (I'll call it myapp_tk.py) imports the
following standard modules:

sys, re, Tkinter, tkFileDialog

....plus, crucially, it imports the original script, myscript.py.

For completeness I'll also mention that my wx-based GUI script
imports

os, re, wx, and myscript


Question: how do I call the setup function (within setup.py) so
that the the GUI script can find myscript.py when the app's icon
is double-clicked?

As I said, I much prefer the wx version of the GUI over the tk
version of my app. If I'm going to the trouble of making an exe
version of the app, it would make sense to do it for the wx version
rather than the tk version. How would I need to modify the call
to setup() so that the required wx libraries are included in the
resulting executable?

TIA!

~G

 

[Tim Golden]

3. Both versions of the app work fine on Windows 7, as long as
I do the following:
a. run CMD
b. cd to where the GUI script and my original script live
c. execute either

C:\Python27\python myapp_tk.py

or

C:\Python27\python myapp_wx.py

The standard python.org associates .py & .pyw files with
the installed interpreter. If you double-click on either
of those files it should just run. If you were to rename
the .py to a .pyw it would run without a console window
showing up.


TJG

 

[gb345]

The standard python.org associates .py & .pyw files with
the installed interpreter. If you double-click on either
of those files it should just run. If you were to rename
the .py to a .pyw it would run without a console window
showing up.

Thanks for the tip! That would be great if I could get it to work.

When I click on the (renamed) myapp_tk.pyw or myapp_wx.pyw a console
appears and immediately disappears (it just flashes, really), too
quickly for me to see what it says. (I imagine it's some error
message.) The renamed files still work fine if I run them as shown
above, though.

I see how clicking directly on these files would obviate the need
to specify the path of the interpreter, but it's still not clear
to me how the interpreter would know where to look for the myscript.py
module that both the GUI scripts require.

~G

 

[Ethan Furman]

Thanks for the tip! That would be great if I could get it to work.

When I click on the (renamed) myapp_tk.pyw or myapp_wx.pyw a console
appears and immediately disappears (it just flashes, really), too
quickly for me to see what it says. (I imagine it's some error
message.) The renamed files still work fine if I run them as shown
above, though.

You need to create a shortcut on the Windows 7 desktop (not sure of the
particulars for 7, but it starts with a right-click). Either while
creating the shortcut, or afterwards (with another right-click on the
shortcut icon, and selecting Properties [hopefully that was not
renamed]) have the startup directory be where ever your script lives,
and the command line should read C:\Python27\pythonw myapp_tk.py.

*disclaimer: I haven't used Windows 7 yet, so some details may vary.

~Ethan~

 

[python]

I much prefer the wx version of the GUI over the tk version of my app.

Check out Python 2.7's Tkinter support for Tile. The enhanced version of
Tkinter that ships with 2.7 supports native OS themes across all
platforms giving you very professional looking user interfaces.

wx has lots more functionality than Tkinter, but if you're just creating
simple user interfaces, then the latest version of Tkinter may be just
what you're looking for.

Malcolm

 

[Lawrence D'Oliveiro]

If you were to rename the .py to a .pyw it would run without a console
window showing up.

Presumably the “w†stands for “windowâ€. Wouldn’t it be less confusing if it
was the other way round?

 

[Chris Rebert]

Presumably the “w†stands for “windowâ€.

Why not "windowless"?

- Chris

 

[Lawrence D'Oliveiro]

Why not "windowless"?

Why mention the fact that you don’t have something?

“This car is the “D†model, the “D†standing for “Deluxelessâ€.â€

 

[Dave Angel]

Presumably the “w” stands for “window”. Wouldn’t it be less confusing if it
was the other way round?

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.

DaveA

 

[Lawrence D'Oliveiro]

In message

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?

 

[Dave Angel]

In message

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

 

[Lawrence D'Oliveiro]

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.

 

[MRAB]

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.

 

[Steve Holden]

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

 

[Lawrence D'Oliveiro]

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.

 

[Lawrence D'Oliveiro]

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.

 

[Steve Holden]

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

 

[Martin Gregorie]

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.

 

[Grant Edwards]

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.

 

[Dennis Lee Bieber]

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