Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #93665 > unrolled thread

beginners choice: wx or tk?

Back to article view | Back to comp.lang.python

Contents

  beginners choice: wx or tk? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-07-11 09:28 +0000
    Re: beginners choice: wx or tk? Chris Angelico <rosuav@gmail.com> - 2015-07-11 19:35 +1000
      Re: beginners choice: wx or tk? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-07-11 09:51 +0000
        Re: beginners choice: wx or tk? Chris Angelico <rosuav@gmail.com> - 2015-07-11 20:20 +1000
          Re: beginners choice: wx or tk? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-07-11 22:42 +0000
            Re: beginners choice: wx or tk? Paul Rubin <no.email@nospam.invalid> - 2015-07-11 15:50 -0700
              Re: beginners choice: wx or tk? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-07-11 23:04 +0000
                Re: beginners choice: wx or tk? Paul Rubin <no.email@nospam.invalid> - 2015-07-11 16:10 -0700
                  Re: beginners choice: wx or tk? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-07-11 23:55 +0000
                    Re: beginners choice: wx or tk? Paul Rubin <no.email@nospam.invalid> - 2015-07-11 21:34 -0700
                  Re: beginners choice: wx or tk? Ian Kelly <ian.g.kelly@gmail.com> - 2015-07-11 17:59 -0600
              Re: beginners choice: wx or tk? Laura Creighton <lac@openend.se> - 2015-07-12 12:00 +0200
                Re: beginners choice: wx or tk? wxjmfauth@gmail.com - 2015-07-13 05:32 -0700
        Re: beginners choice: wx or tk? John Ladasky <john_ladasky@sbcglobal.net> - 2015-07-11 10:25 -0700
          Re: beginners choice: wx or tk? Chris Angelico <rosuav@gmail.com> - 2015-07-12 03:39 +1000
          Re: beginners choice: wx or tk? Michael Torrie <torriem@gmail.com> - 2015-07-11 14:16 -0600
        Re: beginners choice: wx or tk? Jugurtha Hadjar <jugurtha.hadjar@gmail.com> - 2015-07-12 01:54 +0100
      Re: beginners choice: wx or tk? Grant Edwards <invalid@invalid.invalid> - 2015-07-13 14:42 +0000
        Re: beginners choice: wx or tk? Michael Torrie <torriem@gmail.com> - 2015-07-13 20:16 -0600
          Re: beginners choice: wx or tk? wxjmfauth@gmail.com - 2015-07-14 00:45 -0700
          Re: beginners choice: wx or tk? Grant Edwards <invalid@invalid.invalid> - 2015-07-14 14:06 +0000
            Re: beginners choice: wx or tk? Michael Torrie <torriem@gmail.com> - 2015-07-14 09:21 -0600
            Re: beginners choice: wx or tk? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-07-14 16:43 +0100
              Re: beginners choice: wx or tk? Steven D'Aprano <steve@pearwood.info> - 2015-07-15 02:53 +1000
              Re: beginners choice: wx or tk? Grant Edwards <invalid@invalid.invalid> - 2015-07-14 17:28 +0000
                Re: beginners choice: wx or tk? Chris Angelico <rosuav@gmail.com> - 2015-07-15 03:43 +1000
                  Re: beginners choice: wx or tk? Grant Edwards <invalid@invalid.invalid> - 2015-07-14 18:28 +0000
            Re: beginners choice: wx or tk? Terry Reedy <tjreedy@udel.edu> - 2015-07-14 15:27 -0400
        Re: beginners choice: wx or tk? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-07-14 08:39 +0100
          Re: beginners choice: wx or tk? wxjmfauth@gmail.com - 2015-07-14 06:05 -0700
    Re: beginners choice: wx or tk? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-07-11 11:01 +0100
    Re: beginners choice: wx or tk? Christian Gollwitzer <auriocus@gmx.de> - 2015-07-11 12:19 +0200
      Re: beginners choice: wx or tk? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-07-11 16:04 +0000
        Re: beginners choice: wx or tk? nickgeovanis@gmail.com - 2015-07-11 09:26 -0700
    Re: beginners choice: wx or tk? Laura Creighton <lac@openend.se> - 2015-07-11 13:27 +0200
      Re: beginners choice: wx or tk? Christian Gollwitzer <auriocus@gmx.de> - 2015-07-11 13:56 +0200
        Re: beginners choice: wx or tk? Laura Creighton <lac@openend.se> - 2015-07-11 16:48 +0200
          Re: beginners choice: wx or tk? Kevin Walzer <kw@codebykevin.com> - 2015-07-11 21:29 -0400
            Re: beginners choice: wx or tk? Ned Deily <nad@acm.org> - 2015-07-11 22:01 -0700
              Re: beginners choice: wx or tk? wxjmfauth@gmail.com - 2015-07-12 00:42 -0700
                Re: beginners choice: wx or tk? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-07-12 07:55 +0000
                  Re: beginners choice: wx or tk? Christian Gollwitzer <auriocus@gmx.de> - 2015-07-12 10:00 +0200
                    Re: beginners choice: wx or tk? Chris Angelico <rosuav@gmail.com> - 2015-07-12 18:54 +1000
                      Re: beginners choice: wx or tk? wxjmfauth@gmail.com - 2015-07-12 03:15 -0700
      Re: beginners choice: wx or tk? Ned Deily <nad@acm.org> - 2015-07-11 08:09 -0700
      Re: beginners choice: wx or tk? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-07-11 16:01 +0000
        Re: beginners choice: wx or tk? Laura Creighton <lac@openend.se> - 2015-07-11 19:37 +0200
        Re: beginners choice: wx or tk? Laura Creighton <lac@openend.se> - 2015-07-11 19:55 +0200
    Re: beginners choice: wx or tk? Ian Kelly <ian.g.kelly@gmail.com> - 2015-07-11 10:33 -0600

Page 1 of 3  [1] 2 3  Next page →

#93665 — beginners choice: wx or tk?

I want to start a project with python.
The program must have a (simple) GUI and must run on Linux and Windows.
The last one as standalone executable, created with pyinstaller.

I have already an implementation in perl/tk :
http://fex.rus.uni-stuttgart.de/fop/ZAcXSugp/schwuppdiwupp.png
http://fex.belwue.de/download/schwuppdiwupp.pl

I am not really happy with tk, because it has some bugs, at least its perl
integration. I have never used wx.

What is the recommendation for a python beginner: wx or tk?


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@tik.uni-stuttgart.de
Universitaet Stuttgart         Tel:    ++49-711-68565868
Allmandring 30a                Fax:    ++49-711-682357
70550 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [next] | [standalone]

#93666

On Sat, Jul 11, 2015 at 7:28 PM, Ulli Horlacher
<framstag@rus.uni-stuttgart.de> wrote:
> I want to start a project with python.
> The program must have a (simple) GUI and must run on Linux and Windows.
> The last one as standalone executable, created with pyinstaller.

Not sure what your advantage is with pyinstaller, it adds a level of
complication that doesn't usually justify itself IMO.

> I have already an implementation in perl/tk :
> http://fex.rus.uni-stuttgart.de/fop/ZAcXSugp/schwuppdiwupp.png
> http://fex.belwue.de/download/schwuppdiwupp.pl
>
> I am not really happy with tk, because it has some bugs, at least its perl
> integration. I have never used wx.
>
> What is the recommendation for a python beginner: wx or tk?

Using wxPython means you need another library, while tkinter comes
with Python. There are some limitations to tk, and I personally don't
like its style, but if you're wanting to package it up into an EXE,
every third-party library you add will increase the size of that EXE,
potentially quite significantly (wxPython will drag in everything that
it depends on, which IIRC is quite a bit).

There are other choices, too - pygtk/pygobject (GTK) and pyqt (Qt)
come to mind - is there a particular reason you're limiting the
question to just wx vs tk?

Personally, I quite like GTK, but I don't have much experience with
either of the Python bindings. Never used wxPython or PyQt.

ChrisA

[toc] | [prev] | [next] | [standalone]

#93667

Chris Angelico <rosuav@gmail.com> wrote:

> On Sat, Jul 11, 2015 at 7:28 PM, Ulli Horlacher
> <framstag@rus.uni-stuttgart.de> wrote:
> > I want to start a project with python.
> > The program must have a (simple) GUI and must run on Linux and Windows.
> > The last one as standalone executable, created with pyinstaller.
> 
> Not sure what your advantage is with pyinstaller, it adds a level of
> complication that doesn't usually justify itself IMO.

I am not addicted to pyinstaller. It just works.
Do you have a better alternative?


> Using wxPython means you need another library, while tkinter comes
> with Python. 

pyinstaller can make a standalone executable, there is no need for the
users to install "another library". They just click on the program icon,
that's it.


> There are other choices, too - pygtk/pygobject (GTK) and pyqt (Qt)
> come to mind

Both create BIG executables, much bigger than with wx or tk.


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@tik.uni-stuttgart.de
Universitaet Stuttgart         Tel:    ++49-711-68565868
Allmandring 30a                Fax:    ++49-711-682357
70550 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#93671

On Sat, Jul 11, 2015 at 7:51 PM, Ulli Horlacher
<framstag@rus.uni-stuttgart.de> wrote:
> Chris Angelico <rosuav@gmail.com> wrote:
>
>> On Sat, Jul 11, 2015 at 7:28 PM, Ulli Horlacher
>> <framstag@rus.uni-stuttgart.de> wrote:
>> > I want to start a project with python.
>> > The program must have a (simple) GUI and must run on Linux and Windows.
>> > The last one as standalone executable, created with pyinstaller.
>>
>> Not sure what your advantage is with pyinstaller, it adds a level of
>> complication that doesn't usually justify itself IMO.
>
> I am not addicted to pyinstaller. It just works.
> Do you have a better alternative?
>
>
>> Using wxPython means you need another library, while tkinter comes
>> with Python.
>
> pyinstaller can make a standalone executable, there is no need for the
> users to install "another library". They just click on the program icon,
> that's it.

Yeah, I'd distribute the .py files and have done with it. Maybe do it
up as a package and distribute it via pip, which allows you to fetch
dependencies automatically. The supposed ease of "just click on the
program icon" is all very well, but it means you have to have a
whopping new download any time there's an update to your code (they
have to redownload the entire binary even if you're using the same
Python and the same libraries), and you have to distribute a whole
bunch of different versions (32-bit vs 64-bit, possibly different
builds for different Windowses, etc), and deal with the support issues
from people who grabbed the wrong one. Once Python itself has been
installed, users can still normally "just click on the program icon"
even though it's a .py file - that's the whole point of file
associations. And then their installed Python can be updated by the
normal mechanisms, and your code will happily run on the new version.
Suppose, for instance, that your program does something over HTTPS,
and people are using it in a critical environment... and then someone
discovers a flaw in OpenSSL, which has happened now and then. A bugfix
release of CPython will fix that instantly for everyone who's using
the standard python.org downloads; but if you've packaged up your own
Python, it'll be frozen at whatever version you had when you built
that - which might not even be the latest available at the time. How
quickly will you get around to building new installers?

Much better to distribute Python code without an interpreter, and let
people get their own interpreters.

ChrisA

[toc] | [prev] | [next] | [standalone]

#93705

Chris Angelico <rosuav@gmail.com> wrote:

> > pyinstaller can make a standalone executable, there is no need for the
> > users to install "another library". They just click on the program icon,
> > that's it.
> 
> Yeah, I'd distribute the .py files and have done with it.

This is not an option for me. My users only accept standalone executables.
They cannot install any runtime environment or extra libraries.


> distribute a whole bunch of different versions (32-bit vs 64-bit,

Is a 64 bit Windows unable to run 32 bit programs?


> Suppose, for instance, that your program does something over HTTPS, and
> people are using it in a critical environment... and then someone
> discovers a flaw in OpenSSL, which has happened now and then.

The same problem has docker - the newest and hottest computer hype ;-)


> Much better to distribute Python code without an interpreter, and let
> people get their own interpreters.

Again: this is a no-go for me, because my users cannot accept it.

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@tik.uni-stuttgart.de
Universitaet Stuttgart         Tel:    ++49-711-68565868
Allmandring 30a                Fax:    ++49-711-682357
70550 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#93706

Ulli Horlacher <framstag@rus.uni-stuttgart.de> writes:
> This is not an option for me. My users only accept standalone executables.
> They cannot install any runtime environment or extra libraries.

Long ago I was involved with a thing like this and used Inno Setup,
which was great.  It's a very slick installer whose user experience is
similar to Install Shield if you're familiar with that.  I have no idea
what current best practice is, but I see that Inno Setup is still
around.

[toc] | [prev] | [next] | [standalone]

#93707

Paul Rubin <no.email@nospam.invalid> wrote:
> Ulli Horlacher <framstag@rus.uni-stuttgart.de> writes:
> > This is not an option for me. My users only accept standalone executables.
> > They cannot install any runtime environment or extra libraries.
> 
> Long ago I was involved with a thing like this and used Inno Setup,
> which was great.  It's a very slick installer

It is not a matter of knowledge, but one of user rights.
It is also forbidden by organization rules.


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@tik.uni-stuttgart.de
Universitaet Stuttgart         Tel:    ++49-711-68565868
Allmandring 30a                Fax:    ++49-711-682357
70550 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#93709

Ulli Horlacher <framstag@rus.uni-stuttgart.de> writes:
>> Long ago I was involved with a thing like this and used Inno Setup,
>> which was great.  It's a very slick installer
> It is not a matter of knowledge, but one of user rights.
> It is also forbidden by organization rules.

I might not understand what you're looking for.  I thought you wanted a
single .exe to give your users.  Inno Setup packages up such a thing for
you, making it very convenient for them.  I think I used it in
conjunction with py2exe, another Windows packaging tool that might or
might not still be in use.  Do you mean it's not ok for the setup tool
to install files?  Hmm.  It might still be possible with py2exe.

On the UI issue, I've always used tkinter and been satisfied with it,
though the gui's I've done haven't been terribly fancy.  tkinter is
pretty easy to use and relatively portable, and included with python
distros, so that made it my default choice.

[toc] | [prev] | [next] | [standalone]

#93711

Paul Rubin <no.email@nospam.invalid> wrote:

> Ulli Horlacher <framstag@rus.uni-stuttgart.de> writes:
> >> Long ago I was involved with a thing like this and used Inno Setup,
> >> which was great.  It's a very slick installer
> > It is not a matter of knowledge, but one of user rights.
> > It is also forbidden by organization rules.
> 
> Do you mean it's not ok for the setup tool to install files?

Yes, as I wrote before: They cannot install any files.
My program for them must be a single click-and-run executable.


> Hmm.  It might still be possible with py2exe.

What does py2exe better than pyinstaller?
pyinstaller works for me.


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@tik.uni-stuttgart.de
Universitaet Stuttgart         Tel:    ++49-711-68565868
Allmandring 30a                Fax:    ++49-711-682357
70550 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#93718

Ulli Horlacher <framstag@rus.uni-stuttgart.de> writes:
>> Do you mean it's not ok for the setup tool to install files?
> Yes, as I wrote before: They cannot install any files.

You wrote before that the users couldn't install files, but it wasn't
clear before that the setup tool also can't install files.

>> Hmm.  It might still be possible with py2exe.
> What does py2exe better than pyinstaller?
> pyinstaller works for me.

I don't know anything about pyinstaller.  I used py2exe and it worked,
so I mentioned that in case the info is useful.  If pyinstaller also
works, that's great, it sounds like your problem is solved.

[toc] | [prev] | [next] | [standalone]

#93712

On Sat, Jul 11, 2015 at 5:10 PM, Paul Rubin <no.email@nospam.invalid> wrote:
> Ulli Horlacher <framstag@rus.uni-stuttgart.de> writes:
>>> Long ago I was involved with a thing like this and used Inno Setup,
>>> which was great.  It's a very slick installer
>> It is not a matter of knowledge, but one of user rights.
>> It is also forbidden by organization rules.
>
> I might not understand what you're looking for.  I thought you wanted a
> single .exe to give your users.  Inno Setup packages up such a thing for
> you, making it very convenient for them.  I think I used it in
> conjunction with py2exe, another Windows packaging tool that might or
> might not still be in use.  Do you mean it's not ok for the setup tool
> to install files?  Hmm.  It might still be possible with py2exe.

Perhaps you've been misled by the talk about pyInstaller, which
despite the name does not create installers. It merely creates a
portable exe that runs the Python program contained in it, similar to
py2exe.

[toc] | [prev] | [next] | [standalone]

#93729

In a message of Sat, 11 Jul 2015 15:50:05 -0700, Paul Rubin writes:
>Ulli Horlacher <framstag@rus.uni-stuttgart.de> writes:
>> This is not an option for me. My users only accept standalone executables.
>> They cannot install any runtime environment or extra libraries.
>
>Long ago I was involved with a thing like this and used Inno Setup,
>which was great.  It's a very slick installer whose user experience is
>similar to Install Shield if you're familiar with that.  I have no idea
>what current best practice is, but I see that Inno Setup is still
>around.

Docker is what I hear people are using now.
https://www.docker.com/

But I have never tried this myself.

Laura

[toc] | [prev] | [next] | [standalone]

#93755

--------

Bye, bye kivy...

[toc] | [prev] | [next] | [standalone]

#93697

On Saturday, July 11, 2015 at 2:51:32 AM UTC-7, Ulli Horlacher wrote:
> Chris Angelico <ros...@gmail.com> wrote:
> > There are other choices, too - pygtk/pygobject (GTK) and pyqt (Qt)
> > come to mind
> 
> Both create BIG executables, much bigger than with wx or tk.

I worked with wxPython back when I was using Python 2.  I got impatient waiting for Phoenix when I switched to Python 3, so I started using PyQt as my GUI.  

I'm happy with PyQt.  I haven't created standalone executable files with it, though.  Do they necessarily have to be large?  I would think that well-written import statements would cut down on the file size.  Just import the objects you need, rather than the whole namespace.  PyQt is even organized in sub-modules, apparently to encourage you to refrain from importing everything.

[toc] | [prev] | [next] | [standalone]

#93699

On Sun, Jul 12, 2015 at 3:25 AM, John Ladasky
<john_ladasky@sbcglobal.net> wrote:
> On Saturday, July 11, 2015 at 2:51:32 AM UTC-7, Ulli Horlacher wrote:
>> Chris Angelico <ros...@gmail.com> wrote:
>> > There are other choices, too - pygtk/pygobject (GTK) and pyqt (Qt)
>> > come to mind
>>
>> Both create BIG executables, much bigger than with wx or tk.
>
> I worked with wxPython back when I was using Python 2.  I got impatient waiting for Phoenix when I switched to Python 3, so I started using PyQt as my GUI.
>
> I'm happy with PyQt.  I haven't created standalone executable files with it, though.  Do they necessarily have to be large?  I would think that well-written import statements would cut down on the file size.  Just import the objects you need, rather than the whole namespace.  PyQt is even organized in sub-modules, apparently to encourage you to refrain from importing everything.
>

If there are submodules that you aren't importing, then it's possible
they don't need to be included. But if you just import a few names
from a module, you still need the entire module to be included.

ChrisA

[toc] | [prev] | [next] | [standalone]

#93702

On 07/11/2015 11:39 AM, Chris Angelico wrote:
>> I'm happy with PyQt.  I haven't created standalone executable files with it, though.  Do they necessarily have to be large?  I would think that well-written import statements would cut down on the file size.  Just import the objects you need, rather than the whole namespace.  PyQt is even organized in sub-modules, apparently to encourage you to refrain from importing everything.
>>
> 
> If there are submodules that you aren't importing, then it's possible
> they don't need to be included. But if you just import a few names
> from a module, you still need the entire module to be included.

It's not the size of the PyQt wrapper files themselves that are big.
It's the Qt dlls.  Last I worked with Qt, they added nearly 10 MB to an
app bundle's size.  You will have to ship them with your app one way or
another.  There is some modularity there.  But at the very least you
need QtCore and QtGui, which are between 8 and 15 MB total, depending on
debugging symbols, qt version, etc. Qt 5 seems to be more modular; there
are a lot more individual shared libraries that are smaller.

[toc] | [prev] | [next] | [standalone]

#93714

Hello,

On 07/11/2015 11:20 AM, Chris Angelico wrote:

> Yeah, I'd distribute the .py files and have done with it. Maybe do
> it up as a package and distribute it via pip, which allows you to
> fetch dependencies automatically.

I'm also writing something, and the target audience is Windows users in
a Treasury department, not really a command line crowd.


The supposed ease of "just click on the
> program icon" is all very well, but it means you have to have a
> whopping new download any time there's an update to your code (they
> have to redownload the entire binary even if you're using the same
> Python and the same libraries), and you have to distribute a whole
> bunch of different versions (32-bit vs 64-bit, possibly different
> builds for different Windowses, etc), and deal with the support
> issues from people who grabbed the wrong one.

Let the feature creep begin... :

Why not put the updates as diffs/patches? In any given change, there's
only a part of the .EXE that will change and I can't think of a good
reason to download the whole thing again like Google Chrome.

This either requires using some third party tool for the patch, or
rolling one's own.


Once Python itself has been
> installed, users can still normally "just click on the program icon"
> even though it's a .py file - that's the whole point of file
> associations. And then their installed Python can be updated by the
> normal mechanisms, and your code will happily run on the new
> version. Suppose, for instance, that your program does something over
> HTTPS, and people are using it in a critical environment... and then
> someone discovers a flaw in OpenSSL, which has happened now and then.
> A bugfix release of CPython will fix that instantly for everyone
> who's using the standard python.org downloads; but if you've packaged
> up your own Python, it'll be frozen at whatever version you had when
> you built that - which might not even be the latest available at the
> time. How quickly will you get around to building new installers?
>
> Much better to distribute Python code without an interpreter, and
> let people get their own interpreters.
>

I just found this:

https://us.pycon.org/2012/schedule/presentation/393/

It's a talk titled "Deep Freeze: building better stand-alone apps with
Python". I'll watch it later.

> ChrisA
>


-- 
~Jugurtha Hadjar,

[toc] | [prev] | [next] | [standalone]

#93761

On 2015-07-11, Chris Angelico <rosuav@gmail.com> wrote:
> On Sat, Jul 11, 2015 at 7:28 PM, Ulli Horlacher
><framstag@rus.uni-stuttgart.de> wrote:
>> I want to start a project with python.
>> The program must have a (simple) GUI and must run on Linux and Windows.
>> The last one as standalone executable, created with pyinstaller.
>
> Not sure what your advantage is with pyinstaller, it adds a level of
> complication that doesn't usually justify itself IMO.
>
>> I have already an implementation in perl/tk :
>> http://fex.rus.uni-stuttgart.de/fop/ZAcXSugp/schwuppdiwupp.png
>> http://fex.belwue.de/download/schwuppdiwupp.pl
>>
>> I am not really happy with tk, because it has some bugs, at least its
>> perl integration. I have never used wx.

IMO, tk is quite a bit easier to use than wx for simple apps.

>> What is the recommendation for a python beginner: wx or tk?
>
> Using wxPython means you need another library, while tkinter comes
> with Python.

Tkinter _usually_ comes with Python.  You may run into Linux/Unix
installs that have Python without tk.

> There are some limitations to tk, and I personally don't like its
> style, but if you're wanting to package it up into an EXE, every
> third-party library you add will increase the size of that EXE,
> potentially quite significantly (wxPython will drag in everything
> that it depends on, which IIRC is quite a bit).

Interesting.  My experience was opposite.  When I used to use py2exe,
wx bundles tended to be smaller installs that tkinter apps (at least
for small, simple apps).  It doesn't matter whether the library is
"third party" or not when bundling up a windows app.  All that matters
is the size of the library.  When I compared sizes of farily simple
apps, tkinter apps were quite a bit larger than wx apps.  Don't forget
that tkinter pulls in a complete TCL implementation. 

> There are other choices, too - pygtk/pygobject (GTK) and pyqt (Qt)
> come to mind - is there a particular reason you're limiting the
> question to just wx vs tk?

The last time I checked pygtk on Windows wasn't ready for the real
world, but that was a year or two back. That said, I think pygtk feels
like a much cleaner and more pythonesque API than wx.

> Personally, I quite like GTK, but I don't have much experience with
> either of the Python bindings. Never used wxPython or PyQt.

If it didn't have to run on Windows, I'd pick pygtk over wx.  I've
never tried qt.

-- 
Grant Edwards               grant.b.edwards        Yow! Pardon me, but do you
                                  at               know what it means to be
                              gmail.com            TRULY ONE with your BOOTH!

[toc] | [prev] | [next] | [standalone]

#93770

On 07/13/2015 08:42 AM, Grant Edwards wrote:
> If it didn't have to run on Windows, I'd pick pygtk over wx.  I've
> never tried qt.

PyQt is very nice to work with.  In some respects it's not as Pythonic
as PyGTK.  It feels a lot like transliterated C++ code, which it is.
But it's a powerful toolkit and looks great on all supported platforms.
 If the licensing terms of PyQt are not to your liking, PySide is fairly
close to PyQt (a few quirks that can be worked around), though I'm not
sure how much love it's receiving lately.  Like wx, or Gtk, you would
have to ship some extra dlls with your project for Windows and OS X.

[toc] | [prev] | [next] | [standalone]

#93792

Le mardi 14 juillet 2015 04:16:36 UTC+2, Michael Torrie a écrit :
> On 07/13/2015 08:42 AM, Grant Edwards wrote:
> > If it didn't have to run on Windows, I'd pick pygtk over wx.  I've
> > never tried qt.
> 
> PyQt is very nice to work with.  In some respects it's not as Pythonic
> as PyGTK.  It feels a lot like transliterated C++ code, which it is.
> But it's a powerful toolkit and looks great on all supported platforms.
>  If the licensing terms of PyQt are not to your liking, PySide is fairly
> close to PyQt (a few quirks that can be worked around), though I'm not
> sure how much love it's receiving lately.  Like wx, or Gtk, you would
> have to ship some extra dlls with your project for Windows and OS X.

About "Qt".
BTW, PyCharm is also not working, char, unicode, ...
Poor Phil Thompson...
It's vey easy to explain why.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web