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

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

GUI toolkit(s) status

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

Contents

  GUI toolkit(s) status wxjmfauth@gmail.com - 2014-11-19 23:59 -0800
    Re: GUI toolkit(s) status Paul Rubin <no.email@nospam.invalid> - 2014-11-20 00:25 -0800
      Re: GUI toolkit(s) status Chris Angelico <rosuav@gmail.com> - 2014-11-20 19:40 +1100
        Re: GUI toolkit(s) status Christian Gollwitzer <auriocus@gmx.de> - 2014-11-20 10:04 +0100
          Re: GUI toolkit(s) status Chris Angelico <rosuav@gmail.com> - 2014-11-20 20:17 +1100
          Re: GUI toolkit(s) status Terry Reedy <tjreedy@udel.edu> - 2014-11-20 23:34 -0500
            Re: GUI toolkit(s) status Paul Rubin <no.email@nospam.invalid> - 2014-11-20 20:49 -0800
              Re: GUI toolkit(s) status Christian Gollwitzer <auriocus@gmx.de> - 2014-11-21 08:57 +0100
            Re: GUI toolkit(s) status Kevin Walzer <kw@codebykevin.com> - 2014-11-21 09:13 -0500
              Re: GUI toolkit(s) status wxjmfauth@gmail.com - 2014-11-22 00:59 -0800
                Re: GUI toolkit(s) status Kevin Walzer <kw@codebykevin.com> - 2014-11-22 12:40 -0500
                  Re: GUI toolkit(s) status wxjmfauth@gmail.com - 2014-11-22 10:49 -0800
            Re: GUI toolkit(s) status wxjmfauth@gmail.com - 2014-11-21 12:38 -0800
              Re: GUI toolkit(s) status wxjmfauth@gmail.com - 2014-11-21 12:49 -0800
            Re: GUI toolkit(s) status wxjmfauth@gmail.com - 2014-11-22 10:33 -0800
              Re: GUI toolkit(s) status Christian Gollwitzer <auriocus@gmx.de> - 2014-11-22 20:34 +0100
                Re: GUI toolkit(s) status wxjmfauth@gmail.com - 2014-11-24 11:24 -0800
          Re: GUI toolkit(s) status Kevin Walzer <kw@codebykevin.com> - 2014-11-21 09:05 -0500
          Re: GUI toolkit(s) status wxjmfauth@gmail.com - 2014-11-21 12:15 -0800
          Re: GUI toolkit(s) status Michael Torrie <torriem@gmail.com> - 2014-11-21 21:07 -0700
            Re: GUI toolkit(s) status Dave Cook <davecook@nowhere.net> - 2014-11-26 09:40 +0000
              Re: GUI toolkit(s) status Mark Summerfield <list@qtrac.plus.com> - 2014-11-26 03:47 -0800
                Re: GUI toolkit(s) status wxjmfauth@gmail.com - 2014-11-26 06:36 -0800
                  Re: GUI toolkit(s) status wxjmfauth@gmail.com - 2014-11-26 07:11 -0800
              Re: GUI toolkit(s) status Michael Torrie <torriem@gmail.com> - 2014-11-26 20:19 -0700
          Re: GUI toolkit(s) status wxjmfauth@gmail.com - 2014-11-22 00:12 -0800
          Re: GUI toolkit(s) status wxjmfauth@gmail.com - 2014-11-22 02:46 -0800
          Re: GUI toolkit(s) status Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-24 08:18 -0700

Page 1 of 2  [1] 2  Next page →

#81060 — GUI toolkit(s) status

[A complementary info of my previous comment about
"Leo 5.0 beta 2" not working]

The single (not too buggy) GUI toolkit for CPython [*],
which works smoothly, coherently and *SAFELY* is
one of the Qt derivatives for Python 3.2.
(If used properly, one can covers the whole
Unicode range).

Today, there are simply no more valid and working
GUI toolkit running "out of the box".

jmf

[*] CPython, not Jython, ...

[toc] | [next] | [standalone]

#81061

wxjmfauth@gmail.com writes:
> Today, there are simply no more valid and working
> GUI toolkit running "out of the box".

Tkinter still works for me.  What's the problem?

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

#81062

On Thu, Nov 20, 2014 at 7:25 PM, Paul Rubin <no.email@nospam.invalid> wrote:
> wxjmfauth@gmail.com writes:
>> Today, there are simply no more valid and working
>> GUI toolkit running "out of the box".
>
> Tkinter still works for me.  What's the problem?

Ignore jmf. Most of us didn't even see his post, for one reason or
another, and even when his posts were getting through, the
signal-to-noise ratio was denormal.

ChrisA

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

#81063

Am 20.11.14 09:40, schrieb Chris Angelico:
> On Thu, Nov 20, 2014 at 7:25 PM, Paul Rubin <no.email@nospam.invalid> wrote:
>> wxjmfauth@gmail.com writes:
>>> Today, there are simply no more valid and working
>>> GUI toolkit running "out of the box".
>>
>> Tkinter still works for me.  What's the problem?
>
> Ignore jmf.

He is trolling, but in this point he is right, unfortunately: neither 
Tcl nor Tk support Unicode outside the BMP. Full Unicode support is a 
big todo item on the wishlist for Tcl 9, for Tk nobody really knows. We 
are lacking manpower and people with specialized knowledge. Apple is a 
moving target, they pulled the rug from under Tk's feet twice over the 
past 10 years. Nobody knows if Tk will continue to exist on the mac if 
Cocoa is withdrawn some day and replaced by a new and completely 
different windowing framework. Python has largely replaced Tcl as the 
first-choice scripting language, and that also does not help to attract 
people working on Tcl/Tk.

	Christian

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

#81064

On Thu, Nov 20, 2014 at 8:04 PM, Christian Gollwitzer <auriocus@gmx.de> wrote:
> Am 20.11.14 09:40, schrieb Chris Angelico:
>>
>> Ignore jmf.
>
>
> He is trolling, but in this point he is right, unfortunately: neither Tcl
> nor Tk support Unicode outside the BMP. Full Unicode support is a big todo
> item on the wishlist for Tcl 9, for Tk nobody really knows. We are lacking
> manpower and people with specialized knowledge. Apple is a moving target,
> they pulled the rug from under Tk's feet twice over the past 10 years.
> Nobody knows if Tk will continue to exist on the mac if Cocoa is withdrawn
> some day and replaced by a new and completely different windowing framework.
> Python has largely replaced Tcl as the first-choice scripting language, and
> that also does not help to attract people working on Tcl/Tk.

This is what happens when someone spends most of his time trolling.
When the signal-to-noise ratio is sufficiently low, it's just not
worth reading his posts. And even when he does have a decent point to
make, he couches it in such exaggerated language that it's hard to
take him seriously.

But I agree about the issues with tkinter. So, let's see. Shall we
wait for Tcl/Tk Unicode support? Recommend people switch to PyGTK? To
PyQt? To wxPython? To something else? Personally, I'm quite happy with
GTK2 (though that's with Pike, not Python), and it does have full
Unicode support; but there are some issues with the interface that
make it feel a bit clunky. Every other windowing toolkit has its own
flaws. Even if one of them were to be blessed into the stdlib (which
would remove the whole "but it's an external dependency" problem),
there's still no perfect option, and every toolkit will have its
staunch supporters.

If Python were starting from scratch today with the first-ever stdlib
GUI toolkit, as a Python 3 feature, I would expect that full Unicode
support be a hard requirement. But since tkinter already exists,
there's no point stripping it out, and blessing another one means
making a choice. I don't see there's enough to choose between the top
three or four options. If I'm going to build a Python GUI app, I'll
probably use PyGTK, and if you do, you're free to use PyQt. I don't
think this is a problem.

ChrisA

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

#81167

On 11/20/2014 4:04 AM, Christian Gollwitzer wrote:

> Tcl nor Tk support Unicode outside the BMP. Full Unicode support is a
> big todo item on the wishlist for Tcl 9, for Tk nobody really knows. We
> are lacking manpower and people with specialized knowledge.

Tcl/Tk currently use UCS-2, which only handles BMP chars. Alternatives 
to support astral chars:

UTF-32 (Python's 3.2- wide build): Easy, especially starting from USC-2. 
  The main problem is the memory hit.  However, most tk apps are not 
text heavy, so this seems like a possibility.  Does anyone ever try to 
put a gigabyte text in a Text widget?

UTF-16 (Python's 3.2- narrow build): Easy but buggy when it comes to 
indexing and slicing.

UTF-16+: I posted on the tracker a prototype of how to make indexing 
correct by adding an auxiliary index of non-BMP chars.  It makes 
indexing O(k), where k is the number of astral chars.

UFT-8: Makes indexing O(n).

Python FSR (3.3+ Unicode): Handling variable byte width adds complexity, 
but Python has already implemented this pretty efficiently.  Python is 
open source with a liberal licenc

To me, an important consideration for choosing is what the OSes require 
to put characters on the screen.  Are they all the same?

> Apple is a
> moving target, they pulled the rug from under Tk's feet twice over the
> past 10 years. Nobody knows if Tk will continue to exist on the mac if
> Cocoa is withdrawn some day and replaced by a new and completely
> different windowing framework.

> Python has largely replaced Tcl as the
> first-choice scripting language, and that also does not help to attract
> people working on Tcl/Tk.

A possible solution for Tk is to replace the non-C Tcl parts of TK with 
Python (or the CPython API functions as needed for speed).  I have no 
idea how horrendous a project creating Py/Tk would be.

-- 
Terry Jan Reedy

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

#81168

Terry Reedy <tjreedy@udel.edu> writes:
> Tcl/Tk currently use UCS-2, which only handles BMP chars. Alternatives
> to support astral chars: [other encodings]

I haven't looked into the issue but from Christian's post it sounded
like the BMP limitation was deeper inside Tcl/TK and would take more
serious work to fix.  How many people really care?

> UTF-32 ... memory hit.  However, most tk apps are not text heavy ...
> UFT-8: Makes indexing O(n).

Given that most tk apps aren't text heavy, UTF-8 seems fine: when has
the O(n) indexing been found to be a real problem in practice?

>> Apple is a moving target, they pulled the rug from under Tk's feet
>> twice over the past 10 years. 

Hmm interesting.  Then there's also lots of new targets like mobile
phones which Tk hasn't been ported to Afaik.

> A possible solution for Tk is to replace the non-C Tcl parts of TK
> with Python (or the CPython API functions as needed for speed).  I
> have no idea how horrendous a project creating Py/Tk would be.

Tcl itself is reasonably small and portable, the problem is the bindings
(C code) to all the different window systems Tk supports.

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

#81179

Am 21.11.14 05:49, schrieb Paul Rubin:
> Terry Reedy <tjreedy@udel.edu> writes:
>> Tcl/Tk currently use UCS-2, which only handles BMP chars. Alternatives
>> to support astral chars: [other encodings]

This is not entirely true: Tcl supports "lazy" typing, i.e. values 
(Tcl_Obj) are cast upon request into various Tcl_ObjTypes. For strings, 
a dialect of UTF8 and UCS-2 are suported, where UCS-2 is called 
"Uncode-string" and the UTF8-version just "string".
So in principle it would be feasible to implement something similar to 
the Python flexible strig representation. The problem is that this is 
only half of the story:

* There is the regexp engine. Tcl uses Henry Spencer's engine (also used 
in MySQL), which is limited to UCS-2, but Spencer retired and nobody 
else understands the code.

* For GUI, more support is needed e.g. to do LTR rendering. In 
principle, FriBiDi can do the work http://wiki.tcl.tk/40273 , but it is 
under GPL and therefore will never go into Tk

* Tk is "small" compared to other toolkits, but still large enough that 
with less than half a developer currently working on it, and three 
supported platforms, it is unlikely to be fixed soon

>> UTF-32 ... memory hit.  However, most tk apps are not text heavy ...
>> UFT-8: Makes indexing O(n).
>
> Given that most tk apps aren't text heavy, UTF-8 seems fine: when has
> the O(n) indexing been found to be a real problem in practice?

These kind of questions are discussed in the TCT before decision which 
string rep should be the default one. The text widet has other issues, 
too, e.g. it is quite slow on long lines. There is a binding to 
Scintilla, which could come at rescue.

>>> Apple is a moving target, they pulled the rug from under Tk's feet
>>> twice over the past 10 years.
>
> Hmm interesting.  Then there's also lots of new targets like mobile
> phones which Tk hasn't been ported to Afaik.

Well, there is kind of a port to Android called androwish.

http://www.ch-werner.de/sdltk/AndroWish/

It is based on SDL and displays the X version on Android. In principle 
it works, but never looks like a real Android app (though for games it's 
great). Would be interesting to see Tkinter running there, too.


>> A possible solution for Tk is to replace the non-C Tcl parts of TK
>> with Python (or the CPython API functions as needed for speed).  I
>> have no idea how horrendous a project creating Py/Tk would be.

The Perl people tried this earlier, IIRC - the first bindings were not 
issuing Tcl commands, but calling Tk from C. It was later redesigned 
like Tkinter.

> Tcl itself is reasonably small and portable, the problem is the bindings
> (C code) to all the different window systems Tk supports.

Tcl is not just an interpreter, but also a big C library for handling 
strings, File I/O over VFS, Threads etc. All of this code in Tk would 
need to be replaced. It would be an almost complete rewrite of the 
non-GUI parts of Tk.


	Christian

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

#81208

On 11/20/14, 11:34 PM, Terry Reedy wrote:
> A possible solution for Tk is to replace the non-C Tcl parts of TK with
> Python (or the CPython API functions as needed for speed).  I have no
> idea how horrendous a project creating Py/Tk would be.

It would be very horrendous. See Perl/Tk as the example. They ripped out 
the Tcl interpreter and interfaced directly with Tk's C API. The result 
was a rigid, inflexible binding that was never ported to the Mac 
(because it required a C implementation) and could never be easily 
updated to take advantage of new features in Tk, because again it 
required a C implementation. Perl-Tk still exists, but more modern 
bindings like ActiveState's Tkx module have restored the Tcl 
interpreter, giving you access to all Tk advances and platforms "for free."

Apart from the ease of updating Tk features, from a design standpoint I 
think this is the right call. There may be a little extra overhead in 
having an extra interpreter embedded, but that is what Tcl was 
originally designed for: embedding. It handles this requirement more 
easily and with less pain than most languages. I think that's why Tk 
became the default GUI binding of choice for other scripting languages.

--Kevin

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

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

#81280

Le vendredi 21 novembre 2014 15:13:54 UTC+1, Kevin Walzer a écrit :
> On 11/20/14, 11:34 PM, Terry Reedy wrote:
> > A possible solution for Tk is to replace the non-C Tcl parts of TK with
> > Python (or the CPython API functions as needed for speed).  I have no
> > idea how horrendous a project creating Py/Tk would be.
> 
> It would be very horrendous. See Perl/Tk as the example. They ripped out 
> the Tcl interpreter and interfaced directly with Tk's C API. The result 
> was a rigid, inflexible binding that was never ported to the Mac 
> (because it required a C implementation) and could never be easily 
> updated to take advantage of new features in Tk, because again it 
> required a C implementation. Perl-Tk still exists, but more modern 
> bindings like ActiveState's Tkx module have restored the Tcl 
> interpreter, giving you access to all Tk advances and platforms "for free."
> 
> Apart from the ease of updating Tk features, from a design standpoint I 
> think this is the right call. There may be a little extra overhead in 
> having an extra interpreter embedded, but that is what Tcl was 
> originally designed for: embedding. It handles this requirement more 
> easily and with less pain than most languages. I think that's why Tk 
> became the default GUI binding of choice for other scripting languages.
> 
> --Kevin
> 
> -- 
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com

---------

TeXLive (since 2014, if I'm not wrong) has a GUI installer
and package manager, I recognized a "tcl/tk/tkinter-like" - Perl
tool and contrary to Python it works.

jmf

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

#81292

On 11/22/14, 3:59 AM, wxjmfauth@gmail.com wrote:
> TeXLive (since 2014, if I'm not wrong) has a GUI installer
> and package manager, I recognized a "tcl/tk/tkinter-like" - Perl
> tool and contrary to Python it works.

That's Perl-Tk, which, as I said, is still around, but only runs on 
Windows and X11/Linux--no native Mac Port. And it hasn't been updated in 
years, it does not take advantage of recent advances in Tk.

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

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

#81296

Le samedi 22 novembre 2014 18:40:39 UTC+1, Kevin Walzer a écrit :
> On 11/22/14, 3:59 AM, wxjmfauth@gmail.com wrote:
> > TeXLive (since 2014, if I'm not wrong) has a GUI installer
> > and package manager, I recognized a "tcl/tk/tkinter-like" - Perl
> > tool and contrary to Python it works.
> 
> That's Perl-Tk, which, as I said, is still around, but only runs on 
> Windows and X11/Linux--no native Mac Port. And it hasn't been updated in 
> years, it does not take advantage of recent advances in Tk.
> 
> -- 
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com

------

That was my naive point.

jmf

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

#81249

Le vendredi 21 novembre 2014 05:35:22 UTC+1, Terry Reedy a écrit :
> 
> UTF-16+: I posted on the tracker a prototype of how to make indexing 
> correct by adding an auxiliary index of non-BMP chars.  It makes 
> indexing O(k), where k is the number of astral chars.
> 

It will not work (mathematics).
Start by understanding Unicode (mathematically).

jmf







> UFT-8: Makes indexing O(n).
> 
> Python FSR (3.3+ Unicode): Handling variable byte width adds complexity, 
> but Python has already implemented this pretty efficiently.  Python is 
> open source with a liberal licenc
> 
> To me, an important consideration for choosing is what the OSes require 
> to put characters on the screen.  Are they all the same?
> 
> > Apple is a
> > moving target, they pulled the rug from under Tk's feet twice over the
> > past 10 years. Nobody knows if Tk will continue to exist on the mac if
> > Cocoa is withdrawn some day and replaced by a new and completely
> > different windowing framework.
> 
> > Python has largely replaced Tcl as the
> > first-choice scripting language, and that also does not help to attract
> > people working on Tcl/Tk.
> 
> A possible solution for Tk is to replace the non-C Tcl parts of TK with 
> Python (or the CPython API functions as needed for speed).  I have no 
> idea how horrendous a project creating Py/Tk would be.
> 
> -- 
> Terry Jan Reedy

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

#81251

Le vendredi 21 novembre 2014 21:38:14 UTC+1, wxjm...@gmail.com a écrit :
> Le vendredi 21 novembre 2014 05:35:22 UTC+1, Terry Reedy a écrit :
> > 
> > UTF-16+: I posted on the tracker a prototype of how to make indexing 
> > correct by adding an auxiliary index of non-BMP chars.  It makes 
> > indexing O(k), where k is the number of astral chars.
> > 
> 
> It will not work (mathematics).
> Start by understanding Unicode (mathematically).
> 
> jmf
> 
> 

Addendum
And the coding of characters in general (unicode or not).
That why we have to live with all these coding schemes.

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

#81295

Le vendredi 21 novembre 2014 05:35:22 UTC+1, Terry Reedy a écrit :
> On 11/20/2014 4:04 AM, Christian Gollwitzer wrote:
> 
> > Tcl nor Tk support Unicode outside the BMP. Full Unicode support is a
> > big todo item on the wishlist for Tcl 9, for Tk nobody really knows. We
> > are lacking manpower and people with specialized knowledge.
> 
> Tcl/Tk currently use UCS-2, which only handles BMP chars. Alternatives 
> to support astral chars:
> 
> UTF-32 (Python's 3.2- wide build): Easy, especially starting from USC-2. 
>   The main problem is the memory hit.  However, most tk apps are not 
> text heavy, so this seems like a possibility.  Does anyone ever try to 
> put a gigabyte text in a Text widget?
> 
> UTF-16 (Python's 3.2- narrow build): Easy but buggy when it comes to 
> indexing and slicing.
> 
> UTF-16+: I posted on the tracker a prototype of how to make indexing 
> correct by adding an auxiliary index of non-BMP chars.  It makes 
> indexing O(k), where k is the number of astral chars.
> 
> UFT-8: Makes indexing O(n).
> 
> Python FSR (3.3+ Unicode): Handling variable byte width adds complexity, 
> but Python has already implemented this pretty efficiently.  Python is 
> open source with a liberal licenc
> 
> To me, an important consideration for choosing is what the OSes require 
> to put characters on the screen.  Are they all the same?
> 
> > Apple is a
> > moving target, they pulled the rug from under Tk's feet twice over the
> > past 10 years. Nobody knows if Tk will continue to exist on the mac if
> > Cocoa is withdrawn some day and replaced by a new and completely
> > different windowing framework.
> 
> > Python has largely replaced Tcl as the
> > first-choice scripting language, and that also does not help to attract
> > people working on Tcl/Tk.
> 
> A possible solution for Tk is to replace the non-C Tcl parts of TK with 
> Python (or the CPython API functions as needed for speed).  I have no 
> idea how horrendous a project creating Py/Tk would be.
> 

As you are rewriting unicode, a small suggestion/request.

Assume that one processes a part of the Bible in polytonic
Greek, one has to create a ton of temporary (locale) letters,
array of letters (you see the kind of objects).

It would be very nice if one has not to be forced to use ascii
letters to initialize those temporary strings and consequently
to save memory, it makes the code ugly (in my opinion).

>>> sys.getsizeof('a')
32
>>> sys.getsizeof('')
30

Regards.

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

#81299

Am 22.11.14 19:33, schrieb wxjmfauth@gmail.com:
> As you are rewriting unicode, a small suggestion/request.
>
> Assume that one processes a part of the Bible in polytonic
> Greek, one has to create a ton of temporary (locale) letters,

<°)))o><  αὐτὸν τὸν ἰχθύα

	ὁ Χριστιανὸς ἔγραψε τρόλλοι

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

#81469

Le samedi 22 novembre 2014 20:35:01 UTC+1, Christian Gollwitzer a écrit :
> Am 22.11.14 19:33, schrieb wxjmfauth@gmail.com:
> > As you are rewriting unicode, a small suggestion/request.
> >
> > Assume that one processes a part of the Bible in polytonic
> > Greek, one has to create a ton of temporary (locale) letters,
> 
> <°)))o><  αὐτὸν τὸν ἰχθύα
> 
> 	ὁ Χριστιανὸς ἔγραψε τρόλλοι

Nice,

>>> import unicodedata as ud
>>> for c in ud.normalize('NFKD', s):
...     'U+{:#04}  {}'.format(ord(c), ud.name(c))
...     
'U+0959  GREEK SMALL LETTER OMICRON'
'U+0788  COMBINING REVERSED COMMA ABOVE'
'U+0032  SPACE'
'U+0935  GREEK CAPITAL LETTER CHI'
'U+0961  GREEK SMALL LETTER RHO'
'U+0953  GREEK SMALL LETTER IOTA'
'U+0963  GREEK SMALL LETTER SIGMA'
'U+0964  GREEK SMALL LETTER TAU'
'U+0953  GREEK SMALL LETTER IOTA'
'U+0945  GREEK SMALL LETTER ALPHA'
'U+0957  GREEK SMALL LETTER NU'
'U+0959  GREEK SMALL LETTER OMICRON'
'U+0768  COMBINING GRAVE ACCENT'
'U+0962  GREEK SMALL LETTER FINAL SIGMA'
'U+0032  SPACE'
'U+0949  GREEK SMALL LETTER EPSILON'
'U+0787  COMBINING COMMA ABOVE'
'U+0769  COMBINING ACUTE ACCENT'
'U+0947  GREEK SMALL LETTER GAMMA'
'U+0961  GREEK SMALL LETTER RHO'
'U+0945  GREEK SMALL LETTER ALPHA'
'U+0968  GREEK SMALL LETTER PSI'
'U+0949  GREEK SMALL LETTER EPSILON'
'U+0032  SPACE'
'U+0964  GREEK SMALL LETTER TAU'
'U+0961  GREEK SMALL LETTER RHO'
'U+0959  GREEK SMALL LETTER OMICRON'
'U+0769  COMBINING ACUTE ACCENT'
'U+0955  GREEK SMALL LETTER LAMDA'
'U+0955  GREEK SMALL LETTER LAMDA'
'U+0959  GREEK SMALL LETTER OMICRON'
'U+0953  GREEK SMALL LETTER IOTA'
>>> 

but it is however not explaining why 
serious tools does not have to waste time in
encoding to save memory.

>>> sys.getsizeof(s)
84
>>> sys.getsizeof(s.encode('utf-16-le'))
71

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

#81206

On 11/20/14, 4:04 AM, Christian Gollwitzer wrote:
> Apple is a
> moving target, they pulled the rug from under Tk's feet twice over the
> past 10 years. Nobody knows if Tk will continue to exist on the mac if
> Cocoa is withdrawn some day and replaced by a new and completely
> different windowing framework.

There is indeed a lack of manpower and expertise for Tk/Mac:  I'm pretty 
much it, except when someone submits a patch to scratch a specific itch.

Apple has introduced Swift as a new systems language, but (as I 
understand it) the intent is to supersede Objective-C as a language, not 
the Cocoa frameworks per se. So I think the risk of a brand-new 
windowing system replacing Cocoa (and thus requiring yet another new 
implementation of Tk) is pretty small. There may be a larger risk with 
newer API's being expressed mainly in Swift, which would require 
conversion to Objective-C for legacy codebases, but that is a smaller 
hurdle to clear.

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

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

#81246

Le jeudi 20 novembre 2014 10:04:40 UTC+1, Christian Gollwitzer a écrit :
> Am 20.11.14 09:40, schrieb Chris Angelico:
> > On Thu, Nov 20, 2014 at 7:25 PM, Paul Rubin <no.email@nospam.invalid> wrote:
> >> wxjmfauth@gmail.com writes:
> >>> Today, there are simply no more valid and working
> >>> GUI toolkit running "out of the box".
> >>
> >> Tkinter still works for me.  What's the problem?
> >
> > Ignore jmf.
> 
> He is trolling,


Certainly not, and Python is, in my mind, really in
bad shape.

jmf

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

#81265

On 11/20/2014 02:17 AM, Chris Angelico wrote:
> But I agree about the issues with tkinter. So, let's see. Shall we
> wait for Tcl/Tk Unicode support? Recommend people switch to PyGTK? To
> PyQt? To wxPython? To something else? Personally, I'm quite happy with
> GTK2 (though that's with Pike, not Python), and it does have full
> Unicode support; but there are some issues with the interface that
> make it feel a bit clunky. Every other windowing toolkit has its own
> flaws. Even if one of them were to be blessed into the stdlib (which
> would remove the whole "but it's an external dependency" problem),
> there's still no perfect option, and every toolkit will have its
> staunch supporters.

GTK2 and GTK3 are pretty sweet to work with in Python.  The bindings are
very nice and fairly idiomatic. So it feels natural.  However GTK is not
really cross-platform in any usable way.  It's really Unix-only, though
more and more it's moving towards Linux-only.  Due to a lack of manpower
and demand, the Windows port lags far behind X11, and despite decent
theming support (I think it can employ mstheme.dll to draw widgets), it
feels foreign and clunky.  On Mac things are even worse, as far as I can
see.  Just not enough people who can and want to contribute there.

I can't speak for wxWidgets, but when I last looked at it years ago it
fairly reeked of MFC-style GUI programming with event tables instead of
a nice, flexible signal/callback interface.  Has this changed?

My current recommendation is to use PyQt or PySide.  I'm going to look
at PySide soon, but PyQt feels a bit foreign on Python.  Code comes out
looking like C++ using Python keywords.  It has its own facilities for
many things as well that overlap Python's standard libraries.  But all
in all it is the most cross-platform of any that I've seen.  It looks
and can act fairly native on Windows and Mac.  Ironically I find Qt
looks best on Linux when using the GTK theme engine.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web