You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(116) |
Sep
(146) |
Oct
(78) |
Nov
(69) |
Dec
(70) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(188) |
Feb
(142) |
Mar
(143) |
Apr
(131) |
May
(97) |
Jun
(221) |
Jul
(127) |
Aug
(89) |
Sep
(83) |
Oct
(66) |
Nov
(47) |
Dec
(70) |
2003 |
Jan
(77) |
Feb
(91) |
Mar
(103) |
Apr
(98) |
May
(134) |
Jun
(47) |
Jul
(74) |
Aug
(71) |
Sep
(48) |
Oct
(23) |
Nov
(37) |
Dec
(13) |
2004 |
Jan
(24) |
Feb
(15) |
Mar
(52) |
Apr
(119) |
May
(49) |
Jun
(41) |
Jul
(34) |
Aug
(91) |
Sep
(169) |
Oct
(38) |
Nov
(32) |
Dec
(47) |
2005 |
Jan
(61) |
Feb
(47) |
Mar
(101) |
Apr
(130) |
May
(51) |
Jun
(65) |
Jul
(71) |
Aug
(96) |
Sep
(28) |
Oct
(20) |
Nov
(39) |
Dec
(62) |
2006 |
Jan
(13) |
Feb
(19) |
Mar
(18) |
Apr
(34) |
May
(39) |
Jun
(50) |
Jul
(63) |
Aug
(18) |
Sep
(37) |
Oct
(14) |
Nov
(56) |
Dec
(32) |
2007 |
Jan
(30) |
Feb
(13) |
Mar
(25) |
Apr
(3) |
May
(15) |
Jun
(42) |
Jul
(5) |
Aug
(17) |
Sep
(6) |
Oct
(25) |
Nov
(49) |
Dec
(10) |
2008 |
Jan
(12) |
Feb
|
Mar
(17) |
Apr
(18) |
May
(12) |
Jun
(2) |
Jul
(2) |
Aug
(6) |
Sep
(4) |
Oct
(15) |
Nov
(45) |
Dec
(9) |
2009 |
Jan
(1) |
Feb
(3) |
Mar
(18) |
Apr
(8) |
May
(3) |
Jun
|
Jul
(13) |
Aug
(2) |
Sep
(1) |
Oct
(9) |
Nov
(13) |
Dec
|
2010 |
Jan
(2) |
Feb
(3) |
Mar
(9) |
Apr
(10) |
May
|
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(1) |
Dec
(4) |
2011 |
Jan
|
Feb
|
Mar
(10) |
Apr
(44) |
May
(9) |
Jun
(22) |
Jul
(2) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2012 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
|
Jul
(3) |
Aug
(8) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Kevin A. <al...@se...> - 2001-10-07 17:59:20
|
I want to have some generic Find and Find/Replace dialogs and find/replace classes in PythonCard, so as the first step I added a Find/Find Next field and buttons to the bottom of the textIndexer layout. The actual code that does the work is shown below. There is quite a bit of code in common with the three methods, but I didn't try and refactor the code, except where on_doFind_command and on_doFindNext_command both use method findNext to search the remaining cards in the stack if a match isn't found on the current card. This is a brute force search, which is case-insensitive and matches partial words. If someone with more search experience would like to optimize the code, I encourage them to do so. Because of the way textIndexer storage is organized via a separate ZODB storage class, when a match is not made on the current card, the next card in the stack is loaded and then the text from field1 is searched. This additional i/o slows down the search, but since a refresh of field1 is not done until after the search completes there isn't much feedback about what was going on. Consequently, I added a StaticText field to display the current card number, which does update as the card number changes. You'll need to create at least a few cards and enter text on each to see the find do its work. I'm going to add a similar find to the addresses sample which will be generalized a bit more, probably use a separate Find dialog window and support searching of multiple fields. It will also search the dictionary that holds the actual addresses data directly, which will make it closer to the general find classes later on. I don't have a timeframe for the addresses find code, I only finished up the code in textIndexer today because of a post I made to the wx-users mailing list yesterday regarding a problem with selections in wxTextCtrl. ka --- def findNext(self, searchText): startCard = self.wstack._v_current_card numCards = len(self.wstack.card_list)-1 # move to the next card and repeat the search until a match # or we come back to the card we started on doneSearching = 0 while not doneSearching: if self.wstack._v_current_card == numCards: self.wstack.GoFirst() else: self.wstack.GoNext() if self.wstack._v_current_card == startCard: doneSearching = 1 fieldText = self.components.field1.text.lower() offset = fieldText.find(searchText) if offset != -1: offset += fieldText.count('\n', 0, offset) self.components.field1.setSelection(offset, offset + len(searchText)) self.components.field1.setFocus() doneSearching = 1 def on_doFind_command(self, target, event): searchText = self.components.fldFind.text.lower() fieldText = self.components.field1.text.lower() offset = fieldText.find(searchText) if offset != -1: # find apparently doesn't count newlines in its total offset += fieldText.count('\n', 0, offset) self.components.field1.setSelection(offset, offset + len(searchText)) self.components.field1.setFocus() else: self.findNext(searchText) def on_doFindNext_command(self, target, event): searchText = self.components.fldFind.text.lower() fieldText = self.components.field1.text.lower() selOffset = self.components.field1.getSelection()[1] offset = fieldText[selOffset:].find(searchText) if offset != -1: offset += selOffset offset += fieldText.count('\n', 0, offset) self.components.field1.setSelection(offset, offset + len(searchText)) self.components.field1.setFocus() else: self.findNext(searchText) |
From: Andy T. <an...@ha...> - 2001-10-07 10:21:12
|
All, I've finally posted my fixes to the python version of the Worldclock sample to CVS. I've done some testing and the python code is now giving the same results as the javascript function. Those who are living on the bleeding edge can try it out from now - any and all feedback is welcome. Those who are more cautious should be able to stop using the javascript code from the next release. Regards, Andy -- ----------------------------------------------------------------------- From the desk of Andrew J Todd esq. "Hit me with your fax machine, baby" - Francis Dunnery, "Because I Can" |
From: Kevin A. <al...@se...> - 2001-10-06 20:03:24
|
Based on a recent discussion on the wx-dev mailing list, the addition of the key handlers may cause a problem under wxGTK. There may be additional issues with differences in key codes generated. Please report any issues you find to the list. The key events which were defined back in July and added to spec.py, never got added to the TextField, PasswordField, and TextArea class event bindings. There was a problem with passing the event on (wxPython Event.Skip()) if the user code didn't process the event. Anyway, I want to finally solve the issue, so I've checked in changes to: event.py, widget.py, and wxPython_binding.py There will probably be a change to dispatch.py as well. The current changes don't do much except allow the user code to handle the event and display the event in the Message Watcher. I still need to add support for not passing on the keyPress event, which will be necessary to limit the valid keystrokes for a field. For example, if you only wanted a user to enter numbers you would define a on_fieldName_keyPress handler that only called skip() when the key code was 0 through 9. The order of events: keyDown, keyPress, textUpdate, keyUp Adding these events exposed some problems with the handling of tabs and the return/enter key which I also need to investigate. However, it doesn't appear that any of the samples have been broken by adding the key events. As an example of handling each event, the following code could be added to minimal.py: def on_field1_keyDown(self, target, event): print 'field1_keyDown' def on_field1_keyPress(self, target, event): print 'field1_keyPressed' #event.skip() def on_field1_keyUp(self, target, event): print 'field1_keyUp' Note that the 'event.skip()' line commented out above will need to be uncommented in the future or the keyPress handler above would keep the characters from showing up in the field as user typed them. In order to do anything with the event right now you need to get the native wxPython event and then use wxPython methods. def on_field1_keyPress(self, target, event): print 'field1_keyPressed' nEvent = event.getNativeEvent() print nEvent.GetKeyCode() #event.skip() See wxKeyEvent and the Keycodes topics in the wxWindows/wxPython documentation for more info; I've included the Keycodes topic below. We'll have to define our own method wrappers and keycode constants in order to duplicate the wxPython functionality. I am thinking about just duplicating the codes below, but using a KEY_ prefix instead of WXK_ prefix; the constants will be put in a separate module file to make it easy to reference them. I'll need some suggestions for whether we need to do anything specific for supporting Unicode or keyboards outside the USA generating different 8-bit ASCII key codes (Russian, Swedish, etc.) It would be helpful to have some suggestions for a sample or two that need to do key processing to get a better idea of the functionality we need to support. ka --- Keycodes Keypresses are represented by an enumerated type, wxKeyCode. The possible values are the ASCII character codes, plus the following: WXK_BACK = 8 WXK_TAB = 9 WXK_RETURN = 13 WXK_ESCAPE = 27 WXK_SPACE = 32 WXK_DELETE = 127 WXK_START = 300 WXK_LBUTTON WXK_RBUTTON WXK_CANCEL WXK_MBUTTON WXK_CLEAR WXK_SHIFT WXK_CONTROL WXK_MENU WXK_PAUSE WXK_CAPITAL WXK_PRIOR WXK_NEXT WXK_END WXK_HOME WXK_LEFT WXK_UP WXK_RIGHT WXK_DOWN WXK_SELECT WXK_PRINT WXK_EXECUTE WXK_SNAPSHOT WXK_INSERT WXK_HELP WXK_NUMPAD0 WXK_NUMPAD1 WXK_NUMPAD2 WXK_NUMPAD3 WXK_NUMPAD4 WXK_NUMPAD5 WXK_NUMPAD6 WXK_NUMPAD7 WXK_NUMPAD8 WXK_NUMPAD9 WXK_MULTIPLY WXK_ADD WXK_SEPARATOR WXK_SUBTRACT WXK_DECIMAL WXK_DIVIDE WXK_F1 WXK_F2 WXK_F3 WXK_F4 WXK_F5 WXK_F6 WXK_F7 WXK_F8 WXK_F9 WXK_F10 WXK_F11 WXK_F12 WXK_F13 WXK_F14 WXK_F15 WXK_F16 WXK_F17 WXK_F18 WXK_F19 WXK_F20 WXK_F21 WXK_F22 WXK_F23 WXK_F24 WXK_NUMLOCK WXK_SCROLL |
From: Roman S. <rn...@on...> - 2001-10-06 11:51:12
|
A thought came to me that PythonCard could also be used for things Flash and PowerPoint are used now: for quick presentations and as authoring tools. (At least HyperCard was able to do so). Sincerely yours, Roman Suzi -- _/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/ _/ Saturday, October 06, 2001 _/ Powered by Linux RedHat 6.2 _/ _/ "What goes up has probably been doused with petrol." _/ |
From: Kevin A. <al...@se...> - 2001-10-05 01:33:39
|
> From: Ronald D Stephens > > Kevin, I just wonderd if you had seen the discussion goin on over > at cmpnet.byte.joncon (under the "Confessions of a Corporate IT > Director" thread)??? Below is one... I just went to look at it, thanks for the pointer. > For myself, I guess I am hoping for a killer hypercard like > IDE..but I am willing to wait ;-))) > > Do you plan on using Boa Consrtuctor eventually? Or writing a new > IDE?? or something else??? I don't think I'll be writing the PythonCard support for Boa, though Patrick expressed some interest. I'm not particularly fond of code generators and the Boa UI seems overly complex for doing simple apps. I think Boa is a good tool for what it is designed to do, it just doesn't feel right to me for PythonCard. > For us braindead low IQ part timers, an easy IDE may be the most > importnat thing... A great IDE is absolutely essential once the framework is ready for it, we just aren't there yet. Since we're also looking for an environment more like HyperCard, I don't think that it will have the same feel and work flow as VB or Delphi or Boa. Even SuperCard and MetaCard failed to capture the tight integration and feel of developing in and using HyperCard; the HyperCard experience is what I would like to achieve, but we may have to settle for an edit/run cycle more like SuperCard. What would other people really like to see? ka ps. We need a solid framework first, but we can do experiments via runtime tools (Shell, Message Watcher, Property Editor) and samples (resourceEditor) prior to having a full IDE. |
From: Ronald D S. <rd...@ea...> - 2001-10-05 00:05:34
|
Fred Pacquier wrote: > > Well, if you consider Delphi's IDE a commercial-quality GUI, I'd say BOA > comes close. Indeed it does. The UI that it presents is quite an exhilarating thing. However when I tried to actually use all the functionality that it implies, I was left with the impression that BOA is raising expectations that it cannot, as yet, really meet. Was I wrong? Are you actually using BOA to create useful apps? > There are two other interesting projects right now in that domain : > PythonCard wants to be what HyperCard was for the Mac (and relies, > surprise, on wxPython). Already does surprising things (and nice fractals!) I've had a look at it as well, and have had some offline discussions with Kevin Altis about it. My observation was that HyperCard was never an app framework decoupled from an IDE, the two were always integrally bound together. PythonCard *is* currently an app framework decoupled from an IDE. Nothing wrong with that, per se, but I guess that many people who hear "does for Python what HyperCard did for the Mac" will expect the integral IDE right out of the starting gate, and will be surprised not to find it. -- Jon Udell | <http://udell.roninhouse.com/> | 603-355-8980 |
From: Ronald D S. <rd...@ea...> - 2001-10-05 00:02:23
|
Kevin, I just wonderd if you had seen the discussion goin on over at cmpnet.byte.joncon (under the "Confessions of a Corporate IT Director" thread)??? Below is one... For myself, I guess I am hoping for a killer hypercard like IDE..but I am willing to wait ;-))) Do you plan on using Boa Consrtuctor eventually? Or writing a new IDE?? or something else??? For us braindead low IQ part timers, an easy IDE may be the most importnat thing... Ron Stephens -------- Original Message -------- Path: news.cmpnet.com!not-for-mail From: Jon Udell <ud...@mo...> Newsgroups: cmpnet.byte.joncon Subject: Python GUIs -> Tk, wxPython Date: Wed, 03 Oct 2001 13:30:36 -0400 Organization: CMP Media Inc. Lines: 17 Message-ID: <3BB...@mo...> References: <9o7vhg$rhl$1...@cm...> <9otrkp$ri7$1...@cm...> <9ou79p$1v3$1...@cm...> <Xns91298A531B71FPaCmAnRDLM@192.215.71.106> NNTP-Posting-Host: keen13.keene-dsl.monad.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: cmpweb-media0.web.cerf.net 1002130100 11446 208.0.179.13 (3 Oct 2001 17:28:20 GMT) X-Complaints-To: us...@cm... NNTP-Posting-Date: 3 Oct 2001 17:28:20 GMT X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en Xref: news.cmpnet.com cmpnet.byte.joncon:3133 > Unfortunately Tkinter programming usually feels strange to people not used > to Tcl (ie to a lot of people), and has its own specific "look". But if > cross-platform requirements are less stringent there are other choices. A > prominent one is the wxPython library (based on the wxWindows C++ > framework). It has a decidedly MFC-like coding style, and allows portable > GUI apps with native look-n-feel between Win32/Unix/Linux clients (a large > market segment -- probably Macintosh someday too). Lastly, if a Windows- > only user base is the target, Python can use the native Win32 API directly, > in a very natural way to experienced programmers. I'd strongly second that recommendation. wxPython is a terrific piece of work, and I expect (though have not yet seen the proof) that could support the development of complex and commecial-quality GUI apps. -- Jon Udell | <http://udell.roninhouse.com/> | 603-355-8980 |
From: Kevin A. <al...@se...> - 2001-10-04 22:10:57
|
I modified the samples launcher (samples.py) to use sizers and have checked it into cvs. The code uses nested wxBoxSizers and is similar to the sizers in the doodle and hopalong samples, but more complex. It looks fine under Windows 2000. I would appreciate it if someone running Linux or Solaris could try it out and let me know if there are any alignment or overlap issues with the widgets using a variety of themes; a reply to the list with a JPEG shot of the window would be great, especially if there is a problem with the layout. The description field expands with the window to simplify viewing source and resource files. The code appears below, but the code and .rsrc.py file may change slightly depending on how the layout looks on Linux and Solaris. Remember that this isn't what the final user code will look like, I'm using wxPython directly to try and see what common elements are used by a variety of layouts. The final user code will be much simpler. One interesting thing to note is that it is still possible to use the resourceEditor to do the basic fixed position layout without impacting the sizer layout. ka --- def setupSizers(self): sizer1 = wxBoxSizer(wxVERTICAL) sizer2 = wxBoxSizer(wxHORIZONTAL) sizer3 = wxBoxSizer(wxVERTICAL) sizer4 = wxBoxSizer(wxHORIZONTAL) comp = self.components btnFlags = wxLEFT | wxALIGN_BOTTOM vertFlags = wxLEFT | wxTOP | wxALIGN_LEFT sizer4.Add(comp.btnLaunch._delegate, 1, btnFlags, 5) sizer4.Add(comp.btnDescription._delegate, 1, btnFlags, 5) sizer4.Add(comp.btnSource._delegate, 1, btnFlags, 5) sizer4.Add(comp.btnResource._delegate, 1, btnFlags, 5) sizer3.Add(comp.stcCmdLineArgs._delegate, 0, wxLEFT | wxBOTTOM | wxALIGN_TOP, 5) sizer3.Add(comp.chkLogging._delegate, 0, vertFlags, 5) sizer3.Add(comp.chkMessageWatcher._delegate, 0, vertFlags, 5) sizer3.Add(comp.chkNamespaceViewer._delegate, 0, vertFlags, 5) sizer3.Add(comp.chkPropertyEditor._delegate, 0, vertFlags, 5) sizer3.Add(comp.chkShell._delegate, 0, vertFlags, 5) sizer3.Add(5, 5, 1) # spacer sizer3.Add(sizer4, 1, wxALIGN_BOTTOM | wxEXPAND) sizer2.Add(comp.listSamples._delegate, 0, wxRIGHT | wxALIGN_TOP, 5) sizer2.Add(sizer3, 1, wxEXPAND) sizer1.Add(sizer2, 0, vertFlags) sizer1.Add(5, 5, 0) # spacer sizer1.Add(comp.stcDescription._delegate, 0, wxLEFT | wxTOP | wxBOTTOM | wxALIGN_LEFT, 5) sizer1.Add(comp.fldDescription._delegate, 1, wxEXPAND) sizer1.Fit(self) sizer1.SetSizeHints(self) self.panel.SetSizer(sizer1) self.panel.SetAutoLayout(true) self.panel.Layout() |
From: Kevin A. <al...@se...> - 2001-10-01 17:43:19
|
I'm back. It looks like we had 160+ downloads of release 0.4.5 http://sourceforge.net/project/showfiles.php?group_id=19015 in the last two weeks, but as Andy mentioned in a previous email, the list has been awfully quiet while I was away. If you are using the current framework, have found any problems, or are waiting for a particular feature to be added before you get active on the list, please share your thoughts and issues with the list. The TODO.txt file shows my current priorities as documentation, fonts, and sizers. There are a few people on the list that are supposedly working on documentation, so I'll let them respond to the list to let us know their status. Based on the responses I got from the wx-users and wxpython-users mailing lists regarding fonts before I left, I would like to leave fonts as is until we can get some better support for determining the font family based on a font face name. That means that the API for fonts will change in the future, but any updates to user code should be minor. I'll pursue this issue on the wx-dev mailing list. I'm going to modify some more of the samples to use sizers and then start some tests for adding sizers via the .rsrc.py files. I was quite surprised to see that many of the people downloading the latest release got the .tar.gz file which implies that they are running Linux or Solaris. Since the current samples often look pretty bad under Linux because of the fixed positions and sizes of the widgets, I would like to get some sort of sizer arrangement working in the next two weeks. Any suggestions for an implementation or help would be appreciated. On a related note, I'm thinking of adding support for loading different .rsrc.py files based on the runtime platform, so that we might have multiple .rsrc.py files like minimal.win32.rsrc.py, minimal.linux.rsrc.py, and a default minimal.rsrc.py that would be used if no other was available. The pythoncard.user.config.py file could specify the user preference for which to use which will simplify development testing of multiple .rsrc.py files. I thought some more about a simple flat file database creator to further test the back-end persistance mechanism idea. I will probably work on that a bit and then let Patrick, Andy, and some of the other people that expressed interest in that area expand on the idea. My current preference would be to support random access, getRecord/setRecord and getField/setField style methods, though with dot notation, both record (card) and field (widget) would be attributes. In addition, the user will be able to turn on/off the persistance mechanism, since apps like most of the current samples don't really need automatic persistance. We can start a separate thread to go into issues about data and metadata storage. Finally, I'm going to spend some more time on the graphic.py module and wrap up more of the underlying wxPython drawing capabilities. If you have other issues you would like to see addressed or get a higher priority, please post a message to the list. ka --- Kevin Altis al...@se... |
From: Peter <pe...@pe...> - 2001-09-28 04:20:45
|
I'm still very interested in PythonCards progress. Just unable to do anything with it right now. Ever since Nimda we have been living under a no-internet policy at work. And no personal email, no unauthorized software either. It's been Hell. Restrictions are starting to lift, not because our systems are more secure, but because our president got over her panic attack. I read the article on OReillyNet about PythonCard - it's nice to see the project get noticed. And I saw another article there about RealBasic as another HyperCard replacement candidate. It's not open source and no good on UNIX, but it looked promising. But RealBasic's biggest flaw, to my way of thinking, is the lack of built in persistence (Cards and Backgrounds). I can't wait to see what comes from the ZODB work. Peter |
From: Roman S. <rn...@on...> - 2001-09-27 20:47:09
|
As for myself, I am learning Zope. And I really like some things about it which probably will be appropriate for PythonCard too. I like the way Zope stores it's objects in a hierarchy of containers (named folders) and how preperties and objects could be easily reused if stored above or in this folder. Also, I like the idea of Zope management interface. It will be nice to have a mode where logic objects reveal themselves visually. For example, if PythonCard app needs database connection to do a query, it could use one defined in the enclosing containers. Hypercard did acquisition by adding stacks to the path. Zope does the same by using folders. PythonCard could go further by allowing drop-in objects. Programmer could drop a logic object into stack and use it's functionality. To summarise, in Zope I saw a way to have logic, presentation and content consistently present in the organized manner with simple property acquisition rules. So, probably, in PythonCard it could be beneficial to have something like this. That was just an idea. I do not know how this could be visually presented. But some container-structure browser could be built, no doubt. Sincerely yours, Roman Suzi -- _/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/ _/ Thursday, September 27, 2001 _/ Powered by Linux RedHat 6.2 _/ _/ "A closed mouth gathers no feet." _/ |
From: Kevin A. <al...@se...> - 2001-09-27 13:55:36
|
> Q: Why is it quiet? > > A: Kevin has been out of town. I'm still watching the list, just not working on any code. I'll be back and active Monday, October 1st. ka |
From: Patrick K. O'B. <po...@or...> - 2001-09-27 12:57:48
|
Q: Why is it quiet? A: Kevin has been out of town. In the mean time, I'm still pursuing the use of ZODB as a persistent storage. I'll race you! --- Patrick K. O'Brien Orbtech (http://www.orbtech.com) "I am, therefore I think." -----Original Message----- From: pyt...@li... [mailto:pyt...@li...]On Behalf Of Andy Todd Sent: Thursday, September 27, 2001 4:28 AM To: Pythoncard-Users Subject: [Pythoncard-users] Awfully Quiet Around Here My apologies if this is a duplicate, I'm having a few email issues at the moment. Anyone there? I count no messages on this list for the last four days at least. Has anyone looked at the latest prototype? Does it do everything you ever wanted? (somehow I doubt it). Does anyone have suggestions, bugs, documentation, sample applications or opinions of any type they wish to share? Or am I talking to myself here? <snip> Regards, Andy -- ----------------------------------------------------------------------- From the desk of Andrew J Todd esq. "Hit me with your fax machine, baby" - Francis Dunnery, "Because I Can" _______________________________________________ Pythoncard-users mailing list Pyt...@li... https://lists.sourceforge.net/lists/listinfo/pythoncard-users |
From: Andy T. <an...@ha...> - 2001-09-27 09:26:13
|
My apologies if this is a duplicate, I'm having a few email issues at the moment. Anyone there? I count no messages on this list for the last four days at least. Has anyone looked at the latest prototype? Does it do everything you ever wanted? (somehow I doubt it). Does anyone have suggestions, bugs, documentation, sample applications or opinions of any type they wish to share? Or am I talking to myself here? As an update to my last message, I've tracked down the bug in the WorldClock sample and am hoping to have a patch available later this week. As an aside I tried testing this sample under cygwin and it will not work. There is a known bug with time.timezone() on cygwin python that causes an incorrect value to be returned and this messes up all of the delicate calculations. There is a patch on sourceforge for this so I'm hoping it will get included in Python 2.2 (or at least 2.3). Anybody else come across platform specific issues that may trip us up? I've also been looking at Gadfly, initially for inclusion in the dbBrowser sample application but with a view to using it as one of our persistence mechanisms. Its looking good but needs a little work at the Gadfly end (mainly because it uses regex rather than re), any assistance is, of course, welcome. Regards, Andy -- ----------------------------------------------------------------------- From the desk of Andrew J Todd esq. "Hit me with your fax machine, baby" - Francis Dunnery, "Because I Can" |
From: Kevin A. <al...@se...> - 2001-09-23 01:49:44
|
Any Solaris users on the list? What sort of distribution do you need? ka -----Original Message----- From: nobody [mailto:no...@so...]On Behalf Of Jeremy McMillan Sent: Friday, September 21, 2001 11:36 PM To: al...@se... Subject: RE: Binary packages for Windows, Unix, etc. Let me know if you want Solaris packages. I'm not going to go to the trouble until I know you'll post them, and I need to know if you want static binaries, if you need separate packages for the dependancies, or if you want to include the dependancies. Need to settle naming conventions, and I need to have your ear when I discover something else which requires project forward thinking. |
From: Andy T. <an...@cr...> - 2001-09-19 05:51:04
|
All, Just to let you know that extensive testing has discovered a bug in the worldclock sample. Specifically the javascript I converted to a python module is calculating an incorrect value for the URL to update the image from. I'm investigating the bug and hope to have a correction soon. In the meantime if you want to get the 'correct' image I suggest you switch back to using the javascript function to calculate the URL. To accomplish this change just uncomment lines 76 to 83 of worldclock.py and comment out line 84. This section of the file should change from; """ # try: # jScript = "cscript //nologo xearth.js" # file = os.popen(jScript) # s = file.read() # url = "http://www.time.gov/" + s # except: # url = "http://www.time.gov/images/xearths/night.jpg" # #url = "http://www.time.gov/images/xearths/11N/100N.jpg" url = "http://www.time.gov/" + xearth.getLatLong() """ to """ try: jScript = "cscript //nologo xearth.js" file = os.popen(jScript) s = file.read() url = "http://www.time.gov/" + s except: url = "http://www.time.gov/images/xearths/night.jpg" #url = "http://www.time.gov/images/xearths/11N/100N.jpg" # url = "http://www.time.gov/" + xearth.getLatLong() """ Any questions, please shout. Regards, Andy -- ----------------------------------------------------------------------- From the desk of Andrew J Todd esq. "Hit me with your fax machine, baby" - Francis Dunnery, "Because I Can" |
From: Kevin A. <al...@se...> - 2001-09-18 19:45:58
|
I hit the send key too soon on the first post... I basically agree with what Skip had to say below. Just for reference sake, here are some more XML-RPC and SOAP links for those that want to investigate further. A Busy Developer's Guide to SOAP 1.1 http://www.soapware.org/bdg SoapWare.Org http://www.soapware.org/ XML-RPC Home Page http://www.xmlrpc.com/ Most of the data storage and resource work I'll be experimenting with in the next month or so will continue to use Python data types like dictionaries and lists, so I won't be looking at XML much until after that. I would still appreciate it if someone that knows the Python XML libraries could fix the XML bugs in the SourceForgeTracker sample (see the readme and comments in the SourceForgeTracker.py file for more info or just post your questions to the list. ka > -----Original Message----- > From: pyt...@li... > [mailto:pyt...@li...]On Behalf Of Skip > Montanaro > Sent: Tuesday, September 18, 2001 11:54 AM > To: pyt...@li... > Subject: Re: [Pythoncard-users] fwd: The Pros and Cons of XML > > > > (apologies if you receive this multiple times - i've been having mail > problems - originally sent 12 Sep 2001 13:50:11) > > (I am still having trouble sending to this list. I originally posted this > note on September 7th but haven't seen it turn up expect as a mail bounce. > In some sense this is simply a test. My apologies if you're seeing this > message twice.) > > Kevin> At some point we are going to support XML, at least for > Kevin> import/export and possibly the resource format. It > will certainly > Kevin> be used for any XML-RPC or SOAP connectivity, which is probably > Kevin> how PythonCard apps are going to talk to the rest of > the world in > Kevin> a standard way. > > I think there is an important distinction to make between SOAP and XML-RPC > on the one hand, and things like storing Pythoncard resource > files in XML on > the other hand. From the programmer's standpoint, SOAP and > XML-RPC are just > RPC protocols. I've been using XML-RPC for about three years now, and the > only time I've ever looked at the raw XML was when I was mucking about in > the xmlrpclib.py implementation and screwed something up. My clients and > servers pass tens of thousands of messages back and forth every day and I > never pay any attention to the XML. In other words, from the > standpoint of > Pythoncard users or developers, SOAP and XML-RPC might as well be using > paper tapes encoded in Morse code, tied to the legs of carrier pigeons to > get the data back and forth. There are issues of bandwidth usage and the > costs to marshal and unmarshal data with SOAP and XML-RPC, but they aren't > insurmountable, and really only come into play if you are > transferring lots > of data. (They would often be problems with other RPC encodings as well.) > > The October issue of WebTechniques magazine (not available online until > September 12) has an article about SOAP. It posts the obligatory > XML for a > simple request and response. No code was posted (that I recall) > showing how > to make a SOAP call from Perl or Python. In my mind, by dwelling on the > transport encoding the article completely misses the point of > using SOAP (or > XML-RPC or ORBit or Fnorb or ...), which is that for the application > programmer, they make RPC programming drop dead easy. > > All the pros and cons of XML will only come into play when you have to > invent an XML encoding for, say, Pythoncard resource data. I would only > worry about most of the Pros and Cons listed in the Zapthink > article in that > light. > > All that said, the Zapthink article does look like a good contrast of the > pros and cons of XML. > > -- > Skip Montanaro (sk...@po...) > http://www.mojam.com/ > http://www.musi-cal.com/ > > > _______________________________________________ > Pythoncard-users mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncard-users > |
From: Kevin A. <al...@se...> - 2001-09-18 19:40:44
|
I basically agree with what Skip had to say below. Just for reference sake, here are some more XML-RPC and SOAP links for those that want to investigate further. A Busy Developer's Guide to SOAP 1.1 http://www.soapware.org/bdg XML-RPC Home Page http://www.xmlrpc.com/ > -----Original Message----- > From: pyt...@li... > [mailto:pyt...@li...]On Behalf Of Skip > Montanaro > Sent: Tuesday, September 18, 2001 11:54 AM > To: pyt...@li... > Subject: Re: [Pythoncard-users] fwd: The Pros and Cons of XML > > > > (apologies if you receive this multiple times - i've been having mail > problems - originally sent 12 Sep 2001 13:50:11) > > (I am still having trouble sending to this list. I originally posted this > note on September 7th but haven't seen it turn up expect as a mail bounce. > In some sense this is simply a test. My apologies if you're seeing this > message twice.) > > Kevin> At some point we are going to support XML, at least for > Kevin> import/export and possibly the resource format. It > will certainly > Kevin> be used for any XML-RPC or SOAP connectivity, which is probably > Kevin> how PythonCard apps are going to talk to the rest of > the world in > Kevin> a standard way. > > I think there is an important distinction to make between SOAP and XML-RPC > on the one hand, and things like storing Pythoncard resource > files in XML on > the other hand. From the programmer's standpoint, SOAP and > XML-RPC are just > RPC protocols. I've been using XML-RPC for about three years now, and the > only time I've ever looked at the raw XML was when I was mucking about in > the xmlrpclib.py implementation and screwed something up. My clients and > servers pass tens of thousands of messages back and forth every day and I > never pay any attention to the XML. In other words, from the > standpoint of > Pythoncard users or developers, SOAP and XML-RPC might as well be using > paper tapes encoded in Morse code, tied to the legs of carrier pigeons to > get the data back and forth. There are issues of bandwidth usage and the > costs to marshal and unmarshal data with SOAP and XML-RPC, but they aren't > insurmountable, and really only come into play if you are > transferring lots > of data. (They would often be problems with other RPC encodings as well.) > > The October issue of WebTechniques magazine (not available online until > September 12) has an article about SOAP. It posts the obligatory > XML for a > simple request and response. No code was posted (that I recall) > showing how > to make a SOAP call from Perl or Python. In my mind, by dwelling on the > transport encoding the article completely misses the point of > using SOAP (or > XML-RPC or ORBit or Fnorb or ...), which is that for the application > programmer, they make RPC programming drop dead easy. > > All the pros and cons of XML will only come into play when you have to > invent an XML encoding for, say, Pythoncard resource data. I would only > worry about most of the Pros and Cons listed in the Zapthink > article in that > light. > > All that said, the Zapthink article does look like a good contrast of the > pros and cons of XML. > > -- > Skip Montanaro (sk...@po...) > http://www.mojam.com/ > http://www.musi-cal.com/ > > > _______________________________________________ > Pythoncard-users mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncard-users > |
From: Skip M. <sk...@po...> - 2001-09-18 18:53:49
|
(apologies if you receive this multiple times - i've been having mail problems - originally sent 12 Sep 2001 13:50:11) (I am still having trouble sending to this list. I originally posted this note on September 7th but haven't seen it turn up expect as a mail bounce. In some sense this is simply a test. My apologies if you're seeing this message twice.) Kevin> At some point we are going to support XML, at least for Kevin> import/export and possibly the resource format. It will certainly Kevin> be used for any XML-RPC or SOAP connectivity, which is probably Kevin> how PythonCard apps are going to talk to the rest of the world in Kevin> a standard way. I think there is an important distinction to make between SOAP and XML-RPC on the one hand, and things like storing Pythoncard resource files in XML on the other hand. From the programmer's standpoint, SOAP and XML-RPC are just RPC protocols. I've been using XML-RPC for about three years now, and the only time I've ever looked at the raw XML was when I was mucking about in the xmlrpclib.py implementation and screwed something up. My clients and servers pass tens of thousands of messages back and forth every day and I never pay any attention to the XML. In other words, from the standpoint of Pythoncard users or developers, SOAP and XML-RPC might as well be using paper tapes encoded in Morse code, tied to the legs of carrier pigeons to get the data back and forth. There are issues of bandwidth usage and the costs to marshal and unmarshal data with SOAP and XML-RPC, but they aren't insurmountable, and really only come into play if you are transferring lots of data. (They would often be problems with other RPC encodings as well.) The October issue of WebTechniques magazine (not available online until September 12) has an article about SOAP. It posts the obligatory XML for a simple request and response. No code was posted (that I recall) showing how to make a SOAP call from Perl or Python. In my mind, by dwelling on the transport encoding the article completely misses the point of using SOAP (or XML-RPC or ORBit or Fnorb or ...), which is that for the application programmer, they make RPC programming drop dead easy. All the pros and cons of XML will only come into play when you have to invent an XML encoding for, say, Pythoncard resource data. I would only worry about most of the Pros and Cons listed in the Zapthink article in that light. All that said, the Zapthink article does look like a good contrast of the pros and cons of XML. -- Skip Montanaro (sk...@po...) http://www.mojam.com/ http://www.musi-cal.com/ |
From: Kevin A. <al...@se...> - 2001-09-18 17:53:22
|
PythonCard is a software construction kit (in the spirit of Apple's HyperCard) written in Python. You can download the latest release at: http://sourceforge.net/project/showfiles.php?group_id=19015 Samples included in the latest release: addresses, conversions, dbBrowser, dialogs, doodle, findfiles, hopalong, minimal, proof, resourceEditor, samples, searchexplorer, sounds, SourceForgeTracker, textIndexer, tictactoe, turtle, widgets, worldclock To see screenshots of some of the samples, visit: http://pythoncard.sourceforge.net/samples.html A description of each sample is included in the docs directory and the readme.txt file in each sample directory. PythonCard home page http://pythoncard.sourceforge.net/ SourceForge summary page http://sourceforge.net/projects/pythoncard/ Mailing list http://lists.sourceforge.net/lists/listinfo/pythoncard-users PythonCard requires Python 2.1.x or later and wxPython 2.3.x. wxPython is available at http://www.wxpython.org/ PythonCard relies on wxPython, it will support the Macintosh once wxPython has been ported to the Mac. PyCrust 0.6 PyCrust by Patrick K. O'Brien is required by PythonCard, but is no longer included as part of the PythonCardPrototype releases. Please visit the home page at http://sourceforge.net/projects/pycrust/ and download the latest release at http://sourceforge.net/project/showfiles.php?group_id=31263 ---------------------------- Changes since release 0.4.3 (2001-08-23): Release 0.4.5 2001-09-17 PyCrust is no longer included in the PythonCardPrototype distribution, please download PyCrust at: http://sourceforge.net/project/showfiles.php?group_id=31263 moved Bitmap class to graphic.py module added getPILBits and setPILBits to Bitmap class to simplify using PIL with PythonCard added BitmapCanvas widget to widget.py added doodle and hopalong samples which use BitmapCanvas The BitmapCanvas is very experimental and will be enhanced and improved Debug windows are now children of the app window Namespace Viewer, Property Editor, Shell added 'Save Configuration' option to Debug menu this will create a pythoncard.user.config.py file with the current debug window position and sizes changed Message Watcher to use sizers renamed readDictionaryFile to readAndEvalFile updated addresses.py and searchexplorer.py to use the new function Release 0.4.4.5 2001-09-08 posted Help Wanted on SourceForge http://sourceforge.net/people/?group_id=19015 posted Python Conference request for papers/tutorials http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/767719 added addMethod to Scriptable class for dynamically adding handlers at runtime, see: http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/770015 added 'openBackground' message to replace using __init__ changed background handlers to on_mouseClick form modified SourceForgeTracker so that double-clicking on a topic launches the web page for that topic in a browser Neil added Pyker.hta and PykerLaunch.hta see the following URL for more info http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/766307 Andy added a TODO.txt to document short-term plans for PythonCard development Property Editor and resourceEditor sample were changed to use default size (-1, -1) values added enable and check menu items to menu.py see the url below and thread replies http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/766371 started some documentation for the Button class http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/764832 added display of .rsrc.py files in samples.py Patrick added dot notation support to the Font class Jeff and Neil provided some Unix screenshots These show we need to get sizers working to deal with variable size widgets and fonts on different platforms http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/763602 http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/763659 res.py eval() changed to support using Windows-style line endings under Unix added "Redirect stdout to Shell" option to Debug menu Release 0.4.4.1 2001-08-31 added samples.py to launch the the various sample programs see samples\samples.py added readme.txt files to all samples that didn't already have one. the readme.txt is displayed as the 'description' for a sample Release 0.4.4 2001-08-30 added getting_started.html to docs\html added basic status bar support statusbar.py module see test_turtle.py for an example turtle sample updated test_turtle.py now uses a status bar and displays the time required to draw a design added line(x1, y1, x2, y2) method to turtle added extra parametes to FileDialog to support saving files see resourceEditor for an example see dialog.py for complete list of options added Namespace Viewer using PyFilling (part of PyCrust 0.6) fixed numerous Property Editor edit/display bugs widgets are now displayed in the proper order added Font support to all widgets Font class moved to font.py module the actual text descriptions of the fonts is going to change, so if you use them, just be aware that the format of the font descriptions will change by the next release a font can be passed to the Font dialog to set the initial font displayed commented out 'import warnings' for Python 2.0 support but PyCrust usage still means that you need Python 2.1.x if any Debug windows like the shell will be used fixed unitialized empty bitmaps on win98 added append method to Choice class added setFocus method to Widget dbBrowser sample updated to version 0.2 resourceEditor changes resourceEditor can now save .rsrc.py files make sure to only work on copies in case of bugs also some hand editing of .rsrc.py is still necessary depending on what you're trying to do Duplicate Widget menu item now causes the duplicate to be offset 10 pixels so it can be selected to select added template.rsrc.py for defaults worldclock sample demonstrates simple use of logging |
From: Kevin A. <al...@se...> - 2001-09-18 15:51:56
|
In addition to the regular 'proto-0.4.5.zip' source file, there is a win32 binary installer 'proto-0.4.5.win32.exe' and a Unix 'proto-0.4.5.tar.gz' file; both use distutils. Please report any problems to the list. ka > -----Original Message----- > From: pyt...@li... > [mailto:pyt...@li...]On Behalf Of Kevin > Altis > Sent: Monday, September 17, 2001 1:04 PM > To: pythoncard-Users > Subject: [Pythoncard-users] announce: release 0.4.5 > > > I'm just announcing to the list for now. As usual, the file is at: > https://sourceforge.net/project/showfiles.php?group_id=19015 > > The big change is that PyCrust is no longer included in the > distribution, so > you'll need to get PyCrust 0.6 separately. Also, Andy has been work on > distutils and if no problems are reported with this .zip > distribution, then > we'll put up distutils distributions for Linux and Windows tomorrow, but > there won't be any additional changes to the modules and samples. Please > download proto-0.4.5.zip and report any problems to the list today if > possible. > > changes since 0.4.4.5 > > Release 0.4.5 2001-09-17 > PyCrust is no longer included in the PythonCardPrototype > distribution, please download PyCrust at: > http://sourceforge.net/project/showfiles.php?group_id=31263 > moved Bitmap class to graphic.py module > added getPILBits and setPILBits to Bitmap class > to simplify using PIL with PythonCard > added BitmapCanvas widget to widget.py > added doodle and hopalong samples which use BitmapCanvas > The BitmapCanvas is very experimental and will be > enhanced and improved > Debug windows are now children of the app window > Namespace Viewer, Property Editor, Shell > added 'Save Configuration' option to Debug menu > this will create a pythoncard.user.config.py file > with the current debug window position and sizes > changed Message Watcher to use sizers > renamed readDictionaryFile to readAndEvalFile > updated addresses.py and searchexplorer.py to use the new function > > ka > --- > Kevin Altis > al...@se... > > > _______________________________________________ > Pythoncard-users mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncard-users > |
From: Kevin A. <al...@se...> - 2001-09-17 20:02:11
|
I'm just announcing to the list for now. As usual, the file is at: https://sourceforge.net/project/showfiles.php?group_id=19015 The big change is that PyCrust is no longer included in the distribution, so you'll need to get PyCrust 0.6 separately. Also, Andy has been work on distutils and if no problems are reported with this .zip distribution, then we'll put up distutils distributions for Linux and Windows tomorrow, but there won't be any additional changes to the modules and samples. Please download proto-0.4.5.zip and report any problems to the list today if possible. changes since 0.4.4.5 Release 0.4.5 2001-09-17 PyCrust is no longer included in the PythonCardPrototype distribution, please download PyCrust at: http://sourceforge.net/project/showfiles.php?group_id=31263 moved Bitmap class to graphic.py module added getPILBits and setPILBits to Bitmap class to simplify using PIL with PythonCard added BitmapCanvas widget to widget.py added doodle and hopalong samples which use BitmapCanvas The BitmapCanvas is very experimental and will be enhanced and improved Debug windows are now children of the app window Namespace Viewer, Property Editor, Shell added 'Save Configuration' option to Debug menu this will create a pythoncard.user.config.py file with the current debug window position and sizes changed Message Watcher to use sizers renamed readDictionaryFile to readAndEvalFile updated addresses.py and searchexplorer.py to use the new function ka --- Kevin Altis al...@se... |
From: Kevin A. <al...@se...> - 2001-09-17 17:42:46
|
Last week, jabberpy 0.2 was announced http://jabberpy.sourceforge.net/ Yesterday, Roman asked about threading and PythonCard and today I saw this nice page covering info for writing a Jabber client. The Jabber Client Developer's Cheat Sheet http://homepage.mac.com/jens/Jabber/JabberClientCheatSheet.html This got me thinking about Jabber and PythonCard. Writing a basic Jabber client in PythonCard has been one of the tests in my mind since we started the list. Jabber is most typically used as an instant messaging client and Jabber servers can act as gateways to the most popular instant messaging services: AOL, ICQ, Yahoo, and MSN; a large number of other transports are also supported, see http://www.jabber.org/?oid=72. Jabber is also an architecture and platform for handling presence management and distributing XML packets. The short story is that Jabber is good stuff. For more info, check out http://www.jabber.org/ A lot of the components for doing a client with PythonCard are already in place. I probably won't commit any serious thought and effort to a PythonCard-based Jabber client for a while, but if someone else wants to start investigating, it would be a great topic for list discussion because it will expose a lot of issues with the framework. ka |
From: Kevin A. <al...@se...> - 2001-09-17 06:44:58
|
I moved the PIL Image module import and Bitmap class out of widget.py and into a new module called graphic.py I updated the worldclock and tictactoe samples and widget.py to use the new module. ka |
From: Kevin A. <al...@se...> - 2001-09-16 22:16:26
|
I don't know why you are having problems with tkinter and threads. Do the wcgui.py and wsgui.py programs in the the python21\Tools\webchecker directory run correctly? The wxPython demo.py program has a threads example. I've asked Robin to help do the conversion of the webchecker tkinter programs for wxPython as examples of doing threading with wxPython, which will also work with PythonCard, but he's been too busy to work on it. There will probably be some parts of the PythonCard framework that are threaded, but given the additional complexities that threading will add, I doubt we'll use threading that much. It is more likely that we'll provide some examples of using a timer or idle loop or yield operation for the user code to do longer operations. I just don't know right now. We haven't gotten into app to app communication at all yet, so again I don't know the answer. I still want to wrap up most of the basic GUI issues, then work on data storage for user data and meta data before looking at remote and local app communication. Anyone else that would like to address communication issues now by writing some modules and experiments is welcome to. ka > -----Original Message----- > From: pyt...@li... > [mailto:pyt...@li...]On Behalf Of Roman > Suzi > Sent: Sunday, September 16, 2001 1:47 PM > To: pyt...@li... > Subject: [Pythoncard-users] threads & PythonCard > > > I've just understood that Tkinter and threads aren't compatible > under Windows. Is wxPython compatible with threads? > Will PythonCard apps be multithreaded? > What will be the way to interprocesscommunications for > PythonCard? > > Sincerely yours, Roman Suzi > -- > _/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/ > _/ Sunday, September 16, 2001 _/ Powered by Linux RedHat 6.2 _/ > _/ "Phobia: what's left after drinking 2 out of a 6 pack" _/ > > > _______________________________________________ > Pythoncard-users mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncard-users > |