On Jun 6, 10:55 pm, ant <shi...@uklinux.net> wrote: > On Jun 6, 2:22 pm, ant <shi...@uklinux.net> wrote:> I get the strong feeling > that nobody is really happy with the state of > > Python GUIs. > > <snip...> > > What an interesting set of responses I got! > And - even more interesting - how few of them actually seem to think > there is a problem, let > alone make any attempt to move the situation forward. > I appreciate that there are proponents of many different GUIs. I am > asking that all step back > from their particular interests and - for example - try to see the > situation from the viewpoint of > - say - a Python newbie, or an organisation that is thinking of > switching from (example only!) Visual Basic. > > I obviously didn't make my main point clearly enough; I'll restate it > with a different emphasis: > The default GUI shipped with Python is Tkinter. > Few people seem to like it much. This has several consequences. > - It has not blossomed, like Python has. > - There are not hundreds of talented programmers making rapid and > impressive improvements to it. > - Books about Python use it in examples (because it IS the default), > but imply that one should move on. > > The result that our hypothetical new recruit has to make a choice for > the new, big project. Remember that > GUIs have hundreds (sometimes thousands) of classes, functions and > constants. Let alone idioms and design > patterns. That is what I meant by 'Our resources are being > dissipated'; the effort of learning, remembering > and relearning a workable subset of these is substantial. > So it would be good to be able to use One Right Way, not try several > (as I have - I will admit I didn't try PyQt; > GUI fatigue was setting in by then). > > If we are to make progress, I can see two obvious approaches: > 1) Improve Tkinter to the point where it is supportable and supported > by a good fraction of Python programmers > or > 2) Drop Tkinter as the default and use something else. > > If we choose 2) then we have a new set of possibilities: > 2a) Use one of the 'major' GUIs, pretty much as is, but presumably > with a lot more people supporting it if it is the default. > 2b) Use one of the 'minor' GUIs, and get a lot of people working on it > to make it really good. > 2c) Start from scratch. With a project supported by the Community as a > whole, with the agreed objective of being the default. > > None of these is easy. All require strong leadership and great > committment. > > What surprises me is the apparent willingness of the Python community > to let this issue slide.
ah - i think... i believe you may be confusing realism with fatalism. experienced python developers are also experienced, specialist c programmers (amongst other things) and experienced software engineers. they've been around a while (10+ years). they _know_ how much effort is involved in creating a major project such as a GUI widget set (and you can get a wildly-wrong but nevertheless useful answer from ohloh.net statistics, by going to http://ohloh.net/p/gtk for example) so, spec'ing it out, we _know_ that to create a decent GUI widget set, from scratch, in c (to make it fast enough) would be... ye gods... 50 man-years of effort, minimum? you _might_ be able to reduce that by using somebody else's library (libcairo, libpango) but... just... _why_?? so this was why i went "f*** that!" and "leveraged" web browser technology, jumping from virtually nothing (an abandoned python-to- javascript compiler project) to a world-class GUI toolkit, in under 18 months of _part time_ effort. > My concern is simple: I think that Python is doomed to remain a minor > language unless we crack this problem. ah. take a look at that chart that keeps cropping up every now and then: python is _not_ a minor programming language. most likely due to django, it's rated about 7th with about ... i think it was 6% share. perl is now _under_ 4%! so i don't believe there are any concerns there: python has enough alternate uses other than as a GUI toolkit to keep it going :) l. -- http://mail.python.org/mailman/listinfo/python-list