Thread: [Pyobjc-dev] [ pyobjc-Bugs-742629 ] NSBeginAlertSheet crashes
Brought to you by:
ronaldoussoren
Menu
▾
▴
pyobjc-dev
|
From: SourceForge.net <no...@so...> - 2003-05-23 22:55:19
|
Bugs item #742629, was opened at 2003-05-24 00:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=114534&aid=742629&group_id=14534 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: NSBeginAlertSheet crashes Initial Comment: Using NSBeginAlertSheet crashes for me. See the attached demo program (build with "python buildapp.py --link build"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=114534&aid=742629&group_id=14534 |
|
From: Just v. R. <ju...@le...> - 2003-05-23 23:57:06
|
Sf is currently in read-only mode, so here's an old-fashioned email. > Using NSBeginAlertSheet crashes for me. See the attached demo > program (build with "python buildapp.py --link build"). I meant to add that to trigger the crash, simply close the window that shows up when the app has launched. This _should_ show a sheet, but crashes instead. Just |
|
From: Ronald O. <ous...@ci...> - 2003-05-24 06:48:20
|
On Saturday, May 24, 2003, at 01:15 Europe/Amsterdam, Just van Rossum wrote: > Sf is currently in read-only mode, so here's an old-fashioned email. > >> Using NSBeginAlertSheet crashes for me. See the attached demo >> program (build with "python buildapp.py --link build"). > > I meant to add that to trigger the crash, simply close the window that > shows up when the app has launched. This _should_ show a sheet, but > crashes instead. I haven't looked at this yet (SF is down for maintainence, and I'm about to leave anyway), but this does bring up another issue: How can we add tests for GUI features to our test procedures. The best way I can come up with right now would be to build an application that uses a lot of functionality and let the user browse through it. Such an application would also be usefull as a demo on how to use Cocoa widgets from Python. Ronald |
|
From: Dinu G. <gh...@da...> - 2003-05-24 10:39:44
|
Ronald Oussoren: > I haven't looked at this yet (SF is down for maintainence, and I'm > about to leave anyway), but this does bring up another issue: How can > we add tests for GUI features to our test procedures. The best way I > can come up with right now would be to build an application that uses > a lot of functionality and let the user browse through it. Such an > application would also be usefull as a demo on how to use Cocoa > widgets from Python. Some stuff can certainly be done using NSControl.performClick_(sender) which every interactive widget should understand. So you can fill in relevant data into things like textviews, set sliders and so on, and then make the final "Go" button be magically pressed. Eventually, you need to read out the widgets or whatever else that should have chan- ged. I just tried this with simgle widgets and it looks promissing, but it could also become very challenging for complex widgets like NS- TableView, -OutlineView and basically anything deeply structured. But if it works it would be a very furtile road to take, even maybe for purely ObjC applications which one would test using PyObjC! Oh, dear, if that ever happens... Dinu -- Dinu C. Gherman ...................................................................... "Any sufficiently advanced technology is indistinguishable from magic." (Arthur C. Clarke) |
|
From: Dinu G. <gh...@da...> - 2003-05-24 12:00:11
|
I wrote: > Some stuff can certainly be done using NSControl.performClick_(sender) > which every interactive widget should understand. So you can fill in > relevant data into things like textviews, set sliders and so on, and > then make the final "Go" button be magically pressed. Eventually, you > need to read out the widgets or whatever else that should have chan- > ged. > > I just tried this with simgle widgets and it looks promissing, but > it could also become very challenging for complex widgets like NS- > TableView, -OutlineView and basically anything deeply structured. Of course, the real challenge would be to trigger the tests from *outside* the tested application! Honestly, I have no idea if it is possible to get a handle on a running application from outside, perhaps via notifications posted by NSApplication? Dinu -- Dinu C. Gherman ...................................................................... "Journalism largely consists of saying 'Lord Jones is Dead' to people who never knew that Lord Jones was alive." (G. K. Chesterton) |
|
From: Ronald O. <ous...@ci...> - 2003-05-24 12:20:20
|
On Saturday, May 24, 2003, at 14:01 Europe/Amsterdam, Dinu Gherman wrote: >> I just tried this with simgle widgets and it looks promissing, but >> it could also become very challenging for complex widgets like NS- >> TableView, -OutlineView and basically anything deeply structured. > > Of course, the real challenge would be to trigger the tests from > *outside* the tested application! Honestly, I have no idea if it > is possible to get a handle on a running application from outside, > perhaps via notifications posted by NSApplication? If the application supports loading plugins you could load a dummy plugin that is only used as a communication vehicle between the test framework and the runloop in the application. Writing plugins that load Python code is not too hard, I have done a proof of concept implementation some time ago (check the mailinglist archives) and I intend to add a supported version of that to the bridge. Gui testing is probably a bit too much for testing PyObjC, although I'd love to see such a tool especially if it uses PyObjC. BTW. Does anyone have ideas on how to execute some code when 'your' NSBundle is loaded. I need this to automaticly initialize the Python interpreter when someone loads a Python based bundle. My proof of concept uses the +initialize method of a dummy class. That works, but would mean that the user must install the Developer Tools when she wants to write plugins/preference panes/... in pure python (because you cannot have the same class in two different bundles, which would mean you'd have to generate a .m file based on a template) Ronald |
|
From: Jack J. <Jac...@cw...> - 2003-05-24 14:41:20
|
On zaterdag, mei 24, 2003, at 14:19 Europe/Amsterdam, Ronald Oussoren wrote: > > On Saturday, May 24, 2003, at 14:01 Europe/Amsterdam, Dinu Gherman > wrote: > >>> I just tried this with simgle widgets and it looks promissing, but >>> it could also become very challenging for complex widgets like NS- >>> TableView, -OutlineView and basically anything deeply structured. >> >> Of course, the real challenge would be to trigger the tests from >> *outside* the tested application! Honestly, I have no idea if it >> is possible to get a handle on a running application from outside, >> perhaps via notifications posted by NSApplication? I would assume the new System Events by Apple also work for Cocoa programs? If they do then we simply send ourselves (or whatever other program we try to test) the relevant System Event. System Events are an OSA suite, and support for them is included in Python 2.3. In case people aren't familiar with System Events: this is the recently released low-level stuff that makes Universal Access tick. It's really good: you can basically interact with any GUI element of any application. And there's an accompanying browser that lets you get at the names you need to use to address the various UI elements in any application. -- - Jack Jansen <Jac...@or...> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - |
|
From: Dinu G. <gh...@da...> - 2003-05-24 15:43:31
|
Jack Jansen:
> I would assume the new System Events by Apple also work for Cocoa
> programs?
>
> If they do then we simply send ourselves (or whatever other program we
> try to test) the relevant System Event. System Events are an OSA
> suite, and support for them is included in Python 2.3.
>
> In case people aren't familiar with System Events: this is the
> recently released low-level stuff that makes Universal Access tick.
> It's really good: you can basically interact with any GUI element of
> any application. And there's an accompanying browser that lets you get
> at the names you need to use to address the various UI elements in any
> application.
The Anguish et al. book says on page 863 (Apple Events):
"... Cocoa applications must use the Carbon Apple Event Manager API
to send Apple Events. ..."
Unfortunately, it's not quite clear which version that refers to,
since just earlier it mentions problems with 10.1.3...
Dinu
--
Dinu C. Gherman
......................................................................
"It was wonderful to find America, but it would have been more wonder-
ful to miss it." (Mark Twain)
|
|
From: Dinu G. <gh...@da...> - 2003-05-24 14:49:56
|
Ronald Oussoren: > If the application supports loading plugins you could load a dummy > plugin that is only used as a communication vehicle between the test > framework and the runloop in the application. Writing plugins that > load Python code is not too hard, I have done a proof of concept > implementation some time ago (check the mailinglist archives) and I > intend to add a supported version of that to the bridge. That sounds too hackumbersome to me. So I've looked into the class NSDistributedNotificationCenter which allows notifications across applications, but only strings can be passed (which is not enough in this case). And BTW this seems to be buggy in PyObjC; I'll sub- mit a bug report, shortly. Thereafter I've tried distributed objects using NSConnection, which works for me when passing "simple stuff" like a dictionary to an- other app, but it seems to be copied oneway and I can't seem to manipulate the original object in the original app... Distributed objects in ObjC use type modifiers like oneway, bycopy and byref and it would be interesting to know how much of this (if anything) already works in PyObjC, or if it ever has a chance of working on this side of the bridge? My gut feeling is that one could play dirty and exchange string representations of Python objects via distributed notifications in both directions as some kind of a work around, but I can't use this either, as long as that mechanism also seems to be buggy. Dinu -- Dinu C. Gherman ...................................................................... "A whole generation has grown up with the idea that it is normal for them to have no freedom." (Richard M. Stallman) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X