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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#93813

On 2015-07-14, Michael Torrie <torriem@gmail.com> wrote:
> 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.

Why would you have to ship "extra" libraries for Windows?  Extra
compared to what?  When I compared bundled apps for Windows using wx
and Tk, you had to ship more libraries using Tk than you did with wx.
Maybe that's changed...

-- 
Grant Edwards               grant.b.edwards        Yow! On the road, ZIPPY
                                  at               is a pinhead without a
                              gmail.com            purpose, but never without
                                                   a POINT.

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

#93815

On 07/14/2015 08:06 AM, Grant Edwards wrote:
> On 2015-07-14, Michael Torrie <torriem@gmail.com> wrote:
>> 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.
> 
> Why would you have to ship "extra" libraries for Windows?  Extra
> compared to what?  When I compared bundled apps for Windows using wx
> and Tk, you had to ship more libraries using Tk than you did with wx.
> Maybe that's changed...

You make a good point.  Although Tk is considered part of the standard
Python library (though optional), Tk not only requires some dlls, it
also embeds the tcl language interpreter as well.  So by some measures,
Tk in Python is pretty heavy, though I have no idea what the size it
would add to an application bundle actually is.  I've always thought it
was a bit crazy how when you use Tk, you're actually using the Tcl
language as well, even though you're driving it all from Python.  I
believe there were attempts to separate Tk from Tcl, and allow Perl/Tk
to replace all the Tcl code with Perl code.

Qt weighs in at between 5 and 15 MB of dlls, depending on how much of it
you are using, and 32 or 64-bit.  Gtk weighs in at about 10-15 MB also,
and that's over a lot more little files and directories for things like
image loaders.

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

#93816

On 14/07/2015 16:21, Michael Torrie wrote:
> On 07/14/2015 08:06 AM, Grant Edwards wrote:
>> On 2015-07-14, Michael Torrie <torriem@gmail.com> wrote:
>>> 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.
>>
>> Why would you have to ship "extra" libraries for Windows?  Extra
>> compared to what?  When I compared bundled apps for Windows using wx
>> and Tk, you had to ship more libraries using Tk than you did with wx.
>> Maybe that's changed...
>
> You make a good point.  Although Tk is considered part of the standard
> Python library (though optional), Tk not only requires some dlls, it
> also embeds the tcl language interpreter as well.  So by some measures,
> Tk in Python is pretty heavy, though I have no idea what the size it
> would add to an application bundle actually is.  I've always thought it
> was a bit crazy how when you use Tk, you're actually using the Tcl
> language as well, even though you're driving it all from Python.  I
> believe there were attempts to separate Tk from Tcl, and allow Perl/Tk
> to replace all the Tcl code with Perl code.
>

Surely if Tk is optional then IDLE is also optional, as IDLE depends on 
Tk?  But I thought that IDLE was always supplied with Python, so am I 
missing something, or am I simply plain wrong, or what?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#93817

On Wed, 15 Jul 2015 01:43 am, Mark Lawrence wrote:

> Surely if Tk is optional then IDLE is also optional, as IDLE depends on
> Tk?  But I thought that IDLE was always supplied with Python, so am I
> missing something, or am I simply plain wrong, or what?

If you try to run IDLE on a system that doesn't have Tk/Tcl installed, you
get an exception and IDLE won't run.




-- 
Steven

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

#93819

On 2015-07-14, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 14/07/2015 16:21, Michael Torrie wrote:

>>> Why would you have to ship "extra" libraries for Windows?  Extra
>>> compared to what?  When I compared bundled apps for Windows using wx
>>> and Tk, you had to ship more libraries using Tk than you did with wx.
>>> Maybe that's changed...
>>
>> You make a good point.  Although Tk is considered part of the standard
>> Python library (though optional), Tk not only requires some dlls, it
>> also embeds the tcl language interpreter as well.  So by some measures,
>> Tk in Python is pretty heavy, though I have no idea what the size it
>> would add to an application bundle actually is.  I've always thought it
>> was a bit crazy how when you use Tk, you're actually using the Tcl
>> language as well, even though you're driving it all from Python.  I
>> believe there were attempts to separate Tk from Tcl, and allow Perl/Tk
>> to replace all the Tcl code with Perl code.
>
> Surely if Tk is optional

It is.

> then IDLE is also optional,

It is.

> as IDLE depends on Tk?  But I thought that IDLE was always supplied
> with Python,

That depends on who supplied the Python.  Most/all of the ready-made
Windows builds include Tk, but there's no reason you can't build it
without Tk not install IDLE. 

But, you can't assume that all Windows machines have _any_ Python
build installed.

> so am I missing something, or am I simply plain wrong, or what?

My point is that on Windows, _Python_ is optional.  If you want to
ship a stand-alone .exe file, then you've got to ship both Python andT
Tcl/Tk or ship both Python and wx.  In my experience (which was a
couple years ago), Windows wx libs were smaller than Windows Tcl+Tk
libs.  wx on Windows uses native widgets.  Tcl/Tk doesn't: it includes
not only the Tcl language implementation, it also includes low-level
pixel-twiddling implementations of all the widgets.

Comparing the size of Tcl+Tk and wx/Gtk doesn't really make sense
either since we're talking about MS Windows targets.  Gtk isn't
involved.  wxWindows on MS Windows runs on top of native widgets, not
on top of Gtk.

-- 
Grant Edwards               grant.b.edwards        Yow! VICARIOUSLY experience
                                  at               some reason to LIVE!!
                              gmail.com            

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

#93823

On Wed, Jul 15, 2015 at 3:28 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> Comparing the size of Tcl+Tk and wx/Gtk doesn't really make sense
> either since we're talking about MS Windows targets.  Gtk isn't
> involved.  wxWindows on MS Windows runs on top of native widgets, not
> on top of Gtk.

Well, let's look at three straight-forward options:

1) Python program uses tkinter
2) Python program uses wxPython
3) Python program uses PyGTK
4) (optionally) Python program uses PyGObject

Then you package your script up with all of its dependencies - Python
interpreter, GUI toolkit, and everything that they depend on - and see
how big it is. That's the comparison that matters; everything else is
implementation detail.

I had been under the impression that tkinter + Tcl + Tk + etc etc etc
was smaller than wxPython + wxWidgets + etc etc etc, but it's entirely
possible I'm flat wrong on that. It doesn't matter how Python is
normally shipped, it matters how big it's going to be when you make
that single-executable package.

But I still think it's better to *not* do that, because you bind your
deps to your code release cycle. If you make this kind of package,
most people won't know how to unwrap it and get the Python scripts out
of it, so the only thing they can do is upgrade to the latest release
that you've made. So when Python 2.7.11 comes out, maybe with some
crucial security patch that an end user needs, s/he has to wait for
you to make a new package that incorporates the latest Python. If you
ship just the .py files, you're responsible for your own code and
nothing else.

ChrisA

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

#93829

On 2015-07-14, Chris Angelico <rosuav@gmail.com> wrote:
> On Wed, Jul 15, 2015 at 3:28 AM, Grant Edwards <invalid@invalid.invalid> wrote:

>> Comparing the size of Tcl+Tk and wx/Gtk doesn't really make sense
>> either since we're talking about MS Windows targets.  Gtk isn't
>> involved.  wxWindows on MS Windows runs on top of native widgets, not
>> on top of Gtk.
>
> Well, let's look at three straight-forward options:
>
> 1) Python program uses tkinter
> 2) Python program uses wxPython
> 3) Python program uses PyGTK
> 4) (optionally) Python program uses PyGObject
>
> Then you package your script up with all of its dependencies - Python
> interpreter, GUI toolkit, and everything that they depend on - and see
> how big it is. That's the comparison that matters; everything else is
> implementation detail.
>
> I had been under the impression that tkinter + Tcl + Tk + etc etc etc
> was smaller than wxPython + wxWidgets + etc etc etc, but it's entirely
> possible I'm flat wrong on that.

The last time I did exactly that comparison, the tk option was larger.
That was 2-3 years ago, and it's quite possible the py2exe
configuration I was using for the tk option could have been optimized
more to get rid of libraries that py2exe thought were needed but were
in fact not needed.  Once the download gets below about 25MB, nobody
seems to care about the size.

> It doesn't matter how Python is normally shipped, it matters how big
> it's going to be when you make that single-executable package.

Right.  And in practice, I find that doesn't actually matter either.
Python+<any-GUI-of-choice> is small compared to a lot of the things
people are used to downloading.

> But I still think it's better to *not* do that, because you bind your
> deps to your code release cycle. If you make this kind of package,
> most people won't know how to unwrap it and get the Python scripts out
> of it, so the only thing they can do is upgrade to the latest release
> that you've made. So when Python 2.7.11 comes out, maybe with some
> crucial security patch that an end user needs, s/he has to wait for
> you to make a new package that incorporates the latest Python. If you
> ship just the .py files, you're responsible for your own code and
> nothing else.

Maybe your Windows audience is different than mine.  Mine absolutely
will not tolerate anything other than a single myapp-setup.exe or
myapp.msi file.  They will not can not install Python, update Python,
or update the Python scripts independently of the exe/msi single-blob.

If you depend on an external Python installation or make a bundled one
visible to the user, you're just digging yourself a hole.  They'll
screw up the external Python installation somehow or they'll uninstall
a bundled but exposed Python installation and then call in complaining
the app doesn't work.

-- 
Grant Edwards               grant.b.edwards        Yow! Jesuit priests are
                                  at               DATING CAREER DIPLOMATS!!
                              gmail.com            

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

#93835

On 7/14/2015 11:43 AM, Mark Lawrence wrote:
> On 14/07/2015 16:21, Michael Torrie wrote:

>> You make a good point.  Although Tk is considered part of the standard
>> Python library (though optional),

Python-coded tkinter depends on C-coded _tkinter and both are in the 
stdlib, which means the code is in the CPython hg repository.  tcl/tk is 
an external dependency of _tkinter and is not is the stdlib.  There are 
a few other stdlib modules with such external dependencies.  The Windows 
installers include the external dependencies.  AFAIK, Linux 
distributions do not, but expect the dependencies to be already present 
or separately downloaded.  I believe the situation is mixed on Mac.  Ned 
Deily is working on include the latest tcl/tk with the Mac installer, 
but this is apparently not trivial.

> Surely if Tk is optional then IDLE is also optional, as IDLE depends on
> Tk?

Idle is in the stdlib and depends on tkinter (and maybe _tkinter), so it 
indirectly depends on tk.  Turtle and turtledemo and some tools/scripts 
also depend on tkinter.

 > But I thought that IDLE was always supplied with Python,

It is unless a distributor removes it, perhaps to bundle with tcl/tk, 
_tkinter, tkinter, turtle, and turtledemo.

Importing tkinter imports _tkinter, which fails if it cannot find tcl/tk.

-- 
Terry Jan Reedy

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

#93794

On 14/07/2015 03:16, Michael Torrie wrote:
> 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.
>
>

Looks good for PySide
http://lists.qt-project.org/pipermail/pyside/2015-July/002313.html :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#93807

Le mardi 14 juillet 2015 09:55:11 UTC+2, Mark Lawrence a écrit :
> On 14/07/2015 03:16, Michael Torrie wrote:
> > 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.
> >
> >
> 
> Looks good for PySide
> http://lists.qt-project.org/pipermail/pyside/2015-July/002313.html :)
> 
> -- 
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
> 
> Mark Lawrence

=========

Indeed, very interesting.

I'm pretty sure, when it finishes I will be able to make
it failing or crashing.

The world of unicode apps is becoming more and more narrow,
day after day. Very dramatic and fascinating at the same time.

jmf

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

#93669

On 11/07/2015 10:28, Ulli Horlacher 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.
>
> 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?
>

Right now if you only have the choice of wx or tk I'd stick with tk as 
it comes with Python 2 and 3, whereas wx is still in development for 3. 
  However as Chris Angelico has already said there are other choices, 
see here https://wiki.python.org/moin/GuiProgramming for a comprehensive 
list.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#93670

Am 11.07.15 um 11:28 schrieb Ulli Horlacher:
> 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

May I ask what is the reason to port this over to Python? Is it to learn 
Python, or do you want to use packages that are not available for Perl?

	Christian

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

#93692

Christian Gollwitzer <auriocus@gmx.de> wrote:

> > 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
> 
> May I ask what is the reason to port this over to Python? Is it to learn 
> Python, or do you want to use packages that are not available for Perl?

Both is true.
It is a nice project to start learning python and perl/pp does not work
any more with Windows 7, when one needs SSL/TLS.

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

#93694

I've recently been facing the same question but with a new (probably simpler) app than your own. I've decided to re-implement what I have in tk, replacing GTK in the python code. I am no expert in either but I find tk to be more coherent at the API level and better documented. However Windows and Mac support is not necessarily an issue for me.

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

#93677

In a message of Sat, 11 Jul 2015 09:28:43 -0000, Ulli Horlacher writes:
>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/

If you already have a tk version, then tkinter will be a whole lot
more familiar with you.  The question is, why do you want to reimplement
this thing in Python?  If the plan is to get rid of some perl and tk
bugs, then it would be good to check if the bugs exist in tkinter +
python as well.

One of the strengths of wxPython was supposed to be that the signatures
of things was very like what windows developers were already used to
when writing windows code.  Since I never had a windows machine to
develop code on, I wasn't one of the people who was already used to
things like this, so that was no benefit to me.  I tried it for a bit
and discovered I liked PyQT better, so I learned that instead.  But
I don't think that this means that one is better than the other, so
much as 'try them for a bit and see what you like'.

Tk works with Python 3.  wxPython doesn't yet.  So if your porting is
being done 'because I want to learn Python' then it is probably Python
3 you want to learn, so that's a strong reason to use tkinter.

Also, if you need your app to work with MacOS, be warned that you
will need an older version of tk than the most recent one.
This information is current: https://www.python.org/download/mac/tcltk/
Don't use 8.6

I'd also recommend kivy, which has the added advantage that if
somebody wants to use your app from a cellphone or a tablet, it
will just work.  see: http://kivy.org/#home

Laura

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

#93681

Am 11.07.15 um 13:27 schrieb Laura Creighton:
> Also, if you need your app to work with MacOS, be warned that you
> will need an older version of tk than the most recent one.
> This information is current: https://www.python.org/download/mac/tcltk/
> Don't use 8.6

I'm not sure how recent this really is. Kevin Walzer has done a lot of 
work to get recent Tcl/Tk (i.e. 8.6) running on OSX. The most recent 
ActiveTcl release is 8.6.4.1. I'm using exclusively Tk 8.6 on the Mac 
without problems.

	Christian

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

#93685

In a message of Sat, 11 Jul 2015 13:56:09 +0200, Christian Gollwitzer writes:
>Am 11.07.15 um 13:27 schrieb Laura Creighton:
>> Also, if you need your app to work with MacOS, be warned that you
>> will need an older version of tk than the most recent one.
>> This information is current: https://www.python.org/download/mac/tcltk/
>> Don't use 8.6
>
>I'm not sure how recent this really is. Kevin Walzer has done a lot of 
>work to get recent Tcl/Tk (i.e. 8.6) running on OSX. The most recent 
>ActiveTcl release is 8.6.4.1. I'm using exclusively Tk 8.6 on the Mac 
>without problems.
>
>	Christian

Unless I was misinformed 2 weeks or so ago when I asked, that is the
problem.  Tcl/Tk 8.6 works (and is shipped with) OSX, but tkinter
and idle don't work with it.  We will see what Ned Deily says
when he gets around to reading this.

Laura

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

#93715

On 7/11/15 10:48 AM, Laura Creighton wrote:
> Unless I was misinformed 2 weeks or so ago when I asked, that is the
> problem.  Tcl/Tk 8.6 works (and is shipped with) OSX, but tkinter
> and idle don't work with it.  We will see what Ned Deily says
> when he gets around to reading this.

You were misinformed. Tkinter has worked fine with Tk 8.6 for a long 
time. The issues with Tk on the Mac, owing to Apple's force migration of 
GUI libraries to Cocoa, have finally been more or less resolved, and Tk 
8.6.4 is now quite stable on OS X.

--Kevin

-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

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

#93719

In article <mnsfqm$nvg$1@dont-email.me>,
 Kevin Walzer <kw@codebykevin.com> wrote:

> On 7/11/15 10:48 AM, Laura Creighton wrote:
> > Unless I was misinformed 2 weeks or so ago when I asked, that is the
> > problem.  Tcl/Tk 8.6 works (and is shipped with) OSX, but tkinter
> > and idle don't work with it.  We will see what Ned Deily says
> > when he gets around to reading this.
> 
> You were misinformed. Tkinter has worked fine with Tk 8.6 for a long 
> time. The issues with Tk on the Mac, owing to Apple's force migration of 
> GUI libraries to Cocoa, have finally been more or less resolved, and Tk 
> 8.6.4 is now quite stable on OS X.

I believe Laura is referring to the Pythons installed by python.org 
installers and it is true that their versions of tkinter and IDLE are 
not linked with 8.6 (but it is not correct that 8.6 is shipped with OS 
X).  As I replied earlier, the issue is not that Tkinter doesn't work 
with Tk 8.6 on OS X: as you say, it does.  The issues are that (1) Apple 
doesn't supply 8.6 with OS X; (2) the Pythons supplied by the python.org 
installers for OS X have traditionally depended on using Apple-supplied 
Tk's shipped with OS X (with an override to ActiveTcl if installed);  
(3) Apple has not updated the version of Tk 8.5 shipped with recent 
releases of OS X, thus still shipping an early version of Cocoa Tk with 
critical bugs that have been fixed upstream by you (Kevin) and others; 
(4) while liberally licensed, ActiveTcl is not free or open source 
software so it is problematic to require all tkinter users to have to 
install it when using python.org Pythons.  The best solution at the 
moment would be for the python.org OS X installers to supply their own 
builds of Tcl/Tk (like the python.org Windows installers do).  That 
hasn't happened yet (we tried one approach a while back but ran into 
problems with some key third-party Python packages expecting files to be 
in particular locations); I hope to try again in the near future.

-- 
 Ned Deily,
 nad@acm.org

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

#93722

Sad reality, but reality.
On Windows, there are no more usable, working GUI
toolkits (wrappers).

Kevy?
I never used it. My guess is that it will not
work either. Build for Py34, it will suffer
from the same issues as in the Qt derivatives.
(I took a look at the documentation).

jmf

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web