208717 - [patch]New Cursors for Camino

Status: RESOLVED FIXED

(Camino Graveyard :: OS Integration, defect)

Description

[Andrew Thompson]

In bug 78363 animated cursors for Mozilla were implemented.

This bug deals with an implementation for Camino, which tries to use the Cocoa
class NSCursor where possible, at the request of pinkerton & smfr.

I'll attach patches presently.

Comment 1

[Andrew Thompson]

Attachment: Animated cursor implementation for Camino

Comment 2

[Mike Pinkerton (not reading bugmail)]

+ (nsCursorManager *) getInstance;

you should probably rename this |sharedInstance| to be more like cocoa. not sure
if we respect that too well in camino, but we should.

the |-init| method loads all the cursors at startup, but the code you're
replacing loads them lazily. is that really what you want to do?

Why do you bother locking the getInstance/dispose? Will that ever happen on
anything but the main thread?

also, for methods, interface, and class decl's, mozilla style is to put the
brace on a line by itself, eg:

int foo ( )
{
}

> [NSException raise: @"Nonsensical frame indicies" format: @"%d %d",
aFirstFrame, aLastFrame];

is anyone catching these?

Comment 3

[Andrew Thompson]

Thanks for the review. Pretty busy right now. Will try to get to this in a week
or so.

Comment 4

[Jasper]

Anny news on this?

Comment 5

[Andrew Thompson]

Hrm, well. It is actually top on my Mozilla todo list.
But I'm busy so I can't give you an estimate, but I haven't forgotten about it.

Comment 6

[Asa Dotzler [:asa]]

Comment on attachment 125188 [details] [diff] [review]
Animated cursor implementation for Camino

We have a new Camino request flag which can be set multiple times for a patch.
Moving old review requests to the new flag. Sorry for the spam.

Comment 7

[S Woodside]

Is this really supposed to be superreview?sfraser ?

Comment 8

[Andrew Thompson]

Comment on attachment 125188 [details] [diff] [review]
Animated cursor implementation for Camino

Not ready for review right now.

Comment 9

[Jasper]

Dave Haas put this patch in his unofficial build. So I had the chance to test.
The only thing I noticed is that when enabling the ImageResize option the
spyglass cursor wasn't shwoing up.

Comment 10

[Andrew Thompson]

Response to Mike's review:

>+ (nsCursorManager *) getInstance;

> you should probably rename this |sharedInstance| to be more like cocoa. not 
> sure if we respect that too well in camino, but we should.


> the |-init| method loads all the cursors at startup, but the code you're
> replacing loads them lazily. is that really what you want to do?

It was intentional, because I think the huge switch in the Carbon code is the
ugliest possible solution. I could do something where I try to map each enum
constant to some kind of memento for the cursor and when its first set I would
instantiate the class from the memento. The memento would be perhaps the
selector for the factory method along with the arguments it needs. I'm not sure
said mementos would be smaller than the classes they represent though: they're
already pretty small.

The other option is to put the big ugly switch back in and cache the cursors in
the NSDictionary as each is first used. I don't want to do that, but I will if
you ask me to.


>Why do you bother locking the getInstance/dispose? Will that ever happen on
>anything but the main thread?

Because I'm a Java programmer by trade and that language is so pervasively
threaded that one always synchronizes ones Singleton objects, because you never
know how they're going to be used. I've removed it because you're probably right
about this only ever running on the main thread.

>also, for methods, interface, and class decl's, mozilla style is to put the
>brace on a line by itself, eg:

Fixed. Ugly as sin, but fixed ;)

> [NSException raise: @"Nonsensical frame indicies" format: @"%d %d",
> aFirstFrame, aLastFrame]; is anyone catching these?

No, but they're really assertions. I intend them for debugging. There's no real
way for them to happen at runtime.

Comment 11

[Andrew Thompson]

Attachment: New version of cursor patch implements

Patch addresses Mike's comments as per my earlier comment.

I also made all of the Cocoa NSCursor based cursors lazy-load. The cursors are
not allocated until they are first used, which ought to save some memory. The
Theme and Resource based cursors don't load any bitmaps until you use them
anyway, so I don't see the point in lazy loading these.

Comment 12

[Andrew Thompson]

Attachment: Test Case for Cursor Code (tests all standard CSS2 cursors)

I attached some test cases you might like to try.

Comment 13

[David Haas (gone, not reading mail)]

This isn't just a patch of nsChildView - it looks like you've made some new
files?  I'm gonna guess nsCursorManager.h, nsCursorManager.mm, nsMacCursor.h,
nsMacCursor.mm, right?  It'd be nice if they were marked in the patch . . .  

Comment 14

[Andrew Thompson]

Apologies yes, those are the right filenames. Please look at the previous
version of the patch if you need exact names. I'm struggling to remember how I
generated the patch last time, since it seems to have "New File" lines. Maybe I
just inserted them by hand?

Comment 15

[Simon Fraser [no longer active]]

'cvs add' the files, then cvs diff -N

Comment 16

[Mike Pinkerton (not reading bugmail)]

new patch? anyone?

Comment 17

[Ludovic Hirlimann [:Usul]]

Attachment: proper patch, a diff + new files

I also modified the Makefile.in in order to build the new files.
I could not uses simon's trcik to diff the new files, because I do not have cvs
write access.
The test case provided does not work for the First and the two last examples
(help and arrow left and arrow right).

Comment 18

[Andrew Thompson]

The patch as it stands is only the code.

Certainly there needs to be a patch against the makefile (thanks, I forgot that)
and against the Project Builder project (or Xcode I guess it now will be) to
include the new TIFF files.

You'll also need the actual TIFFs for the images. That's probably why the test
case is patchy for you. Apologies for that. I thought I attached the images when
I first made the bug.

Right now I'm still putting things back together after a clean install of
Panther, including building the relevant bits of fink from source. So this is
all going to take a little while to organize. For now, if people could
concentrate on ensuring the code is OK, we can deal with all of the other
details later.

Speaking of which, there is one change I want to make to the patch. Hold on a
tick while I attach the images, then I'll address that.

Comment 19

[Andrew Thompson]

Attachment: The cursors required (Extract into: /mozilla/camino/resources/images)

Comment 20

[Andrew Thompson]

Additional change:

I want to avoid allocating the nsCocoaCursor until I have to, so lines like this:

NSInvocation *lazyConstructor = [nsMacCursor createInvocation:
@selector(initWithCursor:) forTarget: [nsCocoaCursor alloc]];

will become

NSInvocation *lazyConstructor = [nsMacCursor createInvocation:
@selector(initWithCursor:) forTarget: [nsCocoaCursor class]];

Then:
+ (NSInvocation *) createInvocation: (SEL) aMethod forTarget: (NSObject *) aTarget

becomes:

+ (NSInvocation *) createInvocation: (SEL) aMethod forTarget: (Class *) aTarget {
 NSInvocation *result = [NSInvocation invocationWithMethodSignature: [aTarget
instanceMethodSignatureForSelector:: aMethod]];
    [result setSelector: aMethod];
    [result setTarget: aTarget]; 
    return result;

}


Then, when we come to instantiate:

- (void) load
{
    if ( mLazyConstructor != nil )
    {
        [mLazyConstructor invokeWithTarget: [[mLazyConstructor target] alloc]];
       
        [mLazyConstructor getReturnValue: &mRealCursor];
        [mLazyConstructor release];
        mLazyConstructor = nil;
    }
}

Of course, passing [nsCocoaCursor class] in NSInvocation's target instance
variable then alloc-ing it later is a bit of a hack. Probably nsLazyLoadCursor
should take a reference to the class to instantiate in its constructor instead.

In any case I want to respin the patch to make the loading even lazier like this.

Comment 21

[Andrew Thompson]

Attachment: Updates patch for Panther, includes all changes

Updated patch.

Problem: I'm now building on Panther with XCode - so in order to add the new
images to the project, I had to upgrade my project file to Xcode. This has
resulted in a lot of changes to the file. As I understand it, XCode project
files come in 2 flavours: native & upgraded from Project Builder. The later
kind is mostly openable in Project Builder as well as XCode.

Not sure what to do here. Perhaps better to reboot into Jaguar, get clean copy
of project from CVS, add files with 10.2 Project Builder, and send that diff
instead?

Comment 22

[Andrew Thompson]

Attachment: Updated Test Case

Comment 23

[Andrew Thompson]

Attachment: Cursor images -> mozilla/camino/resources/images/cursors/

Comment 24

[Mike Pinkerton (not reading bugmail)]

the plan for xcode is to create a new project (Camino.xcode) rather than just
upgrade the current one in place. I'll check in the new project asap so people
can start working with it. For the time being, we can't build release bits on
panther, so we have to at least keep the PB project in sync.

Comment 25

[Andrew Thompson]

Attachment: Same as Nov. patch but without the XCode/ProjectBuilder changes

This is NOT a new patch. Rather I simply stripped out the XCode/ProjectBuilder
changes. 

To apply this patch:

(1) apply the source code changes
(2) add the images from attachment 134894 [details] to
mozilla/camino/resources/images/cursors/
(3) add the images to your XCode or PB Project.
 - create the folder Resouces/images/cursors in the left hand tree
 - add all of the cursors from step (2) to this folder in XCode/PB

Of course, when this lands I'll patch whichever project files happen to apply.

Comment 26

[Ludovic Hirlimann [:Usul]]

Comment on attachment 137242 [details] [diff] [review]
Same as Nov. patch but without the XCode/ProjectBuilder changes


>+BOOL isJaguarOrEarlier() 
>+{
>+    return floor(NSAppKitVersionNumber) <= NSAppKitVersionNumber10_2;
>+}

Andrew, NSAppKitVersionNumber10_2 is not defined on panther.
On my jaguar system I get :
nsCursorManager.mm: In function `isJaguarOrEarlier':
nsCursorManager.mm:61: `NSAppKitVersionNumber10_2' undeclared (first use this 
   function)
nsCursorManager.mm:61: (Each undeclared identifier is reported only once for 
   each function it appears in.)
nsCursorManager.mm: In function `+[nsCursorManager createCursor:]':
nsCursorManager.mm:76: warning: cannot find class (factory) method

while compiling. According to this
http://www.wodeveloper.com/omniLists/macosx-dev/2002/August/msg00355.html
You'll need to add a #define enum somewhere.

Comment 27

[Andrew Thompson]

>Andrew, NSAppKitVersionNumber10_2 is not defined on panther.

You meant to say its not defined on Jaguar, right?

I guess I'll have to do something about that.

Comment 28

[Ludovic Hirlimann [:Usul]]

I did meant jaguar :)

Comment 29

[S Woodside]

Comment on attachment 137242 [details] [diff] [review]
Same as Nov. patch but without the XCode/ProjectBuilder changes

taking this off the review? list.  Andy, there are apple-approved ways of
testing what system you're on, check out the developer.apple.com site

Comment 30

[Ludovic Hirlimann [:Usul]]

Andy do you plan to update this patch ?

Comment 31

[Andrew Thompson]

Sure. Just as soon as I have a day or so to screw around re-installing Jaguar
and the umpteen thousand patches to the dev tools so I can actually build Camino.

This is a serious pain in the butt - and I just got back from vacation and am
working way too hard at my day job right now :)
Any word on being able to cross compile for 10.2 using XCode?

Alternatively I could just upload a new patch with the changed code, and someone
with a working Jaguar system could test the patch and make the necessary project
file changes. I have checkin priveledges, so I can take care of everything else
once the Project Builder changes are done & reviewed.

Comment 32

[Ludovic Hirlimann [:Usul]]

Please do. My OS is Jaguar and I don't intend to move in the near future.

Comment 33

[Andrew Thompson]

Attachment: Same as previous, but uses Gestalt to check OS version

This version of the patch uses Gestalt to check the OS version, which should
work correctly on anything back to System 6 :)

Bear in mind that this compiles, but I've not yet been able to run it due to my
build system problems

Please do build it on Jaguar for me and try out the test page in attachment
134892 [details].

If you could then make your build available to me to test on Panther I'll do
so. 

I will be reinstalling Jaguar eventually, but if you wanted to diff the
ProjectBuilder file and include it in the patch, that would get this done more
quickly.

Thanks for your help.

Comment 34

[Andrew Thompson]

Attachment: New version, tested on 10.3 & 10.2. Has Xcode project changes included

This new version of the patch is fully up to date with the switchover from
Project Builder to XCode.

I built in on Panther & tested it on Jaguar & Panther.

Applying the patch:

(i) apply the patch
(ii) put the cursors from attachment 134894 [details] into
mozilla/camino/resources/images/cursors
(iii) build 
(iv) Try the test case in attachment 134892 [details]

Comment 35

[Hiro]

Although the application method of my patch may be bad, it became an error in
the following portions.
(It was applicable when changing the number of lines into 201.)

And the test case worked as expected.

Index: mozilla/widget/src/cocoa/nsCursorManager.mm
===================================================================
RCS file: mozilla/widget/src/cocoa/nsCursorManager.mm
diff -N mozilla/widget/src/cocoa/nsCursorManager.mm
--- /dev/null   1 Jan 1970 00:00:00 -0000
+++ mozilla/widget/src/cocoa/nsCursorManager.mm 7 Feb 2004 17:39:45 -0000
@@ -0,0 +1,202 @@

Comment 36

[Andrew Thompson]

Yeah, you're not the only person to notice that.

I think the issue here is I did a cvs diff -N -u -2 to diff the new files, but
it doesn't automatically insert 2 blank lines at the end of each patch file, so
'patch' doesn't like the file. Stick extra whitespace between the files in the
patch and it should work. I think that's what is causing the problem.

Thanks for testing this. Did you see the animated cursors actually moving? One
person said the patch worked but the animated cursors didn't animate.

If you've built with this and you're happy it works, please r= the bug.

Comment 37

[Hiro]

Yes.
For example, the finger is moving the count up/down cursor in a test case etc :-)

My machine environment is Mac OS X 10.3.2.
I do not know whether it works by Mac OS X 10.2.x...

Comment 38

[Hiro]

I will think that I am satisfactory, if this patch operates by 10.2.x.

lordpixel-san, flag cannot be changed in my account.

Comment 39

[Mike Pinkerton (not reading bugmail)]

2-space indenting please, per mozilla rules.

Comment 40

[Mike Pinkerton (not reading bugmail)]

i'd also like to see some function-level and class-level comments, especially in
the header files. You're adding a slew of new code here that's mostly uncommented. 

Also, i noticed you set the timer for animation to go off every quarter-second.
Is that really necessary? What would that do to page load? Is that what it does
in the carbon code?

Comment 41

[Jasper]

Why isn't camino using the same cursor images for grab/grabbing and
countup/countdown they look pretty much the same appart from the fact that the
grab cursors look ugly copmared to the count ones.

Just a dumb question.

Comment 42

[Andrew Thompson]

>Why isn't camino using the same cursor images for grab/grabbing and
>countup/countdown they look pretty much the same appart from the fact that the
>grab cursors look ugly copmared to the count ones.

Because the countup/countdown cursors are animated and the grab/grabbing ones
are just static images...?

In any case, they're all built into Mac OS X, so they look the way Apple makes
them look. Can't see much difference myself, they all seem to follow the same theme.

Comment 43

[Andrew Thompson]

>i'd also like to see some function-level and class-level comments, especially in
>the header files. You're adding a slew of new code here that's mostly
>uncommented. 

Will do. Is there any format you prefer? HeaderDoc, Doxygen? Just plain old English?

>Also, i noticed you set the timer for animation to go off every quarter-second.
>Is that really necessary? What would that do to page load? Is that what it does
>in the carbon code?

Yes, that's what the Mozilla/Carbon implementation does. I'll slow it down if
you tell me to. 0.3 or 0.5 seconds should be fine too. When I checked this into
the trunk for Mozilla, I watched the Tp metric, and it didn't seem to have any
effect. Perhaps the Timer isn't very high priority? Thats how it feels. I've
observed that the animation usually stops if one's machine is working hard. 

Comment 44

[Andrew Thompson]

Attachment: Add comments & fix indenting, as discussed

Comment 45

[Andrew Thompson]

(In reply to comment #38)
> I will think that I am satisfactory, if this patch operates by 10.2.x.
> 
> lordpixel-san, flag cannot be changed in my account.

crot0-sama,

There's some guidelines for getting more permissions on Bugzilla here:
http://www.mozilla.org/quality/help/unconfirmed.html

If you're at a level where you are applying patches, building and testing them,
you should be able to get the requird permissions easily. Point out the help
you've been giving on this bug as an example.

Thanks for your help.

Comment 46

[Hiro]

Attachment: patch of xcode

The error of xcode command took place with the patch of 141889.
And it has noticed forgetting to add a cursor image to a CaminoStatic target.

Comment 47

[Josh Aas]

Which patch(es) need review? Do I use that "patch of xcode"? And out of
curiosity (maybe it would influence my review too) - what do we gain by using
NSCursor instead of whatever we're doing now? i.e. what is the point of this?
Why do pink and smfr want it?

Comment 48

[Andrew Thompson]

(In reply to comment #47)
> Which patch(es) need review? Do I use that "patch of xcode"?

As I understand it crot0's "patch of xcode" simply ensures the cursors get added
to Camino's static build target. As such you shouldn't need it unless you want
to try the static build for some reason.

> And out of
> curiosity (maybe it would influence my review too) - what do we gain by using
> NSCursor instead of whatever we're doing now? i.e. what is the point of this?
> Why do pink and smfr want it?

To directly answer your question

* the custom cursors are TIFF files, which makes them easier to edit than the
old CURS resources, which are in a .r file and need to be Rez/Derezed to work

* you can put colour in the new NSCursors and make then larger that 16x16

Originally it was smfr that asked me to do the port to NSCursor, IIRC.

Incidentally, the patch does a bunch of other stuff, like making cursors which
should be animated actually animate, whereas they didn't before. But you
probably already knew that.

I'd really appreciate a review. This has been sat in my queue for a long time.

Comment 49

[Jasper]

Does this really mean that Camino could use fullcolor specially crafted cursors,
if we wanted?

Comment 50

[Andrew Thompson]

Well, yes and no.
Any version of Camino or Mozilla on any platform I know about uses a mixture of
cursors that are built into the OS (be it GTK, Windows or Mac OS) and custom
cursors. We use the OS cursor wherever one exists, so as to be consistent with
the look and feel on that platform.

* Some of the OS cursors on Mac OS X are already large & colourful (eg, the file
copy cursor, which Camino can use)

* Any of the custom cursors could be colourized by theme designers, but not the
built in ones

I guess one could imagine an enhancement where all of the built in cursors could
be replaced for themeing purposes, but I'm not a huge fan of themes, so you'd
have to look to someone else to get that done. (I'd review it if someone did it,
I'm just not going to do it myself)

Comment 51

[Ludovic Hirlimann [:Usul]]

Comment on attachment 141889 [details] [diff] [review]
Add comments & fix indenting, as discussed

>+/*! @method     setCursor:
>+    @abstract   Sets the current cursor.
>+    @discussion Sets the current cursor to the cursor indicated by the XP cursor constant given as an argument.
>+                Resources associated with the previous cursor are cleaned up.
>+    @param aCursor the cursor to use

I like that comment style. Could we enforce it for the rest of Camino at least
?


>Index: project.pbxproj
>===================================================================
This file is unecssary and corrupts the file presently in CVS. Adding the file
manually works perfectly.


Tested both on Panther and Jaguar. Works on both systems.
r=[e-mail]

Comment 52

[Mike Pinkerton (not reading bugmail)]

if the cursor files land in camino's space, how do they work if you just build
mozilla with cocoa widget? won't they be missing?

Comment 53

[Andrew Thompson]

(In reply to comment #52)
> if the cursor files land in camino's space, how do they work if you just build
> mozilla with cocoa widget? won't they be missing?

We can build Mozilla with Cocoa widgets ?!?

Well, then yes, the cursors .tiff will have to go somewhere else too. I assume I'll need two copies, one 
inside Mozilla's bundle and one inside Camino's bundle. Probably a Makefile can be adjusted to achieve 
this.

Are there any Cocoa related resources shared between the two applications at present? If so, I'll copy 
how that was done.

Comment 54

[Hiro]

(In reply to comment #53)
> (In reply to comment #52)
> We can build Mozilla with Cocoa widgets ?!?

Firefox is made although Mozilla is not known :-)

Comment 55

[Mike Pinkerton (not reading bugmail)]

where do the cursors live for the carbon version? in widget? we can always copy
them into the app bundle with the xcode project at camino's build time.

Comment 56

[Andrew Thompson]

Yes. The Carbon cursors are in a .r file in widget that gets compiled with Rez
by the Mozilla Makefile.

I can certainly put the cursors under widget and add a 'copy files' phase to the
xcode project from Camino.

What I don't currently know is which other bundles I'd need to copy them into.
It sounds like I might need to adjust some other stuff for the Cocoa builds of
Mozilla and/or Firefox?

Comment 57

[Mike Pinkerton (not reading bugmail)]

well, just do in widget/cocoa whatever you did in widget/mac. the build
mechanism for the hypothetical cocoa seamonkey would pick that up. i just didn't
want to preclude that hypothetical by landing the resources in camino.

a copy build phase is exactly what i was thinking. just make sure to hit *all*
the targets with that build phase (esp static).

Comment 58

[Josh Aas]

when you're finished deciding how to add the files to the project, could you
please post instructions as to exactly how to apply the patch? thanks

Comment 59

[Andrew Thompson]

Attachment: Apr 5 patch to xcode, new location for cursor .tiff files

Comment 60

[Andrew Thompson]

(In reply to comment #58)
> when you're finished deciding how to add the files to the project, could you
> please post instructions as to exactly how to apply the patch? thanks

1. Download attachment 134894 [details] and unzip the cursors to
mozilla/widget/src/cocoa/cursors/

2. Get the patch from 141889 and strip out the out of date xcode bit before
applying. You many have some trouble with the new files, because patch seems to
be confused as to where to put them. Each new file specifies its location in its
header, but you can't go wrong if you put all the new files in /widget/src/cocoa/

3. Apply the new patch 145529 - as of Apr 5th it is up to date with respect to
the Camino Xcode project. Of course, these things have a short shelf life as the
project changes often.

That should be it! Rebuild and you should get animated cursors. See attachment
134892 [details] for a complete testcase.

Comment 61

[Josh Aas]

Comment on attachment 141889 [details] [diff] [review]
Add comments & fix indenting, as discussed

Compiles, runs, passes tests, and the code looks good to me. Sorry for the
wait, nice work. r=[e-mail]

Comment 62

[Josh Aas]

I think this patch should land on the trunk, but not on the 0.8 branch for now.

Note - how does bug 78363 relate to this? Don't have time to check it out now
myself.

Comment 63

[Josh Aas]

Never mind that note of mine... forgot that I included fixed bugs in my query to
find this one and thus I assumed it wasn't fixed yet.

Comment 64

[Josh Aas]

Just built with latest code from the trunk, a few hours after pink checked the
patch in. Build completed, patch works as it should as far as I can tell. Can we
mark this fixed? Nice job pixel.

Comment 65

[Josh Aas]

Pinkerton: I just noticed that you checked in some debugging code that fills up
my log. Check out your diff for NSChildView.mm - the bottom half of it. Did you
mean to do that?

Comment 66

[Mike Pinkerton (not reading bugmail)]

landed on trunk (not 0.8 branch) YAY!!!!!

Comment 67

[Mike Pinkerton (not reading bugmail)]

d'oh! i knew i had other changes in there. sigh. i'll fix that tonight.

Comment 68

[Stuart Morgan]

Just FYI, this should never land on the branch as it is. The method
performSelectorOnMainThread:withObject:waitUntilDone:
http://lxr.mozilla.org/mozilla/source/widget/src/cocoa/nsMacCursor.mm#366
is 10.2+, so this won't work on 10.1.5

Comment 69

[R.K.Aa.]

Did someone borrow a Windows cursor and forget to put it back? bug 242233

Comment 70

[Andrew Thompson]

(In reply to comment #68)
> Just FYI, this should never land on the branch as it is. The method
> performSelectorOnMainThread:withObject:waitUntilDone:
> http://lxr.mozilla.org/mozilla/source/widget/src/cocoa/nsMacCursor.mm#366
> is 10.2+, so this won't work on 10.1.5

I didn't think we still supported 10.1 with Camino?

That line could be removed if necessary, I think.

Comment 71

[Stuart Morgan]

0.8 will support 10.1.5; after that Camino will be 10.2+ only.  So probably the
easiest thing is to just leave this patch out of the 0.8 branch, and keep it on
the trunk where breaking 10.1.5 support doesn't matter.

Comment 72

[Stuart Morgan]

Comment on attachment 141889 [details] [diff] [review]
Add comments & fix indenting, as discussed

Removing sr?, since it's already landed.

Comment 73

[timeless]

2004-05-25 05:09:33.210 xcodebuild[8367] warning: work queue node
<node:0x13ef990:'/Users/timeless/obj-powerpc-apple-darwin7.3.1-camino/widget/src/cocoa/cursors/arrowN.tiff'[2]:Missing:0>
wants neither an invocation nor a subprocess -- ignoring it

PBXCp build/Camino.app/Contents/Resources/arrowN.tiff
/Users/timeless/obj-powerpc-apple-darwin7.3.1-camino/widget/src/cocoa/cursors/arrowN.tiff
    cd /Users/timeless/obj-powerpc-apple-darwin7.3.1-camino/camino
    /Developer/Tools/pbxcp -exclude .DS_Store -exclude CVS -strip-debug-symbols
-resolve-src-symlinks
/Users/timeless/obj-powerpc-apple-darwin7.3.1-camino/widget/src/cocoa/cursors/arrowN.tiff
/Users/timeless/obj-powerpc-apple-darwin7.3.1-camino/camino/build/Camino.app/Contents/Resources
/Users/timeless/obj-powerpc-apple-darwin7.3.1-camino/widget/src/cocoa/cursors:
No such file or directory
** BUILD FAILED **

This code is not objdir safe. my brand new build on my brand new mac is unhappy.

You probably want to have a Makefile.in in the cursors directory which symlinks
the files to the objdir when there's an objdir.

Comment 74

[Andrew Thompson]

Since I'm only very vaguely aware of what an objdir build is, can I ask you to
make the patch? I'll review it and get it sr'd and checked in. Probably need a
new bug too

Comment 75

[Jeff Grossman]

Is there a new bug for the objdir problem?  I am currently running into that
problem when I try and build Camino.

Comment 76

[timeless]

my build is otherwise unhappy, bug Bug 245623 has my draft, it seems to do what
is needed, someone should confirm that it doesn't hurt srcdir builds (i do not
plan to build srcdir) and that it fixes (however inellegantly) the problem for
objdir.