Thread: [Anygui-devel] On AnyGUI Core
Brought to you by:
mlh
From: Peter D. <pd...@gm...> - 2005-08-05 08:56:23
|
Hello list, I've been looking around at python GUI toolkits just for fun and I came across AnyGUI. It is very impressive but I think it solves the wrong problem. Let me explain myself: People want to create GUIs but there are very few people that want "just" an user interface, most of them want their GUI to work flawlessly. The fact that it can run on different platforms on different toolkits might not be such a great thing if the developers of the app will have to continuously "fix" the app for some esoteric combinations of OS versions-toolkit versions-python versions. This distracts them from solving the real problem: what the app should do. AnyGUI tries to unify the API and use existing toolkits BUT in this it opens not one but many cans of worms, not only will the end user have to deal with the quirks of one toolkit but with the quirks of many. As a programmer I would like to have is an OSS python GUI toolkit that looks great everywhere and acts the same on all platforms without custom hack in the app code. There is currently no such thing and my little mind cannot understand why. Ok... so its a lot of work to create such a thing BUT I could not find any project that aims to create such a thing. PyUI looked like it could be something in the lines of what I'm looking for but from what I can see.... the people creating it have a different target. Here is how I see such a toolkit approached: - defined the windowing (Frames and Panels) - defined the layout (Layout managers, for starters something like BoxSizer and GidBagSizer from wxpython should do) - defined the basic events/event loop - defined the basic widgets (label, textfield, button, list, etc.) - defined the renderer (this is the thing that actually creates the visual part of the widgets based on their attributes) - the renderer should contain some kind of mechanism for rendering individual widgets, for starters a bitmap based one would be enough) think of something that could take a archive of PNGs and mimic the appearance of Windows, Mac, different themes of GTK or QT. Advantages: - once past the basic implementation of the windowing and event system people could test it and help implement the widgets (let's say the follow the implementation guidelines for let's say Button) - this is a top-down implementation so in theory it should be less buggy.... maybe for starters we could use part of an established toolkit for the windowing and drawing only to replace it with a custom system written specifically for the job. Every time I look at a toolkit I try to see how well the developers learned from their predecessors. For example... one of the best help systems I've come across is the wxPython Demo. In my view this should be present in each and every toolkit out there. Most of what I know today I learned from the Demo. Now to the real question of this email. What should a crazy enough person do to try and build such a toolkit? How could he reuse the work that went into AnyGUI? Thanks for reading so far. :) Peter. |
From: David M. <da...@re...> - 2005-08-05 10:18:50
|
Peter Damoc wrote: > Hello list, > > I've been looking around at python GUI toolkits just for fun and I came > across AnyGUI. > It is very impressive but I think it solves the wrong problem. Let me > explain myself: 8>< Agreed - AnyGui by its nature is vulnerable to countless environmental quirks. If it had a large, organised and devoted development and maintenance team, it would probably cope well. But it would take a lot of resources to prevent the endless "it's not working on <linux distro x>" > As a programmer I would like to have is an OSS python GUI toolkit that > looks great everywhere and acts the same on all platforms without > custom hack in the app code. PyQT is worth a look. However, that carries the cost of Qt's weird windows licensing quirks. > There is currently no such thing True, but (IMHO) the PMW/Tkinter combination comes very close (http://pmw.sourceforge.net). > and my little mind cannot understand why. > Ok... so its a lot of work to create such a thing Creating such a thing is relatively straightforward. Making it practical - easily learned, easy to setup and use, and respectful of resources takes about 5-50 times that amount of work again. There's a lot of good gui libs, but they're hard to understand unless you're willing to study the implementation's source code, or even live with the developer and suck the pizza stains off his/her T-shirt. Please do have a serious try of Tkinter, with the PMW classes over the top. I've been there, from scared gui neophyte to someone that can build smart, platform-independent guis - all the pain and labour you put into learning Tkinter, you will recoup in joy and satisfaction as your apps Simply Just Work. Tkinter-based progs also package well into windows standalone EXE packages (eg Py2EXE), so you can spare your users the confusion of installing/setting up their own Python environment. Cheers David |
From: Peter D. <pd...@gm...> - 2005-08-05 10:40:14
|
On Fri, 05 Aug 2005 13:18:28 +0300, David McNab <da...@re...> wrote: > Peter Damoc wrote: >> Hello list, >> >> I've been looking around at python GUI toolkits just for fun and I came >> across AnyGUI. >> It is very impressive but I think it solves the wrong problem. Let me >> explain myself: > 8>< > > Agreed - AnyGui by its nature is vulnerable to countless environmental > quirks. If it had a large, organised and devoted development and > maintenance team, it would probably cope well. But it would take a lot > of resources to prevent the endless "it's not working on <linux distro > x>" this is why I think is better to just reimplement the low level. Wrapping the toolkits might be too much, especialy for a small team >> As a programmer I would like to have is an OSS python GUI toolkit that >> looks great everywhere and acts the same on all platforms without >> custom hack in the app code. > > PyQT is worth a look. However, that carries the cost of Qt's weird > windows licensing quirks. PyQT follows QT and... some people might not want to invest in something that will allow the to create *only* GPL OpenSource. Where I live 6000$ is about the sallary for 2 years for some people. Not an option. >> There is currently no such thing > > True, but (IMHO) the PMW/Tkinter combination comes very close > (http://pmw.sourceforge.net). anything Tkinter makes me thing at ugly GUIs.... sure that might be a whimsical thing but.... a lot of beginners look at this. >> and my little mind cannot understand why. >> Ok... so its a lot of work to create such a thing > > Creating such a thing is relatively straightforward. Making it practical > - easily learned, easy to setup and use, and respectful of resources > takes about 5-50 times that amount of work again. build it and they will come. Once done the proof of concept... maybe someone will come and optimize the low-end stuff just to demonstrate that it can. > There's a lot of good gui libs, but they're hard to understand unless > you're willing to study the implementation's source code, or even live > with the developer and suck the pizza stains off his/her T-shirt. Not true, I have a fair experience with wxPython and is not that hard BUT it does not allow skinning, and it feels heavy, packaged exe are rather big... and most importantly... a lot of low level bugs surface from the C++ part. > Please do have a serious try of Tkinter, with the PMW classes over the > top. I've been there, from scared gui neophyte to someone that can build > smart, platform-independent guis - all the pain and labour you put into > learning Tkinter, you will recoup in joy and satisfaction as your apps > Simply Just Work. Tkinter-based progs also package well into windows > standalone EXE packages (eg Py2EXE), so you can spare your users the > confusion of installing/setting up their own Python environment. > > Cheers > David Thanks for your reply, will take a look at PMW. Peter. |
From: David M. <da...@re...> - 2005-08-05 12:13:49
|
Peter Damoc wrote: >>> There is currently no such thing >> True, but (IMHO) the PMW/Tkinter combination comes very close >> (http://pmw.sourceforge.net). > anything Tkinter makes me thing at ugly GUIs That's because most tk gui authors don't take the time to style their interfaces. Agreed - default tkinter looks horrible. For instance, the default grey background and bold text for fields - a graphic design abortion! The beauty of Tkinter is that it's accessed through python classes. So all you have to do is write a subclass once for each of the widget classes you use, and all the ugliness goes away. D |
From: Peter D. <pd...@gm...> - 2005-08-08 06:41:35
|
On Fri, 05 Aug 2005 15:13:38 +0300, David McNab <da...@re...> wrote: > Peter Damoc wrote: >>>> There is currently no such thing >>> True, but (IMHO) the PMW/Tkinter combination comes very close >>> (http://pmw.sourceforge.net). > >> anything Tkinter makes me thing at ugly GUIs > > That's because most tk gui authors don't take the time to style their > interfaces. > > Agreed - default tkinter looks horrible. For instance, the default grey > background and bold text for fields - a graphic design abortion! > > The beauty of Tkinter is that it's accessed through python classes. So > all you have to do is write a subclass once for each of the widget > classes you use, and all the ugliness goes away. > > D Does Tkinter supports skins? Simply changing the bgcolour or the font don't cut it... it still looks ugly by todays standards. Peter. |
From: David M. <da...@re...> - 2005-08-08 07:09:35
|
Peter Damoc wrote: > Does Tkinter supports skins? Simply changing the bgcolour or the font > don't cut it... it still looks ugly by todays standards. Sorry, Tkinter doesn't support skins, or alpha-blending, or animated 3d dancing animals either. Choice of gui widgets is akin to religious debate, so I won't engage here. All I'll say is that for me, Tkinter (with PMW) gives me the fastest way to implement a basic clean-looking multiplatform GUI, on a par with Thunderbird or Firefox, with a programming API that lets me implement the desired appearance and functionality with less effort, less lines of code and less platform-specific dramas than the other GUI libs I've looked at. Cheers David |
From: Magnus L. H. <ma...@he...> - 2005-08-05 14:43:13
|
Peter Damoc <pd...@gm...>: > > On Fri, 05 Aug 2005 13:18:28 +0300, David McNab <da...@re...> > wrote: > [snip] > this is why I think is better to just reimplement the low level. > Wrapping the toolkits might be too much, especialy for a small team Yeah -- it turned out to be quite hard in practice. -- Magnus Lie Hetland Fall seven times, stand up eight http://hetland.org [Japanese proverb] |
From: Magnus L. H. <ma...@he...> - 2005-08-05 14:41:41
|
Peter Damoc <pd...@gm...>: > > Hello list, > [snip] > AnyGUI tries to unify the API and use existing toolkits BUT in this > it opens not one but many cans of worms, not only will the end user > have to deal with the quirks of one toolkit but with the quirks of > many. The idea was (originally) to keep things at such a low level that the developer only needed to worry about the general logical structure of the GUI, and the details would be handled by the back-end. That was the idea, but... ;) > As a programmer I would like to have is an OSS python GUI toolkit > that looks great everywhere and acts the same on all platforms > without custom hack in the app code. I agree. Nowadays I think wxPython and PyQt seem like promising candidates, actually. One option to look out for in the future is Greg's PyGUI: http://www.cosc.canterbury.ac.nz/~greg/python_gui [snip] > Now to the real question of this email. > What should a crazy enough person do to try and build such a > toolkit? How could he reuse the work that went into AnyGUI? Hm. Much of the code (and blood, sweat and tears) of Anygui deals with the front-end/back-end stuff -- and if you want to implement the actual GUI stuff yourself, I guess you could just scrap all that. If you want to keep this mechanism, you could probably build on what's there... But if you don't want a pure-Python layer that sits on top of other packages (not sure if you do or not ;) -- why not simply use a packages such as wxPython? It seems to have the BDFLs blessing, so... -- Magnus Lie Hetland Fall seven times, stand up eight http://hetland.org [Japanese proverb] |
From: Greg E. <gre...@ca...> - 2005-08-06 02:11:49
|
Magnus Lie Hetland wrote: > One option to look out for in the future is Greg's PyGUI: > > http://www.cosc.canterbury.ac.nz/~greg/python_gui Peter seems to be suggesting more or less implementing a complete GUI in Python. That would ensure that it worked on all platforms, but there are difficulties with this approach, which is what things like wxWidgets and Qt do. They never seem to look and behave exactly like the native widgets on a given platform, and they're always playing catch-up with changes in the native look and feel. I also have performance concerns about doing it all in Python. I expect it would be very difficult, for example, to implement a pure-Python rich text editor that was as featureful and efficient as those available nowadays in many of the native GUI packages. With PyGUI, I'm taking almost the opposite approach, and trying to make as much use as I can of what is natively provided on the plaform. Like Anygui, PyGUI aims to provide a common API to the Python programmer, implemented in terms of different underlying libraries. But unlike Anygui, I'm not trying to wrap every GUI toolkit in existence, but just provide *one* high-quality implementation on each platform, built as directly as possible on the platform's native facilities. That way, I hope to avoid the worst of the lowest-common- denominator problems that Anygui has, leverage as much power as I can from the underlying platform facilities, and avoid requiring the user to install any large, unwieldy and potentially buggy third-party libraries. Greg |
From: Peter D. <pd...@gm...> - 2005-08-08 10:29:14
|
On Sat, 06 Aug 2005 05:00:04 +0300, Greg Ewing <gre...@ca...> wrote: > Magnus Lie Hetland wrote: > >> One option to look out for in the future is Greg's PyGUI: >> http://www.cosc.canterbury.ac.nz/~greg/python_gui > > Peter seems to be suggesting more or less implementing a > complete GUI in Python. That would ensure that it worked > on all platforms, but there are difficulties with this > approach, which is what things like wxWidgets and Qt do. > They never seem to look and behave exactly like the > native widgets on a given platform, and they're always > playing catch-up with changes in the native look and feel. Yes! this is what I'm suggesting more or less. I'm for the QT like approach NOT the wxWidgets one. If the theming engine is well implemented, the toolkit will look very much alike the native ones. If the feel is implemented using the best approach (think OSX) users on other systems won't mind. I mean... if the apps behave better people won't mind that they don't behave like the native ones. > I also have performance concerns about doing it all in > Python. I expect it would be very difficult, for example, > to implement a pure-Python rich text editor that was > as featureful and efficient as those available nowadays > in many of the native GUI packages. I agree, some widgets would simply have to be implemented in some low level language BUT if they first work people might find it worth reimplementing them in C/C++ or at least the bottleneck bits. Kinda like in pickle/cPickle combo. > With PyGUI, I'm taking almost the opposite approach, > and trying to make as much use as I can of what is > natively provided on the plaform. Like Anygui, PyGUI > aims to provide a common API to the Python programmer, > implemented in terms of different underlying libraries. > But unlike Anygui, I'm not trying to wrap every GUI > toolkit in existence, but just provide *one* high-quality > implementation on each platform, built as directly as > possible on the platform's native facilities. > > That way, I hope to avoid the worst of the lowest-common- > denominator problems that Anygui has, leverage as much > power as I can from the underlying platform facilities, > and avoid requiring the user to install any large, > unwieldy and potentially buggy third-party libraries. FOX and I think FLTK have the best approach... they implement everything on top of a very thin platform specific layer. This is in my view the best approach: Implement as much as possible in python and reuse some of the code from one of those projects altho it might not be all that easy to "extract" the necessary bits from their source tree. The idea is to forgo all the unnecessary, C++ related bits from the toolkit that have counterparts in python and keep only the minimum. Peter |
From: Magnus L. H. <ma...@he...> - 2005-08-08 10:41:21
|
Peter Damoc <pd...@gm...>: > [snip] > I'm for the QT like approach NOT the wxWidgets one. So this would be like Java Swing? (Just checking.) [snip] > This is in my view the best approach: Implement as much as possible > in python and reuse some of the code from one of those projects > altho it might not be all that easy to "extract" the necessary bits > from their source tree. Sounds like a sound enough approach, I guess. > The idea is to forgo all the unnecessary, C++ related bits from the > toolkit that have counterparts in python and keep only the minimum. IIRC, one of your questions was what you could reuse from Anygui? To begin with, I guess you could simply write a back-end using your approach -- but many of the Anygui mechanisms would be highly unnecessary (i.e., the whole front-end/back-end stuff). The event handling stuff could perhaps be useful, and maybe some of the model/observable stuff... -- Magnus Lie Hetland Fall seven times, stand up eight http://hetland.org [Japanese proverb] |
From: Donnal W. <don...@ya...> - 2005-08-08 12:50:22
|
Every GUI toolkit I have looked at has its own system / notation for managing layouts (resizing, alignment, margins and so on). Is there any kind of public standard for application GUI layout, similar to say the W3 CSS standards for web documents (box properties, block elements, etc). The closest thing I have been able to find so far is XUL: http://www.mozilla.org/projects/xul/layout.html but this is not really a public "standard". I would even be willing to look at "proprietary" standards as long as they are published and widely recognized. Regards, Donnal Walter |
From: Magnus L. H. <ma...@he...> - 2005-08-08 15:27:13
|
Donnal Walter <don...@ya...>: > [snip] > > http://www.mozilla.org/projects/xul/layout.html > > but this is not really a public "standard". I would even be willing > to look at "proprietary" standards as long as they are published > and widely recognized. In that case it would seem that XUL would fit the bill...? Isn't it an open and widely recognized standard? Maybe not as in "this is what you must do to do layout" but as in "this is one of the de facto standards when specifying layout in a data file" (as opposed to using a programming language API). -- Magnus Lie Hetland Fall seven times, stand up eight http://hetland.org [Japanese proverb] |
From: Peter D. <pd...@gm...> - 2005-08-08 12:50:55
|
On Mon, 08 Aug 2005 13:41:12 +0300, Magnus Lie Hetland <ma...@he...> wrote: > Peter Damoc <pd...@gm...>: >> > [snip] >> I'm for the QT like approach NOT the wxWidgets one. > > So this would be like Java Swing? (Just checking.) hmm... I don't know all that much about Swing but I think it will differ from their approach. :) IIRC Swing draws the interface elements using Java code. I'm more for moving all the low level drawing to an optimised C/C++ renderer. > [snip] >> This is in my view the best approach: Implement as much as possible >> in python and reuse some of the code from one of those projects >> altho it might not be all that easy to "extract" the necessary bits >> from their source tree. > > Sounds like a sound enough approach, I guess. > >> The idea is to forgo all the unnecessary, C++ related bits from the >> toolkit that have counterparts in python and keep only the minimum. > > IIRC, one of your questions was what you could reuse from Anygui? > > To begin with, I guess you could simply write a back-end using your > approach -- but many of the Anygui mechanisms would be highly > unnecessary (i.e., the whole front-end/back-end stuff). The event > handling stuff could perhaps be useful, and maybe some of the > model/observable stuff... > I'll look at them. Peter. |
From: Peter D. <pd...@gm...> - 2005-08-08 08:53:00
|
On Fri, 05 Aug 2005 17:41:27 +0300, Magnus Lie Hetland <ma...@he...> wrote: > Peter Damoc <pd...@gm...>: [snip] >> As a programmer I would like to have is an OSS python GUI toolkit >> that looks great everywhere and acts the same on all platforms >> without custom hack in the app code. > > I agree. Nowadays I think wxPython and PyQt seem like promising > candidates, actually. wxPython rocks! it is the best OSS has to offer right now (personal opinion) > One option to look out for in the future is Greg's PyGUI: > > http://www.cosc.canterbury.ac.nz/~greg/python_gui I will take another look at this. :) > [snip] >> Now to the real question of this email. >> What should a crazy enough person do to try and build such a >> toolkit? How could he reuse the work that went into AnyGUI? > > Hm. Much of the code (and blood, sweat and tears) of Anygui deals with > the front-end/back-end stuff -- and if you want to implement the > actual GUI stuff yourself, I guess you could just scrap all that. If > you want to keep this mechanism, you could probably build on what's > there... > > But if you don't want a pure-Python layer that sits on top of other > packages (not sure if you do or not ;) -- why not simply use a > packages such as wxPython? It seems to have the BDFLs blessing, so... > I am a wxPython user! for the past 18 months I've used nothing else, however it feels "heavy". The simple HelloWorld is around 11-12 Mb when packaged with py2exe. Peter. |
From: Magnus L. H. <ma...@he...> - 2005-08-08 08:58:09
|
Peter Damoc <pd...@gm...>: > [snip] > I am a wxPython user! for the past 18 months I've used nothing else, > however it feels "heavy". > The simple HelloWorld is around 11-12 Mb when packaged with py2exe. How big is "print 'Hello, world!'" when you package it with py2exe? (Just curious...) -- Magnus Lie Hetland Fall seven times, stand up eight http://hetland.org [Japanese proverb] |
From: Peter D. <pd...@gm...> - 2005-08-08 09:35:43
|
On Mon, 08 Aug 2005 11:57:56 +0300, Magnus Lie Hetland <ma...@he...> wrote: > Peter Damoc <pd...@gm...>: >> > [snip] >> I am a wxPython user! for the past 18 months I've used nothing else, >> however it feels "heavy". >> The simple HelloWorld is around 11-12 Mb when packaged with py2exe. > > How big is "print 'Hello, world!'" when you package it with py2exe? > (Just curious...) > Around 2 Mb (2.14) so the rest is wxPython :) Peter. |
From: Magnus L. H. <ma...@he...> - 2005-08-08 09:40:15
|
Peter Damoc <pd...@gm...>: > [snip] > > Around 2 Mb (2.14) so the rest is wxPython :) Wow -- that *is* heavy :) -- Magnus Lie Hetland Fall seven times, stand up eight http://hetland.org [Japanese proverb] |
From: Greg E. <gre...@ca...> - 2005-08-12 04:56:34
|
Peter Damoc wrote: > If the feel is implemented using the best approach (think OSX) users on > other systems won't mind. The notion of "best" is observer-dependent. I don't think it's a matter of "best", anyway, but of things behaving consistently with other applications on the platform. If the user is accustomed to certain menu items being in certain places or having certain key equivalents, for example, it's annoying when some applications do things differently. I think appearance is important to many people, too. Mac users in particular tend to be unimpressed by apps which look un-Mac-like. It gives an impression of shoddiness, of having been ported from somewhere else in a quick and dirty way, which doesn't help to engender a feeling of trust in it. Maybe Windows users are less discerning, I don't know. But I wouldn't like to foist an Aqua-looking app on a Windows user. If I'm to ask that Mac apps look Mac-like, I feel I owe them the same courtesy. Although if Longhorn turns out to rip off Aqua closely enough, maybe this will cease to be an issue... :-) -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | gre...@ca... +--------------------------------------+ |