various changes to handling custom cursors:

* all cursors owned by a team are visually different,
  or (iaw) an already existing cursor is reused when
  it is set by the client again
* changed various occurances of cursor data from "int8*"
  to "uint8*"
* ServerCursors also remember the R5 data from which
  they were created
* the reference counting and destruction of
  ServerCursors changed: The cursor knows it is attached
  to a CursorManager and one can simply use
  ServerCursor::Acquire() and Release() and the reference
  counting and everything is being taken care of
* destroying a ViewLayer will now correctly release a set
  ServerCursor
* fixed a race condition when setting a cursor through
  BView::SetViewCursor(): If the client code looks like this:

  BCursor cursor(cursorData);
  someView->SetViewCursor(&cursor, false);

  there is a relatively high chance the BCursor destructor
  told the ServerApp thread to destroy the cursor before
  the ServerWindow thread got to "acquire" the cursor for
  use by the view layer. The very same problem is likely the
  reason that SetViewCursor works to unreliably on R5, even
  when the "sync" flag is set to "true" (although it should
  theoretically work in that case).

all these fixes make WonderBrush work fine again with the
new support of custom cursors.... coded by axeld and myself
(the joys of pair programming :-)



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16521 a95241bf-73f2-0310-859d-f6bbb57e9c96

src/kits/interface/View.cpp

@@ -980,18 +980,20 @@ BView::ResizingMode() const
 void
 BView::SetViewCursor(const BCursor *cursor, bool sync)
 {
-	if (!cursor)
+	if (cursor == NULL || fOwner == NULL)
 		return;
 
-	if (!fOwner)
-		debugger("View method requires owner and doesn't have one");
-
 	check_lock();
 
 	fOwner->fLink->StartMessage(AS_LAYER_SET_CURSOR);
 	fOwner->fLink->Attach<int32>(cursor->fServerToken);
 
-	if (sync)
+	if (!sync) {
+		cursor->fPendingViewCursor = true;
+			// this avoids a race condition in case the cursor is
+			// immediately deleted after this call, as the deletion
+			// is handled by the application, not the window
+	} else
 		fOwner->fLink->Flush();
 }