Re: Tkinter: The good, the bad, and the ugly!
rantingrick schrieb: On Dec 29, 6:41 pm, Gerry Reno wrote: wxPython looks good but I don't see anyone developing support for things like smartphones. No wx is not the answer to our problems Rather: ... to *your* problem... Also, what do you think about frameworks such as pyjamas? It lets you write in python and compiles everything down to Javascript so it can be used across the Web as well as on the desktop. Hmm, this is like two double edged swords smashing one another in battle. Sword One: On one hand web frameworks are going to be really big soon -- however legacy GUI's are not going away any time soon! There are enough out there in the wild, they will last quite for awhile indeed; but it's time for them to die. Sword Two: On the other hand web frameworks provide awesome cross platform ability that is surly only going to get better as time goes -- however i utterly hate JavaScript (although much worse web languages exist!). And sending requests back and forth between Python, JavaScript, Apparently the authors do know that, too: MessageID:, *sigh* no svg. BTW: Look in comp.lang.javascript: javascript is framework/toolkit resistent. and BrowserX is also a real PITA. Because even though everyone knows this is coming all the major browsers are trying to insert their API into the mix. So that Joe Scripter has to write code that is compatible between many browsers. Until the world agrees on a unified API --AND IMPLEMENTS IT SERIOUSLY-- we are at the mercy of drunken sailors at the helm. svg: opera, chrome, safari(including ios), ie9, firefox. Although svg is missing under webkit/android --Apple kept the hardware accelerated part to themeselves. Goolge is currently implementing hardware acceleration for svg in chrome/webkit, likewise Microsoft/ie. Lets wait and see when svg becomes available in android, too. Although smil is quiet another subject. I believe pyjamas has a bright future in the web playground, however we still need to focus our community efforts towards a Python based GUI. I can see a pythonGUI and pyjamas existing side by side in mutual harmony for many years. pyjamas: Perhaps without javascript. -roger -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages
Tim Harig schrieb: [snip] This isn't such a tragedy Erlang as it is for other managed VMs because Erlang/BEAM makes powerful usage of its VM for fault tolerance mechanisms. I don't know of any other VM that allows software upgrades on a running system. styx, the distributed operating system inferno, language: limbo. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
Terry Reedy schrieb: On 1/16/2011 11:20 PM, rantingrick wrote: Ok, try this... http://juicereceiver.sourceforge.net/screenshots/index.php http://www.sensi.org/~ak/pyslsk/pyslsk6.png http://www.wxwidgets.org/about/screensh.htm Ok, wxwidgets can look at least as good as tk. Agreed that wxpython might instead link to the excellent wxwidgets page. Well, tosssing screenshots around doesn't prove wether a framwork/toolkit is good or not; It only displays the developers commitment to create a work of art. Lets examine one of your examples: http://juicereceiver.sourceforge.net/screenshots/index.php#mac Overall impression: The software was designed for windows; more or less following the windows hci-guidelines, The windows version is resonable good. About the Aqua screenshots: 1. Negative actions are located on the falling diagonale. 2-3. The select background and foreground inside the multi-column listbox have the wrong color--the used color originates from text fields. 4. The multi-column listbox should have vertical gridlines. 5-6. Too much top and bottom padding inside the column header. 7. The column texture is wrong --there is a visible line in the bottom. 8. There are white boxess around the input fields. 9. Header column label and lisstbox content are not aligned. 10. There is separator line between the status bar and the brusshed dialog. 11. Last picture: there is a single page inside the tabet control. 12. Last picture: The text "Select radio ..." is trucated, the dialog isn't large enough. 13. The Scheduler activation should come before customizing the scheduler. 14. The dialog uses sunken group boxes for some sections, these group should be 2% darker than their surrounding container. 15. The spacing rules from the aqua hci guidlines are violated. The inner tabset should have 20px distance from both sides, 20px from the bottom, 14px from top. 16. Second last picture: The button lables are truncated. 17. Tree: Uses the wrong folder symbols--from windows--, select background and foreground are wrong, too. - The Aqua hci-guidlines discourage group boxes, the same with the windows guidlines, too. Get rid off group boxes. - second last picture: There should be more top padding for the checkbutton inside the white rectangle; best the same as left-padding. - There no focus frames visilbe inside these screenshots, it would be interessting to see how those are realised. - The icon buttons should be brushed, likewise shoud the column header have brushed background. - Aqua hci guidelines: All dialogs should have a centered appearance. Back to rantingrick 21st century toolkit/framwork: Let's have a look at the numbers: Worlwide pc market are 300 Million pcs per year, this number includes desktops(2/3) and servers(1/3). Your gui app is not relevant on servers. Quite a good deal of the remaining pc's are sold in countries with rampant ilict software copies; Since there are no software cost for these copies the people tend to install the big, bloated software pieces from named computer companies --you wont sell linux there, because it is more expensive than an ilict windows+office++. ~ 100 Million potential new desktop users for you. Apple's projection for the ipad in 2011 are 65 Million pieces, iphone and ipod touch will be roughly the same. 130 Million ios pieces. ~ 130 Million new ios users for you. The android market is still unclear, but I do suppose it will rival ios, lets say 100 Million in 2011. ~ 100 Million new android users for you. Microsoft mobile and blueberry are wildcards; no serious forecast is possible for these devices. Lets assume: ~ 50 Million blueberry, windows mobile. Total is: 380 Million potential new user for your application. wxWidgets: 3600 LOC, python: 140 LOC --these are very old numbers, but from the same time period. wxWidgets on desktop, present for windows, Aqua and X11. wxWidgets on ios, possible but unlikely, the thing is way to big for any ios device. wxWidgets on android not realistic. wxWidgets on blueberry not possible. wxWidgets on windows mobile; development is silverlight with .net, so wxWidgets would have to be ported to .net; not realistic. python on desktop, present. python on ios, possible --if not yet present. python on android, present. python on blueberry, possible. python on windows mobile, present--but .net support deprecated by ms. The smartphone and table market has only started, yet. In 2011 the mobile market is already larger than the desktop pc, almost 3 times largerv. The desktop pc market is in decline; there is however a shift toward pc-servers, instead. It is anybodies guess how far the pc-desktop decline will go. Every 21st century toolkit or framework must run on mobile platforms! wxWidgets was written ~1992, it is a copy of mfc, which in turn is a copy of MacApp. MacApp is also OSS, maintained through an industrie consortium. Why do yo
Re: Tkinter: The good, the bad, and the ugly!
Octavian Rasnita schrieb: From: "Arndt Roger Schneider" At least keep the disclaimer: >> Well, tosssing screenshots around doesn't prove wether >> a framwork/toolkit is good or not; >> It only displays the developers commitment to create >> a work of art. Overall impression: The software was designed for windows; more or less following the windows hci-guidelines, The windows version is resonable good. This is the most important thing, because most users use Windows. Those who have other preferences are not forced to choose Windows, so it's their choice, and if the interface doesn't look so nice, that's it. See disclaimer. Since you mentioned "nice": I do not use such words to charcterize a gui. I think the developers of said software tried hard to make it "nice" and "beauty", hence the brushed background and group-boxes --BTW: the windows Guidelines also discourage using group-boxes for usability reasons (see Theo. Mandel object oriented user interfaces). Back to rantingrick 21st century toolkit/framwork: Let's have a look at the numbers: Worlwide pc market are 300 Million pcs per year, this number includes desktops(2/3) and servers(1/3). Your gui app is not relevant on servers. Quite a good deal of the remaining pc's are sold in countries with rampant ilict software copies; Since there are no software cost for these copies Python is an open source software and the programmers that use Python might also prefer to offer open source software for free so this is not important. And "not legal" is not a very correct term, because somebody from Iran or North Corea must respect the laws from his/her country and in her/his country some things might not be forbidden by law, so it may be perfectly legal. Nice cropping, >>the people tend to install the big, bloated software >pieces from named computer companies >>--you wont sell linux there, because it is more >> expensive than an ilict windows+office++. Illict as in unlicensed. Law has nothing to do with it. And yes these unlicensed sofware has an negative impact on the distribution of free open source software. I wonder, what license do you use in your own work, and what do you think about people which violate your license? ~ 100 Million potential new desktop users for you. Apple's projection for the ipad in 2011 are 65 Million pieces, iphone and ipod touch will be roughly the same. 130 Million ios pieces. The android market is still unclear, but I do suppose it will rival ios, lets say 100 Million in 2011. ~ 100 Million new android users for you. Microsoft mobile and blueberry are wildcards; no serious forecast is possible for these devices. Lets assume: ~ 50 Million blueberry, windows mobile. Total is: 380 Million potential new user for your application. wxWidgets: 3600 LOC, python: 140 LOC --these are very old numbers, but from the same time period. This is a bad comparison because the programs targetted to the mobile phones are in most cases very different than the programs that need to be used on the desktop. This is the marketplace for all gui applications, and not a comparision. Do you want to say that WxPython is not good just because it doesn't work well on mobile phones? I do not comment on the quality of either wxWidgets nor wxPython. Both exist for certain reasons. The desktop pc was the sole target for all the big C++ gui class liraries in 1992. Over time a large code base evolved which makes it very difficult to get these class libraries into new markets--such as today with mobile devices. Those numbers show that only the mobile phones are important, because there are more mobile phones than computers. No, it doesn't. There are billions of mobile phones with graphical user interfaces, still these phones weren't relevant for gui applications. Well, Python needs a better GUI lib for using them on desktop computers, not on mobile phones. wxWidgets is suiteable for the desktop. The desktop pc market is in decline; there is however a shift toward pc-servers, instead. What do you mean by declining? Are there fewer desktop PCs today than a year ago? I am writing about graphical applications not computers. Looking into wxWidgets: Interactivity: keyboard focus, shortcuts, function keys, active foreground, active background are obsolete. hovering tooltips obsolete, status bar to large, obsolete. scrolled dialogs, obsolete. OK, Cancel, Retry, Abort buttons, obsolete, file dialogs obsolete, old style printing obsolete, drag-and-drop obsolete... Who says that they are obsolete? A good GUI interface should offer keyboard accessibility. Otherwise it is broken. OK, I take keyboard focus back. Summary wxWidgets: wxWidgets is large scale C++ library from the 20th century, solemnly dedicated toward desktop computers.
Re: Tkinter: The good, the bad, and the ugly!
rantingrick schrieb: On Jan 18, 7:09 am, Arndt Roger Schneider wrote: Summary wxWidgets: wxWidgets is large scale C++ library from the 20th century, solemnly dedicated toward desktop computers. wxWidgets originates from a time before templates were used in C++ and thus duplicates many of today's C++ features. wxWidgets is not suitable for a modern type GUI ad thus clearly not the toolkit/framework of the 21st century. Alight i'll except that Rodger. Wx may be unusable for the mobile market. And since the mobile market is exploding --and will continue to explode-- then we need to consider this. However, does any GUI library exist that can handle desktop, mobile, and accessibility and do it all in a 21st century way? You slaughtered wx but failed to provide any alternative, however i am listing to your advice contently because it is very good advice. Read on... Thanks! Again this is not about the quality of wxWidgets, wxWidgets grew large because there was vested interest in it. Its success is its undoing. We DO need to consider the mobile market in this decision. Maybe it is time for us to actually get on the cutting edge of GUI's. Maybe we should head an effort to create a REAL 21st century GUI that can handle desktop, mobile, and accessibility, and do it all whilst looking very sharp! Sure we rob from peter to pay paul. We will use Tkinters awesome API and geometry managers, wxPythons feature richness, and any other code we can steal to make this work! I am not sure whether this sarcasms or for real..., so I'll take for genuine. Tk is also doomed, and Tkinter isn't Tk. You are right about keeping the separate geometry managers, though. For starters: http://kenai.com/projects/swank Swank publishes java/swing classes as tk in jtcl, which is similar to what tkinter does for python and tk. It should be feasible to use swank with the tkinter interface for jpython--without jtcl. However, this doesn't make tkinter mobile, neither is swing available on android. When you look into the android developer documents concerning the gui, then you can see that the gui model is quite similar to tk. So I suppose android can be reached by jpython in a two stage process. The other devices are more difficult to reach, though. There is webkit on some, but not all. Webkit is available for the desktop, ios and android--today without svg. There are two ways to gain graphical independence: First a basic implementation for each platform and second through abstraction. With abstraction I mean to base the gui on a common graphical model present on all platforms and hence to implement the "toolkit" on-top of it in python (not C, C++, java,javascript), python! The single common graphical model is SVG. Then we can "advertise" python as the best GUI language available. I have nothing against seeing Python on more devices and this would no doubt bring that dream into fruition. There is a huge hole in the market at this very moment and we need to pounce on it like a hungry tiger on wildebeest. Just think how wonderful it would be to switch from mobile to desktop and still write beatiful Python code. So be it. -roger -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
rantingrick schrieb: On Jan 18, 12:25 pm, Arndt Roger Schneider wrote: rantingrick schrieb: On Jan 18, 7:09 am, Arndt Roger Schneider We DO need to consider the mobile market in this decision. Maybe it is time for us to actually get on the cutting edge of GUI's. Maybe we should head an effort to create a REAL 21st century GUI that can handle desktop, mobile, and accessibility, and do it all whilst looking very sharp! Sure we rob from peter to pay paul. We will use Tkinters awesome API and geometry managers, wxPythons feature richness, and any other code we can steal to make this work! I am not sure whether this sarcasms or for real..., so I'll take for genuine. No this is real, albeit a bit fantastical. Thats probably why you thought it was sarcasm :). However, we need to start a revolution in the GUI world. Currently we (as developers) are slaves to the OEM's and OS's. This must change. We must unify GUI coding the same way OpenGL unified graphics coding. Multiplicity is ruining any and all advancements in Graphical User Interfaces. Sure multiplicity is great in emerging systems (language, culture, GUI, etc, etc) However at some point you must reign in this multiplicity and harness the collective knowledge into an all encompassing standard. OpenGUI is that standard. It should be shipped with every OS in the world. This is the only way we can have mobile, desktop, and accessibility all combined into one beautiful package. Then the contest come down to who can create the best abstraction API. There has been no advancement in GUI-Design. Today it looks and behaves just the way Bill Atkinson designed it. Technical revolutions are made by disruptive thoughts, which are never collective. ...The problem with gui-design:It requires an graphical artist, a well versed writer, a software architect and a programmer. The first two job description are the important ones. ...No OS-vender is going to allow that, it equals lost control. Tk is also doomed, and Tkinter isn't Tk. You are right about keeping the separate geometry managers, though. For starters:http://kenai.com/projects/swank This looks like a very young project (beta) and i could not find a widget set. However i will investigate more. Thanks alpha However we need to think beyond even a Python community scale. This problem is inherent in every language community out there. We to unify the GUI standard. And we are a decade behind in development. (yes i am completely serious about all of this!). Then we did find common ground. -roger -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
Adam Skutt schrieb: On Jan 18, 8:09 am, Arndt Roger Schneider wrote: Back to rantingrick 21st century toolkit/framwork: Let's have a look at the numbers: Worlwide pc market are 300 Million pcs per year, this number includes desktops(2/3) and servers(1/3). Your gui app is not relevant on servers. You should tell this "fact" to just about every major enterprise software manufacturer out there. They all ship GUI tools intended to be used on the server. Some of them ship only GUI tools or CLI tools that are worthless, making you use the GUI tools. The desktop pc market is in decline; there is however a shift toward pc-servers, instead. It is anybodies guess how far the pc-desktop decline will go. Every 21st century toolkit or framework must run on mobile platforms! Until we have pixel-perfect touch sensors, toolkits for devices with pointer interfaces (e.g., PCs) and toolkits for devices with touch interfaces (e.g., phones and tablets) will necessarily be different. You note this yourself: the UI paradigms that work well when you have a pixel-perfect pointer do not work at all when you have a touch screen, especially on a limited size and resolution display. Yes I did and that's how it is. Even if you're provided a "single" toolkit, you still end up with two, maybe three, different applications, each using different widgets targeted for the device they run on. And no one provides a "single" toolkit: while Silverlight can run on the desktop, the web, and now on Windows Phone, you can't use the same widgets everywhere; ditto with Cocoa for OS X and Cocoa Touch for iTouch devices. While some further unification is obviously possible, it's rather doubtful we'll ever have unified widgets that are truly workable on the web, on the "desktop", and on a portable touch screen device. Think about all the programmers earning their butter and bread :-). Forget toolkits and widgets for awhile. What remains are specific types of human/computer interactions, a visual representation on a screen and a predefined behaviour for said human action. E.g. a button is: A function gets asychnronously performed in response to a finger/mouse click and release inside a certain screen area. --A widget is essentially a logical abstraction. wxWidgets was written ~1992, it is a copy of mfc, which in turn is a copy of MacApp. MacApp is also OSS, maintained through an industrie consortium. Why do you not use the original framework? Because it's not cross-platform, I'd imagine. The entire point of wxWidgets was to provide a cross-platform "OOP" UI toolkit. It closely copies MFC since MFC and XView were the two "backends" it supported. MacApp is/was cross-platform, Apple pulled the plug on the non-mac platforms; the industrie consortium took charge of the other platforms. Screen resolution: The time of 72ppi CRT monitors is over. A GUI framework/toolkit must be resolution independent, including all icons and indicators; it should use decluttering (newspeak:ZUI). WPF is the only functional resolution-independent UI toolkit in existence. While I don't disagree with you in principal, practice is pretty heavily divorced from principal here. Principal doesn't help me write GUI applications today. wxWidgets is not suitable for a modern type GUI ad thus clearly not the toolkit/framework of the 21st century. None of the toolkits accessible from CPython are suitable for a 21st century guy by your standard. If we talk about IronPython, Silverlight becomes the closest, but it isn't a panacea by any stretch of the imagination. Adam According to Microsoft neither is silverlight. -roger -- http://mail.python.org/mailman/listinfo/python-list
Re: Screen readers for Tkinter (was Re: Tkinter: The good, the bad, and the ugly!
Littlefield, Tyler schrieb: >And of course, it should also offer support for Windows, since most of the computer users use Windows, especially those who need accessibility features. uh. no, and no. Plenty of those utilizing screen readers are using macs nowadays, as well as vinux or some derivitave there of. Do you have first hand experience with it under AQUA? I think Tk-aqua (also 8.6) should work out-of-the-box with brail-lines, text-to-speech and such; the older carbon built however wont... -roger -- http://mail.python.org/mailman/listinfo/python-list
Re: [Code Challenge] WxPython versus Tkinter.
rantingrick schrieb: [snip] 1. You cannot define the terms--restrict your opponent-- and battle it yourselves. 2. Your specified directory browser is useless. --At least define that the directory browser must have constant complexity to work with volatile data over a network... -roger -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with giant font sizes in tkinter
Steven D'Aprano schrieb: On Thu, 10 Feb 2011 15:48:47 +, Cousin Stanley wrote: Steven D'Aprano wrote: I have a tkinter application under Python 2.6 which is shows text in a giant font, about twenty(?) times larger than expected. The fonts are set using: titlefont = '-Adobe-Helvetica-Bold-R-Normal-*-180-*' buttonfont = '-Adobe-Helvetica-Bold-R-Normal-*-140-*' labelfont = '-Adobe-Helvetica-Bold-R-Normal-*-140-*' Although I've been a linux user for several years, that type of font spec hurts my head :-) Will the more simplistic type of tuple spec not work in your tkinter application ? I don't know, but I'll give it a try. Nevertheless, I'd like to learn how to diagnose these sorts of font issues. Can anyone suggest where I should start? Those adobe helveticas are bitmap fonts. Tk 8.5 uses freetype to render fonts under X11, if you wish to use outdated bitmap fonts under X11, then disable-xft when building Tk 8.5. I do assume there are different tk versions on your various platforms, and the troubling one is with version 8.5 --8.5 uses anti-aliasing hence freetype. Recommendation: Get rid of bitmap fonts under X11. BTW the default fonts under Linux are: bitstream vera sans (for helvetica) bitstream vera (for times) and bitstream vera sans mono (for courier). In my opion those bitstream fonts are much better than the mentioned Adobe fonts. -roger -- http://mail.python.org/mailman/listinfo/python-list
Re: Displaying SVG in tkinter using cairo and rsvg
Martin P. Hellwig schrieb: Hi all, Information on using tkinter for displaying an svg image seems a bit low spread on the Internet. I recently played around with pygame and svg and realized, hold on this can be done with tk too. So I thought I post a little example for future generations :-) (and also have stored at http://dcuktec.googlecode.com/hg/source/examples/cairo_rsvg_tkinter.py). So here it is if you are interested: [snip] raster images from SVG: There are multiple methods to convert a scalable vector graphic into a bitmap. In addition to cairo, librsvg and rsvg imageMagick contains a vector graphic format similar to svg--gradients and transparency are problematic for this approach, but its a while since I had looked into it... My product Jeszra imports svg into Tk(using tkpath http://jeszra.sourceforge.net/jeszra/Jeszra_TechnicalNotes.html#d0e10279 ), preserving it as a vector graphics. There are, of course, limitations to what can be preserved in Tk: http://jeszra.sourceforge.net/jeszra/SVG_Import.html The other way is much simpler to convert a Tk graphics into svg, which is also implemented in Jeszra. All svg graphics on http://jeszra.sourceforge.net and http://gestaltitems.sourceforge.net are generated by Jeszra from Tk (there are some hundred graphics)... The generator API is open and a draft documentation is online at: http://jeszra.sourceforge.net/api/ch01s04.html http://jeszra.sourceforge.net/api/index.html Jeszra API Concerning svg: http://jeszra.sourceforge.net/api/ch04.html http://jeszra.sourceforge.net/api/ch05.html http://jeszra.sourceforge.net/api/ch06.html http://jeszra.sourceforge.net/api/ch07.html http://jeszra.sourceforge.net/api/ch08.html Here is an overview about Jeszra, SVG and Tk: http://jeszra.sourceforge.net/api/pictures/overview.svg The svg on those page gets on-demand converted into flash, for the internet explorer. Is there anyting else You want to know about svg? -roger -- http://mail.python.org/mailman/listinfo/python-list
Re: Displaying SVG in tkinter using cairo and rsvg
Martin P. Hellwig schrieb: On 02/16/11 09:04, Arndt Roger Schneider wrote: [snip] tkpath does not seem to come standard with Python's tk version when I looked into it a couple of years ago, but maybe it has now? tk canvas and tkpath share the same interface, the first tkpath was a plugin into the tk canvas. A tkinter wrapper class will be a simple subclass of tk canvas introducing the new item types: path, ppolygone, polyline, circle, elipsis, pimage, prect, ptext, group and for tkpath 0.3 three additional messages for: style, gradient and distance, that's all ~50 lines of code. Is there anyting else You want to know about svg? No not really :-), I just wanted to display a SVG in tkinter with the minimal amount of external dependencies, since I have achieved that I thought I share my experience, so that the next time someone google tkinter and display svg it will return something that (well at least of the time of this writing) worked. Well CAIRO is sort of a shifting target... --currently I am stuck with PPC and new CAIRO versions cannot longer being built on it anymore :-(-- CAIRO can be real pain on non-X11-linux platforms. ImageMagick is simpler than CAIRO cross-platform wise. -roger -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Tkinter Programming by John Grayson
Pradeep B schrieb: On Sat, May 29, 2010 at 7:33 PM, Kevin Walzer wrote: Tkinter doesn't wrap native printing API's. There are a few extensions that do it, but they are platform specific and not complete. The usual ways of printing are like this: 1. If you're outputting data from the text widget, write that to a temporary text file and print via lpr. 2. If you're outputting data from the canvas, write that to a temporary postscript file and print via lpr. This is on Unix/MacOS. Not sure what the equivalent API on Windows is. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list Thanx Kevin. Anybody can throw light on how to do the same in Windows ? -pradeep The conventional --crude-- way is to take the bitmap of a window and to stretchDIBBitBlt it onto the printer device in windows and osx. Native printer dialogs do exist for both platforms ... When you do not need a printer dialog: Convert the Tk-GUI to SVG, then wrap it into a fo-xml wrapper --fo accepts inline SVG-- and use fop for printing. This approach works cross-platform, albeit you need a Java intallation (fop is a Java application). You can use http://jeszra.sourceforge.net to generate SVG for a complete Tk-GUI. In addition. there is a python/tkinter SVG export project for the Tk canvas --search the tkinter wiki. -roger -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
Terry Reedy schrieb: Ant I agree that the current tk situation is not completely satisfactory. In particular, the IO facilities are inadequate and have not, to my knowledge, changed in a decade. Image input formats are limited. There is no canvas output as an image. (Output of the canvase display list as a dialect of postscript that not everything can read is not a substitute for this.) Hah, You are ill-informed. tkpath 0.3 contains a surface element, which renders vector graphics elements in an off-screen tk image. Forget postscript! Generate SVG from a tk canvas or --better-- from tkpath. Jeszra (from me) generates SVG. There is also a SVG export package available in python/tkinter, search the tkinter wiki. However... I think it important that Python come with a minimal IDE that is adequate for someone like me doing Python-only development. I thank the programmers of IDLE. So merely deleting tk/tkinter is not an option. Indeed, having something similar to and at least as good as IDLE for any candidate gui replacememt should and I think would be a requirement for consideration. Yes, use emacs or vim, without any GUI. The problem with the big gui application frameworks are that they are too big. The two I have glanced at -- wx... and qt -- have much more than gui stuff and duplicate parts of the Python stdlib and other 3rd party libs. The question is: What sort of devices are being used by *normal* computer owners in the near future? My guess: It wont be a Desktop Computer. Will any big GUI-Framework work on those devises? No! Will a light-weight GUI-toolkit being ported to these devices ? Perhaps, but not likely. Will any scripting language run on such devices? Perhaps, but not likely, if then it will be Ecmascript or a 4GL. Will SVG run on thoses devices? Yes, it must, because SVG is an integral part of OEBPS, and the tiny implementation is already part most mobile phones. Take a look at SVG for BlackBerry for instance. As for a small gui written in Python, you seem to have ignored the link to pygui. Of course that has its own problems. Among others: it is incomplete; it ignore Python 3 (requires 2.3+ should be 2.3 to 2.6), which is the only place it could be added; the api sytle is not standard in Python (get_xx and set_xx methods instead of direct access or properties); and there is nothing yet like IDLE. What would be required is a Python3 GUI project with multiple contributors. Terry Jan Reedy What sort of GUI project? On the initial proposition: Grapical design is art and art requires an artist. A community cannot work like an artist. The best a community of top-class *graphical designers* could produce would be of mediocre quality. -roger -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
Terry Reedy schrieb: On 6/7/2010 5:25 PM, Arndt Roger Schneider wrote: Terry Reedy schrieb: ... Hah, You are ill-informed. How about 'under-informed'? That I readily admit ;-) tkpath 0.3 contains a surface element, which renders vector graphics elements in an off-screen tk image. As far as I know, tkpath is either not part of the tk that comes with python, or not accessible via tkinter, or not documented. 3x Correct. Tkpath 0.2 is a plugin into tk canvas. Tkpath 0.3 is a standalone replecement for tk canvas. The tkpath interface is identical to tk canvas, but it features additional objects: path, polyline, ppolygon, pline, ptext, circle, ellipse, radial gradients, linear gradients, groups and styles. The original tk canvas elements are the same as with tkpath, but the new elements are the tk counterpart to those elements listed inside the svg 1.1 specification. As for documentation; Use the Jeszra book, the svg 1.1 specification and the ascii text documentation distributed with tkpath. tkpath bypasses the X-emulation layer for the new elements under Windows and OSX. CAIRO is the backend under X11. Forget postscript! Gladly! Generate SVG from a tk canvas or --better-- from tkpath. Jeszra (from me) generates SVG. I found http://jeszra.sourceforge.net/ It looks interesting but not quite what I need, which is to export a tk canvas that I draw on with Python in a form I can import into OpenOffice. OpenOffice does --not yet-- have an svg import filter. You will have to convert SVG into another format. For example: use a fo-wrapper around your SVG and convert this fo-xml into pdf (fop / java). Other options are: inkscape, adobe illustrator, gimp--if you can life with a raster image. I guess SVG import has highest priority within the OpenOffice project --you wont need such workarounds for long. There is also a SVG export package available in python/tkinter, search the tkinter wiki. I presume you mean there is a 3rd party python add-on package that exports from a tk canvas. Can you be more specific as to what you meant? Googling 'tkinter wiki' got me to http://tkinter.unpythonic.net/wiki/ wiki.python.org/moin/TkInter has a link to the same. Searching there for 'svg' title or text has no hits. Searching PyPI also turns up nothing obvious. Googling further, I found canvasvg.py at http://wm.ite.pl/proj/canvas2svg/index.html via an answer to a question at http://bytes.com/topic/python/answers/629332-saving-output-turtle-graphics I will give it a try. Terry Jan Reedy That was it! Be aware only tk canvas elements are exported to SVG by this package. Jeszra on the other hand converts an entire GUI into SVG. I don't have any experience with this python package--for obvious reasons. What you should look after is how raster images are included in the generated SVG; and try each of the 12 different arrow shapes for tk line. If you have controls on your canvas: You may use the screenshot facility of tkImg to create an image from each control, then embed the screenshot base64 encoded inside the generated SVG.- -roger -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
rantingrick schrieb:
On Jun 10, 9:38 pm, Stephen Hansen wrote:
Also-- you're just starting to get wrong.
http://docs.python.org/library/tix.html
They don't -call- them the things you are, but between ComboBox, and the
flexibility of HList and TList... it actually offers quite a lot.
Urm, do you *know* what a Grid widget is Stephen? (hint: Excel) Do you
*know* what a ListCtrl is Stephen? (Hint: File Browser in report or
iconlabel views) Neither of those widgets exists in the Tix package.
And how do i *know* this? Well because unlike you i have actually
written code with Tix widgets, obviously you have not.
All this stuff is present in Tk!
OpenGL:
tkzinc, a 2D visualiation system based on OpenGL,
this one is widley used in air-traffic control...
BTW: tkinc features the best transformation system in the
IT--the author got a patent for it.
canvas3d, OpenGL-3D.
In addition there are *very very very large* visualization systems
available in Tk:
vtk for example...
ListCtrl --besides that I truely hate this type of controls, an
aggregation of usablility problems--
tkTreeCtrl is a true clone of MSWIN Explorer
Spreadsheet:
Well, whow doesn't exist in Tix! Are you sure? Hint: look again.
There is tktable, technically well done with on-demand data aquisition,
looks really ugly. An open field to display your artistic prowess.
Once upon a time there was a complete
spreadsheet application written in C++/Tk: abacus.
The TList only displays iconlabels in a wrapping column format, not in
any "report mode" ala: Windows Explorer("details mode"). The HList
widget is for showing a tree structure and is NOTHING like either a
ListCtrl or a Grid.
See above.
But notice this windows explorer type sort of thing is a major offence
on other platforms.
My own approach for such an interface function is to use seperate window
types, it reduces the maintainment cost for such an application.
HList:
Well *now* I am speachless. Did you actually even do a superfical
research on the topic?
BLT-tree
bwidget-tree
rtl_tree
hugelist
tkTreeCtrl (mentioned above)
ttk:treectrl
tablelist
tixtreecontrol
Just scanning the docs of a module (that you know jack about) and then
parroting off some baseless arguments are bound to bite you in the
@ss! *egg on face*
Please enjoy it.
-roger
--
http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
lkcl schrieb: [snip] it's the exact same thing for SVG image file-format. i'm _definitely_ not convinced that "SVG the image fileformat" is The One True Way to design images - but i'm equally definitely convinced of the power of SVG manipulation libraries which allow for the creation SVG images using declarative programming. You rather severly underestimate the impact from SVG! 1. SVG is a complete visualization system and not an fancy way to create icons. SVG and SMIL are an extreme powerful environment. With it's possible to create(design) sophisticated graphical and interactive --resolution independent-- applictions without resorting to javascript or direct DOM manipulations. Javascript or other languages are still necessary to feed data into an SVG visualization, but not for much more. Further more SVG and the GPU are a natural combination. 2. Many of CSS shiny new features --such as animation originate from SVG. 3. SVG-Print: Printing is one of the biggest problems in the current IT-landscape. I do not want to install printer drivers on each telephon I own, neither on any other device --mobile or not. The printer must contain a computer running an OS and has to handle an agreed upon page description language (Xml based)... Using HTML/CSS/DOM/javascript for application building: Well, yes can be done. HTML is however text oriented; each application entirely based on this technology will be satured with text. HTML works reasonable well with applications of the past two decades, but the importance of text is dwindling and other graphical means of communication become more and more relevant. but, all that having been said, and returning to "HTML and CSS (the fileformats)", there's a lot to be said for convincing people who are stuck in those worlds of the benefits and freedom of declarative programming... _without_ having to get involved directly in javascript. Any User Interface should be pre-determined; this concept allows the consequent separation of application logic and presentation. It's not only important for Web-applications! that web apps are about to take over the world, etc. There is still a place for GUI toolkits that are not based on the DOM, that there definitely are. or whatever the W3C technology of the month is. :) don't underestimate how much time and money is going into the W3C standards! and remember, someone's got to implement them, so the actual proof of the pudding is not what the W3C thinks but whether the technology ends up actually in the hands of users and is successful _for users_. l. The mony part is definitly important. Tk is actually a good example for the working of money-politics (the absence thereof). -roger -- http://mail.python.org/mailman/listinfo/python-list
Re: Customising Tk widgets
Peter schrieb:
I am using Windoze, I suspect the appearance attributes I am asking
about here are platform dependent?
Using Tkinter, I would like to generate a Checkbutton that is filled
in with a solid colour rather than a tick mark when selected.
tk = Tk()
tk.option_add("*Checkbutton.inidcatorOn", 0)
Could somebody provide some pointers as to how I could achieve this?
Also, John Shipman's Tkinter reference shows the Radiobutton drawn as
a diamond and yet when I create one in Windows I get a circle - again,
how and where do I need to look to change this behaviour?
Thanks
Peter
Shipman's screenshots are made under Tk 8.4/X11, featureing the
motif look-a-like.
Tk 8.4 follows the windows user style guide (windows95) under windows.
You could still get the motif look under windows:
Tk 8.5 is bundled with a theming engine ttk, this engine
uses the built-in theming engine under windows xp and later,
but also allows you to supplant this engine.
The related ttk theme is called "classic".
-roger
--
http://mail.python.org/mailman/listinfo/python-list
