pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] gmane?

[David E. <epp...@ic...>]

Would it be possible to add pyobjc-dev and pyobjc-checkins to the 
mail-to-news gateway at gmane.org?  See http://gmane.org for a description 
if you're not familiar with this service, which lets users read many 
technical mailing lists using a newsreader instead of a mailreader.  I find 
it very helpful in keeping my personal mailbox free of clutter, and am more 
likely to actually read messages there instead of quickly deleting them to 
keep my inbox down.  There's already a couple dozen python-related lists 
there, so it seems logical to add these two as well.

I believe adding the lists is a simple matter of filling out some forms on 
the site.  However, it should only be done if the list owners want it done, 
which is why I'm asking...
--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] PreferencePanes in python

[Just v. R. <ju...@le...>]

Ronald Oussoren wrote:

> BTW. I couldn't get bundlebuilder to build the bundle for me, it
> always adds the shell-script wrapper which isn't needed here.

What arguments are you feeding bundlebuilder? I think if you only
specify -e (executable) and not -m (mainprogram) it doesn't create the
sh wrapper.

> Furthermore the output always has a '.app' suffix. More to look
> into...

Perhaps you need to use the BundleBuilder() class manually, it is meant
to be a generic bundle builder; buildapp() uses AppBuilder() which is --
as the name suggests <wink> -- specialized for .app bundles.

If neither satisfy your needs, let me know what you do need and I'll try
to incorporate it in bundlebuilder.py.

Just

[Pyobjc-dev] PreferencePanes in python

[Ronald O. <ron...@xs...>]

I think I have found a way to build preference panes in Python.

The following code seems to work just fine for loading and initializing 
a Python interpreter. The attached archive contains a complete (and 
rather lame) preference pane, run the shell-script to compile the 
Objective-C file and copy the prefpane to ~/Library/PreferencePanes to 
test.

Both the script and the ObjC code require a framework install of 
python, but modifying it for a normal python install is pretty trivial 
(as long as there is a libpython.{so,dylib,a}, Apple's python won't 
work).

Did I mis anything important? I know the PYTHONPATH is not correct, 
I'll look into that later.

BTW. I couldn't get bundlebuilder to build the bundle for me, it always 
adds the shell-script wrapper which isn't needed here. Furthermore the 
output always has a '.app' suffix. More to look into...

Ronald


#import <Foundation/Foundation.h>

#include <Python/Python.h>

#ifndef CLASSNAME
#define CLASSNAME testbundle
#endif


@interface CLASSNAME
{
}

+(void)load;

@end

@implementation CLASSNAME

+(void)load
{
	NSBundle* bundle;
	NSString* mainPath;
	FILE*     fp;

	bundle = [NSBundle bundleForClass:self];
	[bundle load];

	mainPath = [bundle pathForResource:@"__main__" ofType:@"py"];

	if (mainPath == NULL) {
		// TODO: Raise exception;
		abort();
	}

	if (!Py_IsInitialized()) {
		Py_Initialize();
	}

	fp = fopen([mainPath cString], "r");
	if (fp == NULL) {
		abort();
	}

	PyRun_SimpleFile(fp, [mainPath cString]);
}

@end

Re: [Pyobjc-dev] NSAppEnableForeground

[Jack J. <Jac...@or...>]

On donderdag, feb 13, 2003, at 22:34 Europe/Amsterdam, Bob Ippolito 
wrote:
> I could rewrite the patch again to try and find the symbol dynamically 
> and do nothing if it can't find it..

This sounds workable. If we assume the people responsible won't change 
the calling sequence in an incompatible way, and if we could ensure 
CPSEnableForegroundOperation wasn't called earlier than strictly 
necessary (i.e. when calling the first routine that would actually 
require the window manager) and if we would give a warning at that 
point if the call wasn't available then I might even be tempted to put 
this in the core.

Hmm, some of these "if"s could be left to user code, if we add a 
MacOS.EnsureForeground() which would return a yes/no/notsure indicator 
(or a MacOS.EnsureForeground(conservative=True/False) which would raise 
an exception if it didn't work (or couldn't make sure, or any of 
another number of interfaces that would allow the same functionality).
--
- 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 -

Re: [Pyobjc-dev] NSAppEnableForeground

[Bob I. <bo...@re...>]

On Thursday, Feb 13, 2003, at 16:14 America/New_York, Jack Jansen wrote:

>
> On donderdag, feb 13, 2003, at 21:28 Europe/Amsterdam, Ronald Oussoren  
> wrote:
>
>>
>> On Thursday, Feb 13, 2003, at 14:32 Europe/Amsterdam, Jack Jansen  
>> wrote:
>>
>>> I suggest everyone is *very* careful using  
>>> CPSEnableForegroundOperation. It comes up time and again, and most  
>>> recently there was a discussion on the Mac-Tk mailing list about it.  
>>> Jim, the MacTk lead engineer, happens to work at Apple, and he asked  
>>> the people responsible for CPSEnableForegroundOperation to make it  
>>> an official API, but they were unwilling to do so, specifically  
>>> because they want the freedom to change it at will. So you shuldn't  
>>> be surpirsed if you use this in an application and then see the  
>>> application breaking at the next minor MacOSX release:-(
>>
>> Is that list archived anywhere? Considering this information I'm  
>> starting to worry even more about the possible long term effects of  
>> adding this.
>
> It's the tcl-mac list at sourceforge. Look at Jim's postings of  
> 13-Nov-2002:
> https://sourceforge.net/mailarchive/ 
> forum.php?forum_id=3853&max_rows=25&style=flat&viewmonth=200211&viewday 
> =12
>
> In reality it's a bit different than I remembered it, though:
> - the responsible people didn't specifically want to change it, they  
> wanted to be able to decide whether to open it up later.
> - The good news is that they seem to think that this whole business of  
> having to run in a .app bundle may really be a bug...

I could rewrite the patch again to try and find the symbol dynamically  
and do nothing if it can't find it.. but anyways, I just made a diff  
that doesn't require libFoundation.a, I also changed setup.py to  
override "-flat_namespace -undefined suppress" with "-bundle_loader %s"  
% (resolve_to_actual_file(sys.executable),).. which would catch the  
symbol-doesn't-exist bug really quickly, and solves some other issues  
with python modules and namespaces..  I also added a FLAT_NAMESPACE  
flag to the top of setup.py, so if someone were to try and backport to  
10.1 they could just turn it on and the -bundle_loader replacement  
wouldn't happen anymore.

-bob

Re: [Pyobjc-dev] NSAppEnableForeground

[Jack J. <Jac...@or...>]

On donderdag, feb 13, 2003, at 21:28 Europe/Amsterdam, Ronald Oussoren  
wrote:

>
> On Thursday, Feb 13, 2003, at 14:32 Europe/Amsterdam, Jack Jansen  
> wrote:
>
>> I suggest everyone is *very* careful using  
>> CPSEnableForegroundOperation. It comes up time and again, and most  
>> recently there was a discussion on the Mac-Tk mailing list about it.  
>> Jim, the MacTk lead engineer, happens to work at Apple, and he asked  
>> the people responsible for CPSEnableForegroundOperation to make it an  
>> official API, but they were unwilling to do so, specifically because  
>> they want the freedom to change it at will. So you shuldn't be  
>> surpirsed if you use this in an application and then see the  
>> application breaking at the next minor MacOSX release:-(
>
> Is that list archived anywhere? Considering this information I'm  
> starting to worry even more about the possible long term effects of  
> adding this.

It's the tcl-mac list at sourceforge. Look at Jim's postings of  
13-Nov-2002:
https://sourceforge.net/mailarchive/ 
forum.php?forum_id=3853&max_rows=25&style=flat&viewmonth=200211&viewday= 
12

In reality it's a bit different than I remembered it, though:
- the responsible people didn't specifically want to change it, they  
wanted to be able to decide whether to open it up later.
- The good news is that they seem to think that this whole business of  
having to run in a .app bundle may really be a bug...
--
- 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 -

Re: [Pyobjc-dev] NSAppEnableForeground

[Ronald O. <ous...@ci...>]

On Thursday, Feb 13, 2003, at 14:32 Europe/Amsterdam, Jack Jansen wrote:

> I suggest everyone is *very* careful using 
> CPSEnableForegroundOperation. It comes up time and again, and most 
> recently there was a discussion on the Mac-Tk mailing list about it. 
> Jim, the MacTk lead engineer, happens to work at Apple, and he asked 
> the people responsible for CPSEnableForegroundOperation to make it an 
> official API, but they were unwilling to do so, specifically because 
> they want the freedom to change it at will. So you shuldn't be 
> surpirsed if you use this in an application and then see the 
> application breaking at the next minor MacOSX release:-(

Is that list archived anywhere? Considering this information I'm 
starting to worry even more about the possible long term effects of 
adding this.

I understand this is usefull for some people, but I don't want to add 
this to the core. I am willing to introduce a seperate module (Say 
'objc.hacks') that contains just NSAppEnableForeground, that way we're 
sure that sudden changes to this API won't hurt the users that don't 
care about this function (e.g. what if Apple suddenly decides to remove 
this function, if we're not carefull the bridge might break even if you 
don't call NSAppEnableForeground). However, I don't really care about 
this functionality and will probably remove it as soon as it is causing 
problems.

Ronald

Re: [Pyobjc-dev] NSAppEnableForeground

[Bob I. <bo...@re...>]

I'm pretty sure that's why there is the GetProcess / GetFrontProcess /  
SameProcess code in libForeground.a.  It *only* gets called when it's  
absolutely necessary.

On Thursday, Feb 13, 2003, at 08:32 America/New_York, Jack Jansen wrote:

> I suggest everyone is *very* careful using  
> CPSEnableForegroundOperation. It comes up time and again, and most  
> recently there was a discussion on the Mac-Tk mailing list about it.  
> Jim, the MacTk lead engineer, happens to work at Apple, and he asked  
> the people responsible for CPSEnableForegroundOperation to make it an  
> official API, but they were unwilling to do so, specifically because  
> they want the freedom to change it at will. So you shuldn't be  
> surpirsed if you use this in an application and then see the  
> application breaking at the next minor MacOSX release:-(
>
> On donderdag, feb 13, 2003, at 10:36 Europe/Amsterdam, Bob Ippolito  
> wrote:
>> Just to cover bases, CPSEnableForeground is exported by  
>> CoreGraphics.framework, which is part of ApplicationServices (and  
>> used by AppKit, which you can prove for yourself).
>> % nm  
>> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ 
>> Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics | grep  
>> CPSEnableForeground
>> 938a54b8 T _CPSEnableForegroundOperation
>>
>> I will do so once I find the time (likely Saturday or Sunday).. but  
>> you should note that the "number of other projects" that use  
>> CPSEnableForegroundOperation are __all__ straight up copied from my  
>> reverse engineering of the jar runtime, which I did somewhere between  
>> dec 2001 and jan 2002... The first project that actually used the  
>> code was pygame, as that was what I was working on at the time.   You  
>> can tell that it's all derived from my original work by the fact that  
>> they all use the same code:
>> CPSEnableForegroundOperation(&PSN,0x03,0x3C,0x2C,0x1103);
> --
> - 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 -
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] NSAppEnableForeground

[Jack J. <Jac...@or...>]

I suggest everyone is *very* careful using  
CPSEnableForegroundOperation. It comes up time and again, and most  
recently there was a discussion on the Mac-Tk mailing list about it.  
Jim, the MacTk lead engineer, happens to work at Apple, and he asked  
the people responsible for CPSEnableForegroundOperation to make it an  
official API, but they were unwilling to do so, specifically because  
they want the freedom to change it at will. So you shuldn't be  
surpirsed if you use this in an application and then see the  
application breaking at the next minor MacOSX release:-(

On donderdag, feb 13, 2003, at 10:36 Europe/Amsterdam, Bob Ippolito  
wrote:
> Just to cover bases, CPSEnableForeground is exported by  
> CoreGraphics.framework, which is part of ApplicationServices (and used  
> by AppKit, which you can prove for yourself).
> % nm  
> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ 
> Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics | grep  
> CPSEnableForeground
> 938a54b8 T _CPSEnableForegroundOperation
>
> I will do so once I find the time (likely Saturday or Sunday).. but  
> you should note that the "number of other projects" that use  
> CPSEnableForegroundOperation are __all__ straight up copied from my  
> reverse engineering of the jar runtime, which I did somewhere between  
> dec 2001 and jan 2002... The first project that actually used the code  
> was pygame, as that was what I was working on at the time.   You can  
> tell that it's all derived from my original work by the fact that they  
> all use the same code:
> CPSEnableForegroundOperation(&PSN,0x03,0x3C,0x2C,0x1103);
--
- 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 -

Re: [Pyobjc-dev] NSAppEnableForeground

[Bob I. <bo...@re...>]

On Thursday, Feb 13, 2003, at 01:26 America/New_York, Ronald Oussoren  
wrote:

>
> On Wednesday, Feb 12, 2003, at 22:47 Europe/Amsterdam, Bob Ippolito  
> wrote:
>
>> On Wednesday, Feb 12, 2003, at 16:03 America/New_York, Ronald  
>> Oussoren wrote:
>>
>>> As I mentioned in the patch tracker I'd prefer to not use private  
>>> functions of other libraries, even more so when those functions are  
>>> not exported.
>>>
>>> During development I prefer to use the -l option of bundlebuilder,  
>>> that way I don't have to rebuild the app bundle unless I add new  
>>> files and I get a normal application, including Info.plist and the  
>>> like.
>>>
>>> Ronald
>>
>> If it would make a difference, I can convert that libFoundation.a to  
>> source code (using an undocumented but exported function or two).  I  
>> know how it works, I wrote something nearly identical to it about a  
>> year ago (reverse-engineered the jar launcher).  But I figured it  
>> might "feel safer" to use Apple's own implementation.
>
> Please convert libFoundation to C, if I understand correctly this uses  
> CPSEnableForegroundOperation and while that is an undocumented  
> function it is at least exported from its framework and used by a  
> number of other projects.

Just to cover bases, CPSEnableForeground is exported by  
CoreGraphics.framework, which is part of ApplicationServices (and used  
by AppKit, which you can prove for yourself).
% nm  
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ 
Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics | grep  
CPSEnableForeground
938a54b8 T _CPSEnableForegroundOperation

I will do so once I find the time (likely Saturday or Sunday).. but you  
should note that the "number of other projects" that use  
CPSEnableForegroundOperation are __all__ straight up copied from my  
reverse engineering of the jar runtime, which I did somewhere between  
dec 2001 and jan 2002... The first project that actually used the code  
was pygame, as that was what I was working on at the time.   You can  
tell that it's all derived from my original work by the fact that they  
all use the same code:
CPSEnableForegroundOperation(&PSN,0x03,0x3C,0x2C,0x1103);

I bet if you ask ANYONE that uses it, nobody can say what the purpose  
of the 0x03, 0x3C, 0x2C, 0x1103 are.  I never knew myself, they  
probably aren't actually arguments at all (see paragraph after next).

The fact that other projects use this function should not affect your  
decision on whether or not to use it, at least on my account, because  
it's *my fault* that other projects use it in the first place :)  As a  
quick fix I'm recommending the Apple implementation, but if I must  
write my own [again] to get into PyObjC - so be it.

That specific code is the result of on or two runs through gdb (reverse  
engineering the jar runtime), and that's what the registers told me.. I  
didn't know how many arguments it was actually expecting so I just made  
the call from what I saw in the dump, and it worked.. and I realized  
that since they're passed by register on PPC it really didn't matter if  
you specify extra ones.  Everyone has used this line of code for over a  
year now, even after a major upgrade to OS X, and it's Just Worked...  
surprisingly or not :)

Anyways, after looking at the disassembly of Apple's libForeground from  
GLUT this week, it's pretty obvious to me that  
CPSEnableForegroundOperation doesn't require all of these arguments. In  
my opinion, it's highly likely that CPSEnableForegroundOperation only  
requires the pointer to ProcessSerialNumber.. there's certainly not  
enough lines of PPC assembly in the otool -tVv output of libFoundation  
to specify 5 arguments.  I'll figure this out definitively when I get  
around to providing you with the equivalent C source to libForeground.a.

> Could you also add a (short) docstring?

Yeah, I'll do that when I add the C code.

-bob

Re: [Pyobjc-dev] NSAppEnableForeground

[Ronald O. <ous...@ci...>]

On Wednesday, Feb 12, 2003, at 22:47 Europe/Amsterdam, Bob Ippolito 
wrote:

> On Wednesday, Feb 12, 2003, at 16:03 America/New_York, Ronald Oussoren 
> wrote:
>
>> As I mentioned in the patch tracker I'd prefer to not use private 
>> functions of other libraries, even more so when those functions are 
>> not exported.
>>
>> During development I prefer to use the -l option of bundlebuilder, 
>> that way I don't have to rebuild the app bundle unless I add new 
>> files and I get a normal application, including Info.plist and the 
>> like.
>>
>> Ronald
>
> If it would make a difference, I can convert that libFoundation.a to 
> source code (using an undocumented but exported function or two).  I 
> know how it works, I wrote something nearly identical to it about a 
> year ago (reverse-engineered the jar launcher).  But I figured it 
> might "feel safer" to use Apple's own implementation.

Please convert libFoundation to C, if I understand correctly this uses 
CPSEnableForegroundOperation and while that is an undocumented function 
it is at least exported from its framework and used by a number of 
other projects.

Could you also add a (short) docstring?

Ronald

Re: [Pyobjc-dev] NSAppEnableForeground

[Bob I. <bo...@re...>]

On Wednesday, Feb 12, 2003, at 16:03 America/New_York, Ronald Oussoren 
wrote:

> As I mentioned in the patch tracker I'd prefer to not use private 
> functions of other libraries, even more so when those functions are 
> not exported.
>
> During development I prefer to use the -l option of bundlebuilder, 
> that way I don't have to rebuild the app bundle unless I add new files 
> and I get a normal application, including Info.plist and the like.
>
> Ronald

If it would make a difference, I can convert that libFoundation.a to 
source code (using an undocumented but exported function or two).  I 
know how it works, I wrote something nearly identical to it about a 
year ago (reverse-engineered the jar launcher).  But I figured it might 
"feel safer" to use Apple's own implementation.

I understand your preference, however, I wouldn't want to force your 
particular preference onto every user of PyObjC (particularly people 
who are using other frameworks that have PyObjC as a dependency).  I 
don't want to have to teach every user of pygame to use bundlebuilder 
before running their source code on OS X.  I'd like it to Just Work.  
Of course bundlebuilder is the Right Way, and I would mandate that for 
actual distribution of applications.. but if there's a more familiar 
way that developers can use, and it works with enough success to make 
it usable, why can't we have that as a non-harmful alternative (*if* 
you call it when running from a bundled app, it's a no-op)?  It's not 
like I'm arguing for cutting out the_underscores_everywhere_.  I just 
want one function in the source tree because I see it as useful to the 
OS X python community as a whole in a number of situations (primarily 
developers migrating from other platforms).

I'm not asking you to *use* this function anywhere in PyObjC.  You can 
even leave it undocumented if you want.  But I'd rather have it there 
than put it in pygame (and potentially other GUI frameworks that need 
this functionality) where it doesn't really belong.

-bob

Re: [Pyobjc-dev] NSAppEnableForeground

[Ronald O. <ous...@ci...>]

As I mentioned in the patch tracker I'd prefer to not use private 
functions of other libraries, even more so when those functions are not 
exported.

During development I prefer to use the -l option of bundlebuilder, that 
way I don't have to rebuild the app bundle unless I add new files and I 
get a normal application, including Info.plist and the like.

Ronald

[Pyobjc-dev] NSAppEnableForeground

[Bob I. <bo...@re...>]

I've just submitted a patch on sourceforge to enable foreground 
operation of NSApplication if started outside of a bundle (i.e. python 
MyApp.py).

Please put this in the tree, it doesn't hurt anything by being there, 
and it helps significantly during the development phase of projects.  
It has no effect when called if the application has been properly 
started from a bundle.

The next version of pygame for OS X is going to have PyObjC as a 
dependency, and it's going to depend on this function if a user wants 
to test a project from the commandline.

PyOpenGL already has this functionality, because this function (called 
__glutSetForeground, from libForeground.a) is internal to the GLUT 
framework (part of the glutInit call).

-bob

[Pyobjc-dev] flat_namespace is _bad_

[Bob I. <bo...@re...>]

Just a note that I think you all should know, if you're trying to port 
*any* python modules to OS X 10.2's Python 2.2, it's a *really good 
idea* to edit /usr/lib/python2.2/config/Makefile and make this change:

LDSHARED=   $(CC) $(LDFLAGS) -bundle -bundle_loader /usr/bin/python
BLDSHARED=  $(CC) $(LDFLAGS) -bundle -bundle_loader /usr/bin/python
#LDSHARED=  $(CC) $(LDFLAGS) -bundle -flat_namespace -undefined suppress
#BLDSHARED= $(CC) $(LDFLAGS) -bundle -flat_namespace -undefined suppress

In addition to removing the -arch i386 from elsewhere in the file, 
which you presumably already have if you've gotten this far.

Basically what I really ran into problems with was PyOpenGL, the same 
symbols were defined in multiple modules.. I could load one, but not 
the others.  Now I can load them all (I'm still not sure if they work 
or not.. but.. they compile and load now).

-bob

[Pyobjc-dev] my little app

[Gus M. <gu...@mu...>]

So I was playing with Konfabulator ( http://www.konfabulator.com/ ) and
thinking to myself... I wonder if something similar could be done in
python...

Well, not exactly similar, but kinda neat for a little hack- I wrote a
little widget like thing with pyobjc if anyone wants to run it.  It uses
xmlrpc to talk to a perl script on my server that brings back a fortune.

http://gusmueller.com/x/GizmoWOLibs.tgz (187k)
http://gusmueller.com/x/Gizmo.tgz (1003k)

The first link is the app without the pyobjc stuff in the Resources dir.
Also, It's a background app (and takes a while to start up), so if you
want to quit it, right click on it and choose "quit"

I was also wondering... how hard would it be to create little bundles
of these, and load them up dynamically?  Something for me to explore in
the future anyway.

thanks for the cool python bridge,

-gus

-- 
"Christmas means carnage!"  -- Ferdinand, the duck

Re: [Pyobjc-dev] nswindow subclass

[Just v. R. <ju...@le...>]

Gus Mueller wrote:

> > You can simply add 'import PydgetWindow' in __main__.py [assuming
> > that is the name of the source file]...
> 
> It wasn't a python file, it was a compiled objc class.. but I did
> what you described, and that worked just fine.
> 
> But now I'm slightly curious why the other way didn't work.  Maybe
> I'll play with it a little bit more.

That's because the app as you compile it is merely a wrapper that starts
a new process. (Read the main .m file for details and look for execve.
For the _reasons_ of this, check the list archives...)

I _think_ what could work is building a minimal C extension that
contains the class and import that. While that's definitely more work
than adding a .m file to your project, it can probably be streamlined
with a template. I haven't heard of anyone who actually _did_ this, but
I don't see why it wouldn't work. Would be nice to find out, though...

Just

Re: [Pyobjc-dev] nswindow subclass

[Gus M. <gu...@mu...>]

bb...@ma... (bb...@ma...) wrote:
> On Tuesday, Feb 11, 2003, at 15:02 US/Eastern, Gus Mueller wrote:
> >However, when I try and run it, I get the following message:
> >"Unknown Window class PydgetWindow in Interface Builder file,
> >	 creating generic Window instead"
> 
> Assuming that PydgetWindow is implemented in a python file, did you 
> load the file/module before the NIB file was loaded?
> 
> That is, are you sure that the class is defined prior to loading the 
> NIB file?
> 
> You can simply add 'import PydgetWindow' in __main__.py [assuming that 
> is the name of the source file]...

It wasn't a python file, it was a compiled objc class.. but I did what
you described, and that worked just fine.

But now I'm slightly curious why the other way didn't work.  Maybe I'll
play with it a little bit more.

thanks,
 
-gus

-- 
"Christmas means carnage!"  -- Ferdinand, the duck

Re: [Pyobjc-dev] nswindow subclass

[<bb...@ma...>]

On Tuesday, Feb 11, 2003, at 15:02 US/Eastern, Gus Mueller wrote:
> However, when I try and run it, I get the following message:
> "Unknown Window class PydgetWindow in Interface Builder file,
> 	 creating generic Window instead"

Assuming that PydgetWindow is implemented in a python file, did you 
load the file/module before the NIB file was loaded?

That is, are you sure that the class is defined prior to loading the 
NIB file?

You can simply add 'import PydgetWindow' in __main__.py [assuming that 
is the name of the source file]...

b.bum

[Pyobjc-dev] nswindow subclass

[Gus M. <gu...@mu...>]

I searched the archives for "nswindow", so apologies if this has
already been answered already...

I created a new Cocoa-Python Application, compiled it and it worked
fine, I then wanted to see if I could make the window a custom one (for
some silly ideas I've got).. so I created a custom class called
PydgetWindow that extended NSWindow, and made the Window instance in the
MainMenu.nib file a custom class of the same type (PydgetWindow).

However, when I try and run it, I get the following message:
"Unknown Window class PydgetWindow in Interface Builder file,
	 creating generic Window instead"

This technique works out fine for a regular objc project, is this
something that is possible with pyobjc ?

thanks,

-gus

-- 
"Christmas means carnage!"  -- Ferdinand, the duck

Re: [Pyobjc-dev] NSString & mutability

[Mike F. <mi...@lo...>]

I am not entirely clear about what exactly is being discussed here... 
this message was forwarded to me by Bill.

I will make the point (which Bill already undoubtedly knows) that in 
Cocoa the types declared for arguments and return values in the API are 
more about what the caller can do with the return value or what the 
method will do with the argument rather than what the return value 
really will be or what the argument must be.

For example, NSView's -subviews method is declared to return an 
NSArray.  Forever it has actually returned an NSMutableArray: the one 
it uses to manage its subviews.  The fact that it declares the return 
value is NSArray means that the caller is not allowed to change it, not 
that it CANNOT be changed.  In reverse, NSWindow's -setTitle: takes an 
NSString.  That does not mean I cannot pass it an NSMutableString, it 
means that under no circumstances will the window alter the string, 
even if it is mutable.

Mike


Begin forwarded message:

> From: bb...@ma...
> Date: Tue Feb 4, 2003  1:37:00 PM US/Pacific
> To: pyo...@li..., mf...@lo...
> Subject: Re: [Pyobjc-dev] NSString & mutability
>
> On Tuesday, Feb 4, 2003, at 15:56 US/Eastern, Just van Rossum wrote:
>> I'm totally willing to accept a surprise like that. I don't even see 
>> the
>> problem when using such an API from Python: you call
>> fooObject.setMyNameIs_() with a Python string, you call myNameIs() and
>> get a Python string. Same string, different id. No problem in Python.
>
> I'm not willing to accept a surprise like that because it will greatly 
> reduce the value of PyObjC in quite a number of situations.   This is 
> not idle speculation.   I have made the same mistake in the past 
> [creating a bridge that was dependent on internal implementation of 
> underlying frameworks] and it rendered the bridge [Tcl <-> ObjC, in 
> this case] nearly useless until it was fixed -- it broke-- or 
> sometimes didn't break-- depending on what order the user did things 
> simply because some random bit of code somewhere chose to return 
> *this* private subclass vs. *that* private subclass as some internal 
> optimization hack that was *not* apparent, no relevant to, the 
> advertised API.
>
> The fundamental problem is that partial conversion relies on the 
> internal implementation to stay the same over time.   The current 
> behavior does not;  it remains consistent.  Partial conversion 
> behavior that is dependent upon the internal implementation of 'third 
> party' [Apple is a third party, in this case] frameworks will lead to 
> behavior that changes over time and through factors outside of our 
> control.
>
> More below....
>
>> Can you please give an example of an _actual_ problem? I'll have a go
>> myself:
>
> Off the top of my head, no-- I can't remember a specific example.  But 
> that is mostly because I have been relying on the APIs as advertised 
> by the classes and not their internal implementations for long enough 
> that I haven't had this problem in a while.   It *does* come up on the 
> mailing lists on occasion, but searching for "nsmutablestring nsstring 
> return" yields an awful lot of noise hits.
>
>> Let's assume the API does the reverse: it takes an immutable string, 
>> yet
>> returns its internal mutable copy, although myNameIs is declared to
>> return an NSString. Now there _is_ a surprise: instead of a 100%
>> equivalent string we get an NSMutableString instance. Ok, a surprise,
>> but is it so bad? If the object internally uses a mutable string, it's
>> likely that this is clear from the nature of the object (eg. it's some
>> sort of editor for the string). So I still think such a surprise will 
>> be
>> rare.
>
> I agree that the situations where this arise will be rare.   But, when 
> they do arise, the results are the absolute worst kinds of bugs in the 
> world to fix.  It breaks on customer A's computer, but not customer 
> B's -- but they are [supposedly] identical.  Oh, wait a minute, 
> Customer B upgraded to version 1.234b of the some random plugin while 
> customer A is still using 1.233.
>
> Another exmaple: What if Mike [who I included in this because he may 
> have some useful input-- sorry, Mike :-] changes the implementation of 
> TextExtras and throws an NSMutableString into some random object 
> collection that ends up on the other side of the bridge at some point? 
>   The Python developer is screwed if there code breaks.
>
> What happens when Apple ships the 10.2.5 update and they change some 
> random bit of internal implementation such that a method that used to 
> return (NSMutableString*) now *always* returns (NSString*)?   Assuming 
> the PyObjC developer can figure out what is going on, are they now 
> supposed to write OS X version specific code at the x.x.1 level?
>
> Now-- what about the developers that will be using PyObjC with 
> multiple thousands of lines of code embedded in random frameworks 
> across some large scale system?   For them, the choice of using PyObjC 
> now comes with the cost of having to ensure that every method that 
> *may* return an NSMutableString* when it is declared with an NSString* 
> return value is identified and compensated for.   This is not a 
> contrived example-- I and a number of people I have been in contact 
> with since PyObjC became a visible project again-- have used PyObjC in 
> this context in the past and are planning on doing so in the future 
> [some already are].   This would be a deal killer for them.
>
> Bottom line:  PyObjC -- just like the AppleScript in an AS Studio 
> project or a good chunk of the ObjC in a pure ObjC Cocoa app -- is the 
> glue that holds together all of the random objects in a fashion that 
> solves whatever problem the developer is trying to address.   The 
> developer does not have full and complete control over those objects-- 
> heck, there may be entire chunks of implementation present that their 
> code has no awareness of whatsoever [TextExtras].    For such a system 
> to work, the objects must be glued together as advertised by the APIs. 
>   To do otherwise will render a system that is fragile.  Worse, it 
> will create a system whose fragility is dependent upon unreasonable 
> expectations.
>
> It is reasonable to expect-- and history indicates it is true-- that 
> the behavior of the NSCell API will remain consistent going forward.  
> It is unreasonable to expect that the internal implementation will 
> remain consistent over time, yet that is exactly what a partial 
> conversion solution expects.
>
> b.bum
>

Re: [Pyobjc-dev] pth files in Resources

[Bob I. <bo...@re...>]

On Monday, Feb 10, 2003, at 16:15 America/New_York, Bob Ippolito wrote:

> In the project templates, __main__.py should have the following code:
>
> import sys, site
> # preserve original length so we can reorder
> lenPath = len(sys.path)
> # scan for .pth files in Resources (current directory)
> site.addsitedir('')
> # reorder the path so we'll load stuff in the bundle before anything 
> in site-packages or elsewhere
> sys.path[:] = sys.path[lenPath:] + sys.path[:lenPath]
>
> -bob

actually, that should be site.addsitedir(sys.path[0]) ..

[Pyobjc-dev] Re: pth files in Resources

[Bob I. <bo...@re...>]

On Monday, Feb 10, 2003, at 16:15 America/New_York, Bob Ippolito wrote:

>
> import sys, site
> # preserve original length so we can reorder
> lenPath = len(sys.path)
> # scan for .pth files in Resources (current directory)
> site.addsitedir('')
> # reorder the path so we'll load stuff in the bundle before anything 
> in site-packages or elsewhere
> sys.path[:] = sys.path[lenPath:] + sys.path[:lenPath]

if not getattr(__builtins__, 'True', None):
     __builtins__.True = not 0
     __builtins__.False = not not 0

might also be useful..  Some of the Mac modules I backported to jaguar 
python may or may not depend on True and False, I had to add it to my 
site.py to get them to compile + install.

-bob

[Pyobjc-dev] pth files in Resources

[Bob I. <bo...@re...>]

In the project templates, __main__.py should have the following code:

import sys, site
# preserve original length so we can reorder
lenPath = len(sys.path)
# scan for .pth files in Resources (current directory)
site.addsitedir('')
# reorder the path so we'll load stuff in the bundle before anything in 
site-packages or elsewhere
sys.path[:] = sys.path[lenPath:] + sys.path[:lenPath]

-bob

Re: [Pyobjc-dev] strings returned from ObjC are now unicode?

[Chris R. <cp...@em...>]

On Sunday, February 9, 2003, at 06:40  AM, Ronald Oussoren wrote:

> On Sunday, Feb 9, 2003, at 09:23 Europe/Amsterdam, Just van Rossum 
> wrote:
>
>> Chris Ryland wrote:
>>
>>> The latest CVS seems to return unicode strings from objc
>>> string-producing calls.
>>>
>>> Is that the final decision about this hotly-debated topic?
> Converting NSStrings to unicode was only a sidetrack of the string 
> related discussions ;-).
>>
>> I'm not sure it's final, but is it a problem for you? NSStrings can
>> always contain unicode so I think it's a good signal to the user (of
>> PyObjC ;-) to always return unicode strings.
>
> This is partially because I was lazy and only subclassed 
> __builtin__.unicode, but mostly because NSStrings are unicode strings. 
> Unless returning unicode strings proves to be a real problem I'd like 
> to keep it this way (if you want a string you can always do the 
> conversion yourself).

I'm afraid I'm not experienced enough with Python to know whether this 
would be a problem in the long term, but it shouldn't, in theory (let's 
hope Python's Unicode support is robust enough ;-), and it's the right 
reflection of the NSString reality, as you say.

Cheers!
--Chris Ryland / Em Software, Inc. / www.emsoftware.com