GUIs - A Modest Proposal
in [Python]
|
From: rantingrick on 9 Jun 2010 14:11 On Jun 9, 12:53 pm, Brian Blais <bbl...(a)bryant.edu> wrote: > On Jun 9, 2010, at 7:16 , ant wrote: > > > 1 Although a few advocates of Tkinter have spoken in favour of it, > > most seem to think that: > > It's not particularly elegant, either in its use or its > > implementation with Tcl/Tk > > Not many people use it anyway, so why bother? > > > 2 Most people who have used a GUI have some investment in it. So > > arguments about which one is best tend to be > > partial and not wonderfully constructive. > > In this whole discussion, I haven't seen anyone mention wax (http:// > zephyrfalcon.org/labs/wax_primer.html) I myself would not be opposed to a thin Wx, i think it would be a step in the right direction. The project looks very interesting although i have not tried the thing out yet so i can only speak to the idea of it. The beauty is that at least you're investing your time into something that scales into professional level GUI building. Wx has a very large and up to date widget set. With Tkinter you get so far and then bang, brick wall! Your confined by even TclTk so there is no hope of escape! +1 wax
From: rantingrick on 9 Jun 2010 14:27 On Jun 9, 1:06 pm, Adam Tauno Williams <awill...(a)whitemice.org> wrote: > Or just use a different one. Simple enough. Thats not even valid to this argument. Everyone IS free to choose another GUI already. Please re-read this entire thread, absorb the contents therein, ponder extensively the pros and cons, and then formulate an intelligent response. I for one would love to hear some real input from you. > NOT writing code does guarantee NOTHING!! just argumentative. > A point cannot miss itself, that doesn't make sense. "code is working" > *is* the point, the whole point, and there is no other point. just argumentative. > Or not, whatever. just really argumentative. > Or we don't. just more of the same. Can you give us some real explanations as to why you think Tkinter... A. should be included B. should be replaced C. should be improved ....that are more than just argumentative bile?
From: Martin v. Loewis on 9 Jun 2010 15:15 Am 09.06.2010 01:54, schrieb Grant Edwards: > On 2010-06-08, Martin v. Loewis<martin(a)v.loewis.de> wrote: >> Am 08.06.2010 20:15, schrieb Grant Edwards: >>> On 2010-06-08, Martin v. Loewis<martin(a)v.loewis.de> wrote: >>>>> TkInter -> Tcl -> Tk -> Xlib >>>>> >>>>> Is the Tcl intepreter really need to use this GUI? Why not: >>>>> >>>>> (Pyton ->) Tkinter-API -> Xlib ? >>>> >>>> Even if this was possible (which it is not) >>> >>> Why is it not possible? It seems to have been done for other >>> languages. >> >> So you don't know for sure? Which implementation specifically >> do you think of? > > There was a Scheme implementation called STk that didn't use Tcl. That's not true. See, for example, Src/tk-glue.c. It contains functions like static SCM TkResult2Scheme(Tcl_Interp *interp, int objproc) { SCM res; if (objproc) { register SCM data = TCLOBJDATA((SCM) Tcl_GetObjResult(interp)); res = data ? STk_convert_tcl_list_to_scheme(data) : NIL; } else { register char *s = interp->result; res = (*s) ? STk_convert_Tcl_string2list(s) : NIL; } Tcl_ResetResult(interp); return res; } SCM STk_execute_Tcl_lib_cmd(SCM cmd, SCM args, SCM env, int eval_args) .... This looks *exactly* like the approach taken in _tkinter to me. One difference seems to be that they include the full source code of Tcl and Tk with the interpreter, so you don't need to download it separately. The other difference apparently is that they expose Tcl commands as Scheme functions, so that they can write (Tk:pack [Tk:frame w.top :relief "raised" :bd 1] :expand #t :fill "both") However, this still uses a Tcl_Interp object during evaluation. Regards, Martin
From: Martin v. Loewis on 9 Jun 2010 15:28 > But whenever I > write a program that someone else is going to use, it has to have a > GUI. Is that not true for most people? Most definitely not. Of the programs I recently wrote for other people, they either: - were command line scripts, meant to use for sysadmin jobs (and I wrote them for the sysadmin people around me), or - were web application, most of them written with Django I have written 3 GUI applications in the last five years, one in Tkinter, the other two in Java Swing (one being a Swing reimplementation of the Tkinter code because the users needed Java). In addition, I *contributed* to GUI applications that others had written, mainly IDLE. > That, in my opinion, is where a replacement for Tkinter should be > aimed: the beginning graphics programmer. > But if it is built on the right foundation (which Tkinter seems not > to be), it could be extended to cover > far more useful cases than Tkinter can. I personally think that Tkinter is excellent for the beginning graphics programmer. > I don't think so. Even vast libraries of well-written code haven't > become the standard. I seem to remember a > DEC assembler manual from the last century, which said "A standard > doesn't have to be optimal, it just has to be > standard" (Feel free to correct me on that one. The last century > seems like a long time ago). See, that's exactly because Tkinter is the standard; I see no reason for that to change (or, rather, no chance). As a starting point, if Tkinter was replaced, an IDE similar to or more powerful than IDLE would be needed to replace IDLE. > It can't be me - I don't have the clout. That's the reason why it won't happen. Everybody asking for change is not willing to lead the effort. Everybody who would be able and might be willing to lead the change fails to see the need for change. Regards, Martin
From: Martin v. Loewis on 9 Jun 2010 15:42
Am 09.06.2010 19:16, schrieb Ethan Furman: > Gregory Ewing wrote: >> Kevin Walzer wrote: >>> PyGUI ... certainly is *not* a lightweight GUI toolkit that could >>> easily be incorporated into the Python core library--it instead has >>> rather complex dependencies on both other GUI toolkits and Python >>> wrappers of those toolkits. >> >> I don't see how the dependencies could be regarded as "complex". >> There's more or less only one on each platform, and they're >> pretty standard accessories for the platform concerned. You could >> say there are two on Linux if you count gtk itself, but you almost >> certainly already have it these days if you're running any >> kind of desktop at all. > > *Alert* Potentially dumb question following: On the MS Windows platform, > Gtk is not required, just win32? pywin32, to be precise. To include PyGui into Python, either PythonWin would have to be included (which would require it to be contributed in the first place), or the win32 extensions would need to be rewritten, or PyGui would need to be implemented in terms of ctypes (which then would prevent its inclusion, because there is a policy that ctypes must not be used in the standard library). I would personally prefer the win32 extensions to be rewritten for use in core Python. I think it should be possible to generate a Win32 wrapper much more automatically (e.g. using Cython, or something like it), and I think that the separation of pywin32 into modules is somewhat arbitrary - either there should be a single "windows" module, or the split should be by DLL (which still is arbitrary, but defined by MS). That is, of course, all off-topic. Regards, Martin |