pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] Project Templates

[Bill B. <bb...@co...>]

I have added a bunch of [ReST] documentation to the 00README.txt in 
Project Templates.   If any of you has a chance, have a read and let me 
know if there are major holes.   I really don't want to create a 
project template for every possible permutation -- some projects can 
provide examples for how to set up features of others.

I have framework python installed on my machine and am going to do the 
embedded project templates against that -- it is much more likely that 
anyone with an embeddable command line version of Python will know how 
to modify the framework project to embed their command line interpreter.

b.bum

[Pyobjc-dev] Bridging NSRectFillList()

[Bill B. <bb...@co...>]

I added bridge code for NSRectFillList() in _AppKit.m.     For 
example....

     def drawRect_(self, aRect):
         if self.backingStore:
             self.backingStore.draw()
         else:
             self.eraseView_(aRect)

         for pointArray, rectCount, color in self.pointsCountsAndColors:
             color.set()
             NSRectFillList(pointArray, rectCount)

         self.pointsCountsAndColors = []
         self.backingStore = 
NSBitmapImageRep.alloc().initWithFocusedViewRect_(self.bounds())

... where pointArray was created as ....

         pointsArray = array.array('f', [0.0,0.0,1.0,1.0] * len(points))
         rectCount = 0
         for p in points:
             x = int(round(p[0]))
             y = int(round(p[1]))
             if (x >= 0) and (x < pixelsWide) and (y >= 0) and (y < 
pixelsHigh):
                 pointsArray[ (rectCount * 4) ] = x
                 pointsArray[ (rectCount * 4) + 1 ] = y
                 rectCount += 1

         self.pointsCountsAndColors.append((pointsArray, rectCount, 
aColor))

... the rectCount argument is optional.  In this case, I preallocate 
the array to the maximum number of points and then count only the 
points that fall within the bounds of the view.

In any case, this pattern of bridging is very, very fast and the 
addition to _AppKit.m is quite straightforward.

b.bum

Re: [Pyobjc-dev] In and out of NSData

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

On Friday, Jan 10, 2003, at 16:28 US/Eastern, Ronald Oussoren wrote:
> I found where this problem originates: inside Cocoa :-(. I can 
> probably get a simular crash using pure objective-C code (I've not 
> tested this, hence the 'probably').

Ugh...

Maybe we need to create a list of selectors for which the return value 
should be followed as 'self' and not the initial target of the method 
call.

This would also address situations like the following:

- init
{
     if (self = [super init]) {
	    // local initialization
     }

     return self;
}

I would think we could get away with a simple NSMapTable() to do the 
hashing of the SELs that need the kind of test as indicated above.   
NSMap*() makes it fast and can use the SEL type directly as the hash.   
The assumption is that any of the methods of a given selector will all 
behave the same -- as we are really only dealing with -init* selectors 
[that I can think of], this would seem to be safe assumption.

I'm not sure what other implications this might have.   If we can find 
a generalized solution, it will mitigate maintenance issues down the 
road.

b.bum

[Pyobjc-dev] Playing with pyobjc graphics: CycleLab

[Dinu G. <gh...@da...>]

Hi, I'm most impressed how easy it is to do some graphics programming
using PyObjC!

I revisited a former little project of mine, that was first proto-
typed in Python, then written in Obj-C as a screensaver module (it is
still available, but strangely not running anymore on OS X > 10.1).
Now I've backported the crucial bits to Python again (but using na-
tive Cocoa graphics), mostly to see if the graphics is reasonable and
in terms of coding it certainly is. About performance I can't say much
now, though.

Here something for your entertainment, put in a temp. place, unless
you deem it interesting enough to deserve a more prominent home:

   http://python.net/~gherman/tmp/CycleLab.tgz  - source
   http://python.net/~gherman/tmp/CycleLab.jpg  - screenshot
   http://python.net/~gherman/tmp/CycleLab.mov  - movie, 1 min, 116 K
   http://python.net/~gherman/#TimeCycler       - screensaver

All this makes me wonder if it would be an all-too-perverted idea
to try writing something like an wxPython interface to Cocoa (using
PyObjC!)?! But I heard rumours, Robin Dunn was already working on
a native port...

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"I want to put a ding in the universe." (Steve Jobs)

Re: [Pyobjc-dev] Merging pyobj with objc?

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

On Friday, Jan 10, 2003, at 16:33 US/Eastern, Jack Jansen wrote:
> If you're willing to forego using Apple's Python you don't need the 
> bootstrap program, you can call out to Python directly. But Apple 
> didn't provide a framework or a shared library, only the interpreter 
> itself, so there's no simple way to embed Python.

I will have Project Builder templates for all of these cases shortly-- 
tonight or tomorrow.  I'm flying back stateside on Sunday, so it may 
not make it into the repository until early next week.

Also:   to access the closses, use the objc.loadBundle() function.   
That will cause all of the classes to be load and bound appropriately.  
If you pass globals() as the variable context, then the classes will be 
available in your code just as if you had done a 'from MyFramework 
import *'

See Lib/Foundation/__init__.py for an example.

Sorry this is terse-- I have a lot of docs on my computer now, want to 
finish and commit asap.

b.bum

Re: [Pyobjc-dev] Bridging NS and CF classes

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

On Friday, Jan 10, 2003, at 05:52 US/Eastern, Jack Jansen wrote:
> What I could do on the CF side (and what I already do, up to a point) 
> is add special cases only for the CFType objects for which I know the 
> CFTypeID.  In other words: the default for any NS object would be to 
> be a CF.CFType object. But for various types I would return a better 
> wrapper (CFString, CFArray, etc).

Cool.  So that means an ObjC object can be passed as a reference 
throughout the CF APIs and-- hopefully-- can eventually be turned back 
into an Py-wrapped ObjC object when it comes back to Python.  I'm sure 
there are some issues.

> I am working on the assumption here that CFType == NSObject, so that 
> any NS object is representable as a CFType, is that assumption > correct?

Testing would indicate that that does seem to be the case, but I can't 
find specific documentation indicating that it is anything but 
coincidental.

b.bum

Re: [Pyobjc-dev] Merging pyobj with objc?

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

On vrijdag, jan 10, 2003, at 21:29 Europe/Amsterdam, Dinu Gherman wrote:

> Ronald Oussoren:
>
>> What you'll have to do is create a seperate bundle or framework and 
>> then load that from your python script. You can then use 
>> objc.lookUpClass() to access your classes.
>
> Isn't that a little cumbersome? Could there be an easier way, too?

If you're willing to forego using Apple's Python you don't need the 
bootstrap program, you can call out to Python directly. But Apple 
didn't provide a framework or a shared library, only the interpreter 
itself, so there's no simple way to embed Python.
--
- 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] In and out of NSData

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

On Wednesday, Jan 8, 2003, at 07:40 Europe/Amsterdam, Ronald Oussoren 
wrote:

>
> On Tuesday, Jan 7, 2003, at 16:30 Europe/Amsterdam, Bob Ippolito wrote:
>
>> I updated to latest CVS.. it seems that you may now initialize 
>> NSData/NSMutableData with a python string or an array, but it breaks 
>> for big ones.
>>
>> >>> from Foundation import *
>> >>> import array
>> >>> bytes = array.array('b', 'abcdef')
>> >>> NSData.alloc().initWithBytes_length_(bytes, len(bytes))
>> <a07e>
>> >>> NSMutableData.alloc().initWithBytes_length_(bytes, len(bytes))
>> <a07eda48 00000001 00000000 00000054 007db1e0 00000000 00000000 
>> 00000001 76304034 3a385e76 31324931 36000001 76304034 3a384931 
>> 32000000 00010002 76>
>> >>> bytes = array.array('b', 'abcdef' * 1000)
>> >>> NSData.alloc().initWithBytes_length_(bytes, len(bytes))
>> Segmentation fault
>>
>
> You can work around this by using 'NSData.dataWithBytes_length_' for 
> now. There seems to be a problem with reference counts (based on a 
> quick glance at a traceback in gdb), the segfault is caused by the 
> release of 'self' when deallocating the bound method 
> 'initWithBytes_length_', and this self doesn't have a valid 'isa' 
> pointer.

I found where this problem originates: inside Cocoa :-(. I can probably 
get a simular crash using pure objective-C code (I've not tested this, 
hence the 'probably').

	{
		id initial = nil;
		id post = nil;

		initial = [NSData alloc];
		post = [initial initWithBytes:"XXX ... repeat as needed" len:30];
		// here 'initial' is no longer a pointer to a valid object ...
		[initial description]; // CRASH
	}

I've observed the the corruption of 'initial' by adding an appropriate 
NSLog after the call to initWithBytes in 
Modules/Cocoa/_FoundationMapping_NSData. I think this is a feature of 
Cocoa that is needed to avoid leaks with the idiom [[NSData alloc] 
initWithBytes:foo len:bar], because NSData is a class-cluster the 
result of [NSData alloc] cannot be the same object as the one returned 
by initWithBytes:len:. Actually, [NSData alloc] seems to return an 
empty NSConcreteData object, that's probably why it only fails with a 
large-enough buffer.

Sadly enough just bracketing the call to initWithBytes with [self 
retain] and [self release] doesn't help: I then get a abort() on the 
call to [self release]: calling method of a freed object.

My current workaround: Just set the pointer inside the proxy object to 
NULL. I'll check this in after verifying that this won't cause problems 
later on.

Ronald

Re: [Pyobjc-dev] Merging pyobj with objc?

[Dinu G. <gh...@da...>]

Ronald Oussoren:

> What you'll have to do is create a seperate bundle or framework and 
> then load that from your python script. You can then use 
> objc.lookUpClass() to access your classes.

Isn't that a little cumbersome? Could there be an easier way, too?
Or, have you got a sample for it?

Thanks,

Dinu

--
Dinu C. Gherman
......................................................................
"Dancing is a vertical expression of a horizontal desire."
(George Bernard Shaw)

Re: [Pyobjc-dev] Merging pyobj with objc?

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

On Friday, Jan 10, 2003, at 18:51 Europe/Amsterdam, Dinu Gherman wrote:

> Hi, I'm trying to understand if and how it is possible to create
> PB projects containing Python *and* Objective-C sources.
>
> So far, I found that I can just add Obj-C .h/.m files and they seem
> to compile using the Python template project as there are .o files
> generated in the output.

They'll get compiled into the bootstrap program, but as that is only 
used to start /usr/bin/python with the right argv vector that isn't 
very usefull.

What you'll have to do is create a seperate bundle or framework and 
then load that from your python script. You can then use 
objc.lookUpClass() to access your classes.

Ronald

Re: [Pyobjc-dev] Merging pyobj with objc?

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

Dinu Gherman wrote:

> What seems to be the real challenge, though, is to *use* such kind
> of classes from Python code again. Simply importing them doesn't
> work and I wonder what's needed to make that work? Maybe a change
> in the main file?

I'd think that with objc.lookUpClass(className) you should be able to
access any class registered with with the objc runtime.

Just

[Pyobjc-dev] Merging pyobj with objc?

[Dinu G. <gh...@da...>]

Hi, I'm trying to understand if and how it is possible to create
PB projects containing Python *and* Objective-C sources.

So far, I found that I can just add Obj-C .h/.m files and they seem
to compile using the Python template project as there are .o files
generated in the output.

What seems to be the real challenge, though, is to *use* such kind
of classes from Python code again. Simply importing them doesn't
work and I wonder what's needed to make that work? Maybe a change
in the main file?

Thanks,

Dinu

--
Dinu C. Gherman
......................................................................
"Dancers are the athletes of God." (Albert Einstein)

Re: [Pyobjc-dev] Bridging NS and CF classes

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

On Friday, Jan 10, 2003, at 04:52 Europe/Amsterdam, bb...@ma... wrote:
> I have asked if there is a transparent way of determining if a 
> particular type/object is bridged on cocoa-dev.  Hopefully, someone 
> there will cough up a clean and easy solution. :-)

What I could do on the CF side (and what I already do, up to a point) 
is add special cases only for the CFType objects for which I know the 
CFTypeID.  In other words: the default for any NS object would be to be 
a CF.CFType object. But for various types I would return a better 
wrapper (CFString, CFArray, etc).

I am working on the assumption here that CFType == NSObject, so that 
any NS object is representable as a CFType, is that assumption correct?
--
Jack Jansen, <Jac...@cw...>, 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] Bridging NS and CF classes

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

On Thursday, Jan 9, 2003, at 17:24 US/Eastern, Jack Jansen wrote:
> But that doesn't really matter: the PyObjC code could look at the type 
> of the Python object and pass any CoreFoundation object as the 
> corresponding NS object still.

Ideally, we could automatically determine that there is a 
representation of the given object / type ref on the other side of the 
bridge.

Two separate problems -- end result, a single message to return the 
'other' type.   Two slightly different problems, I think.

I have asked if there is a transparent way of determining if a 
particular type/object is bridged on cocoa-dev.  Hopefully, someone 
there will cough up a clean and easy solution. :-)

NS -> CF:

     NSLog(@"%@", CFCopyTypeIDDescription(CFGetTypeID([NSArray array])));
     NSLog(@"%@", CFCopyTypeIDDescription(CFGetTypeID([NSDictionary 
dictionary])));
     NSLog(@"%@", CFCopyTypeIDDescription(CFGetTypeID([NSMutableArray 
array])));
     NSLog(@"%@", CFCopyTypeIDDescription(CFGetTypeID([NSBundle 
mainBundle])));
     NSLog(@"%@", CFCopyTypeIDDescription(CFGetTypeID([NSUserDefaults 
standardUserDefaults])));
     NSLog(@"%@", CFCopyTypeIDDescription(CFGetTypeID([[NSObject alloc] 
init])));
     NSLog(@"%@", CFCopyTypeIDDescription(CFGetTypeID([[NSSet alloc] 
init])));
     NSLog(@"%@", 
CFCopyTypeIDDescription(CFGetTypeID([NSNotificationCenter 
defaultCenter])));

... spews ...

2003-01-09 22:17:26.077 asdfasdf[1835] CFArray
2003-01-09 22:17:26.079 asdfasdf[1835] CFDictionary
2003-01-09 22:17:26.079 asdfasdf[1835] CFArray
2003-01-09 22:17:26.142 asdfasdf[1835] CFType
2003-01-09 22:17:26.143 asdfasdf[1835] CFType
2003-01-09 22:17:26.143 asdfasdf[1835] CFType
2003-01-09 22:17:26.143 asdfasdf[1835] CFSet
2003-01-09 22:17:26.143 asdfasdf[1835] CFType

... and, as such, it appears that there is some potential to automate 
the test.

The 'conversion' method doesn't do any converting.  It simply does:

- (CFTypeRef) cfTypeRef
{
     if (.. test encapsulated object for CFness ..)
	    return encapsulatedObject;
     else
	    return nil;
}

I'm not going to pretend to speak for Ronald regarding adding a method 
to all Python encapsulated ObjC objects....

CF -> NS:

     Jack covered this in his message -- if all CF types inherit from a 
common base, then implementing a method that returns ref or nil, 
depending on if it is bridged.

b.bum

Re: [Pyobjc-dev] Subclassing.

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

On Thursday, Jan 9, 2003, at 19:53 Europe/Amsterdam, Mirko Viviani 
wrote:

> Ciao!
>
> I've implemented objc_addClass() and fixed some things but now there 
> is no
> way to call an objc method from a subclass:
>
> [mirko@rey] /usr/home/mirko/src/gnustep/pyobjc> python
> Examples/subclassing-objective-c.py
> <native-selector alloc of <objective-c class Demo at 0x8105780>>
> ->
> Traceback (most recent call last):
>   File "Examples/subclassing-objective-c.py", line 31, in ?
>     print "->", obj.retainCount();
> AttributeError: 'NoneType' object has no attribute 'retainCount'
>
>
> It seems that is not able to allocate a Demo object... how should I 
> check ?
>
'obj' is None, which means Demo.alloc returned a NULL pointer on the 
Objective-C side. Demo.alloc is implemented using 'class_method_alloc' 
in Modules/objc/class-builder.m, you could add print-statements there 
(or somehow add a breakpoint).

Ronald

Re: [Pyobjc-dev] Bridging NS and CF classes

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

On donderdag, jan 9, 2003, at 05:01 Europe/Amsterdam, bb...@ma... 
wrote:

> On Wednesday, Jan 8, 2003, at 18:03 US/Eastern, Jack Jansen wrote:
>> I think I would like the bridging to be done one-way, i.e. if 
>> something wants an NSArray and the argument isn't an NSArray it 
>> should try coercing the argument to an NSArray. One of the things 
>> that could be coerced is CF.CFArray.
>>
>> I think that for going the other way (from NS to CF) manual 
>> conversion is probably good enough initially.
>
> Won't work as there is no class identification on the arguments to 
> methods.

Ah, you're right of course, silly me...

But that doesn't really matter: the PyObjC code could look at the type 
of the Python object and pass any CoreFoundation object as the 
corresponding NS object still.

> Why can't we add enough stuff to both the CF* module(s) and the PyObjC 
> bridge such that both can transparently consume objects from the 
> other, where appropriate.

Yes. Except that it is easy for PyObjC to get access to Python's CF 
module (the bridge is in the core) and the other way around is 
difficult. So I would like an initial implementation to be in PyObjC 
for that reason. And hopefully for Python 2.5 PyObjC will be part of 
the core so the problem will disappear:-)

No, wait! I think the latter is doable too, see below.

>    This is basically what Apple did to ObjC and CF to create the 
> no-cost bridge -- it would seem that we need a parallel mechanism 
> within the "two" Python modules.
>
> That is, make the following work:
>
> >>> import _CF  #this is framework build, why do I do this and not 
> "CF"??
> >>> x = _CF.CFArrayCreateMutable(10)
> >>> from Foundation import NSMutableArray
> >>> NSMutableArray.addObject_(x, 'y')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: First argument must be an objective-C object, got 
> <CFMutableArrayRef object at 0x0012c0e0 for 0x00160000>

This is easy. If the argument isn't a PyObjC object then pass it to the 
C routine CFTypeRefObj_Convert(). If this succeeds you get back the C 
CF object and convert that to the corresponding NS object.

> And so should this:
>
> >>> import _CF
> >>> from Foundation import NSMutableArray
> >>> x = NSMutableArray.array()
> >>> _CF.CFArrayAppendValue(x, 'y')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> AttributeError: 'module' object has no attribute 'CFArrayAppendValue'

With some help from a PyObjC method  and a little different syntax this 
is indeed doable, if all PyObjC objects had a Python method that would 
return themselves as a CF object. The Python sequence would become
 >>> import _CF
 >>> from Foundation import NSMutableArray
 >>> x = NSMutableArray.array()
 >>> _CF.CFMutableArray(x).CFArrayAppendValue('y')

This would be implemented by having the CFArray() constructor look for 
a (say) "as_CF" [1] method and call that. as_CF() for PyObjC objects 
would do the cast to convert from an NS object to a CF object and then 
call the C routine CFTypeRefObj_New(), which returns the Python _CF 
object [2].

Footnotes:
[1] I picked "as_CF" here in stead of something like "PyObjC_asCF" 
because I think this functionality may be useful to more sources of CF 
objects than only PyObjC, but this is open to discussion.
[2] This won't work at the moment, as CFTypeRefObj_New will always 
return a CF.CFType object. Either this will have to change (which I 
think is reasonable: shortly CFArray will be a true subtype of CFType, 
and I think its reasonable for a constructor to return a "better" 
subtype) of we need to add a CFAny_New() routine.
--
- 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 -

[Pyobjc-dev] Subclassing.

[Mirko V. <mi...@ob...>]

Ciao!

I've implemented objc_addClass() and fixed some things but now there is no
way to call an objc method from a subclass:

[mirko@rey] /usr/home/mirko/src/gnustep/pyobjc> python
Examples/subclassing-objective-c.py 
<native-selector alloc of <objective-c class Demo at 0x8105780>>
->
Traceback (most recent call last):
  File "Examples/subclassing-objective-c.py", line 31, in ?
    print "->", obj.retainCount();
AttributeError: 'NoneType' object has no attribute 'retainCount'


It seems that is not able to allocate a Demo object... how should I check ?
 

Thanks.

-- 
Ciao
Mirko

[Pyobjc-dev] Bridging NS and CF classes

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

On Wednesday, Jan 8, 2003, at 18:03 US/Eastern, Jack Jansen wrote:
> I think I would like the bridging to be done one-way, i.e. if 
> something wants an NSArray and the argument isn't an NSArray it should 
> try coercing the argument to an NSArray. One of the things that could 
> be coerced is CF.CFArray.
>
> I think that for going the other way (from NS to CF) manual conversion 
> is probably good enough initially.

Won't work as there is no class identification on the arguments to 
methods.   As such, there is no way to implement a system as you 
described -- no way to identify [short of parsing the headers-- but 
that won't be completely correct] that a particular argument should be 
an instance of NSArray vs. an NSDictionary vs. a DeveloperDefined.

ObjC just doesn't care.

Why can't we add enough stuff to both the CF* module(s) and the PyObjC 
bridge such that both can transparently consume objects from the other, 
where appropriate.   This is basically what Apple did to ObjC and CF to 
create the no-cost bridge -- it would seem that we need a parallel 
mechanism within the "two" Python modules.

That is, make the following work:

 >>> import _CF  #this is framework build, why do I do this and not 
"CF"??
 >>> x = _CF.CFArrayCreateMutable(10)
 >>> from Foundation import NSMutableArray
 >>> NSMutableArray.addObject_(x, 'y')
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: First argument must be an objective-C object, got 
<CFMutableArrayRef object at 0x0012c0e0 for 0x00160000>

And so should this:

 >>> import _CF
 >>> from Foundation import NSMutableArray
 >>> x = NSMutableArray.array()
 >>> _CF.CFArrayAppendValue(x, 'y')
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
AttributeError: 'module' object has no attribute 'CFArrayAppendValue'

--

In the first case (CF type being messaged via PyObjC), a simple [I 
think] fix would be to add a method *on the C side* that can return a 
reference to the ObjC representation of the CF type.  In the handler 
that produces the TypeError as shown above, the PyObjC bridge could 
check to see if the object has a method/attribute/function/identifier 
that can be used to retrieve/identify what part of the object could be 
used directly as the ObjC instance to be messaged.

Something similar could be done for the second case, as well -- but I 
have *no* idea what the implementation issues would be in that context.

(I couldn't actually figure out how to call CFArrayAppendValue() on 
CFMutableArrayRef.)

b.bum

Re: [Pyobjc-dev] Changing the dock icon

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

Try NSImage.alloc().initWithContentsOfFile_()...

-initWithContentsOfFile: is an instance method, not a class method.   
That error message is slightly obscure, but that is what it means.

b.bum

On Wednesday, Jan 8, 2003, at 20:18 US/Eastern, David Casti wrote:
> On 1/8/03 5:11 PM, "Ronald Oussoren" <ous...@ci...> wrote:
>
>> You can use either AppKit.NSApp(), a function instead of a global
>> variable, or  NSApplication.sharedApplication() to access the
>> NSApplication instance for your application.
>
> OK, I've got AppKit.NSApp() going, but I need to feed an NSImage into
>
> The line I'm using is --
>
> closed_image = NSImage.initWithContentsOfFile_(
> '/Users/david/Documents/gr-star.tif' )
>
> -- which results in the following error --
>
> 2003-01-08 20:10:31.855 NewTunnels[851] First argument must be an
> objective-C object, got '/Users/david/Documents/gr-star.tif'

Re: [Pyobjc-dev] Changing the dock icon

[David C. <da...@ne...>]

On 1/8/03 5:11 PM, "Ronald Oussoren" <ous...@ci...> wrote:

> You can use either AppKit.NSApp(), a function instead of a global
> variable, or  NSApplication.sharedApplication() to access the
> NSApplication instance for your application.

OK, I've got AppKit.NSApp() going, but I need to feed an NSImage into

The line I'm using is --

closed_image = NSImage.initWithContentsOfFile_(
'/Users/david/Documents/gr-star.tif' )

-- which results in the following error --

2003-01-08 20:10:31.855 NewTunnels[851] First argument must be an
objective-C object, got '/Users/david/Documents/gr-star.tif'

-- the documentation for NSImage seems to suggest that I can put a path into
the function.  What is the correct way to create the NSImage so I can then
put that image into NSApp().setApplicationIconImage_ to change my dock icon?

Thanks,
David.

Re: [Pyobjc-dev] In and out of NSData

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

On woensdag, jan 8, 2003, at 23:06 Europe/Amsterdam, Ronald Oussoren 
wrote:
>> But: why would going CF->NS->CF change the type of the object?
> It wouldn't, but given the automatic translation from CF to NS (NOT 
> using the pyobjc_CFtoNS function) the following code would have 
> unexpected results:
>
> 	input = CF.CFMutableData(...)
> 	arr = Foundation.NSMutableArray.arrayWithArray([data])
> 	output = arr[0]
>
> At this point 'output is not input', the do not even have the same 
> type(). Converting it back to CF would of course recover an object of 
> the same type as 'input'.

I don't think this is too much of a problem. And there are already 
similar problems with Unicode vs. strings (try to get unicode data back 
where an NSString is returned:-).

I think I would like the bridging to be done one-way, i.e. if something 
wants an NSArray and the argument isn't an NSArray it should try 
coercing the argument to an NSArray. One of the things that could be 
coerced is CF.CFArray.

I think that for going the other way (from NS to CF) manual conversion 
is probably good enough initially.
--
- 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] NSRects and NSPoints as tuples...

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

On woensdag, jan 8, 2003, at 22:58 Europe/Amsterdam, Ronald Oussoren 
wrote:

> This is working as designed, but not because tuples are more pythonic 
> than structs (I'm don't even think tuples are more pythonic). They are 
> tuples because PyObjC doesn't know anything about NSRect and other 
> struct-types, other than what it can extract from the runtime. The 
> runtime doesn't know field names, but only the number and types of the 
> fields.
>
> It would be possible to add an interface to specify custom mappings 
> for structure types, but IMHO that is post-1.0 work.

There's a new builtin Python type, structsequence, that is two-faced: 
you can access the members by name or by index. os.stat() is one of the 
calls that uses it.

Unfortunately the C interface is rather baroque. At least, I was going 
to use it for some of the values returned by Mac toolbox calls, but 
I've pushed it forward for the time being as I didn't understand it.
--
- 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] Pycotine now using PyObjC! ;-)

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

On Wednesday, Jan 8, 2003, at 04:56 US/Eastern, Dinu Gherman wrote:
> this is really exciting... I once wrote a little Cocoa GUI to Steve
> Purcell's PyUnit, following closely an existing Tkinter GUI. I've
> "ported" Pycotine y'day to use PyObjC and put the new development
> version 0.2 into my Starship cabin:

Very, very cool!   Definite boost for me -- this just caused a 
'management presentable' UI for unit testing to come into existence.  
Makes for a much more impressive demo!

Speaking of projects like this...

We should collect a set of links to the various projects that are 
implemented with PyObjC.   I will add a section to the web site and 
start adding the project there.

b.bum

Re: [Pyobjc-dev] Changing the dock icon

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

You can use either AppKit.NSApp(), a function instead of a global 
variable, or  NSApplication.sharedApplication() to access the 
NSApplication instance for your application.

Ronald

Re: [Pyobjc-dev] In and out of NSData

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

On Wednesday, Jan 8, 2003, at 11:45 Europe/Amsterdam, Jack Jansen wrote:

>
> On Wednesday, Jan 8, 2003, at 07:24 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>> Proposed interface:
>>
>> 	Foundation.pyobjc_NSToCF(NSObject) -> CFObject
>> 	Foundation.pyobjc_CFToNS(CFObject) -> NSObject
>>
>> Both raise ValueError if the argument cannot be mapped to the other 
>> representation.
>>
>> These are uncontroversion, except maybe the location of the 
>> functions. When I first looked at doing this I intended to implement 
>> pyobjc_CFToNS as part of the generic bridge; that is, if the 
>> Objective-C code expects to receive an NSObject and the user passed 
>> in a CFObject automaticly translate between the two. I'm currently 
>> not sure whether that would be a good idea, stuffing a CFObject in a 
>> NS<Datastructure> and retrieving it again would effectivly change its 
>> type. This might be pretty confusing (especially because the 
>> translation from NSObject to CFObject won't be automatic).
>>
>> I'm therefore inclined to making all mappings from CF to NS and back 
>> manual operations.
>
> Let's start with this, and we can always do more later.
>
> But: why would going CF->NS->CF change the type of the object?
It wouldn't, but given the automatic translation from CF to NS (NOT 
using the pyobjc_CFtoNS function) the following code would have 
unexpected results:

	input = CF.CFMutableData(...)
	arr = Foundation.NSMutableArray.arrayWithArray([data])
	output = arr[0]

At this point 'output is not input', the do not even have the same 
type(). Converting it back to CF would of course recover an object of 
the same type as 'input'.

That's why I'd prefer to only implement the pyobjc_CFtoNS and 
pyobjc_NStoCF functions and not transparent translation.

Ronald