anygui-devel Mailing List for anygui - Generic GUI Module for Python (Page 4)
Brought to you by:
mlh
Menu
▾
▴
anygui-devel — Discussions about the development of the Anygui package
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(8) |
Jul
(286) |
Aug
(438) |
Sep
(326) |
Oct
(392) |
Nov
(494) |
Dec
(591) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(247) |
Feb
(228) |
Mar
(85) |
Apr
(41) |
May
(82) |
Jun
(28) |
Jul
(117) |
Aug
(114) |
Sep
(119) |
Oct
(34) |
Nov
(85) |
Dec
(5) |
| 2003 |
Jan
(17) |
Feb
(27) |
Mar
(30) |
Apr
(19) |
May
(20) |
Jun
(4) |
Jul
(6) |
Aug
(11) |
Sep
(6) |
Oct
(2) |
Nov
(6) |
Dec
(5) |
| 2004 |
Jan
|
Feb
(57) |
Mar
(5) |
Apr
(30) |
May
|
Jun
(2) |
Jul
(3) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(3) |
| 2005 |
Jan
|
Feb
|
Mar
(3) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
(20) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Matthew S. <ma...@nu...> - 2004-02-25 07:14:23
|
On 21/02/2004, at 12:09 AM, Alex Martelli wrote: > On Friday 20 February 2004 01:27 pm, Matthew Schinckel wrote: > ... >> There is already a group of (apple supplied?) shared libraries that >> provide a Carbon interface. This is on standard python OSX install. > > I think you mean CoreGraphics? That's more like Quartz, lower level > than > Carbon. Or what else do you mean...? > Try (within python): from Carbon import Win, Windows win = Win.CreateNewWindow(6, 0, (10,50,150,180)) win.MacShowWindow() (you'll need to Ctrl-D to exit - i can't figure out how to get the window to receive mouse-clicks, yet) >> I need to source the Learning Carbon and/or Learning Cocoa books from >> O'Reilly, since I can't stay connected to the internet to look at >> Apple's docs all day and night. > > When you install Apple's free Developer Tools you get all the docs > installed > too, and can read them on your Mac. I downloaded the 600 MB of the > latest > XCode CD (a bit more updated than what you get with Panther itself, > 1.1 I > believe). But whether you get that or the plain Developer Tools CD > that > comes with Panther, install it and start reading > /Developer/Documentation/* . > Budget a couple months...:). > Yeah, I found the docs. Stupid me to miss them. I'm (see my reply to Magnus here) working by comparing Carbon to BeOS, in terms of the API. >> Someone has created a Python thingo for Xcode, Apple's Development >> Environment. This might allow for direct creation of MacOS X apps in >> python! (Sorry, i got excited about that bit!) > > URL? I haven't heard about this one... > Sorry. Here you go: http://pythonmac.org/wiki/XcodeIntegration http://www.ulaluma.com/pyx/archives/000956.html I don't actually know how to use Xcode, or most IDEs really. I cut my C teeth under a pure CLI unix interface 10 years ago, and since I don't code for a living (I'm a high school teacher, and mainly teach CAD), haven't really bothered to improve my skills, other than to learn python. >> Apple have included stuff for Quartz access, which allows for graphics >> handling, but, IIUC (if I understand correctly) not for UI stuff. > > The CoreGraphics, again? Right, i don't think you get UI events there. Yeah, I found a link to a guy who used Python/Quartz for image manipulation - there wasn't much info on the site, but look in: /Developer/Examples/Quartz/Python/ (After actually looking in there, yes, CoreGraphics stuff I don't like they way Apple use Deutschesprechen (combining words with stuff, like kCGLineCapRound), it doesn't look pythonic to me... Matt. -- Matt Schinckel <ma...@nu...> |
|
From: Matthew S. <ma...@nu...> - 2004-02-25 07:01:02
|
On 21/02/2004, at 2:47 AM, Magnus Lie Hetland wrote: > Just a note: A cocoa back-end would be nice, but, as mentioned, I > think it would be more useful for the project, at present, if you put > some work into the core back-ends. (But if the choice is between work > on cocoa and nothing -- then, by all means, work on cocoa; at least > we'll get the front-end tested :) I take it this was (partly?) aimed at me;) I will do some testing with the other backends, (ie, I agree with you on that point). but I really do want to do some native carbon/cocoa stuff - just because I want to contrast OSX with BeOS, more than anything else. btw, at this stage BeOS is coming out ahead...except for the lack of apps - and the lack of a machine for me to run it on. -- Matt Schinckel <ma...@nu...> |
|
From: Magnus L. H. <ma...@he...> - 2004-02-20 20:37:15
|
Sascha Silbe <sas...@si...>: > > On Fri, Feb 20, 2004 at 05:20:44PM +0100, Magnus Lie Hetland wrote: > > [set of testers for (widget set, platform)] > >I think, however, that testing that the various APIs have been used > >appropriately is something that we need to test first and foremost. > > What exactly (and possibly in detail) do you mean? OK -- sorry to be unclear. As far as I can see, there are two different issues here: (1) testing that things look OK (and work OK) on different platforms, and (2) testing that things work at all (i.e. that the APIs, e.g. the wx API, are being used correctly). It seems to me that as long as the back-end is truly cross-platform (e.g. a proper wxPython program will work independently of platform) issue 2 can be dealt with by testing each back-end on any one platform. Also, I meant that issue 2 seems to be more fundamental, in my view, so that even if we can't get all back-ends tested on all platforms, it's important to at least have tested all back-ends on *some* platforms. But it may be that I misunderstood your point. Perhaps there are more important issues that need to be checked by running a given back-end on all platforms. Anyway: One of the advantages of open source development is the possibility of incorporating patches or bug reports from users; so if we're satisfied that the back-ends work, platform-specific bugs that are discovered after a release can be fixed then... (This goes for all kinds of bugs, of course.) If you have ideas for a different division of labour, that's interesting of course. We could certainly all test all the back-ends on our own platforms -- but since there is quite a bit of work with dealing with each back-end, I assumed this would be an unrealistic workload. (Everyone is rather busy here, it seems :) > CU Sascha -- Magnus Lie Hetland "The mind is not a vessel to be filled, http://hetland.org but a fire to be lighted." [Plutarch] |
|
From: Magnus L. H. <ma...@he...> - 2004-02-20 16:27:55
|
Sascha Silbe <sas...@si...>: > > On Fri, Feb 20, 2004 at 12:31:42AM +0100, Magnus Lie Hetland wrote: > > > wx: Magnus (already works -- just verification) > > msw: Matt > > qt: Alex, Fabio > > tk: Magnus > > java: Terry > What's especially needed is a set of testers for those widget sets on > different platforms. That would definitely be beneficial. I think, however, that testing that the various APIs have been used appropriately is something that we need to test first and foremost. > I develop under Linux and have normal-user access to FreeBSD/x86, > Solaris, AIX/ppc and possibly Linux/ppc hosts, but I cannot really > test my changes under Windows (only via a very slow Terminal Server > as a normal user, but some widget sets need Admin privileges for > installation), MacOS and so on. Yeah, I see. The more combinations of back-end/platform we can test, the better, of course. > CU/Lnx Sascha -- Magnus Lie Hetland "The mind is not a vessel to be filled, http://hetland.org but a fire to be lighted." [Plutarch] |
|
From: Magnus L. H. <ma...@he...> - 2004-02-20 16:23:42
|
Just a note: A cocoa back-end would be nice, but, as mentioned, I think it would be more useful for the project, at present, if you put some work into the core back-ends. (But if the choice is between work on cocoa and nothing -- then, by all means, work on cocoa; at least we'll get the front-end tested :) -- Magnus Lie Hetland "The mind is not a vessel to be filled, http://hetland.org but a fire to be lighted." [Plutarch] |
|
From: Magnus L. H. <ma...@he...> - 2004-02-20 16:20:49
|
Kalle Svensson <ka...@ly...>: > > [Magnus Lie Hetland] > > So: If there are people out there who want to work on other back-ends > > (Kalle -- do you feel gtkgui beckoning? ;) then that would be nice. > > Well, actually I do, a bit. But I couldn't honestly say that I have > time to put into developing it. University-related activities takes > almost all my free time these days, plus I'm trying to cut down on the > time I spend in front of computers to save my wrists (and my mind). I understand. > So, it's time for me to step down as gtkgui maintainer. It's been > great working with you! Same here! > Peace, > Kalle -- Magnus Lie Hetland "The mind is not a vessel to be filled, http://hetland.org but a fire to be lighted." [Plutarch] |
|
From: Magnus L. H. <ma...@he...> - 2004-02-20 16:19:30
|
Robin Becker <ro...@re...>: > > I'm fairly sure that I won't be maintainining the ctypes back end at > this time. I'm almost sure that the ctypes one (and probably msw) > suffers from leakage caused by the event loop re-entering etc etc. > > Probably the person who should have been doing that work is Thomas, but > he's already moved else where. I'm certainly not expert enough at the > analysis to figure out where we ought to grab GILS. Maybe ctypes/msw should be left out for now, too? In that case we're left with wx, qt, tk and java. Maybe not such a bad selection? tk, qt and wx work on most platforms, anyway, so one of our main contributions would (as mentioned) be to present a very simple API, as well as covering java (which is *not* covered by the others). It's a pity, as mswgui seems to be working rather well, but I guess we need to be realistic if there is to be any hope of not just stranding again. Matt: What would you like to work with if we leave msw out of the equation (given the distribution of other people)? -- Magnus Lie Hetland "The mind is not a vessel to be filled, http://hetland.org but a fire to be lighted." [Plutarch] |
|
From: Robin B. <ro...@re...> - 2004-02-20 15:55:34
|
I'm fairly sure that I won't be maintainining the ctypes back end at this time. I'm almost sure that the ctypes one (and probably msw) suffers from leakage caused by the event loop re-entering etc etc. Probably the person who should have been doing that work is Thomas, but he's already moved else where. I'm certainly not expert enough at the analysis to figure out where we ought to grab GILS. -- Robin Becker |
|
From: Samuele P. <ped...@bl...> - 2004-02-20 15:08:10
|
At 23:29 15.02.2004 +0100, Magnus Lie Hetland wrote: >I have now finished my Ph.D and have more or less settled into my new >(for now, temporary) research/teaching position, and it might be time >to see if it's feasible to get 0.2 out there. I was sort of spurred on >by the somewhat bitter postings about Anygui (and me) on >comp.lang.python recently (although I'm not sure whether to be >motivated or demotivated) -- but the question is, what is a realistic >assessment of Anygui's future? > >So: > > 1. Who are interested in continuing some work on Anygui? > I would, but right now I have no time > 2. Do you have any strategy suggestions? > > How could we structure our process to make it easier to keep the > project going? How about the project objectives? |
|
From: Wezzy <we...@ya...> - 2004-02-20 15:06:11
|
Il giorno 20/feb/04, alle 13:27, Matthew Schinckel ha scritto: > There are no stupid questions, only stupid answers... > > I've spent the last couple of hours looking for info about the MacOS > interface(s). Here is my summary: > > There is already a group of (apple supplied?) shared libraries that > provide a Carbon interface. This is on standard python OSX install. > (?) > I'm not sure if there is a similar thing for Cocoa. > I'm still learning the difference ;) > [edit]Cocoa might be better, since Carbon is partly a legacy thing, > but Carbon apps might run in OS9. Care?[/edit] > I need to source the Learning Carbon and/or Learning Cocoa books from > O'Reilly, since I can't stay connected to the internet to look at > Apple's docs all day and night. If you install XCode CD you've got all the apple documentation and some tutorial for Cocoa's beginners ( ithink that thare are also Carbon tutorials but i've never studied Carbon). I have two books about Cocoa : Learning Cocoa With Objective-C from O'Reilly Cocoa Programming from Sams. The first is an introduction for beginners, it is a good book really easy that explains lot of concepts but if you don't have any problem with studing on screen you can read the same information into the /Developer/Documentation directory. The second is a reference, it is really good because it have a lot of triks and useful suggestion. > Someone has created a Python thingo for Xcode, Apple's Development > Environment. This might allow for direct creation of MacOS X apps in > python! (Sorry, i got excited about that bit!) With pyobjc you have some scripts that create OS X app. > PyObjC exists also. (Allows use of Objective-C [MacOS X standard > language] bits in python) Probably this is the best choice. If you learn Cocoa with ObjC translate the code into Python is very easy and your scripts looks like a native application. As you noticed with Cocoa we loose os9 support but i also Apple doesn't support it. > Apple have included stuff for Quartz access, which allows for graphics > handling, but, IIUC (if I understand correctly) not for UI stuff. You don't have to use Quarts directly for GUI. Cocoa (or Quartz) hides it and helps you a lot with GUI. > [OT]Running limewire causes safari to fail on dns lookups.[/OT] > pythonmac.wiki.org has some good information... > The best resource for Cocoa is Cocoa-dev ML, look at Apple Developer site. I've done some experiment with cocoa application without nibs. Building Cocoa Application (http://www.oreilly.com/catalog/buildcocoa/index.html?CMP=IL7015) explains how to create an app only with code (without IB). i've downloaded chapter's examples and translate them. I hope that they can be a useful resource. Fabio "Wezzy" Trezzi |
|
From: Alex M. <al...@ya...> - 2004-02-20 15:01:49
|
On Friday 20 February 2004 01:27 pm, Matthew Schinckel wrote: ... > There is already a group of (apple supplied?) shared libraries that > provide a Carbon interface. This is on standard python OSX install. I think you mean CoreGraphics? That's more like Quartz, lower level than Carbon. Or what else do you mean...? > I need to source the Learning Carbon and/or Learning Cocoa books from > O'Reilly, since I can't stay connected to the internet to look at > Apple's docs all day and night. When you install Apple's free Developer Tools you get all the docs installed too, and can read them on your Mac. I downloaded the 600 MB of the latest XCode CD (a bit more updated than what you get with Panther itself, 1.1 I believe). But whether you get that or the plain Developer Tools CD that comes with Panther, install it and start reading /Developer/Documentation/* . Budget a couple months...:). O'Reilly's books are surely also good, but right now I can only read them on safari.oreilly.com (no connection w/the Safari browser), so _those_ are the ones which would require me to keep connected. > Someone has created a Python thingo for Xcode, Apple's Development > Environment. This might allow for direct creation of MacOS X apps in > python! (Sorry, i got excited about that bit!) URL? I haven't heard about this one... > PyObjC exists also. (Allows use of Objective-C [MacOS X standard > language] bits in python) Yes, and particularly Cocoa user interfaces -- that's mostly what it's for. > Apple have included stuff for Quartz access, which allows for graphics > handling, but, IIUC (if I understand correctly) not for UI stuff. The CoreGraphics, again? Right, i don't think you get UI events there. > [OT]Running limewire causes safari to fail on dns lookups.[/OT] > pythonmac.wiki.org has some good information... > > More later - I've got stuff to play with now... Don't we all...;-). Alex |
|
From: Kalle S. <ka...@ly...> - 2004-02-20 14:05:05
|
[Magnus Lie Hetland] > So: If there are people out there who want to work on other back-ends > (Kalle -- do you feel gtkgui beckoning? ;) then that would be nice. Well, actually I do, a bit. But I couldn't honestly say that I have time to put into developing it. University-related activities takes almost all my free time these days, plus I'm trying to cut down on the time I spend in front of computers to save my wrists (and my mind). So, it's time for me to step down as gtkgui maintainer. It's been great working with you! Peace, Kalle -- Kalle Svensson, http://www.juckapan.org/~kalle/ Student, root and saint in the Church of Emacs. |
|
From: Matthew S. <ma...@nu...> - 2004-02-20 13:06:33
|
On 20/02/2004, at 5:50 PM, Matthew Schinckel wrote: > > On 17/02/2004, at 7:33 AM, Magnus Lie Hetland wrote: > >> Wezzy <we...@ya...>: >>> >>> Il giorno 16/feb/04, alle 14:57, Magnus Lie Hetland ha scritto: >>>> >>>> What do you think? >>> >>> I think that starting with simple objectives is a good idea. i'm >>> also agreed with you to reduce the backends' list, but i think that >>> a native cocoa backend should be a good improvement. > > [snip] > >> What is the general feeling about this? Matt and Alex -- you're OS X >> guys; what do you think? Perhaps this is the sort of thing you were >> envisioning? > > Yeah, I'd like to see (relatively) native hooks to the cocoa gui, but > I'm not sure how easy this is. I've downloaded a couple of tools that > are designed to interface directly with cocoa and bash scripts (or > even python, IIRC), and might look into these. > Hate to be a tool and reply to myself, but...fabio & alex, don't bother with iHook and Platypus, they are too limited, and not useful for our purposes (IMHO). -- Matt Schinckel <ma...@nu...> |
|
From: Matthew S. <ma...@nu...> - 2004-02-20 12:36:04
|
On 20/02/2004, at 10:52 AM, Wezzy wrote: > Il giorno 20/feb/04, alle 00:32, Magnus Lie Hetland ha scritto: > >> qt: Alex, Fabio > > I hope that i can help Alex but i am a total newbie of qt. Anyway > studing qt is one of my short period project so i'm happy to > participate :-) > >> Fabio: If you'd like to look into a cocoa back-end, feel free to do >> so. >> > > Very well, i'm doing some test and collecting information, i hope to > start the backend untill the next week. Probably i'll overload this ML > with a lot of stupid question :-) > There are no stupid questions, only stupid answers... I've spent the last couple of hours looking for info about the MacOS interface(s). Here is my summary: There is already a group of (apple supplied?) shared libraries that provide a Carbon interface. This is on standard python OSX install. (?) I'm not sure if there is a similar thing for Cocoa. I'm still learning the difference ;) [edit]Cocoa might be better, since Carbon is partly a legacy thing, but Carbon apps might run in OS9. Care?[/edit] I need to source the Learning Carbon and/or Learning Cocoa books from O'Reilly, since I can't stay connected to the internet to look at Apple's docs all day and night. Someone has created a Python thingo for Xcode, Apple's Development Environment. This might allow for direct creation of MacOS X apps in python! (Sorry, i got excited about that bit!) PyObjC exists also. (Allows use of Objective-C [MacOS X standard language] bits in python) Apple have included stuff for Quartz access, which allows for graphics handling, but, IIUC (if I understand correctly) not for UI stuff. [OT]Running limewire causes safari to fail on dns lookups.[/OT] pythonmac.wiki.org has some good information... More later - I've got stuff to play with now... -- Matt Schinckel <ma...@nu...> |
|
From: Matthew S. <ma...@nu...> - 2004-02-20 07:34:06
|
On 17/02/2004, at 10:33 AM, Greg Ewing wrote: > Magnus: > >> But I keep getting emails from people who say that Anygui is a >> "Good Idea(tm)" > > Perhaps those are the people who want an API that's small, simple and > Pythonic, as opposed to big, complicated and warped in the direction > of some other language such as C++ or Tcl. > > That's the goal of my own Python GUI project (which I *am* still > working on, by the way, despite appearances to the contrary!). > > My goals aren't quite the same as AnyGUI's, because I only intend to > provide *one* implementation for each platform, preferably built as > directly as possible on whatever is provided natively, so that users > don't have to install any extra packages. > yeah, I agree about having an (extremely) simple UI interface (and I mean that, a User Interface Interface!), and I actually, as a basis for Anygui/beosgui wrote a wrapper around each of the BeOS API classes, doing things like giving them decent defaults, and subclassing them (rather, superclassing them, I suppose). It actually meant I could write a GUI wrapper for a program with about 5 lines, including window, buttons, textbox, labels/textareas. (maybe a slight exaggeration, but the programming was the main bit, not the gui coding). Now, if I can see if I can find the simplegui.py files I created in a backup somewhere, since I wiped clean all of the hard disks connected to my old mac in order to try and sell her... Matt. -- Matt Schinckel <ma...@nu...> |
|
From: Matthew S. <ma...@nu...> - 2004-02-20 07:29:02
|
On 17/02/2004, at 7:33 AM, Magnus Lie Hetland wrote: > Wezzy <we...@ya...>: >> >> Il giorno 16/feb/04, alle 14:57, Magnus Lie Hetland ha scritto: >>> >>> What do you think? >> >> I think that starting with simple objectives is a good idea. i'm >> also agreed with you to reduce the backends' list, but i think that >> a native cocoa backend should be a good improvement. [snip] > What is the general feeling about this? Matt and Alex -- you're OS X > guys; what do you think? Perhaps this is the sort of thing you were > envisioning? Yeah, I'd like to see (relatively) native hooks to the cocoa gui, but I'm not sure how easy this is. I've downloaded a couple of tools that are designed to interface directly with cocoa and bash scripts (or even python, IIRC), and might look into these. Of course, they may be designed simply for creating stand-alone MacOSX apps, but we'll see. Since all MacOSX installations newer than 10.2 come with a new (2.3) python, I'm all for making a really easy interface for use, and if it happens to be anygui (see my coming comments on Greg's post(s)) then all the better. Matt. -- Matt Schinckel <ma...@nu...> |
|
From: Wezzy <we...@ya...> - 2004-02-20 00:28:36
|
Il giorno 20/feb/04, alle 00:32, Magnus Lie Hetland ha scritto: > qt: Alex, Fabio I hope that i can help Alex but i am a total newbie of qt. Anyway studing qt is one of my short period project so i'm happy to participate :-) > Fabio: If you'd like to look into a cocoa back-end, feel free to do > so. > Very well, i'm doing some test and collecting information, i hope to start the backend untill the next week. Probably i'll overload this ML with a lot of stupid question :-) Fabio "Wezzy" Trezzi |
|
From: Magnus L. H. <ma...@he...> - 2004-02-19 23:43:02
|
My focus on the "big five" back-ends (I'm just assuming they're the "biggest" -- no offense meant to the others) doesn't mean that I don't want the others in Anygui, of course. I'm just trying to set realistic goals. So: If there are people out there who want to work on other back-ends (Kalle -- do you feel gtkgui beckoning? ;) then that would be nice. The main point is that if we *don't* get the others done, that shouldn't hold us back from releasing. beosgui is pretty much dead in the water now, as Matt doesn't have a beos machine anymore, so the remaining ones are cursesgui, textgui and gtkgui. (gtkgui actually sort of works.) -- Magnus Lie Hetland "The mind is not a vessel to be filled, http://hetland.org but a fire to be lighted." [Plutarch] |
|
From: Magnus L. H. <ma...@he...> - 2004-02-19 23:37:56
|
OK... I've tried a couple of times before (during the hiatus after our
previous frenetic stint of development) to allocate some tasks, but
haven't been to successful. Nevertheless, I'll try again, based on the
feedback I've gotten so far. Who knows -- maybe we can get a teensy
weensy step further?
What we need first is debugging, using the existing test suite (or
similar functionality) -- consult the nondist/admin/status.txt file
for the relevant tests and the current test status.
The following is a suggested temporary (hopefully until the next release, at
least) allocation of responsibility for testing. The responsibility
entails:
- Testing the back-end when called for (not necessarily promptly...
:)
- Trying to identify and localize bugs as clearly and precisely as
possible
If you're able to *fix* the bug, that's great -- if not, simply
pointing it out so someone else can take a whack at it (and then have
you test it again, with your set-up/back-end) then that's fine.
Here is my suggested allocation (for this release):
wx: Magnus (already works -- just verification)
msw: Matt
qt: Alex, Fabio
tk: Magnus
java: Terry
I just boldly added Terry here, since he seemed to be interested in
the Python/Jython-crossover potential for Anygui.
Matt and Alex: Feel free to pair-program on qt or whatever else, of
course.
Fabio: If you'd like to look into a cocoa back-end, feel free to do
so.
If there are others who'd like to double up on the testing and
bugfixing here (remember that simply testing and pinpointing bugs is
*very* helpful, even if you don't actually fix them), just say so.
Or... Just jump in and test as you feel like it. At present, we just
need to make the best use of the (overworked) resources we have, so
there's no point in overstructuring, I guess.
Sorry for the slightly verbose email -- I guess you'll be able to pick
out the indented paragraphs that really matter ;)
Feedback appreciated -- especially if the suggested allocation doesn't
work.
--
Magnus Lie Hetland "The mind is not a vessel to be filled,
http://hetland.org but a fire to be lighted." [Plutarch]
|
|
From: Magnus L. H. <ma...@he...> - 2004-02-19 23:24:03
|
Greg Ewing <gr...@co...>: > > Magnus: > > > But I keep getting emails from people who say that Anygui is a > > "Good Idea(tm)" > > Perhaps those are the people who want an API that's small, simple > and Pythonic, as opposed to big, complicated and warped in the > direction of some other language such as C++ or Tcl. That may well be. Just today, I talked to a guy (locally, at my university) who had started using Anygui for a project. I mentioned to him that there hadn't been much progress lately, and that if he was aiming for completeness, he might want to consider some bigger toolkit. His reply was basically twofold: "(1) but it works! and (2) it's so simple!" So Anygui isn't dead... > That's the goal of my own Python GUI project (which I *am* still > working on, by the way, despite appearances to the contrary!). Something one could say about several projects, I suppose :) > My goals aren't quite the same as AnyGUI's, because I only intend to > provide *one* implementation for each platform, preferably built as > directly as possible on whatever is provided natively, so that users > don't have to install any extra packages. I think that sounds great too. If you could get it into the standard library somehow -- now *that* would be neat. > However, there's a lot in common between the goals of our respective > projects in terms of providing a simple, standardised, Pythonic API, > which I still believe is sorely lacking in the Python world. Yup. (Just answered this in another email -- I guess I'm reading stuff backwards today.) > We also seem to share the trait of having been in a > not-quite-released state for some time. :-) <ahem>. Yes. > It will be interesting to see which of us manages to release > something useful first! Indeed. Either way, it'll be a victory for the Pythonic GUI API :) -- Magnus Lie Hetland "The mind is not a vessel to be filled, http://hetland.org but a fire to be lighted." [Plutarch] |
|
From: Magnus L. H. <ma...@he...> - 2004-02-19 23:20:35
|
Donnal Walter <don...@ya...>:
>
> Greg Ewing wrote:
> > Perhaps those are the people who want an API
> > that's small, simple and Pythonic, as opposed
> > to big, complicated and warped
>
> My two cents may be irrelevant to the long terms goals of Anygui,
> but since it seems that we are in a brainstorming mode here, I'll
> toss them in anyway.
Sure.
> My ultimate goal is to establish a framework for the rapid
> development of custom, data-centric, GUI-based, clinical
> applications. (The "clinical" part is optional, of course. :-)
Sounds interesting.
> What I have in mind is an abstraction-presentation architecture
> that consists of two separate layers: an abstraction layer for
> modeling the data structures of the application, and a presentation
> layer for defining the user interface. I have put most of my effort
> so far on the abstraction layer, working out a notation (an API)
> for defining data structures of (theoretically) limitless
> complexity with both independent and dependent elements. The
> abstraction layer is to include a built-in persistence mechanism.
Sounds pretty fancy :)
[snip]
> My interest in Anygui is precisely what Greg Ewing stated above, an
> API that is small, simple and (possibly) Pythonic. I say "possibly"
> Pythonic because my abstraction layer uses a notation that is not
> exactly traditional Python syntax.
>
> <OT>
> For example,
> __init__(self, ...) is replaced by
> Assemble(self, ...)
>
> And
> self.myname = Someclass(parent=self) is replaced by
> self.Add('myname', Someclass)
> </OT>
Well, this is still Pythonic enough, I'd say...
[snip]
> A small, clean approach is attractive.
Sounds good -- as long as Anygui isn't *too* simple.
> Greg Ewing continued:
> > My goals aren't quite the same as AnyGUI's, because ...
> > ...
> > However, there's a lot in common between the goals
> > of our respective projects in terms of providing a
> > simple, standardised, Pythonic API, which I still
> > believe is sorely lacking in the Python world.
>
> I agree wholeheartedly!
Indeed. That's one of the two main reasons why I started Anygui -- the
other reason was what I perceived as a good idea, i.e. the multiple
back-end thing.
> Donnal Walter
> Arkansas Children's Hospital
--
Magnus Lie Hetland "The mind is not a vessel to be filled,
http://hetland.org but a fire to be lighted." [Plutarch]
|
|
From: Magnus L. H. <ma...@he...> - 2004-02-19 23:15:37
|
Niki Spahiev <ni...@vi...>: > > Terry Hancock wrote: > > >The other issue, of course, is that I will want graphics as well as > >"widgets", > >so there will need to be a portable "canvas" type object. Last time I > >looked at AnyGUI that part wasn't figured out yet. > > > > Drawbot looks very promising and easy to port. > > http://effbot.org/zone/drawbot.htm Oops -- I guess I got some postings crossed here -- read Terry's mail about drawbot *before* I saw his stated need for graphics here. I actually mentioned drawbot myself earlier (I think?) -- hence the confusion. So: Terry, if you need graphics, you should definitely feel free to work on getting it into the codebase. That's the way things get done; by people who need them :) It would be nice if you considered the pros and cons of the current sping-based API and the DrawBot API (which, I believe, does not support text?) and posted something about it here, maybe? > Niki Spahiev -- Magnus Lie Hetland "The mind is not a vessel to be filled, http://hetland.org but a fire to be lighted." [Plutarch] |
|
From: Magnus L. H. <ma...@he...> - 2004-02-19 23:10:42
|
Terry Hancock <ha...@an...>: > > On Thursday 19 February 2004 04:15 am, Niki Spahiev wrote: > > Terry Hancock wrote: > > > The other issue, of course, is that I will want graphics as well as "widgets", > > > so there will need to be a portable "canvas" type object. Last time I > > > looked at AnyGUI that part wasn't figured out yet. > > > > Drawbot looks very promising and easy to port. > > http://effbot.org/zone/drawbot.htm > > Yes it does look interesting. Are you suggesting that that could become > the canvas API for AnyGUI? I don't know... I guess I'm just suggesting that we consider it as an option -- or as a possible model. The Piddle/Sping way may still be useful, though. > Should I put that on my todo list? ;-) Well... If you want to implement a Canvas, I won't stop you :) (You might want to take a look at the existing (*very* preliminary) code for Canvas -- although we don't have to use that.) On the other hand: If you have time to spare, consider taking a look at the status.txt file in nondist/admin and see if you can localize some of the bugs in (for example) qtgui, mswgui or javagui... I know it may not be as exciting, though ;) Also: I still think that (1) menus and (2) basic dialogs are the only core objectives (in addition to the ever tedious testing and debugging it seems we can never get done...) > I kind of like the fact that there's not a whole lot of primitives > -- suggesting > that you could do a small back end and have most of the fancier > stuff in common. Indeed. That is also the idea of Piddle/Sping, though -- you just have to implement four (IIRC) methods, and (again, IIRC) these can really be boiled down to three... > Cheers, > Terry -- Magnus Lie Hetland "The mind is not a vessel to be filled, http://hetland.org but a fire to be lighted." [Plutarch] |
|
From: Terry H. <ha...@an...> - 2004-02-19 18:31:16
|
On Thursday 19 February 2004 04:15 am, Niki Spahiev wrote: > Terry Hancock wrote: > > The other issue, of course, is that I will want graphics as well as "= widgets", > > so there will need to be a portable "canvas" type object. Last time I > > looked at AnyGUI that part wasn't figured out yet. >=20 > Drawbot looks very promising and easy to port. > http://effbot.org/zone/drawbot.htm Yes it does look interesting. Are you suggesting that that could become the canvas API for AnyGUI? Should I put that on my todo list? ;-) I kind of like the fact that there's not a whole lot of primitives -- sug= gesting that you could do a small back end and have most of the fancier stuff in common. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com |
|
From: Niki S. <ni...@vi...> - 2004-02-19 10:21:39
|
Terry Hancock wrote: > The other issue, of course, is that I will want graphics as well as "widgets", > so there will need to be a portable "canvas" type object. Last time I > looked at AnyGUI that part wasn't figured out yet. > Drawbot looks very promising and easy to port. http://effbot.org/zone/drawbot.htm Niki Spahiev |
17 messages has been excluded from this view by a project administrator.