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

Discussion in 'Python' started by gb345, Oct 22, 2010.

  1. gb345

    gb345 Guest

    In <i9n9ed$q03$> gb345 <> writes:

    >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
     
    gb345, Oct 22, 2010
    #1
    1. Advertising

  2. gb345

    Tim Golden Guest

    On 22/10/2010 15:25, gb345 wrote:
    > 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
     
    Tim Golden, Oct 22, 2010
    #2
    1. Advertising

  3. gb345

    gb345 Guest

    In <> Tim Golden <> writes:

    >On 22/10/2010 15:25, gb345 wrote:
    >> 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.


    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
     
    gb345, Oct 22, 2010
    #3
  4. gb345

    Ethan Furman Guest

    gb345 wrote:
    >
    > In <> Tim Golden <> writes:
    >
    >> On 22/10/2010 15:25, gb345 wrote:
    >>> 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.

    >
    > 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~
     
    Ethan Furman, Oct 22, 2010
    #4
  5. gb345

    Guest

    > 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
     
    , Oct 22, 2010
    #5
  6. In message <>, Tim Golden
    wrote:

    > 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?
     
    Lawrence D'Oliveiro, Oct 23, 2010
    #6
  7. gb345

    Chris Rebert Guest

    On Sat, Oct 23, 2010 at 12:32 AM, Lawrence D'Oliveiro
    <_zealand> wrote:
    > In message <>, Tim Golden
    > wrote:
    >
    >> 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â€.


    Why not "windowless"?

    - Chris
     
    Chris Rebert, Oct 23, 2010
    #7
  8. In message <>, Chris
    Rebert wrote:

    > On Sat, Oct 23, 2010 at 12:32 AM, Lawrence D'Oliveiro
    > <_zealand> wrote:
    >
    >> In message <>, Tim
    >> Golden wrote:
    >>
    >>> 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â€.

    >
    > Why not "windowless"?


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

    “This car is the “D†model, the “D†standing for “Deluxelessâ€.â€
     
    Lawrence D'Oliveiro, Oct 23, 2010
    #8
  9. gb345

    Dave Angel Guest

    On 2:59 PM, Lawrence D'Oliveiro wrote:
    > In message<>, Tim Golden
    > wrote:
    >
    >> 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?
    >

    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
     
    Dave Angel, Oct 23, 2010
    #9
  10. In message
    <>, 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?
     
    Lawrence D'Oliveiro, Oct 24, 2010
    #10
  11. gb345

    Dave Angel Guest

    On 2:59 PM, Lawrence D'Oliveiro wrote:
    > In message
    > <>, 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
     
    Dave Angel, Oct 24, 2010
    #11
  12. In message <>, Dave Angel
    wrote:

    > On 2:59 PM, Lawrence D'Oliveiro wrote:
    >>
    >> In message
    >> <>, 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.
     
    Lawrence D'Oliveiro, Oct 25, 2010
    #12
  13. gb345

    MRAB Guest

    On 25/10/2010 02:19, Lawrence D'Oliveiro wrote:
    > In message<>, Dave Angel
    > wrote:
    >
    >> On 2:59 PM, Lawrence D'Oliveiro wrote:
    >>>
    >>> In message
    >>> <>, 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.
     
    MRAB, Oct 25, 2010
    #13
  14. gb345

    Steve Holden Guest

    On 10/24/2010 9:40 PM, MRAB wrote:
    > On 25/10/2010 02:19, Lawrence D'Oliveiro wrote:
    >> In message<>, Dave
    >> Angel
    >> wrote:
    >>
    >>> On 2:59 PM, Lawrence D'Oliveiro wrote:
    >>>>
    >>>> In message
    >>>> <>, 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/
     
    Steve Holden, Oct 25, 2010
    #14
  15. In message <>, MRAB wrote:

    > On 25/10/2010 02:19, Lawrence D'Oliveiro wrote:
    >
    >> In message<>, 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.
     
    Lawrence D'Oliveiro, Oct 26, 2010
    #15
  16. In message <>, 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.
     
    Lawrence D'Oliveiro, Oct 26, 2010
    #16
  17. gb345

    Steve Holden Guest

    On 10/26/2010 2:08 AM, Lawrence D'Oliveiro wrote:
    > In message <>, MRAB wrote:
    >
    >> On 25/10/2010 02:19, Lawrence D'Oliveiro wrote:
    >>
    >>> In message<>, 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/
     
    Steve Holden, Oct 26, 2010
    #17
  18. 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 |
     
    Martin Gregorie, Oct 26, 2010
    #18
  19. On 2010-10-26, Lawrence D'Oliveiro <_zealand> wrote:
    > In message <>, 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!
     
    Grant Edwards, Oct 26, 2010
    #19
  20. 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/
     
    Dennis Lee Bieber, Oct 26, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John

    HTML-ize a server-side control

    John, Dec 14, 2005, in forum: ASP .Net
    Replies:
    5
    Views:
    447
    addup
    Dec 14, 2005
  2. Bura Tino

    How to URL-ize a string

    Bura Tino, Apr 19, 2004, in forum: Java
    Replies:
    10
    Views:
    681
    Roedy Green
    Apr 20, 2004
  3. sputnik

    ASP newbie in over his head

    sputnik, Jul 12, 2003, in forum: HTML
    Replies:
    3
    Views:
    461
    William Tasso
    Jul 12, 2003
  4. gb345
    Replies:
    9
    Views:
    508
    Ulrich Eckhardt
    Oct 21, 2010
  5. Seth Eliot

    Ruby-ize me (or at least my code)

    Seth Eliot, Oct 22, 2006, in forum: Ruby
    Replies:
    6
    Views:
    88
    Seth E.
    Oct 23, 2006
Loading...

Share This Page