Re: PyGUI as a standard GUI API for Python?
On 11 Okt., 09:56, lkcl [EMAIL PROTECTED] wrote: The role of Python is somewhat arbitrary. This could change only if Python becomes a client side language executed by AVM,V8etc. pyv8 -http://advogato.org/article/985.html pyjs.py - standalone python-to-javascript compiler, seehttp://pyjs.org. O.K. you got me all. I give up! I've already imlemented some small Flex supporting functionality in the P4D Langlet [1] and I'll also checkout pyjamas ( didn't worn them for long ) and if they are fine I work out a bridge the next days. Then only style sheets are left :) [1] http://pypi.python.org/pypi/P4D Langlet/ -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Oct 15, 12:27 am, greg [EMAIL PROTECTED] wrote: Paul Boddie wrote: there are a few things with regard to layouts which are very difficult with Web technologies (and aren't getting any easier, either) but which are almost trivial with classic graphical user interface toolkits, and of course there are cases where the roles are reversed. I've written quite a lot of desktop gui apps, and I don't think I've ever felt the need for free-flowing widget layouts. i have. an image library. placed in a scrollpanel, the images automatically flow left-to-right then down the page. the application doesn't dictate what size of panel the user _must_ view the images in. if they want to use the whole screen width, they can. if they want to view the images in a single column, they can. To say that a desktop gui api is severely lacking without this feature is somewhat overstating the case. it's the _combination_ of the limitations that makes them severely lacking. each limitation on its own does not, of course. the key point is, really, that if you take away one particular layout methodology from designers, they _will_ adapt - they _will_ cope, and rejig the design of the app to fit the widget set. ... but that's cart-before-horse. that's IT tail wagging the business Dog. so, when it comes to moving the same application functionality to a different platform, or to the web, people freak out. you're locked in. the cost is too great. the effort is too much. ... as you might be aware, i'm not really a big fan of restrictions imposed by software design :) Also, I think that proportional resizing is overrated. proportional resizing is very difficult to do well, and so many people don't even consider it. many designers will say this app is to be used on a 1024x768 screen (and now of course they're running into difficulties with the netbook pcs with the 1024x600 screens, and KDE's control panel close button is now off-screen for example!) it took several months to design a 2d graph widget which was useful when scaled down to 200x150, especially given that the axes could be logarithmic (!) starting with the axes themselves, we had to break things down into small, medium and large graticules, where the distance between each range of graticules would no longer be displayed, below a certain number of pixels (5 or so). likewise with the axes numbering. then the axis description had to go, below a certain size. then, we had controls (sliders and dials) where, again, the graticules automatically disappeared, and, also, if below a certain size, the readout would also disappear. so if you're doing _simple_ applications, then yes, proportional resizing is entirely unnecessary. but if you're doing applications where you have to display vast amounts of interactive graphical data (the example above was a real- time digital audio restoration GUI) then you really do have to think a bit harder about what you're going to present the user with. Proportional resizing is a compromise that just ends up annoying me. if it's done badly, then yeah, i agree. if you look, for example, at the source code of my web site, http://lkcl.net/site_code, you'll see that the site is capable of resizing to deal with anything down to about 300 pixels in width. the onResize function redoes the layout, placing the seven components in a hexagon if there's space, a side-on H below 800 pixels, and a single line below 640 pixels. it didn't take too much effort, and it means that anyone viewing my web site even on a QVGA screen won't have to do horizontal scrolling. not that i'm _expecting_ anyone to do that - i just wanted to prove a point :) l. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
hello_loader.py is the main err um i just double- checked, so i'd be able to advise you and... err... the problem i described (with the GridTest) seems to have... gone away!! There are lots of references to PyGTK classes in there. yes, that's because i had started with the gtk port, and was going through the examples one-by-one removing them and replacing them with qt. as i only got up to the Info tab of KitchenSink, there is still quite a bit to do. i _say_ quite a bit - but it's only about ... 16-24 hours of work. pyjamas is surprisingly small. Is there a way to select Qt instead of GTK? sorry! removing them :) Hacking the code a bit, :) I can run the hello_loader.py example. The items on the left do indeed overlap. It looks like the minimum size of the labels aren't being respected for some reason. yeah. and the pyjamas ui.HTML() class is based on a Qt.QLabel(). if that can be fixed, then there's a fair good reason to continue. Yes, there are ways to relate the height of a widget to its width, and there may well be a way to do that for a standard text widget, but it might involve some experimentation with the underlying text document. *sharp intake of breath* :) yehhh, i did word-breaking by wrapping groups of 8 letters at a time in floating-divs once, to simulate word- breaking in a situation where the column width was 200px and people were putting in web site addresses of 50 chars in length yukk. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
Although using browser technologies for desktop applications is interesting (and not new by any means), there are a few things with regard to layouts which are very difficult with Web technologies (and aren't getting any easier, either) but which are almost trivial with classic graphical user interface toolkits, and of course there are cases where the roles are reversed. if it wasn't for luis pamirez's brilliant work, porting pygtk to pyjamas, i would be absolutely agreeing with you, 100%. see this: http://code.google.com/p/pyjamas/wiki/GsocLlpamies luis has demonstrated that it's possible to have your cake and eat it. effectively - incredibly - he's ported pygtk ... to the browser! so your python pygtk application gets compiled, along with his reimplementation of gtk.py, gdk.py etc., into javascript (using the pyjamas compiler) and - unmodified - your pygtk app gets to run in every major web browser. that's just... stunning. regarding what you say about web technologies being more difficult to do layouts than traditional desktop apps - i'm really sorry to say that, from my experience with using the pyjamas widget set API, i couldn't agree less. HOWEVER - if this were pure HTML and CSS, i would utterly, utterly be agreeing with you - 100%. the first paragraph of my talk for ukuug 2009 says it best: http://ukuug.org/events/linux2008/programme/abstract-LKCLeighton-2.shtml it was _such_ an abortion trying to do a simple centred layout. and it's for exactly this reason that GWT was created (and then pyjamas ported from GWT). when you're using javascript to manipulate the DOM model (or, in the case of pyjamas-desktop, manipulating the DOM model directly) then it's an _entirely_ different matter. then, when you put standard- like widgets which include layout manager on top of _that_, which have identical functions and functionality to those of Desktop Widgets... ... the distinction between web and desktop suddenly becomes... moot. especially in the context of luiz's work. there isn't a _single_ thing that pyjamas can't do that pygtk2, wxWidgets or pyqt4 can do. there are _lots_ of things that pyjamas can do that pygtk2, wxWidgets and pyqt4 can't do (as they stand. without extra work and/or extensions e.g. derivative customised classes based on QAbstractLayout) ok - i'm exaggerating a little :) you can't access standard python modules from pyjamas apps in a web browser, because javascript is a restricted execution environment, so you have to make do (and you can make do _extremely_ well with what's available) with the provided implementation of builtins. so, if you don't mind using XMLHTTPRequest to communicate with the rest of the world - even if it's on http loopback - _then_ you're ok :) and yes, XMLHTTPRequest is supported in pyjamas-desktop (it has to be). also, writing new layouts and new widgets, which _happen_ to operate underneath on the DOM model of a browser (or a browser-kit-library such as PyKDE or PyWebKitGTK) is trivial. _really_ trivial. i've outlined how to write your own widget, here: http://pyjd.sourceforge.net/controls_tutorial.html and it's interesting to compare that to writing one for pygtk (there's a stars example which is easy to find python gtk tutorial i think it's hit number 3). the only thing i _can_ say, for definite, is that because pyjamas is missing an equivalent of glade, the UI-generator, and those GUI-based UI editors / designers, it _is_ at the moment a bit more... hard work doing the UI design manually, if you're used to using a GUI tool to design your UI. but i'm sure that will change. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Oct 13, 9:12 pm, Terry Reedy [EMAIL PROTECTED] wrote: lkcl wrote: On Oct 11, 11:17 pm, Terry Reedy [EMAIL PROTECTED] wrote: lkcl wrote: I got the impression that there is currently no Windows binary available. Correct? If not, perhaps someone trustworthy will someday donate one. sorry, terry, you deleted a bit too much context :) I was referring to this at pyjd.org: Pre-built amd64 .debs are available for download, providing pywebkitgtk-1.0, libwebkit-1.0-2 and libwebkit-dev, here: * Download libwebkit-dev, libwebkit-1.0-2 and pywebkitgtk-1.0 thanks for confirming, i thought so. and this If not, perhaps someone trustworthy will someday donate one. was my acknowledgement that a Windows binary is not trivial ha ha - i found that out :) and that I don't expect one from you after all the nice work you have done. thanks. [compiling with mingw32] why the python developers didn't include the patches, and keep them up- to-date, isn't clear. Mostly likely because no one who uses mingw32 has volunteered to become the mingw32 Python developer who would update such patches to current Python (now 2.6/3.0) and support them by responding to bug reports and by upgrading them to 2.7/3.1 in the next few years. *nods head side-to-side*... yeahh, good point :) -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
if there's a way to enforce the displaying of text - for the _text_ to say i need to be a total area of X in order to display my words. if you make my width too small, i will _force_ my height to be larger as i wrap the text. just like an HTML p /p does. ... of course, i'm well aware of the reasons _why_ this isn't supported - in either of Qt4 or Gtk2. it's because automatic- resizing, and correct (i.e. exact) size-hinting, is a complete lairy nightmare to implement. browsers get it right, because they have to, and the trade-off is a rather awkward judder-judder-displaying of content (which, for example, gives the use of HTML tables such a bad name). all of which of course makes the desktop-app developers' job just that little bit more awkward... -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Oct 13, 9:59 pm, Orestis Markou [EMAIL PROTECTED] wrote: Just want to say, thank you for a very enlightening writeup. You should really post this somewhere that we can link to. orestis, thank you for the encouragement. i did post it on my diary: http://advogato.org/person/lkcl/diary/523.html - i decided against doing a full-blown article because i've been doing quite a _lot_ of writing on advogato :) but i'm reconsidering. will post here if i do. i note with interest your comments here: http://orestis.gr/blog/2008/09/19/random-gui-toolkits-web-and-python/ whilst pyjamas and pyjamas-desktop are definitely cross-browser, cross- desktop, cross-platform and can even be made to be cross-widget-set, there isn't anything to substitute for _design_ ethos on a per- platform basis. by that i mean, expectations of there being a File menu on which the word Quit will occur, or, as you point out, mac- user expectations of application behaviour. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On 13 Okt, 23:59, Orestis Markou [EMAIL PROTECTED] wrote: Just want to say, thank you for a very enlightening writeup. You should really post this somewhere that we can link to. Is this not good enough for you...? http://mail.python.org/pipermail/python-list/2008-October/511375.html I don't see the Python mail archives going away soon, although there's also the Wiki for updated and maintained documents. Although using browser technologies for desktop applications is interesting (and not new by any means), there are a few things with regard to layouts which are very difficult with Web technologies (and aren't getting any easier, either) but which are almost trivial with classic graphical user interface toolkits, and of course there are cases where the roles are reversed. I haven't really written any classic GUI applications for quite some time, but I feel that it's worth pointing this out. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Oct 13, 10:56 pm, David Boddie [EMAIL PROTECTED] wrote: On Monday 13 October 2008 11:42, lkcl wrote: i don't know if it _was_ detached from the layout, but it was definitely still visible. see http://pyjs.org/examples/gridtest/output/GridTest.html for the example i was porting to pyqt4. each time i clicked Next, a new set of N,N would be _overlaid_ on top of the old ones, even though i was doing removeItem(). Yes, it just sounds like you needed to delete the layouts after removing them. the code's athttp://lkcl.net/pyjamas-desktop/pyqt4.tgz I might take a look later in the week if the code in there is runnable. yeah, it is. hello_loader.py is the main err um i just double- checked, so i'd be able to advise you and... err... the problem i described (with the GridTest) seems to have... gone away!! *slightly embarrassed* :) however, clicking too fast _did_ end up with fifty little windows of text (!) and the respect for text boundaries is definitely broken - shrink the window to 300 x 400 with the kitchensink example (which is where i stopped and moved to webkit, so all the _other_ examples prior to that will work) and you'll see that the text in a column down the left hand side end up all overlapping each other. so, you get to see the top few pixels of each word. if there's a way to enforce the displaying of text - for the _text_ to say i need to be a total area of X in order to display my words. if you make my width too small, i will _force_ my height to be larger as i wrap the text. just like an HTML p /p does. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Tuesday 14 October 2008 12:55, lkcl wrote: hello_loader.py is the main err um i just double- checked, so i'd be able to advise you and... err... the problem i described (with the GridTest) seems to have... gone away!! There are lots of references to PyGTK classes in there. Is there a way to select Qt instead of GTK? however, clicking too fast _did_ end up with fifty little windows of text (!) and the respect for text boundaries is definitely broken - shrink the window to 300 x 400 with the kitchensink example (which is where i stopped and moved to webkit, so all the _other_ examples prior to that will work) and you'll see that the text in a column down the left hand side end up all overlapping each other. so, you get to see the top few pixels of each word. Hacking the code a bit, I can run the hello_loader.py example. The items on the left do indeed overlap. It looks like the minimum size of the labels aren't being respected for some reason. if there's a way to enforce the displaying of text - for the _text_ to say i need to be a total area of X in order to display my words. if you make my width too small, i will _force_ my height to be larger as i wrap the text. Yes, there are ways to relate the height of a widget to its width, and there may well be a way to do that for a standard text widget, but it might involve some experimentation with the underlying text document. David -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
Paul Boddie wrote: there are a few things with regard to layouts which are very difficult with Web technologies (and aren't getting any easier, either) but which are almost trivial with classic graphical user interface toolkits, and of course there are cases where the roles are reversed. I've written quite a lot of desktop gui apps, and I don't think I've ever felt the need for free-flowing widget layouts. To say that a desktop gui api is severely lacking without this feature is somewhat overstating the case. Also, I think that proportional resizing is overrated. In my experience, either it's sufficient to just resize one pane and keep the others a fixed size, or you really want user control over the size of each pane individually. Proportional resizing is a compromise that just ends up annoying me. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Oct 11, 11:17 pm, Terry Reedy [EMAIL PROTECTED] wrote: lkcl wrote: I got the impression that there is currently no Windows binary available. Correct? If not, perhaps someone trustworthy will someday donate one. sorry, terry, you deleted a bit too much context :) so, assuming that you mean that there is currently no http://pyjd.org windows binary, then then answer is: pyjamas-desktop is pure python, relying on a modified version of pywebkitgtk and a modified version of webkit to add glib bindings to it. i spent one week fighting with mingw32 to cross-compile webkit for win32 - when i say fighting i mean segfaults at link time (!!), which was tracked down to the msvc-compiled version of libicu 3.8 and eliminated by hack-compiling libicu with mingw32; _rebuilding_ mingw32 from the latest svn at the time, in order to include support for exceptions across thread boundaries (libstdc++ exceptions - libgcc_a.dll) all in all, it was a bitch :) _then_ i started on cross-compiling python2.5 because there's no .exe or .zip installer for python - only a .MSI, and, having installed MSI under wine on linux with the excellent winetricks script, it causes a segfault when you try to run a .MSI. cross-compilation of python2.4 was successful (by the person who did the initial patch, a year ago). cross-compilation of python2.5, to generate a libpython2.4.dll and .a, fails miserably. why the python developers didn't include the patches, and keep them up- to-date, isn't clear. at that point, i gave up, despite valiant efforts, because it was clear that, given that there was no financial incentive to continue, i was wasting my time. the bottom line is: if you want a windows version of pywebkitgtk, i'm happy to assist and advise anyone of the process- it should be quite straightforward _if_ you have MSVC and follow the standard procedure, but i'm not about to spend my own time and effort on providing a win32 port using ming32, doing all the work _myself_, on my own, without financial incentive and renumeration. i'll happily explain to other people what _they_ need to do, though. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
the bottom line is: if you want a windows version of pywebkitgtk, i'm happy to assist and advise anyone of the process- it should be quite straightforward _if_ you have MSVC and follow the standard procedure, but i'm not about to spend my own time and effort on providing a win32 port using ming32, doing all the work _myself_, on my own, without financial incentive and renumeration. Is Visual Studio 2005 OK, or is some other compiler required? i'll happily explain to other people what _they_ need to do, though. l. If Visual Studio 2005 suffices, I'd give it a try. Propad -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
You can remove layouts from layouts with the QLayout.removeItem() method. yes... it didn't work. a layout within a layout - i think it was a QHorizontalLayout within a QGridLayout - didn't want to be removed. it's probably a bug. Was it detached from the layout, but still visible? i don't know if it _was_ detached from the layout, but it was definitely still visible. see http://pyjs.org/examples/gridtest/output/GridTest.html for the example i was porting to pyqt4. each time i clicked Next, a new set of N,N would be _overlaid_ on top of the old ones, even though i was doing removeItem(). the code's at http://lkcl.net/pyjamas-desktop/pyqt4.tgz although i'm interested to know if there's a solution (to this particular problem), the amount of additional work to provide an equivalent of the 1px, 10em, 25% etc. subdivisions on layouts, and the amount of additional work to provide flowing and HTML- substitutable layouts (see http://pyjd.org/api/pyjamas.ui.HTMLPanel-class.html) is just... it's a lot of work. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
lkcl wrote: On Oct 11, 11:17 pm, Terry Reedy [EMAIL PROTECTED] wrote: lkcl wrote: I got the impression that there is currently no Windows binary available. Correct? If not, perhaps someone trustworthy will someday donate one. sorry, terry, you deleted a bit too much context :) I was referring to this at pyjd.org: Pre-built amd64 .debs are available for download, providing pywebkitgtk-1.0, libwebkit-1.0-2 and libwebkit-dev, here: * Download libwebkit-dev, libwebkit-1.0-2 and pywebkitgtk-1.0 and this If not, perhaps someone trustworthy will someday donate one. was my acknowledgement that a Windows binary is not trivial and that I don't expect one from you after all the nice work you have done. [compiling with mingw32] why the python developers didn't include the patches, and keep them up- to-date, isn't clear. Mostly likely because no one who uses mingw32 has volunteered to become the mingw32 Python developer who would update such patches to current Python (now 2.6/3.0) and support them by responding to bug reports and by upgrading them to 2.7/3.1 in the next few years. Any system supported in core Python code with a set of #includes needs *someone* who will support that set. If the supporter disappears and no one else volunteers, the #includes become obsolete and get deleted. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
Propad wrote: the bottom line is: if you want a windows version of pywebkitgtk, i'm happy to assist and advise anyone of the process- it should be quite straightforward _if_ you have MSVC and follow the standard procedure, but i'm not about to spend my own time and effort on providing a win32 port using ming32, doing all the work _myself_, on my own, without financial incentive and renumeration. Is Visual Studio 2005 OK, or is some other compiler required? I believe 2.4/2.5 used VS 2003 while 2.6/3.0 do (and 2.7/3.1 will) at least officially use VS 2008. The free express version apparently works. It is possible the extension extension modules compiled with 2005 have/will work. I would ask in a separate thread with VS 2005 in the subject line. i'll happily explain to other people what _they_ need to do, though. l. If Visual Studio 2005 suffices, I'd give it a try. Propad -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
Just want to say, thank you for a very enlightening writeup. You should really post this somewhere that we can link to. -- [EMAIL PROTECTED] http://orestis.gr/ On 11 Oct 2008, at 10:19, lkcl wrote: On Sep 3, 4:34 pm, Michael Palmer [EMAIL PROTECTED] wrote: So far, development of PyGUI seems to be a one-man effort, and it may be slowed down by the attempt to develop the API and the implementations concurrently. Could it be useful to uncouple the two, such that the API would be specified ahead of the implementation? michael, i went back to the beginning of this thread, to reply to your question, because i have some insights to share with you from my failed attempts on porting pyjamas to the desktop - which you can collect here: http://lkcl.net/pyjamas-desktop there, you will find an IronPython-GtkSharp port; a pyqt4 port and a pygtk2 port. they were each failures in their own unique and special ways. to explain: pyjamas is a widget set api that looks desktop-like; you write code in python, it's compiled to javascript; the DOM.py module actually does things like document.getElementById() etc. etc. and in this way you end up completely manipulating the DOM model, turning the browser into just a giant desktop-like canvas. in fact, the pyjamas widget set api is _so_ similar to a desktop api that i decided to have a go at porting it _to_ the desktop. eventually i succeeded. the first attempt was with ironpython. i actually got a long way with this one - i chewed through the pyjamas examples in about a day. i had a small stumbling block implementing the HTML() widget, but GtkSharp.HTML came to the rescue, there, and i was off again. i then ran into a wall i decided not to bash my head against at such an early stage (36 hours) - an implementation of XMLHTTPRequest (remember - i was implementing every single bit of functionality that a DOM model has access to). so, i decided to port the ironpython port to pygtk2. unfortunately, whilst i got a lot further and managed to implement all of the examples, there was no equivalent of HTML(). GTK itself totally lacks a rich media content widget. there is python-gtkhtml2 which is good, but not good enough. the much better gtkhtml3 library doesn't have python bindings around it, and i wasn't in the mood to write any (and hadn't at the time any experience with pygtk codegen.py). also i heard that gtkhtml2 had been abandoned, and gtkhtml3 wasn't going to be followed up on, and that there were rumours about webkit. crucially - much more importantly - gtkhtml 2 and 3 have absolutely no automatic resizing of the HTML content within them. so, unless you specify both the width and the height of the widget container, you end up with a flatlined widget. by that i mean a widget of say 200 pixels in width but ZERO pixels in height! and, as you may well know, if you specify a width and height on a gtk widget, that's it: it's entirely fixed. there's no going back. you're screwed. this was an absolute killer. with no foresight in the design of gtk or gtkhtml2 to make even a _guess_ at the width and height of the content, the port was screwed. i made half-hearted attempts to not specify width/height at all, but all that that resulted in was piss-poor layout, and when you shrank the app to small size, all the text disappeared because there was a margin defaulting to 5px or so and all but the top left corner of the text boxes would disappear! so, there was no point in me attempting to make python bindings around gtkhtml3, even though it has a system for inserting widgets into HTML (using span ids). and, even though there's python-gtkmozembed wrappers which would have allowed me to embed flash plugins etc. into my application, thus neatly emulating the way that html allows you to do that. so - sadly - on to pyqt4. well, i say sadly, but it was actually quite fun. i'm doing a complete comprehensive test of absolutely every single feature of the major widget sets out there, crawling every single corner of their functionality in order to map concepts one-for-one, and finding that they don't really cope. pyqt4. again, i got a long long way. the rich media support of qt4 allowed me to do widgets that looked reasonable. i even had, by that time, a non-asynchronous version of XMLHTTPRequest. then i got to the implementation of Grid() and FlexTable(). this is where it started to go wrong. pyqt4 has the concept of layouts. a layout can be a horizontal layout, vertical, grid, and you can even specify the percentage or ratio of the width (or height) that individual cells can use. you attach a layout to a widget; you can attach layouts to layouts. you can remove layouts from widgets. what you _can't_ do is _remove_ layouts from layouts. disappointingly, this was the killer, for me. it was just getting... too complicated. i had already encountered advice that, in order to implement the means to move widgets around, i should remove *everything* and redo
Re: PyGUI as a standard GUI API for Python?
On Monday 13 October 2008 11:42, lkcl wrote: i don't know if it _was_ detached from the layout, but it was definitely still visible. see http://pyjs.org/examples/gridtest/output/GridTest.html for the example i was porting to pyqt4. each time i clicked Next, a new set of N,N would be _overlaid_ on top of the old ones, even though i was doing removeItem(). Yes, it just sounds like you needed to delete the layouts after removing them. the code's at http://lkcl.net/pyjamas-desktop/pyqt4.tgz I might take a look later in the week if the code in there is runnable. David -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
3) Following the public rumor mill and the latest hype RIA i.e. the merge of web- and desktop applications with systems like Adobe AIR, JavaFX, Google Gears and MS Silverlight is the future of frontend development. With the exception of IronPython and Silverlight, Python hasn't even entered this game and no one knows if it ever will. http://pyjd.org tada :) (based on webkit, just like adobe air is). -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
The role of Python is somewhat arbitrary. This could change only if Python becomes a client side language executed by AVM, V8 etc. pyv8 - http://advogato.org/article/985.html pyjs.py - standalone python-to-javascript compiler, see http://pyjs.org. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Sep 17, 1:16 am, Todd Whiteman [EMAIL PROTECTED] wrote: Todd Whiteman wrote: Mark Hammond's Python/Mozilla work has enabled products like Komodo, Miro (Democracy) and the OLPC project to use Python as a major driver for consistent cross-platform GUI applications. Personally, I believe XULRunner has a lot to offer for Python GUI development, I'm currently finishing up some documentation steps to show off how to use it specifically for Python (I'll post it to this list when it's finished). Here is the tutorial I've started in order to show off building a Python/XULRunner GUI application.http://pyxpcomext.mozdev.org/no_wrap/tutorials/pyxulrunner/python_xul... The details in this tutorial mostly targets a Windows/Linux platform (MacOSX is possible with a few deviations, I have tried to cover these deviations where applicable). Feedback is welcome. oh for _goodness_ sake :) i don't know whether to be derangedly-happy and overexcited that pyxpcom and pydom exist, or whether to be annoyed that i'll have to do _yet another_ port of the pyjamas widget set api to another platform. how come this stuff is so hard to find? it's a _brilliant_ idea to be running python in a web browser, direct. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Sep 3, 4:34 pm, Michael Palmer [EMAIL PROTECTED] wrote: So far, development of PyGUI seems to be a one-man effort, and it may be slowed down by the attempt to develop the API and the implementations concurrently. Could it be useful to uncouple the two, such that the API would be specified ahead of the implementation? michael, i went back to the beginning of this thread, to reply to your question, because i have some insights to share with you from my failed attempts on porting pyjamas to the desktop - which you can collect here: http://lkcl.net/pyjamas-desktop there, you will find an IronPython-GtkSharp port; a pyqt4 port and a pygtk2 port. they were each failures in their own unique and special ways. to explain: pyjamas is a widget set api that looks desktop-like; you write code in python, it's compiled to javascript; the DOM.py module actually does things like document.getElementById() etc. etc. and in this way you end up completely manipulating the DOM model, turning the browser into just a giant desktop-like canvas. in fact, the pyjamas widget set api is _so_ similar to a desktop api that i decided to have a go at porting it _to_ the desktop. eventually i succeeded. the first attempt was with ironpython. i actually got a long way with this one - i chewed through the pyjamas examples in about a day. i had a small stumbling block implementing the HTML() widget, but GtkSharp.HTML came to the rescue, there, and i was off again. i then ran into a wall i decided not to bash my head against at such an early stage (36 hours) - an implementation of XMLHTTPRequest (remember - i was implementing every single bit of functionality that a DOM model has access to). so, i decided to port the ironpython port to pygtk2. unfortunately, whilst i got a lot further and managed to implement all of the examples, there was no equivalent of HTML(). GTK itself totally lacks a rich media content widget. there is python-gtkhtml2 which is good, but not good enough. the much better gtkhtml3 library doesn't have python bindings around it, and i wasn't in the mood to write any (and hadn't at the time any experience with pygtk codegen.py). also i heard that gtkhtml2 had been abandoned, and gtkhtml3 wasn't going to be followed up on, and that there were rumours about webkit. crucially - much more importantly - gtkhtml 2 and 3 have absolutely no automatic resizing of the HTML content within them. so, unless you specify both the width and the height of the widget container, you end up with a flatlined widget. by that i mean a widget of say 200 pixels in width but ZERO pixels in height! and, as you may well know, if you specify a width and height on a gtk widget, that's it: it's entirely fixed. there's no going back. you're screwed. this was an absolute killer. with no foresight in the design of gtk or gtkhtml2 to make even a _guess_ at the width and height of the content, the port was screwed. i made half-hearted attempts to not specify width/height at all, but all that that resulted in was piss-poor layout, and when you shrank the app to small size, all the text disappeared because there was a margin defaulting to 5px or so and all but the top left corner of the text boxes would disappear! so, there was no point in me attempting to make python bindings around gtkhtml3, even though it has a system for inserting widgets into HTML (using span ids). and, even though there's python-gtkmozembed wrappers which would have allowed me to embed flash plugins etc. into my application, thus neatly emulating the way that html allows you to do that. so - sadly - on to pyqt4. well, i say sadly, but it was actually quite fun. i'm doing a complete comprehensive test of absolutely every single feature of the major widget sets out there, crawling every single corner of their functionality in order to map concepts one-for-one, and finding that they don't really cope. pyqt4. again, i got a long long way. the rich media support of qt4 allowed me to do widgets that looked reasonable. i even had, by that time, a non-asynchronous version of XMLHTTPRequest. then i got to the implementation of Grid() and FlexTable(). this is where it started to go wrong. pyqt4 has the concept of layouts. a layout can be a horizontal layout, vertical, grid, and you can even specify the percentage or ratio of the width (or height) that individual cells can use. you attach a layout to a widget; you can attach layouts to layouts. you can remove layouts from widgets. what you _can't_ do is _remove_ layouts from layouts. disappointingly, this was the killer, for me. it was just getting... too complicated. i had already encountered advice that, in order to implement the means to move widgets around, i should remove *everything* and redo the layout. it just... wasn't happening. plus, i think also that there are problems, again, with the HTML layout: you can't _entirely_ stop text-squashing. so, although pyqt4 was _better_, it still
Re: PyGUI as a standard GUI API for Python?
On Saturday 11 October 2008 11:19, lkcl wrote: pyqt4 has the concept of layouts. a layout can be a horizontal layout, vertical, grid, and you can even specify the percentage or ratio of the width (or height) that individual cells can use. you attach a layout to a widget; you can attach layouts to layouts. you can remove layouts from widgets. what you _can't_ do is _remove_ layouts from layouts. You can remove layouts from layouts with the QLayout.removeItem() method. disappointingly, this was the killer, for me. it was just getting... too complicated. i had already encountered advice that, in order to implement the means to move widgets around, i should remove *everything* and redo the layout. it just... wasn't happening. You'll need to delete the contents of those layouts yourself - maybe that's the real problem. You shouldn't need to redo the whole layout structure, though. plus, i think also that there are problems, again, with the HTML layout: you can't _entirely_ stop text-squashing. so, although pyqt4 was _better_, it still wasn't _enough_. These days, you'd probably use PyQt4's WebKit integration for HTML rendering, anyway, though I imagine that it doesn't help you much if you're already using WebKit directly. [...] QT4 lacks crucial layout management (layouts not being deletable from layouts), flow-layout, and variable-sized rich text. they _do_ have proportional subdivision of layouts (allowing you to specify a fixed width on one cell and a percentage width on others) but it is very clumsy. You can write your own layouts as well, but maybe that's more work than you're prepared to do, especially now that you seem to have settled on WebKit as your toolkit. David -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Oct 11, 3:31 pm, David Boddie [EMAIL PROTECTED] wrote: On Saturday 11 October 2008 11:19, lkcl wrote: pyqt4 has the concept of layouts. a layout can be a horizontal layout, vertical, grid, and you can even specify the percentage or ratio of the width (or height) that individual cells can use. you attach a layout to a widget; you can attach layouts to layouts. you can remove layouts from widgets. what you _can't_ do is _remove_ layouts from layouts. You can remove layouts from layouts with the QLayout.removeItem() method. yes... it didn't work. a layout within a layout - i think it was a QHorizontalLayout within a QGridLayout - didn't want to be removed. it's probably a bug. These days, you'd probably use PyQt4's WebKit integration for HTML rendering, anyway, though I imagine that it doesn't help you much if you're already using WebKit directly. [see below...] You can write your own layouts as well, but maybe that's more work than you're prepared to do, definitely. especially now that you seem to have settled on WebKit as your toolkit. well, it just made vast amounts of sense - cut out all the middle men. if you're going to pull in a 17mb binary dependency, why do it in a clumsy way? in order to pull in flash plugins and other material, the accepted method in pygtk2 is to use python-gtk-mozplugger. that's crazy. embed an _entire_ web browser, just to pull in a flash component. likewise, for doing a single bit of HTML, in pyqt4 and/or pygtk2, pull in a 17mb binary dependency using python-webkit-qt4 and/or pywebkitgtk, _just_ to display _one_ bit of HTML text?? _that's_ crazy. especially as webkit actually has far better rendering capability, features and flexibility than any of the standard desktop widget sets which had been designed for the job! wonderfully ironic... oh - for completeness, if anyone's reading this and goes no chance i will _ever_ convert to the pyjamas API because i've spent so much time writing pygtk2 apps - there is a project by luis pamirez, where he has _reimplemented_ gtk.py, gobject.py and gdk.py to sit _on top_ of the pyjamas DOM model. at present, it's only available in the subversion repository of http://code.google.com, and you'll need to check out a revision some time around sep 2007 of the llpamies branch. basically, what that will give you is a means to run your pygtk2 applications... in a web browser! very cool. i'll do a port to pyjamas-desktop at some time, if i have a need for it, and will be happy to help guide anyone who wants to spend the time on it themselves. especially now that you seem to have settled on WebKit as your toolkit. well, it's not _my_ toolkit - i just use it. but you're right inasmuch as i won't be initiating any new applications using pyqt4 or pygtk2, not out of personal choice, anyway. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
ofhttp://code.google.com, and you'll need to check out a revision some time around sep 2007 of the llpamies branch. rsrrmsrrwssrrfssnrssrr :) http://code.google.com/p/pyjamas then follow through to svn instructions, bearing in mind that, other than the llpamies branch, that code is out-of-date. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Saturday 11 October 2008 21:40, lkcl wrote: On Oct 11, 3:31 pm, David Boddie [EMAIL PROTECTED] wrote: You can remove layouts from layouts with the QLayout.removeItem() method. yes... it didn't work. a layout within a layout - i think it was a QHorizontalLayout within a QGridLayout - didn't want to be removed. it's probably a bug. Was it detached from the layout, but still visible? [...] in order to pull in flash plugins and other material, the accepted method in pygtk2 is to use python-gtk-mozplugger. that's crazy. embed an _entire_ web browser, just to pull in a flash component. likewise, for doing a single bit of HTML, in pyqt4 and/or pygtk2, pull in a 17mb binary dependency using python-webkit-qt4 and/or pywebkitgtk, _just_ to display _one_ bit of HTML text?? _that's_ crazy. Sure, if all you want to do is display one bit of HTML text. It always helps if you choose the most appropriate libraries for each task. David -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
lkcl wrote: I got the impression that there is currently no Windows binary available. Correct? If not, perhaps someone trustworthy will someday donate one. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
Todd Whiteman wrote: Mark Hammond's Python/Mozilla work has enabled products like Komodo, Miro (Democracy) and the OLPC project to use Python as a major driver for consistent cross-platform GUI applications. Personally, I believe XULRunner has a lot to offer for Python GUI development, I'm currently finishing up some documentation steps to show off how to use it specifically for Python (I'll post it to this list when it's finished). Here is the tutorial I've started in order to show off building a Python/XULRunner GUI application. http://pyxpcomext.mozdev.org/no_wrap/tutorials/pyxulrunner/python_xulrunner_about.html The details in this tutorial mostly targets a Windows/Linux platform (MacOSX is possible with a few deviations, I have tried to cover these deviations where applicable). Feedback is welcome. Cheers, Todd -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On 10 sep, 20:36, Fred Pacquier [EMAIL PROTECTED] wrote: Todd Whiteman [EMAIL PROTECTED] said : Personally, I believe XULRunner has a lot to offer for Python GUI development, I'm currently finishing up some documentation steps to show off how to use it specifically for Python (I'll post it to this list when it's finished). That would be really nice ! I've long been curious about the potential of XUL+Python, but put off by the lack of leads to follow up, and not having time to do the digging myself... TIA, fp I will also like to see such documentation as soon as possible. To me, XUL+python really looks like what could be my prefered solution for multiplatform GUI for my python program. I'm really impatient and hope a strong and motivated community could set up arrond such XUL+python project. All the best, David -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On 10 sep, 20:36, Fred Pacquier [EMAIL PROTECTED] wrote: Todd Whiteman [EMAIL PROTECTED] said : Personally, I believe XULRunner has a lot to offer for Python GUI development, I'm currently finishing up some documentation steps to show off how to use it specifically for Python (I'll post it to this list when it's finished). That would be really nice ! I've long been curious about the potential of XUL+Python, but put off by the lack of leads to follow up, and not having time to do the digging myself... TIA, fp I will also like to see such documentation as soon as possible. To me, XUL+python really looks like what could be my prefered solution for multiplatform GUI for my python program. I'm really impatient and hope a strong and motivated community could set up arrond such XUL+python project. All the best, David -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
Todd Whiteman [EMAIL PROTECTED] said : Personally, I believe XULRunner has a lot to offer for Python GUI development, I'm currently finishing up some documentation steps to show off how to use it specifically for Python (I'll post it to this list when it's finished). That would be really nice ! I've long been curious about the potential of XUL+Python, but put off by the lack of leads to follow up, and not having time to do the digging myself... TIA, fp -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Wed, Sep 3, 2008 at 11:57 AM, Diez B. Roggisch [EMAIL PROTECTED] wrote: Michael Palmer schrieb: As anyone knows, the state of Python GUI programming is a little fractured at this time, with many toolkits, wrappers and meta-wrappers dead and alive, with or without documentation. I've come across two projects that have the appeal of striving for simple, pythonic APIs: PyGUI and wax. The latter is a wrapper around wxPython. It is lacking documentation but actually quite usable and concise. The other, PyGUI, has an even nicer API and more docs but has relatively few widgets implemented at this time. It also strives for compatibility with several toolkits (two at this time), which I think is the right idea. I disagree with that. Meta-wrappers like this will always suffer from problems, as they have difficulties providing a consistent api. For example wx is said to be very windows-toolkit-centric in it's API. Yes I know that it works under Linux with GTK, but it does not come as natural . With all due respect, it seems like you are not terribly familiar with wxPython. It uses the native UI toolkit for each platform wherever possible: Aqua on OS X; MFC on Windows and Gtk on Linux. Applications tend to look 'natural' on each platform, rather than uniform across platforms, and I believe that this is what most people prefer. -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
Peter Decker schrieb: On Wed, Sep 3, 2008 at 11:57 AM, Diez B. Roggisch [EMAIL PROTECTED] wrote: Michael Palmer schrieb: As anyone knows, the state of Python GUI programming is a little fractured at this time, with many toolkits, wrappers and meta-wrappers dead and alive, with or without documentation. I've come across two projects that have the appeal of striving for simple, pythonic APIs: PyGUI and wax. The latter is a wrapper around wxPython. It is lacking documentation but actually quite usable and concise. The other, PyGUI, has an even nicer API and more docs but has relatively few widgets implemented at this time. It also strives for compatibility with several toolkits (two at this time), which I think is the right idea. I disagree with that. Meta-wrappers like this will always suffer from problems, as they have difficulties providing a consistent api. For example wx is said to be very windows-toolkit-centric in it's API. Yes I know that it works under Linux with GTK, but it does not come as natural . With all due respect, it seems like you are not terribly familiar with wxPython. It uses the native UI toolkit for each platform wherever possible: Aqua on OS X; MFC on Windows and Gtk on Linux. Applications tend to look 'natural' on each platform, rather than uniform across platforms, and I believe that this is what most people prefer. You got me wrong. I didn't say it doesn't use the native toolkit under various OSes, I'm well aware of that it does. What I *did* say was that wx API is designed primarily with windows' toolkit as base, and as a consequence the API tends to be less functional for other toolkits, making it harder to work with it. As the OP was after a one API to rule them all for GUIs, I pointed that out. See for example this (arguably somewhat dated) post that illustrates my point: http://mail.python.org/pipermail/python-list/2005-March/313354.html From my personal experience with Qt and Cocoa, I can say that both are great, but their full power is unleashed only if used directly - talk about Multi-threading in Qt4, or KeyValue-coding in Cocoa. Neither is available in wx. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
M.-A. Lemburg wrote: A long time ago, there was a Python plugin for Netscape which allowed you to run Python straight in the browser. Perhaps it's time to revive such an idea... but then you're still missing out on the GUI part, since you're still stuck with what the browser has to offer in terms of widget support. There is still a plugin (extension) for Mozilla based products, that enables use of Python in products like Firefox: http://pyxpcomext.mozdev.org/ Mark Hammond's Python/Mozilla work has enabled products like Komodo, Miro (Democracy) and the OLPC project to use Python as a major driver for consistent cross-platform GUI applications. Personally, I believe XULRunner has a lot to offer for Python GUI development, I'm currently finishing up some documentation steps to show off how to use it specifically for Python (I'll post it to this list when it's finished). Cheers, Todd -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Fri, Sep 5, 2008 at 10:48 AM, Diez B. Roggisch [EMAIL PROTECTED] wrote: You got me wrong. I didn't say it doesn't use the native toolkit under various OSes, I'm well aware of that it does. What I *did* say was that wx API is designed primarily with windows' toolkit as base, and as a consequence the API tends to be less functional for other toolkits, making it harder to work with it. As the OP was after a one API to rule them all for GUIs, I pointed that out. See for example this (arguably somewhat dated) post that illustrates my point: http://mail.python.org/pipermail/python-list/2005-March/313354.html OK, that's a little clearer. That's one of the things that I like about Dabo - it gets rid of the ugly (IMO) wxPython API and replaces it with a much more consistent (and, IMO) more Pythonic API. I hated coding in wx, but I love coding in Dabo. -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On 2008-09-04 07:49, Kay Schluehr wrote: 3) Following the public rumor mill and the latest hype RIA i.e. the merge of web- and desktop applications with systems like Adobe AIR, JavaFX, Google Gears and MS Silverlight is the future of frontend development. With the exception of IronPython and Silverlight, Python hasn't even entered this game and no one knows if it ever will. Actually, it has already and quite some time ago: http://www.artima.com/weblogs/viewpost.jsp?thread=208528 The recipe is simple: use Python for the business logic, database interfacing, etc and have it talk to a Flex front-end via XML-RPC or REST. As a nice side-effect, this also results in a better separation between GUI and backend, effectively making the solution future-proof and easy to adapt to other front-end technologies. We've been working with this approach for almost a year now and so far never had to look back. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 04 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On 4 Sep., 10:31, M.-A. Lemburg [EMAIL PROTECTED] wrote: On 2008-09-04 07:49, Kay Schluehr wrote: 3) Following the public rumor mill and the latest hype RIA i.e. the merge of web- and desktop applications with systems like Adobe AIR, JavaFX, Google Gears and MS Silverlight is the future of frontend development. With the exception of IronPython and Silverlight, Python hasn't even entered this game and no one knows if it ever will. Actually, it has already and quite some time ago: http://www.artima.com/weblogs/viewpost.jsp?thread=208528 The recipe is simple: use Python for the business logic, database interfacing, etc and have it talk to a Flex front-end via XML-RPC or REST. Python is still server-side in this scenario and plays no role in UI definitions. So one doesn't get more than e.g. Django apps that respond to HTTP requests triggered by JavaScript forms except that JavaScript+HTML+Browser is replaced by Flex = AS3+MXML+FlashPlayer. The role of Python is somewhat arbitrary. This could change only if Python becomes a client side language executed by AVM, V8 etc. like IronPython in Silverlight. About separating UI from application logics by assigning functionality to different general purpose languages I have to admit that I don't think it is such a great idea ... -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On 2008-09-04 11:14, Kay Schluehr wrote: On 4 Sep., 10:31, M.-A. Lemburg [EMAIL PROTECTED] wrote: On 2008-09-04 07:49, Kay Schluehr wrote: 3) Following the public rumor mill and the latest hype RIA i.e. the merge of web- and desktop applications with systems like Adobe AIR, JavaFX, Google Gears and MS Silverlight is the future of frontend development. With the exception of IronPython and Silverlight, Python hasn't even entered this game and no one knows if it ever will. Actually, it has already and quite some time ago: http://www.artima.com/weblogs/viewpost.jsp?thread=208528 The recipe is simple: use Python for the business logic, database interfacing, etc and have it talk to a Flex front-end via XML-RPC or REST. Python is still server-side in this scenario and plays no role in UI definitions. That depends on how you design the application. It is well possible to have Python drive the GUI by sending the required details to the Flex front-end via XML (ie. data-driven GUIs). So one doesn't get more than e.g. Django apps that respond to HTTP requests triggered by JavaScript forms except that JavaScript+HTML+Browser is replaced by Flex = AS3+MXML+FlashPlayer. You really can't compare the Flex stack to an AJAX stack. Flex has a lot more to offer for GUI programming than AJAX, it also doesn't suffer from the problems of AJAX having to support several different sets of browser or library bugs. We switched from an AJAX approach to a Flex-based approach last year and never even considered moving back again. The role of Python is somewhat arbitrary. This could change only if Python becomes a client side language executed by AVM, V8 etc. like IronPython in Silverlight. About separating UI from application logics by assigning functionality to different general purpose languages I have to admit that I don't think it is such a great idea ... In my experience, Flex + Python gives you the best of both worlds, the nice GUI features of Flex and the efficiency of Python for the business logic. A long time ago, there was a Python plugin for Netscape which allowed you to run Python straight in the browser. Perhaps it's time to revive such an idea... but then you're still missing out on the GUI part, since you're still stuck with what the browser has to offer in terms of widget support. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 04 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Thu, Sep 4, 2008 at 3:45 PM, M.-A. Lemburg [EMAIL PROTECTED] wrote: On 2008-09-04 11:14, Kay Schluehr wrote: On 4 Sep., 10:31, M.-A. Lemburg [EMAIL PROTECTED] wrote: On 2008-09-04 07:49, Kay Schluehr wrote: 3) Following the public rumor mill and the latest hype RIA i.e. the merge of web- and desktop applications with systems like Adobe AIR, JavaFX, Google Gears and MS Silverlight is the future of frontend development. With the exception of IronPython and Silverlight, Python hasn't even entered this game and no one knows if it ever will. Actually, it has already and quite some time ago: http://www.artima.com/weblogs/viewpost.jsp?thread=208528 The recipe is simple: use Python for the business logic, database interfacing, etc and have it talk to a Flex front-end via XML-RPC or REST. Python is still server-side in this scenario and plays no role in UI definitions. That depends on how you design the application. It is well possible to have Python drive the GUI by sending the required details to the Flex front-end via XML (ie. data-driven GUIs). So one doesn't get more than e.g. Django apps that respond to HTTP requests triggered by JavaScript forms except that JavaScript+HTML+Browser is replaced by Flex = AS3+MXML+FlashPlayer. You really can't compare the Flex stack to an AJAX stack. Flex has a lot more to offer for GUI programming than AJAX, it also doesn't suffer from the problems of AJAX having to support several different sets of browser or library bugs. We switched from an AJAX approach to a Flex-based approach last year and never even considered moving back again. The approach does seem quite impressive, but isn't Flex's platform neutrality quite over-rated ? I mean after-all, it assumes that Flex is available for and available on the platform. Flex today is not yet so ubiquitous as the JRE... Are there some established best-practices on how to package such applications -- s.a. shipping with its's own Flex runtime, offer-download if missing etc. ? What happens if owner of target machine decides to upgrade their version of Flex, will it impact the application package in anyway, and render rest of it non-upgradable ? The role of Python is somewhat arbitrary. This could change only if Python becomes a client side language executed by AVM, V8 etc. like IronPython in Silverlight. About separating UI from application logics by assigning functionality to different general purpose languages I have to admit that I don't think it is such a great idea ... In my experience, Flex + Python gives you the best of both worlds, the nice GUI features of Flex and the efficiency of Python for the business logic. A long time ago, there was a Python plugin for Netscape which allowed you to run Python straight in the browser. Perhaps it's time to revive such an idea... but then you're still missing out on the GUI part, since you're still stuck with what the browser has to offer in terms of widget support. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 04 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 -- http://mail.python.org/mailman/listinfo/python-list -- regards, Banibrata http://www.linkedin.com/in/bdutta http://octapod.wordpress.com -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On 2008-09-04 12:57, Banibrata Dutta wrote: On Thu, Sep 4, 2008 at 3:45 PM, M.-A. Lemburg [EMAIL PROTECTED] wrote: On 2008-09-04 11:14, Kay Schluehr wrote: On 4 Sep., 10:31, M.-A. Lemburg [EMAIL PROTECTED] wrote: On 2008-09-04 07:49, Kay Schluehr wrote: 3) Following the public rumor mill and the latest hype RIA i.e. the merge of web- and desktop applications with systems like Adobe AIR, JavaFX, Google Gears and MS Silverlight is the future of frontend development. With the exception of IronPython and Silverlight, Python hasn't even entered this game and no one knows if it ever will. Actually, it has already and quite some time ago: http://www.artima.com/weblogs/viewpost.jsp?thread=208528 The recipe is simple: use Python for the business logic, database interfacing, etc and have it talk to a Flex front-end via XML-RPC or REST. Python is still server-side in this scenario and plays no role in UI definitions. That depends on how you design the application. It is well possible to have Python drive the GUI by sending the required details to the Flex front-end via XML (ie. data-driven GUIs). So one doesn't get more than e.g. Django apps that respond to HTTP requests triggered by JavaScript forms except that JavaScript+HTML+Browser is replaced by Flex = AS3+MXML+FlashPlayer. You really can't compare the Flex stack to an AJAX stack. Flex has a lot more to offer for GUI programming than AJAX, it also doesn't suffer from the problems of AJAX having to support several different sets of browser or library bugs. We switched from an AJAX approach to a Flex-based approach last year and never even considered moving back again. The approach does seem quite impressive, but isn't Flex's platform neutrality quite over-rated ? I mean after-all, it assumes that Flex is available for and available on the platform. Flex today is not yet so ubiquitous as the JRE... Since Flex is compiled to Flash and runs inside the Flash player, it is fairly easy to get Flex apps running. You do have to have the Flash9 player installed and the default minimum is 9.0.115.0 for Flex builder 3. Are there some established best-practices on how to package such applications -- s.a. shipping with its's own Flex runtime, offer-download if missing etc. ? What happens if owner of target machine decides to upgrade their version of Flex, will it impact the application package in anyway, and render rest of it non-upgradable ? So far we have not had any such problems, but that could change when Flash10 starts to ship, of course. We currently ship the application as a server application. The only requirement on the client side is having a browser with Flash9 installed. Pointing the browser at the server will then load the compiled Flex application (as .swf file). An alternative approach is bundling the client as AIR application which then runs as stand-alone app on the client side, but we haven't tried that yet. The role of Python is somewhat arbitrary. This could change only if Python becomes a client side language executed by AVM, V8 etc. like IronPython in Silverlight. About separating UI from application logics by assigning functionality to different general purpose languages I have to admit that I don't think it is such a great idea ... In my experience, Flex + Python gives you the best of both worlds, the nice GUI features of Flex and the efficiency of Python for the business logic. A long time ago, there was a Python plugin for Netscape which allowed you to run Python straight in the browser. Perhaps it's time to revive such an idea... but then you're still missing out on the GUI part, since you're still stuck with what the browser has to offer in terms of widget support. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 04 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 04 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
PyGUI as a standard GUI API for Python?
As anyone knows, the state of Python GUI programming is a little fractured at this time, with many toolkits, wrappers and meta-wrappers dead and alive, with or without documentation. I've come across two projects that have the appeal of striving for simple, pythonic APIs: PyGUI and wax. The latter is a wrapper around wxPython. It is lacking documentation but actually quite usable and concise. The other, PyGUI, has an even nicer API and more docs but has relatively few widgets implemented at this time. It also strives for compatibility with several toolkits (two at this time), which I think is the right idea. So far, development of PyGUI seems to be a one-man effort, and it may be slowed down by the attempt to develop the API and the implementations concurrently. Could it be useful to uncouple the two, such that the API would be specified ahead of the implementation? This might make it easier for people to contribute implementation code and maybe port the API to additional toolkits. It seems that this approach has been quite successful in case of the Python database API. That API defines levels of compliance, which might be a way of accommodating different GUI toolkits as well. I may be underestimating the difficulties of my proposed approach - I don't have much practical experience with GUI programming myself. Best, Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
Michael Palmer schrieb: As anyone knows, the state of Python GUI programming is a little fractured at this time, with many toolkits, wrappers and meta-wrappers dead and alive, with or without documentation. I've come across two projects that have the appeal of striving for simple, pythonic APIs: PyGUI and wax. The latter is a wrapper around wxPython. It is lacking documentation but actually quite usable and concise. The other, PyGUI, has an even nicer API and more docs but has relatively few widgets implemented at this time. It also strives for compatibility with several toolkits (two at this time), which I think is the right idea. I disagree with that. Meta-wrappers like this will always suffer from problems, as they have difficulties providing a consistent api. For example wx is said to be very windows-toolkit-centric in it's API. Yes I know that it works under Linux with GTK, but it does not come as natural . So far, development of PyGUI seems to be a one-man effort, and it may be slowed down by the attempt to develop the API and the implementations concurrently. Could it be useful to uncouple the two, such that the API would be specified ahead of the implementation? This might make it easier for people to contribute implementation code and maybe port the API to additional toolkits. It seems that this approach has been quite successful in case of the Python database API. That API defines levels of compliance, which might be a way of accommodating different GUI toolkits as well. I may be underestimating the difficulties of my proposed approach - I don't have much practical experience with GUI programming myself. I think you do. The reason for the various toolkits is not because of python - it's the proliferation of toolkits that exist out there. As long as none of these is the winner (and it doesn't look is if that's to happen soon), I doubt that one API to rule them all will exist - they all have their different strengths and weaknesses, and a python-API should reflect these. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Sep 3, 12:57 pm, Diez B. Roggisch [EMAIL PROTECTED] wrote: Michael Palmer schrieb: The other, PyGUI, has an even nicer API and more docs but has relatively few widgets implemented at this time. It also strives for compatibility with several toolkits (two at this time), which I think is the right idea. I disagree with that. Meta-wrappers like this will always suffer from problems, as they have difficulties providing a consistent api. For example wx is said to be very windows-toolkit-centric in it's API. Yes I know that it works under Linux with GTK, but it does not come as natural . wax actually does a nice job at wrapping wxPython with a cleaner API. So far, development of PyGUI seems to be a one-man effort, and it may be slowed down by the attempt to develop the API and the implementations concurrently. Could it be useful to uncouple the two, such that the API would be specified ahead of the implementation? This might make it easier for people to contribute implementation code and maybe port the API to additional toolkits. It seems that this approach has been quite successful in case of the Python database API. That API defines levels of compliance, which might be a way of accommodating different GUI toolkits as well. I may be underestimating the difficulties of my proposed approach - I don't have much practical experience with GUI programming myself. I think you do. The reason for the various toolkits is not because of python - it's the proliferation of toolkits that exist out there. Right. But that is similar to the situation with relational databases. There are so many of them that it's impossible to include an adapter to each of them in the stdlib. The next best thing is to provide a high-level API that abstracts away the differences. As long as none of these is the winner (and it doesn't look is if that's to happen soon), I doubt that one API to rule them all will exist - they all have their different strengths and weaknesses, and a python-API should reflect these. I rather think that a standard API would cover a reasonable subset - it should NOT contain the idiosyncrasies of each individual toolkit. The anygui project, which has been dormant for a while, is another attempt at a high-level api. Apparently, it tried to implement backends for a lot of toolkits - which again may have been to ambitious an agenda. Maybe someone who was involved in that project might provide some insight. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
Michael Palmer schrieb: I disagree with that. Meta-wrappers like this will always suffer from problems, as they have difficulties providing a consistent api. For example wx is said to be very windows-toolkit-centric in it's API. Yes I know that it works under Linux with GTK, but it does not come as natural . wax actually does a nice job at wrapping wxPython with a cleaner API. wax wraps wx. It does not wrap PyQt, Tk, win32, GTK and whatnot. That was what I was talking about. Right. But that is similar to the situation with relational databases. There are so many of them that it's impossible to include an adapter to each of them in the stdlib. The next best thing is to provide a high-level API that abstracts away the differences. As long as none of these is the winner (and it doesn't look is if that's to happen soon), I doubt that one API to rule them all will exist - they all have their different strengths and weaknesses, and a python-API should reflect these. I rather think that a standard API would cover a reasonable subset - it should NOT contain the idiosyncrasies of each individual toolkit. And thus reduce the usability massively. A reasonable subset is already included in python, with tkinter, available on a wide range of plattforms. Yet still people strive for the various other toolkits, because they miss richer widgets, gui-designers (an important topic you don't cover at all) or e.g. multi-threading capabilities. The anygui project, which has been dormant for a while, is another attempt at a high-level api. Apparently, it tried to implement backends for a lot of toolkits - which again may have been to ambitious an agenda. Maybe someone who was involved in that project might provide some insight. Sure, that would be interesting. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
Michael Palmer wrote: As anyone knows, the state of Python GUI programming is a little fractured at this time, with many toolkits, wrappers and meta-wrappers dead and alive, with or without documentation. How about Dabo? http://www.dabodev.com/ -- --OKB (not okblacke) Brendan Barnwell Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail. --author unknown -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
Michael Palmer wrote: So far, development of PyGUI seems to be a one-man effort, and it may be slowed down by the attempt to develop the API and the implementations concurrently. Could it be useful to uncouple the two, such that the API would be specified ahead of the implementation? I'm not sure that would work very well. I don't think it's possible to invent a good API for something as complex as a GUI toolkit in the absence of experience using it, so the API has to evolve in parallel with at least one implementation, and with real applications that actually use the features concerned. Also, the features that go into the PyGUI API are partly determined by what is available in the underlying target libraries. I don't want to end up with things in the API specification that are too difficult or unwieldy to implement on some of the target platforms. I also don't want one implementation to get too far ahead of the others, for the same reason. If anyone wants to help, what's needed most right now is a good native Windows implementation. One or two people claimed to be working on that some time ago, but I haven't heard from them recently. For the reasons I mentioned above, I'm reluctant to forge ahead with too many new features until a native Windows version exists. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On 3 Sep., 18:34, Michael Palmer [EMAIL PROTECTED] wrote: As anyone knows, the state of Python GUI programming is a little fractured at this time, with many toolkits, wrappers and meta-wrappers dead and alive, with or without documentation. A few thoughts. 1) This topic is discussed here every few months. While some kind of AnyGUI is theoretically very elegant it hasn't worked out well in practice: GUI libs are huge and heterogeneous. It's much unlike building an API-layer on top of SQL. Moreover I'd like to ask whether the fragmentation turns out to be that much of a problem in practice? 2) Tcl/Tk might have a revival due to the new Tk-theme engine in version 8.5. http://www.tcl.tk/software/tcltk/8.5.tml http://wiki.tcl.tk/13636 Chances are Tkinter widgets will not look like early '90s legacy anymore. 3) Following the public rumor mill and the latest hype RIA i.e. the merge of web- and desktop applications with systems like Adobe AIR, JavaFX, Google Gears and MS Silverlight is the future of frontend development. With the exception of IronPython and Silverlight, Python hasn't even entered this game and no one knows if it ever will. Ciao, Kay -- http://mail.python.org/mailman/listinfo/python-list
