Re: Future standard GUI library
Okay... how long does a round-trip cost? With a protocol that wasn't made for the purpose (such as HTTP) and all that HTML to render (not to mention javascript that's required for even the most trivial issues) - way too long. Considering that usability guidelines generally permit ~100ms for direct interaction, That's generous. A proficient user with a responsive application can easily outpace that. 100ms is definitely a noticeable lag. Even I feel that and I don't use touch-typing to use the GUI. 50ms might not be noticeable, but I don't have the skills myself to test that. (Magento, a PHP-based online shopping cart system, took the better part of a second - something in the order of 700-800ms - to add a single item. And that on reasonable hardware, not a dedicated server but my test box was certainly not trash.) That's not a question of hardware. Just like with MS (Not Responding). That's the entire round-trip cost. The queries from Sikorsky to Yosemite involve three computers (the client, the server, and the file server), and is completed in under 30 milliseconds. I am talking about applications that actually do something. In my case, database applications. A PostgreSQL transaction is supposed to take at most 25ms to complete (anything above is generally considered an issue that needs to be solved, such as bad SQL), *server-side*. That leaves you another 25ms for the entire network protocol (the pgsql protocol, whatever it is, was designed for the purpose, unlike HTTP) *and* the client-side application logic, including the GUI rendering. Qt is already quite sluggish sometimes, don't know why. GTK and wxPython feel swifter, at least on an actual *operating* system. MS (Not Responding) is definitely incapable to allow applications anything remotely close to responsiveness. Minute-long lockups with frozen cursor are normal. That still gives you 70 milliseconds to render the page to the user, Forget that. 25ms for client-server (pgsql) network protocol, client-side application logic *and* GUI. With a web application that would have to include application server-side application logic, *and* generation of HTML (and javascript), *and* HTTP protocol *and* HTML rendering *and* client-side javascript. Won't work. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Sat, Jun 15, 2013 at 10:25 PM, Wolfgang Keller felip...@gmx.net wrote: Okay... how long does a round-trip cost? With a protocol that wasn't made for the purpose (such as HTTP) and all that HTML to render (not to mention javascript that's required for even the most trivial issues) - way too long. You keep saying this. I have yet to see actual timings from you. Considering that usability guidelines generally permit ~100ms for direct interaction, 100ms is definitely a noticeable lag. Even I feel that and I don't use touch-typing to use the GUI. 50ms might not be noticeable, but I don't have the skills myself to test that. Okay, so let's talk 50ms then. We can handle this. That's the entire round-trip cost. The queries from Sikorsky to Yosemite involve three computers (the client, the server, and the file server), and is completed in under 30 milliseconds. I am talking about applications that actually do something. In my case, database applications. A PostgreSQL transaction is supposed to take at most 25ms to complete (anything above is generally considered an issue that needs to be solved, such as bad SQL), *server-side*. That leaves you another 25ms for the entire network protocol (the pgsql protocol, whatever it is, was designed for the purpose, unlike HTTP) *and* the client-side application logic, including the GUI rendering. No problem. Again taking *actual real figures*, I got roughly 35-40tps in PostgreSQL across a LAN. That's around about the 25ms figure you're working with, so let's use that as a baseline. My benchmark was actually a durability test from work, which was done on two laptops on a gigabit LAN, with the database server brutally powered down in the middle of the test. Each transaction updates a minimum of two rows in a minimum of one table (transaction content is randomized some). So that's 25ms for the database, leaving us 25ms for the rest. 25ms for client-server (pgsql) network protocol, client-side application logic *and* GUI. With a web application that would have to include application server-side application logic, *and* generation of HTML (and javascript), *and* HTTP protocol *and* HTML rendering *and* client-side javascript. Won't work. I've demonstrated already that with basic hardware and a simple Python HTTP server, network, application logic, and generation of HTML, all take a total of 8ms. That leaves 17ms for rendering HTML. Now, getting figures for the rendering of HTML is not easy; I've just spent fifteen minutes researching on Google and playing with the Firebug-like feature of Chrome, and haven't come up with an answer; so it may well be that 17ms isn't enough for a full page load. However, I would say that the matter is sufficiently borderline (bearing in mind that you can always use a tiny bit of JS and a DOM change) that it cannot be called as Won't work; it's what Mythbusters would dub Plausible. Of course, if you're trying to support MS IE, there's no way you'll guarantee 50ms response time. This is all predicated on having at least reasonably decent hardware and software. But using either the 100ms figure from common usability guidelines [1] [2] [3] or your more stringent 50ms requirement [4], it's certainly entirely possible to achieve immediate response using AJAX. I've worked with real figures, hard numbers. You keep coming back with vague FUD that it won't work. Where are your numbers? And like Sir Ruthven Murgatroyd, I fail to see how you can call this impossible in the face of the fact that I have done it. ChrisA [1] http://www.nngroup.com/articles/response-times-3-important-limits/ [2] http://usabilitygeek.com/14-guidelines-for-web-site-tabs-usability/#attachment_719 [3] http://calendar.perfplanet.com/2011/how-response-times-impact-business/ [4] Can you provide a link to any study anywhere that recommends 50ms? -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Fri, Jun 14, 2013 at 3:39 PM, Frank Millman fr...@chagford.com wrote: It's not either-or. The server *MUST* perform the checks at the time of form submission; the question is whether or not to perform duplicate checks earlier. This is an absolute rule of anything where the client is capable of being tampered with, and technically, you could violate it on a closed system; but it's so easy to migrate from closed system to diverse system without adding all the appropriate checks, so just have the checks from the beginning. In my case, it is either-or. I do not just do field-by-field validation, I do field-by-field submission. The server builds up a record of the data entered while it is being entered. When the user selects 'Save', it does not resend the entire form, it simply sends a message to the server telling it to process the data it has already stored. Ah, I see what you mean. What I was actually saying was that it's mandatory to check on the server, at time of form submission, and optional to pre-check (either on the client itself, for simple syntactic issues, or via AJAX or equivalent) for faster response. As a general rule, I would be inclined to go with a more classic approach for reasons of atomicity. What happens if the user never gets around to selecting Save? Does the server have a whole pile of data that it can't do anything with? Do you garbage-collect that eventually? The classic model allows you to hold off inserting anything into the database until it's fully confirmed, and then do the whole job in a single transaction. But if you want to use a wizard approach, where the user enters one thing and then moves on to the next, that can work too. It gets clunky quickly, but it can be useful if the early responses make the subsequent questions drastically different. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
Chris Angelico ros...@gmail.com wrote in message news:captjjmq_m4y0uxxt3jqythjj9ckbsvp+z2pgf5v_31xlrgf...@mail.gmail.com... On Fri, Jun 14, 2013 at 3:39 PM, Frank Millman fr...@chagford.com wrote: In my case, it is either-or. I do not just do field-by-field validation, I do field-by-field submission. The server builds up a record of the data entered while it is being entered. When the user selects 'Save', it does not resend the entire form, it simply sends a message to the server telling it to process the data it has already stored. Ah, I see what you mean. What I was actually saying was that it's mandatory to check on the server, at time of form submission, and optional to pre-check (either on the client itself, for simple syntactic issues, or via AJAX or equivalent) for faster response. As a general rule, I would be inclined to go with a more classic approach for reasons of atomicity. What happens if the user never gets around to selecting Save? Does the server have a whole pile of data that it can't do anything with? Do you garbage-collect that eventually? The classic model allows you to hold off inserting anything into the database until it's fully confirmed, and then do the whole job in a single transaction. The data is just stored in memory in a 'Session' object. I have a 'keep-alive' feature that checks if the client is alive, and removes the session with all its data if it detects that the client has gone away. Timeout is configurable, but I have it set to 30 seconds at the moment. The session is removed immediately if the user logs off. He is warned if there is unsaved data. Frank -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
I share your passion for empowering a human operator to complete and submit a form as quickly as possible. I therefore agree that one should be able to complete a form using the keyboard only. This is not just about forms, it's about using the entire application without having to use the mouse, ever. Do you have strong views on which is the preferred approach. Use a decent database RAD desktop (non-web) GUI application framework which uses client-side application logics. Validation of input will then be essentially instantaneous. Unless you run the client on that pathological non-operating system MS (Not Responding), obviously. I've posted a corresponding list of frameworks available for Python multiple times already on this group: using PyQt ( Sqlalchemy): Qtalchemy: www.qtalchemy.org Camelot: www.python-camelot.com Pypapi: www.pypapi.org using PyGTK: Sqlkit: sqlkit.argolinux.org (also uses Sqlalchemy) Kiwi: www.async.com.br/projects/kiwi using wxPython: Gui2Py: code.google.com/p/gui2py/ Dabo: www.dabodev.com Defis: sourceforge.net/projects/defis (Russian only) GNUe: www.gnuenterprise.org Server-roundtrips required for simple user interaction are an absolute non-starter for productivity applications. No matter whether in a LAN or WAN. If you want a responsive application you have to de-centralise as much as possible. Perfect solution would be if Bettina Kemme's Postgres-R was available for production use, then even the persistence could run locally on the client with asynchronous replication of all clients (peer to peer). Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Sat, Jun 15, 2013 at 1:18 AM, Wolfgang Keller felip...@gmx.net wrote: Server-roundtrips required for simple user interaction are an absolute non-starter for productivity applications. No matter whether in a LAN or WAN. If you want a responsive application you have to de-centralise as much as possible. Okay... how long does a round-trip cost? Considering that usability guidelines generally permit ~100ms for direct interaction, and considering that computers on a LAN can easily have sub-millisecond ping times, it seems to me you're allowing a ridiculous amount of time for code to execute on the server. Now, granted, there are systems that suboptimal. (Magento, a PHP-based online shopping cart system, took the better part of a second - something in the order of 700-800ms - to add a single item. And that on reasonable hardware, not a dedicated server but my test box was certainly not trash.) For a real-world example of a LAN system that uses a web browser as its UI, I'm using the Yosemite Project here. It consists of a single-threaded Python script, no scaling assistance from Apache, just the simplest it can possibly be. It is running on three computers: yosemite [the one after whom the project was named], huix, and sikorsky. I used 'time wget http://hostname:3003/airshow' for my testing, which involves: * A DNS lookup from the local DNS server (on the LAN) * An HTTP query to the specified host * A directory listing, usually remote * Building a response (in Python) * Returning that via HTTP * Save the resulting page to disk Since I'm using the bash 'time' builtin, all of this is counted (I'm using the 'real' figure here; the 'user' and 'sys' figures are of course zero, or as close as makes no odds - takes no CPU to do this). The files in question are actually stored on Huix. Queries to that server therefore require a local directory listing; queries to sikorsky involve an sshfs directory listing, and those to yosemite use NetBIOS. (Yosemite runs Windows XP, Huix and Sikorsky are running Linux.) My figures do have one peculiar outlier. Queries from Sikorsky to Yosemite were taking 4-5 seconds, consistently; identical queries from Huix to Yosemite were more consistent with other data. I have no idea why this is. So, the figures! Every figure I could get for talking to a Linux server (either Huix or Sikorsky) was between 7ms and 16ms. (Any particular combination of client and server is fairly stable, eg sikorsky - sikorsky is consistently 8ms.) And talking to the Windows server, aside from the crazy outlier, varied from 22ms to 29ms. Considering that the Windows lookups involve NetBIOS, I'm somewhat not surprised; there's a bit of cost there. That's the entire round-trip cost. The queries from Sikorsky to Yosemite involve three computers (the client, the server, and the file server), and is completed in under 30 milliseconds. That still gives you 70 milliseconds to render the page to the user, and still be within the estimated response time for an immediate action. In the case of localhost, as mentioned above, that figure comes down to just 8ms - just *eight milliseconds* to do a query involving two servers - so I have to conclude that HTTP is plenty fast enough for a UI. I have seen a number of desktop applications that can't beat that kind of response time. There, thou hast it all, Master Wilfred. Make the most of it. :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
Wolfgang Keller felip...@gmx.net wrote in message news:2013061819.2a044e86ab4b6defe1939...@gmx.net... But could it be that you have never seen an actually proficient user of a typical enterprise application (ERP, MRP, whatever) zipping through the GUI of his/her bread-and-butter application so fast that you can not even read the titles of windows or dialog boxes. Obviously, this won't work if the client runs on this pathological non-operating system MS (Not Responding), much less with web applications. [...] On a LAN, with a proper back-end, I can get instant response from a web app. I have been involved as domain specialist (and my input has always been consistently conveniently ignored) with projects for web applications and the results never turned out to be even remotely usable for actually productive work. Hi Wolfgang I share your passion for empowering a human operator to complete and submit a form as quickly as possible. I therefore agree that one should be able to complete a form using the keyboard only. There is an aspect I am unsure of, and would appreciate any feedback based on your experience. I am talking about what I call 'field-by-field validation'. Each field could have one or more checks to ensure that the input is valid. Some can be done on the client (e.g. value must be numeric), others require a round-trip to the server (e.g. account number must exist on file). Some applications defer the server-side checks until the entire form is submitted, others perform the checks in-line. My preference is for the latter. I agree with Chris that on a LAN, it makes little or no difference whether the client side is running a web browser or a traditional gui interface. On a WAN, there could be a latency problem. Ideally an application should be capable of servicing a local client or a remote client, so it is not easy to find the right balance. Do you have strong views on which is the preferred approach. Thanks for any input. Frank Millman -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Thu, Jun 13, 2013 at 7:32 PM, Frank Millman fr...@chagford.com wrote: I am talking about what I call 'field-by-field validation'. Each field could have one or more checks to ensure that the input is valid. Some can be done on the client (e.g. value must be numeric), others require a round-trip to the server (e.g. account number must exist on file). Some applications defer the server-side checks until the entire form is submitted, others perform the checks in-line. My preference is for the latter. It's not either-or. The server *MUST* perform the checks at the time of form submission; the question is whether or not to perform duplicate checks earlier. This is an absolute rule of anything where the client is capable of being tampered with, and technically, you could violate it on a closed system; but it's so easy to migrate from closed system to diverse system without adding all the appropriate checks, so just have the checks from the beginning. In terms of software usability, either is acceptable, but do make sure the user can continue working with the form even if there's latency talking to the server - don't force him/her to wait while you check if the previous field was valid. I know that seems obvious, but apparently not to everyone, as there are forms out there that violate this... ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
Chris Angelico ros...@gmail.com wrote in message news:CAPTjJmo+fWsCD3Lb6s+zmWspKzzk_JB=pbcvflbzjgcfxvm...@mail.gmail.com... On Thu, Jun 13, 2013 at 7:32 PM, Frank Millman fr...@chagford.com wrote: I am talking about what I call 'field-by-field validation'. Each field could have one or more checks to ensure that the input is valid. Some can be done on the client (e.g. value must be numeric), others require a round-trip to the server (e.g. account number must exist on file). Some applications defer the server-side checks until the entire form is submitted, others perform the checks in-line. My preference is for the latter. It's not either-or. The server *MUST* perform the checks at the time of form submission; the question is whether or not to perform duplicate checks earlier. This is an absolute rule of anything where the client is capable of being tampered with, and technically, you could violate it on a closed system; but it's so easy to migrate from closed system to diverse system without adding all the appropriate checks, so just have the checks from the beginning. In my case, it is either-or. I do not just do field-by-field validation, I do field-by-field submission. The server builds up a record of the data entered while it is being entered. When the user selects 'Save', it does not resend the entire form, it simply sends a message to the server telling it to process the data it has already stored. In terms of software usability, either is acceptable, but do make sure the user can continue working with the form even if there's latency talking to the server - don't force him/her to wait while you check if the previous field was valid. I know that seems obvious, but apparently not to everyone, as there are forms out there that violate this... I plead guilty to this, but I am not happy about it, hence my original post. I will take on board your comments, and see if I can figure out a way to have the best of both worlds. Frank -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
A touch-type GUI is a must have for any application that's supposed to be used productively. The mouse is nice to explore a GUI or for occasional/leisurely use, but once you use an application daily to earn your living, it's a hopeless roadblock for productivity. You have seriously underestimated the power of the combined keyboard+mouse interface. As someone who has started to use computers with the Atari ST and later the Mac, and as someone who has never become proficient himself with any of the various Unix shells (besides that I had to learn to *hate* any version of MS DOS or MS (Not Responding)), I certainly don't underestimate the value of the mouse. But could it be that you have never seen an actually proficient user of a typical enterprise application (ERP, MRP, whatever) zipping through the GUI of his/her bread-and-butter application so fast that you can not even read the titles of windows or dialog boxes. Obviously, this won't work if the client runs on this pathological non-operating system MS (Not Responding), much less with web applications. Oh, and btw; SAP is a particularly illustrative example for the horrible response time behaviour of applications with centralised application logic. They call it hour-glass display program over here, SanduhrAnzeigeProgramm in German. As is the response time behaviour of web applications. On a LAN, with a proper back-end, I can get instant response from a web app. I have been involved as domain specialist (and my input has always been consistently conveniently ignored) with projects for web applications and the results never turned out to be even remotely usable for actually productive work. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
A GUI that can not be used without taking the ten fingers off the keyboard is indeed entirely unusable for any half-proficient screenworker. And anyone doing actual productive screenwork every day for more than just a few months will inevitably (have to) get proficient (unless completely braindead). My ten fingers stay on my keyboard, which looks somewhat thus: http://www.xbitlabs.com/images/mobile/lenovo-thinkpad-t61/keyboard.jpg See the red dot in the middle? Mouse. I didn't mean trackpoints or similar devices, but full keyboard navigation of the entire GUI through shortcuts etc. A touch-type GUI is a must have for any application that's supposed to be used productively. The mouse is nice to explore a GUI or for occasional/leisurely use, but once you use an application daily to earn your living, it's a hopeless roadblock for productivity. As is the response time behaviour of web applications. Besides that pathological non-operating system MS (Not Responding), btw. No cursor animation ever is an absolute must have requirement for productivity applications. THIS is a professional programmer's workspace. :) And by screenworkers I didn't refer to programmers. Those people rarely have to use the stuff that they implement. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Sun, Jun 2, 2013 at 4:18 AM, Wolfgang Keller felip...@gmx.net wrote: A GUI that can not be used without taking the ten fingers off the keyboard is indeed entirely unusable for any half-proficient screenworker. And anyone doing actual productive screenwork every day for more than just a few months will inevitably (have to) get proficient (unless completely braindead). My ten fingers stay on my keyboard, which looks somewhat thus: http://www.xbitlabs.com/images/mobile/lenovo-thinkpad-t61/keyboard.jpg See the red dot in the middle? Mouse. I didn't mean trackpoints or similar devices, but full keyboard navigation of the entire GUI through shortcuts etc. A touch-type GUI is a must have for any application that's supposed to be used productively. The mouse is nice to explore a GUI or for occasional/leisurely use, but once you use an application daily to earn your living, it's a hopeless roadblock for productivity. You have seriously underestimated the power of the combined keyboard+mouse interface. I absolutely agree that keyboard-only will (almost) always beat mouse-only, but keyboard AND mouse together can beat either alone, if the UI is designed correctly. Case in point: Partial staging of a file in git. I can use 'git add -p' or 'git gui'. With the former, it's all keyboard; I can step through the hunks, choose what to stage, move on. With the latter, it's more visual; I right-click a hunk and choose Stage this hunk (or Stage this line, which is actually quite fiddly with 'git add -p'). I am a self-confessed keyboard junkie. I will use the keyboard for pretty much everything. Yet I use git gui and almost never git add -p, the one exception being when I can't use git gui (eg it's not installed on some remote headless system and installing it would require fetching gobs of GUI libraries). It uses the mouse to good result. As is the response time behaviour of web applications. On a LAN, with a proper back-end, I can get instant response from a web app. Obviously over the internet there's latency, but that's nothing to do with the use of a web browser as a UI; you'll see that with ssh just as much. No cursor animation ever is an absolute must have requirement for productivity applications. Not really. There are times when the human will be legitimately waiting for the computer. http://xkcd.com/303/ for one. But this still has little to do with the use of a web browser UI; I can achieve exactly that with the Yosemite Project, which can actually be a three-computer system: the content is stored on one, the HTTP server is on another, and the web browser is separate again. And this is only a 100Mbit LAN. If you need moar speeed, you can always demand gigabit or better. THIS is a professional programmer's workspace. :) And by screenworkers I didn't refer to programmers. Those people rarely have to use the stuff that they implement. Of course not, programmers never use software they've themselves written. Never. Not in a million... oh wait, what's this I have? Hmm, gcc used to compile gcc, RosMud being used by Rosuav, Neil Hodgson using SciTE... naw, they're all statistical anomalies, carry on! You really have a very low opinion of programmers for someone on a programming mailing list :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On 6/1/2013 4:46 PM, Chris Angelico wrote: On Sun, Jun 2, 2013 at 4:18 AM, Wolfgang Keller felip...@gmx.net wrote: And by screenworkers I didn't refer to programmers. Those people rarely have to use the stuff that they implement. Of course not, programmers never use software they've themselves written. Never. Not in a million... oh wait, what's this I have? Hmm, gcc used to compile gcc, RosMud being used by Rosuav, Neil Hodgson using SciTE... naw, they're all statistical anomalies, carry on! And I use Idle to improve Idle. I use the HgWorkbench front-end to hg because point and click is often *faster* for me than remember (or look up command and arg) and type (without error, or correction after error). Now back to ignoring the troll. Terry -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
suppose I now want the app natively on my phone (because that's all the rage). It's an iPhone. Oh. Apple doesn't support Python. Okay, rewrite the works, including business logic, in Objective C. Now I want it on my android phone. Those are gadgets, not work tools. As a professional programmer I'm afraid you're going to soon find yourself out of work if you really see things that way. As a domain expert, I come from the end-user side of enterprise applications and again; those are not tools for screenworkers to get actual work done, but consumer crap for fad-driven gadget-addicted kids (regardless of nominal age). I honestly used to feel that way about graphical user interfaces. A GUI that can not be used without taking the ten fingers off the keyboard is indeed entirely unusable for any half-proficient screenworker. And anyone doing actual productive screenwork every day for more than just a few months will inevitably (have to) get proficient (unless completely braindead). Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Fri, May 31, 2013 at 2:40 AM, Wolfgang Keller felip...@gmx.net wrote: A GUI that can not be used without taking the ten fingers off the keyboard is indeed entirely unusable for any half-proficient screenworker. And anyone doing actual productive screenwork every day for more than just a few months will inevitably (have to) get proficient (unless completely braindead). My ten fingers stay on my keyboard, which looks somewhat thus: http://www.xbitlabs.com/images/mobile/lenovo-thinkpad-t61/keyboard.jpg See the red dot in the middle? Mouse. See the keys all around it? My hands are all over that. I can casually mouse and keyboard at the same time. Doesn't bother me. THIS is a professional programmer's workspace. :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Wed, May 29, 2013 at 3:26 AM, Wolfgang Keller felip...@gmx.net wrote: I won't give you an example, but just some very basic criteria: - It must be very efficient for very small datagrams - It must provide connections - For asynchronous programming it must provide for callbacks In other words, a TELNET connection. I absolutely concur. I've made extensive use of that family of protocols; between MUDs (three active connections right at this moment), mail (SMTP and POP both), actual command execution (though that's usually encrypted via SSH), and *seven* separate protocols that I devised for work, I pretty much *always* am working with a system that parses text into lines and (usually) lines into commands with arguments. It's a broad concept that can be applied to *everything*. I'm firmly of the opinion that Magic: The Gathering could be played over a MUD connection. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Tue, May 28, 2013 at 9:10 AM, Roy Smith r...@panix.com wrote: In article mailman.2265.1369693294.3114.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: I'll use XML when I have to, but if I'm inventing my own protocol, nope. There are just too many quirks with it. How do you represent an empty string named Foo? Foo/Foo or equivalently Foo/ How do you represent an empty list named Foo? The same way. How do you represent an empty dict/mapping named Foo? Lemme look up my documentation... ah, the same way. Does this seem right to you?/JubalEarly XML doesn't represent strings, or lists, or dicts. It represents trees of nodes with labels. If you wish to invent some richer semantic meaning to impose on those nodes, that's up to you. Sure it doesn't, but it's very often used that way. So I guess what I'm really saying is that XML is wrong for 90% of the places it's used. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
Chris Angelico於 2013年5月28日星期二UTC+8下午3時11分55秒寫道： On Tue, May 28, 2013 at 9:10 AM, Roy Smith r...@panix.com wrote: In article mailman.2265.1369693294.3114.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: I'll use XML when I have to, but if I'm inventing my own protocol, nope. There are just too many quirks with it. How do you represent an empty string named Foo? Foo/Foo or equivalently Foo/ How do you represent an empty list named Foo? The same way. How do you represent an empty dict/mapping named Foo? Lemme look up my documentation... ah, the same way. Does this seem right to you?/JubalEarly XML doesn't represent strings, or lists, or dicts. It represents trees of nodes with labels. If you wish to invent some richer semantic meaning to impose on those nodes, that's up to you. Sure it doesn't, but it's very often used that way. So I guess what I'm really saying is that XML is wrong for 90% of the places it's used. ChrisA Please check the annual sales in Ebay or similar sites and the advertizement fees collected by Google and Yahoo. -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On 2013-05-26, Roy Smith r...@panix.com wrote: Michael Torrie torr...@gmail.com wrote: On good thing web development has brought us is the knowledge that modularization and layers are a brilliant idea. Modularization and layers were a brilliant idea long before the web came around. Once again USENET proves to be an unsuitable RPC protocol for implementing irony. :) [OTOH, perhaps Micheal wasn't being ironic...] -- Grant Edwards grant.b.edwardsYow! Am I having fun yet? at gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
Please give me an example of a suitable transport layer for a RPC protocol. I won't give you an example, but just some very basic criteria: - It must be very efficient for very small datagrams - It must provide connections - For asynchronous programming it must provide for callbacks No RPC-over-HTTP protocol that I know of does this. Besides, no one needs RPC just to logically separate GUI and application layer. And between application logic and database, you use the native database API for the RDBMS in question, of course. The whole idea to centralise application logic (and even the GUI with web applications) is backwards, it dates from the 70s/early 80s when desktop computers weren't able to run application logic. Today, to make an application responsive (minimise latencies and maximise throughput), it's just obvious to *de*-centralise as much as possible. In fact, if Postgres-R was available for production, you could even distribute the persistence and run an entirely serverless application. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
What is screenwork? Actually productive work of significant intensity at a computer screen. As opposed to leisurely clicking around like managers, administrators or home users (gaming, webbing,...) do. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On 05/28/2013 11:26 AM, Wolfgang Keller wrote: Please give me an example of a suitable transport layer for a RPC protocol. I won't give you an example, but just some very basic criteria: - It must be very efficient for very small datagrams I won't argue for XML here, but sometimes space efficiency is simply a premature optimization. - It must provide connections How would you do this? Connections can and do get dropped regularly. To rebuild connections you need another layer to track them. - For asynchronous programming it must provide for callbacks What do you mean by this? A transport layer has nothing to do with callbacks. All a client can do is make the call, and wait for the answer. The client library can make it look asynchronous of course. And I suppose one could implement an RPC system using UDP where answer packets are dispatched as they come in. -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On 2013-05-28, Wolfgang Keller felip...@gmx.net wrote: Actually productive work of significant intensity at a computer screen. Oh. You mean emacs. -- Grant Edwards grant.b.edwardsYow! Will it improve my at CASH FLOW? gmail.com -- http://mail.python.org/mailman/listinfo/python-list
RE: Future standard GUI library
From: felip...@gmx.net Subject: Re: Future standard GUI library Date: Tue, 28 May 2013 19:26:55 +0200 To: python-list@python.org Please give me an example of a suitable transport layer for a RPC protocol. I won't give you an example, but just some very basic criteria: - It must be very efficient for very small datagrams Interoperability is much more expensive than efficiency. That's why you won't get the most optimized protocol for speed or size. - It must provide connections What do you mean? - For asynchronous programming it must provide for callbacks No RPC-over-HTTP protocol that I know of does this. XHR implements asynchronous callbacks over HTTP. Besides, no one needs RPC just to logically separate GUI and application layer. And between application logic and database, you use the native database API for the RDBMS in question, of course. The whole idea to centralise application logic (and even the GUI with web applications) is backwards, it dates from the 70s/early 80s when desktop computers weren't able to run application logic. Today, to make an application responsive (minimise latencies and maximise throughput), it's just obvious to *de*-centralise as much as possible. In fact, if Postgres-R was available for production, you could even distribute the persistence and run an entirely serverless application. web applications is so nowadays! All of my recent software development projects (last 10 years) focus on business processes integration. In all of them the BLL (Business Logic Layer), or application logic, is run on server side (as a controller in MVC) due to security and performance reasons. None of my clients want their business rules and internal workflows exposed, so the old ways of the 70/80's ain't gonna change. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
Grant Edwards於 2013年5月29日星期三UTC+8上午2時25分08秒寫道： On 2013-05-28, Wolfgang Keller felip...@gmx.net wrote: Actually productive work of significant intensity at a computer screen. Oh. You mean emacs. -- Grant Edwards grant.b.edwardsYow! Will it improve my at CASH FLOW? gmail.com Check http://www.pyamf.org/index.html for Python +flash in browser applications. Annyway the virtual server part can be obtained from the Adobe system in the cloudy services or whatever. As long as it is scalable in fees to provide services to web users in PCs or mobile phones, then it might be very profitable than 10 to 15 years ago. -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
Your back end exposes services and business logic, and your front end can be in HTMLv5 and Javascript, or QtQuick, PyGTK, or Visual Studio. If you do need a native interface, it's a heck of a lot easier to rewrite just the frontend then the entire stack. Any decent database CRUD framework will allow to implement the application model as behaviour complete domain objects, with a persistence layer totally independent from the GUI layer. In many Python RAD frameworks, this is done using SQLalchemy. Who cares how the RPC is done; As an end-user I do care for how much an application makes we watch the cursor animation. that's an implementation detail. HTTP does happen to work well though. Why do you say it is not suitable? Because from personal experience I know too well that it does definitely not work well though. suppose I now want the app natively on my phone (because that's all the rage). It's an iPhone. Oh. Apple doesn't support Python. Okay, rewrite the works, including business logic, in Objective C. Now I want it on my android phone. Those are gadgets, not work tools. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
HTTP handles that just fine, with your choice of XML, And XML is definitely not suitable as a marshalling format for a RPC protocol. XML-over-HTTP is a true cerebral flatulance of some hopelessly clueless moron. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On 05/27/2013 09:31 AM, Wolfgang Keller wrote: HTTP handles that just fine, with your choice of XML, And XML is definitely not suitable as a marshalling format for a RPC protocol. XML-over-HTTP is a true cerebral flatulance of some hopelessly clueless moron. Hmm. Well I think there are a lot of very smart developers that are using xml to marshal rpc and it's working fine. So either they know something you don't, or maybe they are just busy making code that functions and functions pretty well, instead of making inflammatory statements on USENET. Sure XML is not very efficient or compact, but it does handle unicode intrinsically through standard encodings, and a plethora of parsers makes it a decent choice. It's like what they say about the book: for though it has many omissions and contains much that is apocryphal, or at least wildly inaccurate, it scores over the older, more pedestrian work in two important respects. First, it is slightly cheaper; and second, it has the words Don't Panic inscribed in large friendly letters on its cover. I've used LBER-encoded wire protocol before, and it was fine, but hard to debug on the wire, and didn't haven anything in it to handle unicode except base64-encoding utf8 byte streams. That said, all this reminds me of a good saying, XML is like violence; if it doesn't solve your problem you're not using enough of it. Fortunately none of this really matters. Who cares what is used to marshall RPC over the wire? As a developer I certainly don't care. I'll use whatever is convenient and well supported. One reason I do like xmlrpc, though, because it's pretty much available to all web-based back ends for free (or at little cost) and you don't need to set up a special server process to handle it, or deal with odd port numbers that might be blocked, doing ssl yourself, etc. Having HTTP do the transport frees me from having to worry about all that, since in the case of a web app I am already using a web server. -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On 05/27/2013 09:22 AM, Wolfgang Keller wrote: suppose I now want the app natively on my phone (because that's all the rage). It's an iPhone. Oh. Apple doesn't support Python. Okay, rewrite the works, including business logic, in Objective C. Now I want it on my android phone. Those are gadgets, not work tools. As a professional programmer I'm afraid you're going to soon find yourself out of work if you really see things that way. I honestly used to feel that way about graphical user interfaces. -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Tue, May 28, 2013 at 3:13 AM, Michael Torrie torr...@gmail.com wrote: On 05/27/2013 09:31 AM, Wolfgang Keller wrote: HTTP handles that just fine, with your choice of XML, And XML is definitely not suitable as a marshalling format for a RPC protocol. XML-over-HTTP is a true cerebral flatulance of some hopelessly clueless moron. Hmm. Well I think there are a lot of very smart developers that are using xml to marshal rpc and it's working fine. So either they know something you don't, or maybe they are just busy making code that functions and functions pretty well, instead of making inflammatory statements on USENET. Sure XML is not very efficient or compact, but it does handle unicode intrinsically through standard encodings, and a plethora of parsers makes it a decent choice. I'll use XML when I have to, but if I'm inventing my own protocol, nope. There are just too many quirks with it. How do you represent an empty string named Foo? Foo/Foo or equivalently Foo/ How do you represent an empty list named Foo? The same way. How do you represent an empty dict/mapping named Foo? Lemme look up my documentation... ah, the same way. Does this seem right to you?/JubalEarly ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
In article mailman.2265.1369693294.3114.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: I'll use XML when I have to, but if I'm inventing my own protocol, nope. There are just too many quirks with it. How do you represent an empty string named Foo? Foo/Foo or equivalently Foo/ How do you represent an empty list named Foo? The same way. How do you represent an empty dict/mapping named Foo? Lemme look up my documentation... ah, the same way. Does this seem right to you?/JubalEarly XML doesn't represent strings, or lists, or dicts. It represents trees of nodes with labels. If you wish to invent some richer semantic meaning to impose on those nodes, that's up to you. JSON isn't better or worse than XML. They solve different problems. -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Tue, 28 May 2013 08:21:25 +1000, Chris Angelico wrote: I'll use XML when I have to, but if I'm inventing my own protocol, nope. There are just too many quirks with it. How do you represent an empty string named Foo? Foo/Foo or equivalently Foo/ How do you represent an empty list named Foo? The same way. How do you represent an empty dict/mapping named Foo? Lemme look up my documentation... ah, the same way. Does this seem right to you?/JubalEarly Foo type=list / Foo type=mapping / Foo type=string / -- Denis McMahon, denismfmcma...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
Both the concept and actually implemented examples of so-called web applications prove that they are just plain garbage and hopelessly unusable for anything remotely resembling actual screenwork. HTML forms may be at best useful for web shops, but for actual screenwork, HTML is not a valid GUI, no matter how much javascript you add to it. All depends on your requirements. Obivously, if your requirements are to be compliant with latest IT management fads and to not give a darn for end-user productivity or even legal requirements for screen workplace ergonomics... For the Yosemite Project, I wanted the networking aspect, so the web browser UI was a good one. From the description this looks like a simble database CRUD application. Somethign like that is definitely easier to implement and to deploy and a *lot* more functional with any of the RAD frameworks available for Python. And just like HTML never was a valid GUI framework and never will be one, HTTP will never be a suitable transport layer for a RPC protocol. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
In article 20130526194310.9cdb1be80b42c7fdf0ba5...@gmx.net, Wolfgang Keller felip...@gmx.net wrote: HTTP will never be a suitable transport layer for a RPC protocol. What, in particular, is wrong with HTTP for doing RPC? RPC is pretty straight-forward. Take this method, run it over there, with these arguments, and give me back the result. HTTP handles that just fine, with your choice of XML, JSON, or whatever turns you on for the content encoding. There are protocols that are more efficient (mostly binary ones like Thrift and Protocol Buffers), but for a lot of things, the simplicity and convenience of HTTP is worth than the efficiency hit. It's really nice to be able to slap together HTTP components like load balancers and caches by just editing a few config files. -- http://mail.python.org/mailman/listinfo/python-list
RE: Future standard GUI library
From: felip...@gmx.net Subject: Re: Future standard GUI library Date: Sun, 26 May 2013 19:43:10 +0200 To: python-list@python.org [...] one, HTTP will never be a suitable transport layer for a RPC protocol. Sincerely, Wolfgang Please give me an example of a suitable transport layer for a RPC protocol. -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Mon, May 27, 2013 at 3:43 AM, Wolfgang Keller felip...@gmx.net wrote: For the Yosemite Project, I wanted the networking aspect, so the web browser UI was a good one. From the description this looks like a simble database CRUD application. Somethign like that is definitely easier to implement and to deploy and a *lot* more functional with any of the RAD frameworks available for Python. And just like HTML never was a valid GUI framework and never will be one, HTTP will never be a suitable transport layer for a RPC protocol. No, it's basically a modified version of a file browser; you get a directory listing, you can browse subdirectories, and selecting a file causes an action to happen on the server. You also have some action buttons that provide a measure of control: click a button and something is done (eg a key is pressed, or a 'killall' command is fired). The browser works just fine. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On 05/26/2013 11:43 AM, Wolfgang Keller wrote: And just like HTML never was a valid GUI framework and never will be one, HTTP will never be a suitable transport layer for a RPC protocol. On good thing web development has brought us is the knowledge that modularization and layers are a brilliant idea. Your back end exposes services and business logic, and your front end can be in HTMLv5 and Javascript, or QtQuick, PyGTK, or Visual Studio. If you do need a native interface, it's a heck of a lot easier to rewrite just the frontend then the entire stack. Who cares how the RPC is done; that's an implementation detail. HTTP does happen to work well though. Why do you say it is not suitable? From the description this looks like a simble database CRUD application. Somethign like that is definitely easier to implement and to deploy and a *lot* more functional with any of the RAD frameworks available for Python. Chuckle. Simple CRUD, eh. Almost all apps involve database CRUD interactions. And often in highly complex ways using business logic. Maybe it would have been faster to develop, but ultimately less useful and require more development time in the long run. suppose I now want the app natively on my phone (because that's all the rage). It's an iPhone. Oh. Apple doesn't support Python. Okay, rewrite the works, including business logic, in Objective C. Now I want it on my android phone. Oops rewrite the stack again in Java. Since his application by nature is network oriented (client/server I presume since he mentions multiple users), sticking it on a web server and having the front end be separate (be it HTML or not) gives him the flexibility to rapidly build native screenable UIs for his app on any platform he chooses, something your philosophy does not allow for. -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
In article mailman.2193.1369597318.3114.python-l...@python.org, Michael Torrie torr...@gmail.com wrote: On good thing web development has brought us is the knowledge that modularization and layers are a brilliant idea. Modularization and layers were a brilliant idea long before the web came around. -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On 26/05/13 20:41, Michael Torrie wrote: On 05/26/2013 11:43 AM, Wolfgang Keller wrote: snip Maybe it would have been faster to develop, but ultimately less useful and require more development time in the long run. suppose I now want the app natively on my phone (because that's all the rage). It's an iPhone. Oh. Apple doesn't support Python. Okay, rewrite the works, including business logic, in Objective C. Now I want it on my android phone. Oops rewrite the stack again in Java. Kivy (http://kivy.org) is a python library that can be used to write python apps for Linux, Windows, MaxOSX, Android and IOS. Regards, Ian F -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On 05/26/2013 01:45 PM, Roy Smith wrote: In article mailman.2193.1369597318.3114.python-l...@python.org, Michael Torrie torr...@gmail.com wrote: On good thing web development has brought us is the knowledge that modularization and layers are a brilliant idea. Modularization and layers were a brilliant idea long before the web came around. True. Though it seems like it fell out of fashion for a long time. I went to school before the advent of web development and though we talked about modularization and coupling in software engineering, really it was all rather monolithic. Web development changed our focus back to where it should have been all along. -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Mon, May 27, 2013 at 5:41 AM, Michael Torrie torr...@gmail.com wrote: Chuckle. Simple CRUD, eh. Almost all apps involve database CRUD interactions. And often in highly complex ways using business logic. Right. Sturgeon's Law of Applications. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On 23 May 2013 03:39, llanitedave llanited...@veawb.coop wrote: On Wednesday, May 22, 2013 7:24:15 AM UTC-7, Chris Angelico wrote: On Wed, May 22, 2013 at 11:42 PM, Wolfgang Keller felip...@gmx.net wrote: ... there's another option that is available to every platform and (practially) every high level language: the web browser. Make your app serve HTTP and do up your UI in HTML5/CSS3 - your facilities are pretty extensive. Plus you get networking support for free! Obviously this option isn't for everyone, but don't discount it out of hand. ChrisA I've been thinking about that myself for some future app ideas. If you have a stand-alone app working from your web browser, don't you need an embedded web server to utilize the file system? Is a system like Django for an app overkill? Or is its embedded development server underkill for a single-user browser-based application? -- http://mail.python.org/mailman/listinfo/python-list JavaScript has this: http://appjs.org/ It's a node.js server app serving a folder of plain old HTML files to a chrome embedded browser. You can code in a node.js server using anything you like, serve requests for your client app (or use the server code directly, you can just put the functions you would like to share with the client in the window object), etc. I'm using it for a peer to peer configurable application. To do that I serve up the web application for me and my peers (by using a regular server instead of the fake server it comes with), and the browser is just a client which can connect wherever I want it to. Someone should fork this and make it work in python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Thu, May 23, 2013 at 4:43 PM, Fábio Santos fabiosantos...@gmail.com wrote: On 23 May 2013 03:39, llanitedave llanited...@veawb.coop wrote: On Wednesday, May 22, 2013 7:24:15 AM UTC-7, Chris Angelico wrote: there's another option that is available to every platform and (practially) every high level language: the web browser. Make your app serve HTTP and do up your UI in HTML5/CSS3 - your facilities are pretty extensive. Plus you get networking support for free! Obviously this option isn't for everyone, but don't discount it out of hand. ChrisA I've been thinking about that myself for some future app ideas. If you have a stand-alone app working from your web browser, don't you need an embedded web server to utilize the file system? Is a system like Django for an app overkill? Or is its embedded development server underkill for a single-user browser-based application? -- http://mail.python.org/mailman/listinfo/python-list JavaScript has this: http://appjs.org/ It's a node.js server app serving a folder of plain old HTML files to a chrome embedded browser. You can code in a node.js server using anything you like, serve requests for your client app (or use the server code directly, you can just put the functions you would like to share with the client in the window object), etc. Many high level languages today come with simple HTTP server modules. They may not scale to infinity and beyond, but they'll work fine for a single-user system using a browser for its UI. Chances are they'll do well for everything up to a single CPU core. Depends on the language and library, of course. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
RE: Future standard GUI library
You don't! If your app needs local content just use a regular open() (or your browser) to read the files and render them as you see fit. For remote content you just need the 'urllib2' module or something like 'requests' module to get the data. Date: Wed, 22 May 2013 19:31:55 -0700 Subject: Re: Future standard GUI library From: llanited...@veawb.coop [...] I've been thinking about that myself for some future app ideas. If you have a stand-alone app working from your web browser, don't you need an embedded web server to utilize the file system? Is a system like Django for an app overkill? Or is its embedded development server underkill for a single-user browser-based application? -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Thu, May 23, 2013 at 4:58 PM, Carlos Nepomuceno carlosnepomuc...@outlook.com wrote: You don't! If your app needs local content just use a regular open() (or your browser) to read the files and render them as you see fit. For remote content you just need the 'urllib2' module or something like 'requests' module to get the data. BTW, forgot the link. The part you DO need is something like this: http://docs.python.org/3/library/http.server.html It takes care of the irrelevant and lets you just write your app. The same sort of thing is available in quite a few languages. Great for knocking something together quickly; not designed for thousand-TPS web servers. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
RE: Future standard GUI library
It would be way more practical to have an embedded browser. Appjs doesn't even occupy a port on the client. We could totally benefit from that. Django applications practically make themselves. On 23 May 2013 08:02, Carlos Nepomuceno carlosnepomuc...@outlook.com wrote: You don't! If your app needs local content just use a regular open() (or your browser) to read the files and render them as you see fit. For remote content you just need the 'urllib2' module or something like 'requests' module to get the data. Date: Wed, 22 May 2013 19:31:55 -0700 Subject: Re: Future standard GUI library From: llanited...@veawb.coop [...] I've been thinking about that myself for some future app ideas. If you have a stand-alone app working from your web browser, don't you need an embedded web server to utilize the file system? Is a system like Django for an app overkill? Or is its embedded development server underkill for a single-user browser-based application? -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
But there's another option that is available to every platform and (practially) every high level language: the web browser. Make your app serve HTTP and do up your UI in HTML5/CSS3 - your facilities are pretty extensive. Plus you get networking support for free! Obviously this option isn't for everyone, but don't discount it out of hand. Both the concept and actually implemented examples of so-called web applications prove that they are just plain garbage and hopelessly unusable for anything remotely resembling actual screenwork. HTML forms may be at best useful for web shops, but for actual screenwork, HTML is not a valid GUI, no matter how much javascript you add to it. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Fri, May 24, 2013 at 1:41 AM, Wolfgang Keller felip...@gmx.net wrote: But there's another option that is available to every platform and (practially) every high level language: the web browser. Make your app serve HTTP and do up your UI in HTML5/CSS3 - your facilities are pretty extensive. Plus you get networking support for free! Obviously this option isn't for everyone, but don't discount it out of hand. Both the concept and actually implemented examples of so-called web applications prove that they are just plain garbage and hopelessly unusable for anything remotely resembling actual screenwork. HTML forms may be at best useful for web shops, but for actual screenwork, HTML is not a valid GUI, no matter how much javascript you add to it. All depends on your requirements. For the Yosemite Project, I wanted the networking aspect, so the web browser UI was a good one. It's been working beautifully for... what, four or six years now, I think; and it's just a few pages of Python. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On 2013-05-23, Wolfgang Keller felip...@gmx.net wrote: But there's another option that is available to every platform and (practially) every high level language: the web browser. Make your app serve HTTP and do up your UI in HTML5/CSS3 - your facilities are pretty extensive. Plus you get networking support for free! Obviously this option isn't for everyone, but don't discount it out of hand. Both the concept and actually implemented examples of so-called web applications prove that they are just plain garbage and hopelessly unusable for anything remotely resembling actual screenwork. What is screenwork? -- Grant Edwards grant.b.edwardsYow! Am I elected yet? at gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
Do you think tkinter is going to be the standard python built-in gui solution as long as python exists? AT the moment, there is nothing really comparable that is a realistic candidate to replace tkinter. FLTK? (http://www.fltk.org/index.php) tkinter is the Python wrapper of the tk library, just as wxpython is the python wrapper of the wx library. I do not see a py-fltk wrapper. It exists, but it's really old. http://pyfltk.sourceforge.net/ And it's imho definitely not native (in terms of look and feel) on *any* operating system, not even on Linux. In fact it's SGI's Irix Forms re-implemented, afaik. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
I know this may sound a silly question because no one can see the future. But ... Do you think tkinter is going to be the standard python built-in gui solution as long as python exists? Standard built-in maybe, but by far most people who need a GUI for an actual application will keep using something else. I couldn't help but wonder if wx or PySide receives better py2 and py3 support, or anything else that prevent them from getting into the standard python distributions, whether or not this scene could start to shift ... Didn't Pyside have serious trouble recently, requiring a reanimation of the project? I believe this which one of tkinter, wx, qt, is the best gui toolkit for python flame war has been going on for ages. If (Py)Qt wasn't so freaking fat, it might be the best. If wxPython had a more pythonic (and stable?) API, it might be the best. If PyGTK was more native on Windows and native at all on MacOS X, it might be the best. If PyGUI was more extensive, it might be the best. This worries me very much about whether I should start a gui app using python. What other open-source cross-platform programming language choices do yo have. Java? For GUIs? Excuse me while I vomit. C++? As a language for human beings? Oops, I have to throw up again. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Wed, May 22, 2013 at 11:42 PM, Wolfgang Keller felip...@gmx.net wrote: What other open-source cross-platform programming language choices do yo have. Java? For GUIs? Excuse me while I vomit. C++? As a language for human beings? Oops, I have to throw up again. I personally like using Pike and GTK, so if I were to try a cross-platform Python GUI project, I'd probably give PyGTK a shot. But there's another option that is available to every platform and (practially) every high level language: the web browser. Make your app serve HTTP and do up your UI in HTML5/CSS3 - your facilities are pretty extensive. Plus you get networking support for free! Obviously this option isn't for everyone, but don't discount it out of hand. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Wednesday, May 22, 2013 7:24:15 AM UTC-7, Chris Angelico wrote: On Wed, May 22, 2013 at 11:42 PM, Wolfgang Keller felip...@gmx.net wrote: What other open-source cross-platform programming language choices do yo have. Java? For GUIs? Excuse me while I vomit. C++? As a language for human beings? Oops, I have to throw up again. I personally like using Pike and GTK, so if I were to try a cross-platform Python GUI project, I'd probably give PyGTK a shot. But there's another option that is available to every platform and (practially) every high level language: the web browser. Make your app serve HTTP and do up your UI in HTML5/CSS3 - your facilities are pretty extensive. Plus you get networking support for free! Obviously this option isn't for everyone, but don't discount it out of hand. ChrisA I've been thinking about that myself for some future app ideas. If you have a stand-alone app working from your web browser, don't you need an embedded web server to utilize the file system? Is a system like Django for an app overkill? Or is its embedded development server underkill for a single-user browser-based application? -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On 5/20/2013 1:04 AM, Vito De Tullio wrote: Terry Jan Reedy wrote: Do you think tkinter is going to be the standard python built-in gui solution as long as python exists? AT the moment, there is nothing really comparable that is a realistic candidate to replace tkinter. FLTK? (http://www.fltk.org/index.php) tkinter is the Python wrapper of the tk library, just as wxpython is the python wrapper of the wx library. I do not see a py-fltk wrapper. -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On 2013-05-20 08:00, Terry Jan Reedy wrote: On 5/20/2013 1:04 AM, Vito De Tullio wrote: Terry Jan Reedy wrote: Do you think tkinter is going to be the standard python built-in gui solution as long as python exists? AT the moment, there is nothing really comparable that is a realistic candidate to replace tkinter. FLTK? (http://www.fltk.org/index.php) tkinter is the Python wrapper of the tk library, just as wxpython is the python wrapper of the wx library. I do not see a py-fltk wrapper. It exists, but it's really old. http://pyfltk.sourceforge.net/ -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On 5/20/13 1:04 AM, Vito De Tullio wrote: FLTK? (http://www.fltk.org/index.php) FLTK is even uglier than non-themed Tkinter: non-native on every platform. Tkinter wraps native widgets on MacOS and WIndows, but FLTK draws its own widgets everywhere. -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On 2013-05-20, Terry Jan Reedy tjre...@udel.edu wrote: On 5/20/2013 1:04 AM, Vito De Tullio wrote: Terry Jan Reedy wrote: Do you think tkinter is going to be the standard python built-in gui solution as long as python exists? AT the moment, there is nothing really comparable that is a realistic candidate to replace tkinter. FLTK? (http://www.fltk.org/index.php) tkinter is the Python wrapper of the tk library, just as wxpython is the python wrapper of the wx library. I do not see a py-fltk wrapper. http://pyfltk.sourceforge.net/ -- Grant Edwards grant.b.edwardsYow! Is it 1974? What's at for SUPPER? Can I spend gmail.commy COLLEGE FUND in one wild afternoon?? -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On 5/18/13 11:01 PM, llanitedave wrote: I'm curious about how commonly tkinter is actually used among Python app developers as compared to wx, Pyside, or PyQT. I get the impression that more distributed apps are built with wxPython, at least, than tkinter. My impression is far from actual knowledge, of course. I have two commercial apps developed with Tkinter: http://www.codebykevin.com/phynchronicity.html http://www.codebykevin.com/quickwho.html --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
Terry Jan Reedy wrote: Do you think tkinter is going to be the standard python built-in gui solution as long as python exists? AT the moment, there is nothing really comparable that is a realistic candidate to replace tkinter. FLTK? (http://www.fltk.org/index.php) -- ZeD -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
Hello, On 5/18/13 10:03 AM, Beinan Li wrote: I know this may sound a silly question because no one can see the future. But ... Do you think tkinter is going to be the standard python built-in gui solution as long as python exists? I don't see any significant clamoring among the Python core developers to make a change. I couldn't help but wonder if wx or PySide receives better py2 and py3 support, or anything else that prevent them from getting into the standard python distributions, whether or not this scene could start to shift ... I am not going to engage in the old UI toolkit flame ware; I will limit myself to factual observations and a few opinions about Tkinter without placing it against other toolkits. Python has the PEP process for suggesting changes to the core language and libraries. Changing the default UI toolkit would require someone to submit a proposal, get it approved, provide the implementation, and commit to maintaining the implementation over the long term. You propose it, you own it. Thus far no one has done this. I would think the only person who would be in a position to propose wxPython would be Robin Dunn since he is the primary copyright holder, and to my knowledge he has never done so. As for Pyside, it was not part of the transition of Qt from Nokia to Digia, and so it appears to be orphaned. PyQt might be an alternative, but I don't think Phil Thompson would ever submit it, as it would likely affect his livelihood. Given these facts, it's safe to say that Tkinter will remain the default GUI toolkit in the stdlib for some years to come. I believe this which one of tkinter, wx, qt, is the best gui toolkit for python flame war has been going on for ages. I love the fact that python ships a built-in gui solution which makes shipping a pure-python desktop application a viable choice. But tkinter does not appear to be the most time-saving way to write a gui app. The layout designer support, for one, is next to zero. I tried many 3rd-party designers and loved PAGE (http://page.sourceforge.net) for a few minutes, then came the author's comment: PAGE strikes me as an odd choice for a Python developer to develop a Tk UI. It's a descendent of the old Visual Tcl tool, and is run from Tcl and not Python. VTcl was always famous for producing a huge pot of spaghetti UI code that couldn't be easily modified outside the tool. I have also tried many Tk UI tools including VTcl, SpecTcl, and the orphaned tool from ActiveState, and have concluded that writing my own code is both simpler and faster. As always, your mileage may vary. For release 4.0, I spent about two months working with the “Theme” part of Ttk and have had only partial success. I now believe that the “Theme” part of Ttk is really a very poor piece of software at all levels - concept, implementation, and especially documentation. My guess is if it had been well documented it would have been recognized by even the author as junk. I find it hard to believe that the people who control Tcl/Tk allowed it in the code base. I continue to support ttk because of the paned window, notebook and treeview widgets. The implementation of the ttk widgets is quite complex--that, in turn, makes their documentation complex, and the complexity is a drawback. It's hard to customize the ttk themes, especially compared to customizing standard Tk widgets. I'm one of the core Tk developers, and I don't fully understand the themed widgets' internals or how to customize them. But it's not fair to say that they are junk. The author of PAGE may think so, but many would disagree. I think the widgets work quite well, especially if used in their default mode. It's difficult to overstate the improvement in the look and feel of my Tk apps on the Mac when I switched to using the themed widgets. And ttk seems to be a major attraction that keeps people coming back to tk for the looks. This worries me very much about whether I should start a gui app using python. Because if ttk is not a mature technology, I'd avoid premature adoption. If ttk is out of the question, tkinter will be too. I'd then be forced to use a 3rd-party solution like wx or qt, which I really don't want to see. ttk is a mature technology. The initial specification, code, and docs were developed by Joe English nearly a decade ago (see http://tktable.sourceforge.net/tile/tile-tcl2004.pdf), and they had been accepted into Tcl/Tk's core in version 8.5 (released in 2007). The earliest work on integrating these widgets into Python began in 2008, and they were formally released in 2010. I would say that ttk is mature, stable, and unlikely to undergo radical change in the future. Guilherme Polo has done superb work in integrating the themed widgets into Python--it's the most significant UI advance in Python's stdlib in years. You are quite safe in developing against this API, unless your taste simply does not run to using the ttk
Re: Future standard GUI library
On 5/18/2013 10:03 AM, Beinan Li wrote: Not sure if this is the right place to talk about this. It is. Even less sure if I can move this discussion to tkinter list, The idea of replacing tkinter is not about improving tkinter ;-). Do you think tkinter is going to be the standard python built-in gui solution as long as python exists? AT the moment, there is nothing really comparable that is a realistic candidate to replace tkinter. Tkinter is a tcl-based c gui library. wx and qt4 are gui application frameworks that include a gui library -- and much more that duplicate part of Python's stdlib. They, and consequently their Python wrappers, are too big. That is quite aside from the fact that the authors of the wrappers have good reason to not donate their code, but stay independent. PyGui was designed as a gui library comparable to tkinter and a possible replacement. But according to the web page, it is still not completely ready for py 3 (the last update was July 2011). http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ I think a tkinter replacement should be written for at least 3.4+, so it can use the new 3.3 unicode implementation and use or at least integrate with the new 3.4 event loop that will be part of the planned new async library. One test for any new gui library is whether idle can be rewritten in it. It heavily uses the tag features of the tk text widget. TJR -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Sat, 18 May 2013 10:03:02 -0400, Beinan Li wrote: Do you think tkinter is going to be the standard python built-in gui solution as long as python exists? Probably. I couldn't help but wonder if wx or PySide receives better py2 and py3 support, or anything else that prevent them from getting into the standard python distributions, whether or not this scene could start to shift ... One of the major issues preventing projects being added to the standard library is the maintenance schedule. Python's schedule for new releases is quite conservative and slow. If, say, wxPython was added to the std lib, it would have to follow Python's schedule: * most backwards incompatible changes would be forbidden; * those that are allowed would require a minimum of two major releases (three years) before removing functionality; * about four bug-fix releases (I think?) per year. If a project is used to (say) weekly releases, dropping down to Python's schedule can be rather painful. Once something has been added to the standard library, it more or less has to have a stable API, become conservative about changes, and care more about backwards-compatibility than new features. Stability and consistency become paramount. Many excellent, popular packages cannot live under those restrictions, and so will never be part of the standard library. Tkinter is good in this regard, because it is a wrapper around Tk/Tcl, which is equally stable and conservative as Python. Possibly even more so. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
Thanks for the clarification, Kevin. It's nice to have a tk dev standing out :-) This more or less convinced me about the trend. I also agree that it would be probably a simpler and more maintainable way to write my own tk(inter) code than using any existing 3rd-party designers. Beinan On Sat, May 18, 2013 at 1:40 PM, python-list-requ...@python.org wrote: -- Forwarded message -- From: Kevin Walzer k...@codebykevin.com To: python-list@python.org Cc: Date: Sat, 18 May 2013 11:32:04 -0400 Subject: Re: Future standard GUI library Hello, On 5/18/13 10:03 AM, Beinan Li wrote: I know this may sound a silly question because no one can see the future. But ... Do you think tkinter is going to be the standard python built-in gui solution as long as python exists? I don't see any significant clamoring among the Python core developers to make a change. I couldn't help but wonder if wx or PySide receives better py2 and py3 support, or anything else that prevent them from getting into the standard python distributions, whether or not this scene could start to shift ... I am not going to engage in the old UI toolkit flame ware; I will limit myself to factual observations and a few opinions about Tkinter without placing it against other toolkits. Python has the PEP process for suggesting changes to the core language and libraries. Changing the default UI toolkit would require someone to submit a proposal, get it approved, provide the implementation, and commit to maintaining the implementation over the long term. You propose it, you own it. Thus far no one has done this. I would think the only person who would be in a position to propose wxPython would be Robin Dunn since he is the primary copyright holder, and to my knowledge he has never done so. As for Pyside, it was not part of the transition of Qt from Nokia to Digia, and so it appears to be orphaned. PyQt might be an alternative, but I don't think Phil Thompson would ever submit it, as it would likely affect his livelihood. Given these facts, it's safe to say that Tkinter will remain the default GUI toolkit in the stdlib for some years to come. I believe this which one of tkinter, wx, qt, is the best gui toolkit for python flame war has been going on for ages. I love the fact that python ships a built-in gui solution which makes shipping a pure-python desktop application a viable choice. But tkinter does not appear to be the most time-saving way to write a gui app. The layout designer support, for one, is next to zero. I tried many 3rd-party designers and loved PAGE (http://page.sourceforge.net) for a few minutes, then came the author's comment: PAGE strikes me as an odd choice for a Python developer to develop a Tk UI. It's a descendent of the old Visual Tcl tool, and is run from Tcl and not Python. VTcl was always famous for producing a huge pot of spaghetti UI code that couldn't be easily modified outside the tool. I have also tried many Tk UI tools including VTcl, SpecTcl, and the orphaned tool from ActiveState, and have concluded that writing my own code is both simpler and faster. As always, your mileage may vary. For release 4.0, I spent about two months working with the “Theme” part of Ttk and have had only partial success. I now believe that the “Theme” part of Ttk is really a very poor piece of software at all levels - concept, implementation, and especially documentation. My guess is if it had been well documented it would have been recognized by even the author as junk. I find it hard to believe that the people who control Tcl/Tk allowed it in the code base. I continue to support ttk because of the paned window, notebook and treeview widgets. The implementation of the ttk widgets is quite complex--that, in turn, makes their documentation complex, and the complexity is a drawback. It's hard to customize the ttk themes, especially compared to customizing standard Tk widgets. I'm one of the core Tk developers, and I don't fully understand the themed widgets' internals or how to customize them. But it's not fair to say that they are junk. The author of PAGE may think so, but many would disagree. I think the widgets work quite well, especially if used in their default mode. It's difficult to overstate the improvement in the look and feel of my Tk apps on the Mac when I switched to using the themed widgets. And ttk seems to be a major attraction that keeps people coming back to tk for the looks. This worries me very much about whether I should start a gui app using python. Because if ttk is not a mature technology, I'd avoid premature adoption. If ttk is out of the question, tkinter will be too. I'd then be forced to use a 3rd-party solution like wx or qt, which I really don't want to see. ttk is a mature technology. The initial specification, code, and docs were developed by Joe English nearly a decade ago (see http
Re: Future standard GUI library
I'm curious about how commonly tkinter is actually used among Python app developers as compared to wx, Pyside, or PyQT. I get the impression that more distributed apps are built with wxPython, at least, than tkinter. My impression is far from actual knowledge, of course. -- http://mail.python.org/mailman/listinfo/python-list
