pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] NSRects and NSPoints as tuples...

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

On Wednesday, Jan 8, 2003, at 17:55 Europe/Amsterdam, Dinu Gherman 
wrote:

> I've read somewhere and experienced now myself that NSRects and
> NSPoints are mapped to 2-2 and 2-tuples of numbers respectively.
>
> While this is surely more convenient and more Pythonic in most cir-
> cumstances I feel like it has the drawback that existing Cocoa
> code calling attributes like size, width/height or x/y of NSRect
> will need to be "ported" to the more Pythonic way in a more than
> just syntactical fashion.
>
> In this case it means going from rather clear names to numeric
> indices, which have a higher potential to confuse their users.
>
> Am I correctly assuming that this is working "as designed", then?
> ;-)

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.

Ronald

[Pyobjc-dev] Changing the dock icon

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

I am now trying to change the application's icon in the dock, depending on
different conditions.  I have found a URL that describes how to do this with
Objective C (http://cocoa.mamasam.com/COCOADEV/2002/12/1/51192.php), but I
am unsure of how to access the right NSApp to tell it to
setApplicationIconImage_ ... and then I assume I pass in an NSImage object
which I specified earlier.

FYI, I am now using the Python Template Project that comes with pyobjc, so
the current code that I'm working in is of class MyAppDelegate (subclassed
from AppKit.NibClassBuilder.AutoBaseClass).

Thanks,
David.

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

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

On Wednesday, Jan 8, 2003, at 15:56 Europe/Amsterdam, bb...@ma... 
wrote:

> On Wednesday, Jan 8, 2003, at 01:24 US/Eastern, Ronald Oussoren wrote:
>>> Is there currently any way to do (pyobjc) NS* <-> (Carbon.CF) CF* 
>>> for the toll-free bridged types?  I don't see anything obvious from 
>>> a quick look.
>
> It isn't necessary.  Toll-free means that they are effectively one in 
> the same.
>
> In ObjC, if you have....
>
> CFDataRef foo;  // basically, CFData *foo
>
>
> .... you can:
>
>     [foo bytes];
>
> That is, CFData * and NSData * are *exactly the same* as far as the 
> ObjC runtime and CF*() APIs are concerned.

But Python doesn't know that. We'll have to add functions that will 
basicly perform pointer casts. Remember that we use one set of types to 
wrap NS* objects (PyObjC) and another set to wrap CF* objects (part of 
the python core). The functions will have to extract a pointer from one 
kind of wrapper and stuff it into another one.

Ronald

Re: [Pyobjc-dev] NSRects and NSPoints as tuples...

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

On Wednesday, Jan 8, 2003, at 11:55 America/New_York, Dinu Gherman 
wrote:

> I've read somewhere and experienced now myself that NSRects and
> NSPoints are mapped to 2-2 and 2-tuples of numbers respectively.
>
> While this is surely more convenient and more Pythonic in most cir-
> cumstances I feel like it has the drawback that existing Cocoa
> code calling attributes like size, width/height or x/y of NSRect
> will need to be "ported" to the more Pythonic way in a more than
> just syntactical fashion.
>
> In this case it means going from rather clear names to numeric
> indices, which have a higher potential to confuse their users.
>
> Am I correctly assuming that this is working "as designed", then?
> ;-)

pygame ( www.pygame.org ) does the equivalent of NSRect in its Rect 
class, and it's got all of the height/width/etc niceness.. might even 
be worth just yanking some of the code out and using that, as they have 
a bunch of nice functions for working on them as well.

-bob

[Pyobjc-dev] NSRects and NSPoints as tuples...

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

I've read somewhere and experienced now myself that NSRects and
NSPoints are mapped to 2-2 and 2-tuples of numbers respectively.

While this is surely more convenient and more Pythonic in most cir-
cumstances I feel like it has the drawback that existing Cocoa
code calling attributes like size, width/height or x/y of NSRect
will need to be "ported" to the more Pythonic way in a more than
just syntactical fashion.

In this case it means going from rather clear names to numeric
indices, which have a higher potential to confuse their users.

Am I correctly assuming that this is working "as designed", then?
;-)

Dinu

--
Dinu C. Gherman
......................................................................
"I tremble for my country when I reflect that God is just, that His
justice will not sleep forever." (Thomas Jefferson)

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

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

On Wednesday, Jan 8, 2003, at 15:54 Europe/Amsterdam, bb...@ma... 
wrote:

> On Tuesday, Jan 7, 2003, at 18:33 US/Eastern, Jack Jansen wrote:
>> Carbon.CF is in there, albeit through an oversight of either myself 
>> or Apple. The only problem is that it is called "_CF" only (that's 
>> the internal name, the external name should be "Carbon.CF").
>
>> But note that my note was more aimed towards development of PyObjC 
>> itself: I think we should tie in more to what is already available 
>> than try to do everything from scratch.
>
> Why not just 'CoreFoundation'?

It will become that (or something similar). For historical reasons 
QuickTime and Core Foundation are in Carbon.Qt and Carbon.CF.

If you file an SF bugreport I'll try and fix this shortly (it is 
slightly less than trivial: there are actually two modules Carbon.CF 
with the API calls and Carbon.CoreFoundation with the constants, and 
these will have to be folded).
--
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] In and out of NSData

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

On Wednesday, Jan 8, 2003, at 09:56 America/New_York, bb...@ma... 
wrote:

> On Wednesday, Jan 8, 2003, at 01:24 US/Eastern, Ronald Oussoren wrote:
>>> Is there currently any way to do (pyobjc) NS* <-> (Carbon.CF) CF* 
>>> for the toll-free bridged types?  I don't see anything obvious from 
>>> a quick look.
>
> It isn't necessary.  Toll-free means that they are effectively one in 
> the same.
>
> In ObjC, if you have....
>
> CFDataRef foo;  // basically, CFData *foo
>
>
> .... you can:
>
>     [foo bytes];
>
> That is, CFData * and NSData * are *exactly the same* as far as the 
> ObjC runtime and CF*() APIs are concerned.

I meant, implicitly, that it needed to be done from python code.  I 
know that it's easy otherwise.

.. and don't you have to [(NSData*)foo bytes] ?

-bob

Re: [Pyobjc-dev] Getting PB warnings about "Component Manager"

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

It is because of Toast.   Plug that error message into Google and do a 
search... you'll find the answer/fix.   Has to do w/VideoCD support.

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

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

On Wednesday, Jan 8, 2003, at 01:24 US/Eastern, Ronald Oussoren wrote:
>> Is there currently any way to do (pyobjc) NS* <-> (Carbon.CF) CF* for 
>> the toll-free bridged types?  I don't see anything obvious from a 
>> quick look.

It isn't necessary.  Toll-free means that they are effectively one in 
the same.

In ObjC, if you have....

CFDataRef foo;  // basically, CFData *foo


.... you can:

     [foo bytes];

That is, CFData * and NSData * are *exactly the same* as far as the 
ObjC runtime and CF*() APIs are concerned.

b.bum

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

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

On Tuesday, Jan 7, 2003, at 18:33 US/Eastern, Jack Jansen wrote:
> Carbon.CF is in there, albeit through an oversight of either myself or 
> Apple. The only problem is that it is called "_CF" only (that's the 
> internal name, the external name should be "Carbon.CF").

> But note that my note was more aimed towards development of PyObjC 
> itself: I think we should tie in more to what is already available 
> than try to do everything from scratch.

Why not just 'CoreFoundation'?   Part of the reason that I have been 
somewhat hesitant about dipping into the MacPython stuff is that it 
seems [may be my complete ignorance] to be oriented very much to Carbon 
-- the Core isn't directly accessible without dragging in Carbon?

I would liked to keep PyObjC in line with Apple's model for the system; 
   not what is there now, but the direction they have repeatedly 
emphasized at WWDC over the last N years.   That is, Cocoa is on top 
Core and Carbon is on top of Core, but Cocoa and Carbon are relatively 
separated.

A goal, anyway.

But, yes, overall, PyObjC should not re-invent wheels that already 
exist, work well, and have been tested by a large community.

b.bum

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

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

On Tuesday, Jan 7, 2003, at 22:46 America/New_York, bb...@ma... wrote:

>> oh.. and I think these segfaults are doing something really nasty to 
>> my system (though I don't see exactly why it should), as my front 
>> terminal window (that I was using for Python) was going between 
>> normal display and completely white and unresponsive at a cycle time 
>> of about 5 seconds.. I did manage to close it eventually, and the 
>> other terminals seem fine.  I dunno if this is related, but I have 
>> never seen it happen before.
>
> Sounds like it is causing your system to swap heavily.   How much RAM 
> do you have?   Unless the subprocess was outputting lots and lots of 
> data-- which would have been visible-- the terminal window should have 
> been unaffected.

The subprocess was not running at this point, and no output was being 
processed (it had just segfaulted).  That's why it was strange.  I 
don't think this is a ram issue, I have 1GB on my powerbook.

>
> Odd but may indicate that something is broken on the bridge such that 
> it is trying to allocate a really huge chunk of memory within the 
> NSData (but that wouldn't make sense -- NSData/NSMutableData only 
> allocate address space, not physical RAM, until the first time you 
> touch a page of RAM... it wouldn't cause swap death unless you (a) 
> allocated a huge NSData and (b) tried to actually read/write from the 
> data object across a significant number of pages).

I haven't tried to allocate anything larger than a few kb at most and 
haven't really done any reading from them since I don't yet know of a 
way to get arbitrary data out of NSData and back into python in any 
reasonable manner.

-bob

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

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

On Tuesday, Jan 7, 2003, at 10:30 US/Eastern, 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.

I saw that for a while, then it disappeared in the unit tests and I was 
unable to reproduce it elsewhere....

Ronald?  Any ideas?

> ^^ failed at 31 (30 being the last one that initialized successfully)

That sounds an awful lot like a transition point between one private 
subclass of the NSData class cluster and another...?

> Is there some reason the unittest seems to skirt around this issue 
> (other than not wanting to crash ;)?  It does work (probably 
> unreliably) with small strings/arrays.

No idea.

> Maybe there should be some convenience methods in the ObjC core, or 
> additions to the NSData/NSMutableData proxy objects so you can just 
> get an NSData/NSMutableData directly to and from str, array, and 
> numeric arrays?  I think that would cover most bases, and I don't 
> think people would mind having to use convenience methods so long as 
> they're documented.  It seems kind of silly to require you to specify 
> the length.. it's not very 'pythonic' since it's to easy to slice 
> sequence types to whatever size they need to be and not safe to 
> specify lengths any longer than that.

Actually, that method can be initialized from any Python object that 
implements the buffer interface, including Strings.

The length is there only because that is the API on the ObjC side -- it 
leaves open the possibility of the developer passing in a 100KB buffer, 
but only using the first 10kb bytes, for example.

Agreed on the 'pythonic' part -- once PyObjC reaches 1.0 quality, we 
can put some effort into a 1.1 that adds various convenience APIs to 
make the ObjC APIs more 'pythonic'.   Of course, feel free to submit a 
patch. :-)

> oh.. and I think these segfaults are doing something really nasty to 
> my system (though I don't see exactly why it should), as my front 
> terminal window (that I was using for Python) was going between normal 
> display and completely white and unresponsive at a cycle time of about 
> 5 seconds.. I did manage to close it eventually, and the other 
> terminals seem fine.  I dunno if this is related, but I have never 
> seen it happen before.

Sounds like it is causing your system to swap heavily.   How much RAM 
do you have?   Unless the subprocess was outputting lots and lots of 
data-- which would have been visible-- the terminal window should have 
been unaffected.

Odd but may indicate that something is broken on the bridge such that 
it is trying to allocate a really huge chunk of memory within the 
NSData (but that wouldn't make sense -- NSData/NSMutableData only 
allocate address space, not physical RAM, until the first time you 
touch a page of RAM... it wouldn't cause swap death unless you (a) 
allocated a huge NSData and (b) tried to actually read/write from the 
data object across a significant number of pages).

BTW: NSData has a 1/2 GB limit on the size of memory it contain.  I 
don't know why.  CFData does not "suffer" from this limitation.

b.bum

Re: [Pyobjc-dev] Python subclasses of NSView?

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

Dinu Gherman wrote:

> I'm trying to find out if it is possible to have Python subclasses
> of graphic widgets like NSView, say? I can't quite figure out how
> to tell IB about a new Python file containing the subclass and then
> change a "custom view" widget to be of the new class, MyView, say.

You can! ;-)

> With Obj-C you tell IB by making it read the MyView.h file, and
> then you can switch a custom view from the container views palette
> to the new MyView class. How would I do this for a Python subclass?

You need to:

1. subclass NSView in the Classes tab of the NIB file window in
    IB to MyView, say
2. drag a custom view from the container views palette on some window
3. select the custom view and type Cmd-5 to change its class to MyView
4. add Python code for MyView somewhere, inheriting from AutoBaseClass,
    not NSView!
5. implement relevant methods for MyView like drawRect!

Excellent! Will be fun to extend this to mouse handling and dragging
operations...! ;-)

Dinu

--
Dinu C. Gherman
......................................................................
"Any sufficiently advanced technology is indistinguishable
from magic." (Arthur C. Clarke)

Re: [Pyobjc-dev] Python subclasses of NSView?

[Etienne P. <ep...@ep...>]

On Wednesday, Jan 8, 2003, at 14:07 Europe/Amsterdam, Dinu Gherman 
wrote:

> I'm trying to find out if it is possible to have Python subclasses
> of graphic widgets like NSView, say? I can't quite figure out how
> to tell IB about a new Python file containing the subclass and then
> change a "custom view" widget to be of the new class, MyView, say.
>
> With Obj-C you tell IB by making it read the MyView.h file, and
> then you can switch a custom view from the container views palette
> to the new MyView class. How would I do this for a Python subclass?


Have a look at: http://www.cs.vu.nl/~etienne/pyDotView.tar.gz

It is the 'DotView' example from the Apple 'Learning Cocoa' book 
converted to a Python App.
I think the source code will make it clear, a single custom class with 
instance in IB for the Custom View, and then the code in Python for 
that class.

Etienne

[Pyobjc-dev] Python subclasses of NSView?

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

I'm trying to find out if it is possible to have Python subclasses
of graphic widgets like NSView, say? I can't quite figure out how
to tell IB about a new Python file containing the subclass and then
change a "custom view" widget to be of the new class, MyView, say.

With Obj-C you tell IB by making it read the MyView.h file, and
then you can switch a custom view from the container views palette
to the new MyView class. How would I do this for a Python subclass?

Thanks,

Dinu

--
Dinu C. Gherman
......................................................................
"An age is called Dark, not because the light fails to shine, but
because people refuse to see it." (James Michener)

Re: [Pyobjc-dev] how to clean up on quit

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

On 1/8/03 6:41 AM, "Dinu Gherman" <gh...@da...> wrote:

> Taking the standard Python template Project as an example, you can
> just add this method to your MyAppDelegate class:
> 
>    def applicationWillTerminate_(self, aNotification):
>        NSLog( "Application will terminate." )

My first error was not using the standard Python template Project.  I have
tried your recommendation, and it works perfectly.

Thanks!
David.

Re: [Pyobjc-dev] Getting PB warnings about "Component Manager"

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

I wrote:

> Hi, I'm constantly getting this message when running pyobjc apps
> inside PB:
>
>   ## Component Manager: attempting to find symbols in a component
>   alias of type (regR/carP/x!bt)

In fact, I'm also getting them for purely Objective-C projects! :-/

Dinu

--
Dinu C. Gherman
......................................................................
"La seule mani=E8re de parler de rien est d'en parler comme si c'=E9tait
quelque chose, tout comme la seule mani=E8re de parler de Dieu est d'en
parler comme s'il =E9tait un homme." (Samual Beckett)

Re: [Pyobjc-dev] how to clean up on quit

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

David Casti:

> The Cocoa documentation says I should become a delegate for
> applicationWillTerminate, but I've been unable to figure out how to do 
> this.

Taking the standard Python template Project as an example, you can
just add this method to your MyAppDelegate class:

     def applicationWillTerminate_(self, aNotification):
         NSLog( "Application will terminate." )

much like this (existing) one:

     def applicationDidFinishLaunching_(self, aNotification):
         NSLog( "Application did finish launching." )

The first method will be called when you type Cmd-Q or click on the
Quit menu entry. Instead of calling NSLog() you can do whatever you
need to. With aNotification.object() you should get the NSApp object,
I beliebe.

You can also register an object to observe equivalent "notifications"
posted by the NSApp object, in this case it is "NSApplicationWill\
TerminateNotification" using the class named NSNotificationCenter.
I tried that before and it works.

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"It is by the goodness of God that in our country we have these three
unspeakably precious things: freedom of speech, freedom of conscience,
and the prudence to practice neither." (Mark Twain)

[Pyobjc-dev] how to clean up on quit

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

Hello,

I've started writing my first pyobjc applications, and so far things are
going well.  Today, I came across a new requirement: clean up on quit.

The Cocoa documentation says I should become a delegate for
applicationWillTerminate, but I've been unable to figure out how to do this.

Can anyone help?

Thanks,
David.

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

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

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? If that 
is an artefact of the fact that the various Carbon.CF types don't 
currently inherit from each other: don't worry, this will be fixed 
shortly (all the other Carbon types now do have inheritance, for CF it 
was slightly difficult because I already used "poor mans inheritance" 
to get access to (for instance) the CFType methods from CFString 
objects, etc.
--
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

[Pyobjc-dev] Pycotine now using PyObjC! ;-)

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

Hi,

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:

   http://python.net/crew/gherman/#pycotine

The interesting bits are: it's still using NSTask to spawn an exter-
nal "tracking" TestRunner and an NSTimer to read the data from some
files and refresh the GUI during testing. Under Objective-C this
was the only way, but using Python only this can clearly be improv-
ed, maybe in the next version. Ideally, the info in the traceback
view would be clickable and able to take you to the source files...
maybe one day... ;-)

To run it on your own test suites just add a function named either
suite() or makeSuite() that returns a unittest.TestSuite object to
your Python file and open/run it with Pycotine! The previous ver-
sion 0.1 contains some samples, too, which you can reuse with 0.2.

I like the fact that Cocoa/PB/IB development is much faster with
Python than with Objective-C! It would be interesting to compare
to AppleScript, which I know little about...

Enjoy,

Dinu

--
Dinu C. Gherman
......................................................................
"Some are born great, some achieve greatness, and some hire public
relations officers." (Daniel J. Boorstin)

[Pyobjc-dev] Getting PB warnings about "Component Manager"

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

Hi, I'm constantly getting this message when running pyobjc apps
inside PB:

   ## Component Manager: attempting to find symbols in a component
   alias of type (regR/carP/x!bt)

Is this a known issue or am I the only one to see this?

Thanks,

Dinu

--
Dinu C. Gherman
......................................................................
"It is absurd to divide people into good and bad. People are either
charming or tedious." (Oscar Wilde)

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

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

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.

Ronald

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

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

On Wednesday, Jan 8, 2003, at 00:33 Europe/Amsterdam, Jack Jansen wrote:
>
> But note that my note was more aimed towards development of PyObjC 
> itself: I think we should tie in more to what is already available 
> than try to do everything from scratch.
>
I think this is worth repeating :-)

Ronald

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

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

On Wednesday, Jan 8, 2003, at 00:49 Europe/Amsterdam, Bob Ippolito 
wrote:
>
> Is there currently any way to do (pyobjc) NS* <-> (Carbon.CF) CF* for 
> the toll-free bridged types?  I don't see anything obvious from a 
> quick look.

Not yet, but adding these mappings would be quite easy.

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.

Opinions?

Ronald