use .IsSet() instead if .Get() != NULL

Change-Id: Ia2b7a719fd398e78cc3b11d4f7b02cb81179f65f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3488
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>

app_server memory management: use ObjectDeleter to mark ownership

Make object ownership explicit by use of ObjectDeleter where possible.

Change-Id: I499a00aa3390d1510ae284419e73faffa5166430
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2695
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>

app_server memory management fixes: use BReference

Use BReference for more automated reference counting in app_server,
fixing some use-after-free and other problems.

Extracted from https://review.haiku-os.org/c/haiku/+/2695

Change-Id: I141bb248229405896b29feff3338447f7257b0b4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3175
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

AppServer: check for NULL bitmap.
Consistently check for NULL the ServerBitmap pointer.
There seems to be cases where BView::DragMessage could pass an invalid
Bitmap token to app_server.
Maybe it's when a client only bitmap is passed, I don't know.
Anyway, this is defensive programming, and at least we check for NULL
consistently now.
This fixes #11681.
Note that SuperFreeCell still crashes, but at least app_server doesn't crash.

Fix a bug retreiving tooltips

Noticed this in Time prefs was displaying wrong time zone tool tip,
dug deeper...

hrev46290 introduced this bug because it passes fLastCursorPosition
into the “be:view_where” parameter of the B_MOUSE_IDLE message.
The problem is that fLastCursorPosition is in the screen’s coordinate
system, not the view’s and BView expects “be:view_where” to be in the
view’s coordinate system.

So, to fix this I pass fLastCursorPosition in the “screen_where” parameter
instead which I’ve instructed BView to interpret as the point in the screen’s
coordinate system which is then dutifully converted back the the view’s
coordinate system.

I tried to follow the naming scheme of other code, not sure if screen_where
should be namespaced with the be: predicate or not.

EventDispatcher: Style fixes

Move B_MOUSE_IDLE generation to app_server.

* BWindow used to generate the B_MOUSE_IDLE events by sending a
delayed message with a one-shot BMessageRunner to itself.
Every creation and deletion of BMessageRunners causes synchronous
messaging between the application under the mouse cursor and the
registrar. This creates large amounts of calls to set_port_owner()
in the kernel whenever moving the mouse.

* Now, B_MOUSE_IDLE is sent by the cursor loop inside the app_server
instead. When the mouse wasn't moved for the tooltip delay time,
it inserts a B_MOUSE_IDLE message into the event stream.

* The tooltip delay thus becomes a system-wide constant and is not
configurable per-application anymore (no code currently in the
Haiku repo makes use of that anyhow).

CID 10229: fDraggingMessage was not initialized, potentially sending out drag
messages where there shouldn't have been any.


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

* Refactored ServerBitmap a bit: it now inherits from Referenceable instead of
roling its own solution.
* Also removed BitmapManager::DeleteBitmap() - you only call
ServerBitmap::RemoveReference(), and that one will notify the manager if
needed.
* Some more cleanup.


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

Renamed the new "_fake" mouse moved boolean to "be:transit_only", as suggested
by Axel.


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

Add a boolean "_fake" parameter to fake mouse moves in case views care that the
app_server generated it.

For now used by screen_blanker, in my next commit.


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

* Reworked EventDispatcher::SendFakeMouseMoved() after an idea by Stephan
that solves most app_server locking headaches: it now works asynchronously,
and therefore doesn't need to lock the EventDispatcher anymore.
* EventStreams now allow to inject messages into the stream to allow the above
functionality.
* InputServerStream::GetNextEvent() no longer returns when there is no event.
* Desktop::ActivateWindow() now locks all windows before checking the
workspaces of the windows, fixing a race condition that could lead to
Window::Foremost() being called for a window that isn't on the current
workspace, leading to a crash.
* I currently cannot access Trac, but I recall there should be an open bug
report about this.


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

Whitespace cleanup.


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

zooey + axeld + stippi:
Fixed a problem with dispatching B_MOUSE_MOVED messages to views which need
the transit event:
* If the app_server decided to send a B_MOUSE_MOVED to the previous mouse
containing window, it forgot to add the _feed_focus flag, which was a problem
if the message actually happened to contain tokens (views that registered
for events.) On the client side, only those views would receive the message,
while the regular last mouse moved view would not be notified at all.
* On the client side, never change fLastMouseMovedView if the message is not
targeted at the preferred handler. In the above situation, any "registered
for events views" would receive the message first, but viewUnderMouse would
be NULL and then when the regular last mouse moved view received it, it
resulted in the wrong transit (B_OUTSIDE_VIEW instead of B_EXITED_VIEW).


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

* fDragBitmap was never initialized, leading to occasional crashes after the
first mouse click.
* Minor cleanup.


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

* SetDragMessage() could be called when the mouse button was already released.
* Since it didn't check if any mouse button was pressed at the time it was
called, it would still initiate a drag, and thus caused bug #1710.


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

Implemented AS_IDLE_TIME, this closes bug #1593.


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

* added a way for the ServerWindow message loop to determine the required type
of locking before processing the message (single/all window lock)
-> in most message cases, I could comment out the unlocking/locking which
switched to the different lock, because the required lock is now already held,
this removes some race conditions which were commented in the code already
* EventDispatcher::SetDragMessage() didn't lock the object, this would have
been bad if multiple windows tried to set a drag bitmap at once
* the Desktop object keeps track of mouse position and pressed buttons, so
that it doesn't need to lock the EventDispatcher for sending fake mouse
moves to windows on show/hide of windows (solves some cases of possible
dead locks with the new locking strategy)
* the keyboard EventFilter switches the current workspace asynchrnously from
the Desktop thread (another source of possible deadlocks)
* the "reader is trying to become writer" check in MultiLocker is only used
in DEBUG mode now

As a summary: It would be nice if ServerWindow used a readlock for all messages
it processes itself, and forwards all messages for which it needs a write lock
to the Desktop thread. All cases where either the Desktop or the ServerWindow
mess with the EventDispatcher are possible sources of deadlocks. This is solved
right now by making sure that the lock is released before using the
EventDispatcher.

I have not observed any deadlocks while switching workspaces and launching
many apps anymore, neither crashes. But I have not tested extensively except
for in the test environment. That being said, I could reproduce the problems
on first try before in Haiku.


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

The app_server now starts and restarts (if needed) the input_server. The use of
a debugger call in _LaunchInputServer may be overkill, but at least you could
conceivably cleanly restart the machine in the debugger (I think.) Because
without the input_server the machine is pretty useless.


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

The app_server did not reset keyboard focus on B_INPUT_METHOD_EVENT messages.
This should fix bug #658.


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

Improved the fake mouse-moved mechanism quite a bit:
* EventDispatcher now adopts the cursor position from the HWInterface upon
assignment, so that even the initial cursor reports match the on screen
visuals.
* The message was never sent because "target" in Desktop::_SendFakeMouseMoved()
was never set.
* EventDispatcher::SendFakeMouseMoved() now accepts an EventTarget and no
longer a BMessenger (fits better to the rest of the API).
* EventDispatcher::SendFakeMouseMoved() now sends out the exit transit message
to the previous target directly (doesn't wait until the next actual mouse
move), and updates the previous target as well, so that scrolling now
works in that new window.
* This only partially fixes bug #762, though, as GetMouse() can still steal
this mouse message (BTextViews do that in WindowActivated()).


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

* If a BView::SetMouseEventMask() arrived in the app_server after the mouse buttons
have already been released again, the temporary listener was still added.
This fixes bug #727.
* No longer removes temporary listeners if there are mouse buttons left pressed; ie.
if you press two buttons at once, the listeners are now only removed after you've
released them both. This is not only more logical, it's also how BeOS behaves :-)


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

Since the keyboard filter compared targets by their pointers, it could happen
that it didn't reset the EventDispatcher's focus target even though the object
underneath that same pointer had change, which caused the EventDispatcher to
drop the event.
This fixes bug #416, and should fix bug #409, too.


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

First steps at getting drag & drop to work properly. Simple drag & drop (draging Tracker items) should work now. Not sure about the negotiated version (with mimetype exchange). Fixed left behind drag bitmaps. Some cleanup.

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

* A fake B_MOUSE_MOVED message is now send on workspace change, and when
a window is closed, too (only happened when a new window was shown
before). This is done via the new Desktop::_SendFakeMouseMoved()
method. This fixes bug #342.
* The MouseFilter now always sets Desktop::fWindowUnderMouse, so that
one can differentiate between no window under mouse, and decorator
under mouse.
* EventDispatcher::SendFakeMouseMoved() now expects a BMessenger instead
of an EventTarget as target - this guarantees that it can safely be
called with any window now (instead of only the current window).


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

Moved the ViewUnderMouse() functionality from the EventDispatcher to the Desktop;
this saves us some locking headaches and solves a possible deadlock in
ServerApp::Activate().


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

* The EventDispatcher takes care of reference counting the ServerBitmap
used for the drag bitmap, see NOTEs on why that is...
* moved reference counting of the ServerCursor from Desktop into
HWInterface where it is actually used
* I hope to have fixed the problems with _DrawCursor when dragging
something. At least the reference counting of the ServerCursor was
for real, since the HWInterface rejected changes to the cursor while
something was dragged, which caused the old cursor to be Released() and
deleted each time the mouse moved...


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

* added a way to retrieve the view under the mouse
via token

(coded by axeld)



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

Fixed possible crashing bug for B_NO_POINTER_HISTORY views.


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

Implemented B_NO_POINTER_HISTORY. Window moving/resizing uses this mechanism
as well now, and makes quite a difference in Qemu.
Not tested for standard BViews, though.


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

Quick fix to make the Qemu experience less bad :-)


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

Removed timeout in the EventDispatcher, clarified TODO about the message queue
of messages that failed to be sent.


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

ServerFont:
* fixed weird pointer conversion in SetStyle()
* fixed a potential mix up in operator=() in case the
other ServerFont has fStyle == NULL

ServerWindow:
* the WindowLayer fTopLayer cannot be deleted by
client request, just for safety reasons
* the link is flushed if there is no drawing engine,
but this case is theoretical only
* deleting the ServerWindow object syncs with the
client, so that when BBitmaps are deleted, they
can be sure there are no pending messages (which
would be executed in a nother thread)
* there is no timeout anymore when sending messages
to the client, which made absolutely no sense

AGGTextRenderer:
* renamed fFontManager to fFontCache, because that's
what it really is
* fLastFamilyAndStyle defaulted to the system plain
font and therefor that font was never loaded when
the font never changed meanwhile

DrawingMode:
* I'm not quite sure but I think there was the
potential of a division by zero, at least I
had crashes with "divide error"

HWInterface:
* fix update when the cursor shape changed in
double buffered mode

ViewLayer:
* since the top layer is never really deleted
before its time has come, it is not necessary
to set it to NULL in the ViewLayer destructor

ViewLayer/WindowLayer:
* added a function to collect the view tokens
that are affected by an update session

EventDispatcher:
* use the importance of the message for the timeout
in _SendMessage()
* drop mouse moved events in the server if we're
lagging behind more than 5 ms (Axel, maybe review)

View:
* there were some problems with the locking
of the BWindow looper in RemoveSelf(), since
this is called from the window destructor,
also of BWindows from BBitmaps, which have
never been run (this might need review), at
least I seem to have solved the crashing
problems introduced by actually deleting the
view hirarchy in the BWindow destructor
* fixed _Draw() for being used non-recursively,
temporarily disabled DrawAfterChildren, which
didn't work yet anyways (because views cannot
draw over children in the server yet)

Window:
* small cleanup when deleting shortcuts
* sync with the server when having send
AS_DELETE_WINDOW (see ServerWindow above)
* fixed locking in Begin/EndViewTransaction()
* removed folding of _UPDATE_ messages, since
there is only one ever in the queue
* set the fInTransaction flag during an update,
I plan to use this in BView later to
flush the link when drawing outside of an
update
* BView::_Draw() is now called by view token,
this gives the next leap forward in speed,
the overhead because of drawing clean views
was considerable



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

Fixed some problems of the EventDispatcher I introduced since I've played
with the "EventMask" test app the last time:
* The focus view didn't get any mouse messages anymore if there was a permanent
B_POINTER_EVENTS view.
* B_KEYBOARD_EVENTS now works again.
* B_MOUSE_WHEEL_CHANGED messages no do arrive their targets without prior
keyboard input.
* Added TODO item that other focus messages don't go through to the app without
keyboard input (fix only works for B_MOUSE_WHEEL_CHANGED).


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

first simplistic implementation of drag bitmaps, drawing modes need more work, drawing text into offscreen bitmaps seems to be broken for some weird reason, B_OP_COPY actually copies the alpha value of the color as well

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

Merged app_server_new_clipping branch changes r15290 to 15418 back into trunk.
Also fixed Jamfile for the test environment.


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

EventDispatcher::_Unset() did not wait for the event looper thread under BeOS, as
wait_for_thread() always returns B_BAD_ADDRESS when the second argument is NULL
(it works fine under Haiku).
Instead of enqueuing a B_QUIT_REQUESTED message, InputStream now directly quits
when the 'quit' code is read from the port (B_QUIT_REQUESTED was never handled
by the event loop either, it just didn't get noticed because of the wrong
wait_for_thread() usage).


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

* new windows now get a fake B_MOUSE_MOVED message in case they are opened
directly under the mouse cursor.
* Added Desktop::ShowWindow() and HideWindow().


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

Added a bit of documentation to the EventDispatcher.


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

Have I said input event handling is done?
* didn't realize that mouse events always go to the view under the mouse, not
only if its the focus window (FFM can really do harm, after all :-)).
* removed a TODO from the list: EventDispatcher::Target is now a public
class EventTarget, and every ServerWindow has one.
* as a result, EventDispatcher no longer manages targets itself, it
just maintains a list of them. You no longer set messengers, you
only set targets.
* customization of the message filters, they no longer inherit from
BMessageFilter (but EventFilter).
* a message target is no longer set explicetly anywhere, it's only
changed in the message filters if needed.
* therefore, no more locking mess in the EventDispatcher needed.
* this also made the EventDispatcher::fLastFocus stuff superfluous.
* moved the RootLayer::MouseEventHandler() into the message filter.
* Replaced RootLayer::_ChildAt() with WindowAt().
* WindowLayer now has an idea if it has focus or not, it no longer needs
to query the RootLayer for this - maybe we should rename "focus" to
"active", though (as far as layers are concerned).
* the "_view_token" data is now added from the EventDispatcher, not
the (Window)Layer class anymore.
* removed Layer::MouseWheelChanged() as we currently don't need it
(if the need arises, we can add it back later again)
* there is still no mouse moved message sent when opening a window
under the cursor, though...


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

Added temporary hack so that windows don't get mouse messages if the cursor
is not over them - this should be better integrated with the rest of the
code (later, when we don't rely on RootLayer for everything anymore).


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

Quick fix for our broken locking model:
The mouse filter needs to lock RootLayer, but the event dispatcher lock is held
during that time, too, so that the focus cannot change in the mean time.
On the other side, ServerWindow needs to lock the event dispatcher when adding
or removing a listener, or for AS_GET_MOUSE - but since it always helds the
root layer lock during message dispatching this easily resulted in a deadlock.


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

Minor cleanup: removed unused stuff.


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

In anticipation of Stippi's new clipping code, I refactored the EventDispatcher
a bit:
* listeners are now managed per target (ie. per messenger) (by the Target class)
* therefore, the fFocusTokens/fLastFocusTokens lists are no longer needed; every
Target knows its listeners already.
* this also fixes the obvious bug that the focus window's views would get both
keyboard and pointer events, no matter which of them they originally wanted.
* renamed event_target to event_listener (there was actually a mix up in naming
before - to the outside it was "listener", and internally, "target" was used)
* WinBorder::MouseMoved()/MouseUp() now also add the view token to the message;
the messages weren't received by the target before (unless the view used
tracking via BView::SetMouseEventMask()...) - maybe the client should only
update fLastMouseMoved on B_MOUSE_MOVED events, and direct B_MOUSE_UP/DOWN
(plus wheel changes) always to fLastMouseMoved...
* some cleanup.


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

* removed adding "be:transit" stuff in the EventDispatcher - this is now only done
client side (or will be, with the next commit).
* added GetMouse() functionality.


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

* changed the way a message is forwarded to the focus view (instead of adding
a suspend focus field to the message, there is now a "feed focus" field in
case the message should be forwarded).
* added a comment to the BPoint version of _FindView() (since it's broken)
* _DistributeMessage() is now called after _DetermineTarget() - so that it
can prevent sending the message twice to the focus view.
* removed BWindow::DoUpdate() as it's no longer used.


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

* now all event targets of the focus window get into the focus list - that
way, we always send only one message per event, no matter how many targets
there are in the window (the focus event list was not always maintained
correctly before, too).
* the current mouse filter eats all B_MOUSE_UP events, and therefore, the
temporary event targets were never removed.
* changed the way BWindow::_DistributeMessage() recognizes if it should forward
the event - not yet final, though.
* naming is now more consistent (events -> event_mask).
* some minor cleanup.


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

Some minor fixes.


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

* EventDispatcher::AddListener() now honors the BView semantics and will only
update the options in case the specified eventMask was zero.
* Added missing EventDispatcher::RemoveTemporaryTarget().
* Layers setting their event mask are now added to the EventDispatcher.
* The RootLayer is no longer contacted for SetEventMask() - it still handles
SetMouseEventMask(), tough - as a result, SetEventMask() temporarily doesn't
work anymore.
* Added Layer::ViewToken() method.


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

* Moved workspace keyboard switch and dump screen capability from RootLayer
into a Desktop keyboard filter.
* Removed keyboard handling code from RootLayer and Layer.
* Renamed Desktop::ActiveRootLayer() to RootLayer() as there is only one
root layer per desktop.


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

* the keyboard events are now using the new EventDispatcher, B_KEYBOARD_EVENTS don't
work yet, though, as the dispatcher is not yet notified about those.
* no more mouse cursor jumping - the cursor will now start in the middle of the screen;
this should be part of the initial input_server handshake, though.
* ServerWindow can now return a BMessenger of its client window.


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

* the new input event dispatcher is now actually used, although it doesn't
distribute any messages to the clients yet.
* removed the working thread from RootLayer - for now, its event handlers are
still called using input filters in the new event dispatcher, though (to
get things started).
* ServerApp is now using a BMessenger to identify its client, and no longer
stores the port/token separately.
* the input_server handshake is a bit simpler now, as it can now just reply
to the app_server message, removed unused code from ServerProtocol.h
* calmed down the MultiLocker (it always printed thread statistics on startup,
because it's compiled in debug mode).
* removed the cursor thread stuff from AppServer.cpp
* the new event dispatcher now uses a cursor thread when supported (only in
native mode, not in the test environment), although it improves cursor
movement under Qemu, the effect is not as good as expected - this might
need some more investigations (might just be a thread priority problem).


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

Implemented support for Set[Mouse]EventMask() functionality - still untested, though.
Also supports the B_SUSPEND_VIEW_FOCUS options, B_NO_POINTER_HISTORY is not yet there,
and B_LOCK_WINDOW_FOCUS has to be implemented somewhere else (its outside of the
scope of this class).


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

* Fixed the most obvious copy&paste bugs.
* no longer allocates focus messengers on the heap but keeps them around.


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

The basics of the new event handling - not yet connected to anything, and therefore
neither used nor tested. It's not even complete yet (support for Set[Mouse]EventMask()
is missing), but it will get there :)


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

AppServer: check for NULL bitmap.
Consistently check for NULL the ServerBitmap pointer.
There seems to be cases where BView::DragMessage could pass an invalid
Bitmap token to app_server.
Maybe it's when a client only bitmap is passed, I don't know.
Anyway, this is defensive programming, and at least we check for NULL
consistently now.
This fixes #11681.
Note that SuperFreeCell still crashes, but at least app_server doesn't crash.

Fix a bug retreiving tooltips

Noticed this in Time prefs was displaying wrong time zone tool tip,
dug deeper...

hrev46290 introduced this bug because it passes fLastCursorPosition
into the “be:view_where” parameter of the B_MOUSE_IDLE message.
The problem is that fLastCursorPosition is in the screen’s coordinate
system, not the view’s and BView expects “be:view_where” to be in the
view’s coordinate system.

So, to fix this I pass fLastCursorPosition in the “screen_where” parameter
instead which I’ve instructed BView to interpret as the point in the screen’s
coordinate system which is then dutifully converted back the the view’s
coordinate system.

I tried to follow the naming scheme of other code, not sure if screen_where
should be namespaced with the be: predicate or not.

EventDispatcher: Style fixes

Move B_MOUSE_IDLE generation to app_server.

* BWindow used to generate the B_MOUSE_IDLE events by sending a
delayed message with a one-shot BMessageRunner to itself.
Every creation and deletion of BMessageRunners causes synchronous
messaging between the application under the mouse cursor and the
registrar. This creates large amounts of calls to set_port_owner()
in the kernel whenever moving the mouse.

* Now, B_MOUSE_IDLE is sent by the cursor loop inside the app_server
instead. When the mouse wasn't moved for the tooltip delay time,
it inserts a B_MOUSE_IDLE message into the event stream.

* The tooltip delay thus becomes a system-wide constant and is not
configurable per-application anymore (no code currently in the
Haiku repo makes use of that anyhow).

CID 10229: fDraggingMessage was not initialized, potentially sending out drag
messages where there shouldn't have been any.


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

* Refactored ServerBitmap a bit: it now inherits from Referenceable instead of
roling its own solution.
* Also removed BitmapManager::DeleteBitmap() - you only call
ServerBitmap::RemoveReference(), and that one will notify the manager if
needed.
* Some more cleanup.


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

Renamed the new "_fake" mouse moved boolean to "be:transit_only", as suggested
by Axel.


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

Add a boolean "_fake" parameter to fake mouse moves in case views care that the
app_server generated it.

For now used by screen_blanker, in my next commit.


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

* Reworked EventDispatcher::SendFakeMouseMoved() after an idea by Stephan
that solves most app_server locking headaches: it now works asynchronously,
and therefore doesn't need to lock the EventDispatcher anymore.
* EventStreams now allow to inject messages into the stream to allow the above
functionality.
* InputServerStream::GetNextEvent() no longer returns when there is no event.
* Desktop::ActivateWindow() now locks all windows before checking the
workspaces of the windows, fixing a race condition that could lead to
Window::Foremost() being called for a window that isn't on the current
workspace, leading to a crash.
* I currently cannot access Trac, but I recall there should be an open bug
report about this.


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

Whitespace cleanup.


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

zooey + axeld + stippi:
Fixed a problem with dispatching B_MOUSE_MOVED messages to views which need
the transit event:
* If the app_server decided to send a B_MOUSE_MOVED to the previous mouse
containing window, it forgot to add the _feed_focus flag, which was a problem
if the message actually happened to contain tokens (views that registered
for events.) On the client side, only those views would receive the message,
while the regular last mouse moved view would not be notified at all.
* On the client side, never change fLastMouseMovedView if the message is not
targeted at the preferred handler. In the above situation, any "registered
for events views" would receive the message first, but viewUnderMouse would
be NULL and then when the regular last mouse moved view received it, it
resulted in the wrong transit (B_OUTSIDE_VIEW instead of B_EXITED_VIEW).


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

* fDragBitmap was never initialized, leading to occasional crashes after the
first mouse click.
* Minor cleanup.


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

* SetDragMessage() could be called when the mouse button was already released.
* Since it didn't check if any mouse button was pressed at the time it was
called, it would still initiate a drag, and thus caused bug #1710.


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

Implemented AS_IDLE_TIME, this closes bug #1593.


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

* added a way for the ServerWindow message loop to determine the required type
of locking before processing the message (single/all window lock)
-> in most message cases, I could comment out the unlocking/locking which
switched to the different lock, because the required lock is now already held,
this removes some race conditions which were commented in the code already
* EventDispatcher::SetDragMessage() didn't lock the object, this would have
been bad if multiple windows tried to set a drag bitmap at once
* the Desktop object keeps track of mouse position and pressed buttons, so
that it doesn't need to lock the EventDispatcher for sending fake mouse
moves to windows on show/hide of windows (solves some cases of possible
dead locks with the new locking strategy)
* the keyboard EventFilter switches the current workspace asynchrnously from
the Desktop thread (another source of possible deadlocks)
* the "reader is trying to become writer" check in MultiLocker is only used
in DEBUG mode now

As a summary: It would be nice if ServerWindow used a readlock for all messages
it processes itself, and forwards all messages for which it needs a write lock
to the Desktop thread. All cases where either the Desktop or the ServerWindow
mess with the EventDispatcher are possible sources of deadlocks. This is solved
right now by making sure that the lock is released before using the
EventDispatcher.

I have not observed any deadlocks while switching workspaces and launching
many apps anymore, neither crashes. But I have not tested extensively except
for in the test environment. That being said, I could reproduce the problems
on first try before in Haiku.


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

The app_server now starts and restarts (if needed) the input_server. The use of
a debugger call in _LaunchInputServer may be overkill, but at least you could
conceivably cleanly restart the machine in the debugger (I think.) Because
without the input_server the machine is pretty useless.


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

The app_server did not reset keyboard focus on B_INPUT_METHOD_EVENT messages.
This should fix bug #658.


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

Improved the fake mouse-moved mechanism quite a bit:
* EventDispatcher now adopts the cursor position from the HWInterface upon
assignment, so that even the initial cursor reports match the on screen
visuals.
* The message was never sent because "target" in Desktop::_SendFakeMouseMoved()
was never set.
* EventDispatcher::SendFakeMouseMoved() now accepts an EventTarget and no
longer a BMessenger (fits better to the rest of the API).
* EventDispatcher::SendFakeMouseMoved() now sends out the exit transit message
to the previous target directly (doesn't wait until the next actual mouse
move), and updates the previous target as well, so that scrolling now
works in that new window.
* This only partially fixes bug #762, though, as GetMouse() can still steal
this mouse message (BTextViews do that in WindowActivated()).


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

* If a BView::SetMouseEventMask() arrived in the app_server after the mouse buttons
have already been released again, the temporary listener was still added.
This fixes bug #727.
* No longer removes temporary listeners if there are mouse buttons left pressed; ie.
if you press two buttons at once, the listeners are now only removed after you've
released them both. This is not only more logical, it's also how BeOS behaves :-)


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

Since the keyboard filter compared targets by their pointers, it could happen
that it didn't reset the EventDispatcher's focus target even though the object
underneath that same pointer had change, which caused the EventDispatcher to
drop the event.
This fixes bug #416, and should fix bug #409, too.


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

First steps at getting drag & drop to work properly. Simple drag & drop (draging Tracker items) should work now. Not sure about the negotiated version (with mimetype exchange). Fixed left behind drag bitmaps. Some cleanup.

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

* A fake B_MOUSE_MOVED message is now send on workspace change, and when
a window is closed, too (only happened when a new window was shown
before). This is done via the new Desktop::_SendFakeMouseMoved()
method. This fixes bug #342.
* The MouseFilter now always sets Desktop::fWindowUnderMouse, so that
one can differentiate between no window under mouse, and decorator
under mouse.
* EventDispatcher::SendFakeMouseMoved() now expects a BMessenger instead
of an EventTarget as target - this guarantees that it can safely be
called with any window now (instead of only the current window).


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

Moved the ViewUnderMouse() functionality from the EventDispatcher to the Desktop;
this saves us some locking headaches and solves a possible deadlock in
ServerApp::Activate().


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

* The EventDispatcher takes care of reference counting the ServerBitmap
used for the drag bitmap, see NOTEs on why that is...
* moved reference counting of the ServerCursor from Desktop into
HWInterface where it is actually used
* I hope to have fixed the problems with _DrawCursor when dragging
something. At least the reference counting of the ServerCursor was
for real, since the HWInterface rejected changes to the cursor while
something was dragged, which caused the old cursor to be Released() and
deleted each time the mouse moved...


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

* added a way to retrieve the view under the mouse
via token

(coded by axeld)



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

Fixed possible crashing bug for B_NO_POINTER_HISTORY views.


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

Implemented B_NO_POINTER_HISTORY. Window moving/resizing uses this mechanism
as well now, and makes quite a difference in Qemu.
Not tested for standard BViews, though.


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

Quick fix to make the Qemu experience less bad :-)


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

Removed timeout in the EventDispatcher, clarified TODO about the message queue
of messages that failed to be sent.


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

ServerFont:
* fixed weird pointer conversion in SetStyle()
* fixed a potential mix up in operator=() in case the
other ServerFont has fStyle == NULL

ServerWindow:
* the WindowLayer fTopLayer cannot be deleted by
client request, just for safety reasons
* the link is flushed if there is no drawing engine,
but this case is theoretical only
* deleting the ServerWindow object syncs with the
client, so that when BBitmaps are deleted, they
can be sure there are no pending messages (which
would be executed in a nother thread)
* there is no timeout anymore when sending messages
to the client, which made absolutely no sense

AGGTextRenderer:
* renamed fFontManager to fFontCache, because that's
what it really is
* fLastFamilyAndStyle defaulted to the system plain
font and therefor that font was never loaded when
the font never changed meanwhile

DrawingMode:
* I'm not quite sure but I think there was the
potential of a division by zero, at least I
had crashes with "divide error"

HWInterface:
* fix update when the cursor shape changed in
double buffered mode

ViewLayer:
* since the top layer is never really deleted
before its time has come, it is not necessary
to set it to NULL in the ViewLayer destructor

ViewLayer/WindowLayer:
* added a function to collect the view tokens
that are affected by an update session

EventDispatcher:
* use the importance of the message for the timeout
in _SendMessage()
* drop mouse moved events in the server if we're
lagging behind more than 5 ms (Axel, maybe review)

View:
* there were some problems with the locking
of the BWindow looper in RemoveSelf(), since
this is called from the window destructor,
also of BWindows from BBitmaps, which have
never been run (this might need review), at
least I seem to have solved the crashing
problems introduced by actually deleting the
view hirarchy in the BWindow destructor
* fixed _Draw() for being used non-recursively,
temporarily disabled DrawAfterChildren, which
didn't work yet anyways (because views cannot
draw over children in the server yet)

Window:
* small cleanup when deleting shortcuts
* sync with the server when having send
AS_DELETE_WINDOW (see ServerWindow above)
* fixed locking in Begin/EndViewTransaction()
* removed folding of _UPDATE_ messages, since
there is only one ever in the queue
* set the fInTransaction flag during an update,
I plan to use this in BView later to
flush the link when drawing outside of an
update
* BView::_Draw() is now called by view token,
this gives the next leap forward in speed,
the overhead because of drawing clean views
was considerable



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

Fixed some problems of the EventDispatcher I introduced since I've played
with the "EventMask" test app the last time:
* The focus view didn't get any mouse messages anymore if there was a permanent
B_POINTER_EVENTS view.
* B_KEYBOARD_EVENTS now works again.
* B_MOUSE_WHEEL_CHANGED messages no do arrive their targets without prior
keyboard input.
* Added TODO item that other focus messages don't go through to the app without
keyboard input (fix only works for B_MOUSE_WHEEL_CHANGED).


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

first simplistic implementation of drag bitmaps, drawing modes need more work, drawing text into offscreen bitmaps seems to be broken for some weird reason, B_OP_COPY actually copies the alpha value of the color as well

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

Merged app_server_new_clipping branch changes r15290 to 15418 back into trunk.
Also fixed Jamfile for the test environment.


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

EventDispatcher::_Unset() did not wait for the event looper thread under BeOS, as
wait_for_thread() always returns B_BAD_ADDRESS when the second argument is NULL
(it works fine under Haiku).
Instead of enqueuing a B_QUIT_REQUESTED message, InputStream now directly quits
when the 'quit' code is read from the port (B_QUIT_REQUESTED was never handled
by the event loop either, it just didn't get noticed because of the wrong
wait_for_thread() usage).


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

* new windows now get a fake B_MOUSE_MOVED message in case they are opened
directly under the mouse cursor.
* Added Desktop::ShowWindow() and HideWindow().


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

Added a bit of documentation to the EventDispatcher.


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

Have I said input event handling is done?
* didn't realize that mouse events always go to the view under the mouse, not
only if its the focus window (FFM can really do harm, after all :-)).
* removed a TODO from the list: EventDispatcher::Target is now a public
class EventTarget, and every ServerWindow has one.
* as a result, EventDispatcher no longer manages targets itself, it
just maintains a list of them. You no longer set messengers, you
only set targets.
* customization of the message filters, they no longer inherit from
BMessageFilter (but EventFilter).
* a message target is no longer set explicetly anywhere, it's only
changed in the message filters if needed.
* therefore, no more locking mess in the EventDispatcher needed.
* this also made the EventDispatcher::fLastFocus stuff superfluous.
* moved the RootLayer::MouseEventHandler() into the message filter.
* Replaced RootLayer::_ChildAt() with WindowAt().
* WindowLayer now has an idea if it has focus or not, it no longer needs
to query the RootLayer for this - maybe we should rename "focus" to
"active", though (as far as layers are concerned).
* the "_view_token" data is now added from the EventDispatcher, not
the (Window)Layer class anymore.
* removed Layer::MouseWheelChanged() as we currently don't need it
(if the need arises, we can add it back later again)
* there is still no mouse moved message sent when opening a window
under the cursor, though...


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

Added temporary hack so that windows don't get mouse messages if the cursor
is not over them - this should be better integrated with the rest of the
code (later, when we don't rely on RootLayer for everything anymore).


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

Quick fix for our broken locking model:
The mouse filter needs to lock RootLayer, but the event dispatcher lock is held
during that time, too, so that the focus cannot change in the mean time.
On the other side, ServerWindow needs to lock the event dispatcher when adding
or removing a listener, or for AS_GET_MOUSE - but since it always helds the
root layer lock during message dispatching this easily resulted in a deadlock.


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

Minor cleanup: removed unused stuff.


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

In anticipation of Stippi's new clipping code, I refactored the EventDispatcher
a bit:
* listeners are now managed per target (ie. per messenger) (by the Target class)
* therefore, the fFocusTokens/fLastFocusTokens lists are no longer needed; every
Target knows its listeners already.
* this also fixes the obvious bug that the focus window's views would get both
keyboard and pointer events, no matter which of them they originally wanted.
* renamed event_target to event_listener (there was actually a mix up in naming
before - to the outside it was "listener", and internally, "target" was used)
* WinBorder::MouseMoved()/MouseUp() now also add the view token to the message;
the messages weren't received by the target before (unless the view used
tracking via BView::SetMouseEventMask()...) - maybe the client should only
update fLastMouseMoved on B_MOUSE_MOVED events, and direct B_MOUSE_UP/DOWN
(plus wheel changes) always to fLastMouseMoved...
* some cleanup.


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

* removed adding "be:transit" stuff in the EventDispatcher - this is now only done
client side (or will be, with the next commit).
* added GetMouse() functionality.


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

* changed the way a message is forwarded to the focus view (instead of adding
a suspend focus field to the message, there is now a "feed focus" field in
case the message should be forwarded).
* added a comment to the BPoint version of _FindView() (since it's broken)
* _DistributeMessage() is now called after _DetermineTarget() - so that it
can prevent sending the message twice to the focus view.
* removed BWindow::DoUpdate() as it's no longer used.


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

* now all event targets of the focus window get into the focus list - that
way, we always send only one message per event, no matter how many targets
there are in the window (the focus event list was not always maintained
correctly before, too).
* the current mouse filter eats all B_MOUSE_UP events, and therefore, the
temporary event targets were never removed.
* changed the way BWindow::_DistributeMessage() recognizes if it should forward
the event - not yet final, though.
* naming is now more consistent (events -> event_mask).
* some minor cleanup.


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

Some minor fixes.


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

* EventDispatcher::AddListener() now honors the BView semantics and will only
update the options in case the specified eventMask was zero.
* Added missing EventDispatcher::RemoveTemporaryTarget().
* Layers setting their event mask are now added to the EventDispatcher.
* The RootLayer is no longer contacted for SetEventMask() - it still handles
SetMouseEventMask(), tough - as a result, SetEventMask() temporarily doesn't
work anymore.
* Added Layer::ViewToken() method.


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

* Moved workspace keyboard switch and dump screen capability from RootLayer
into a Desktop keyboard filter.
* Removed keyboard handling code from RootLayer and Layer.
* Renamed Desktop::ActiveRootLayer() to RootLayer() as there is only one
root layer per desktop.


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

* the keyboard events are now using the new EventDispatcher, B_KEYBOARD_EVENTS don't
work yet, though, as the dispatcher is not yet notified about those.
* no more mouse cursor jumping - the cursor will now start in the middle of the screen;
this should be part of the initial input_server handshake, though.
* ServerWindow can now return a BMessenger of its client window.


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

* the new input event dispatcher is now actually used, although it doesn't
distribute any messages to the clients yet.
* removed the working thread from RootLayer - for now, its event handlers are
still called using input filters in the new event dispatcher, though (to
get things started).
* ServerApp is now using a BMessenger to identify its client, and no longer
stores the port/token separately.
* the input_server handshake is a bit simpler now, as it can now just reply
to the app_server message, removed unused code from ServerProtocol.h
* calmed down the MultiLocker (it always printed thread statistics on startup,
because it's compiled in debug mode).
* removed the cursor thread stuff from AppServer.cpp
* the new event dispatcher now uses a cursor thread when supported (only in
native mode, not in the test environment), although it improves cursor
movement under Qemu, the effect is not as good as expected - this might
need some more investigations (might just be a thread priority problem).


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

Implemented support for Set[Mouse]EventMask() functionality - still untested, though.
Also supports the B_SUSPEND_VIEW_FOCUS options, B_NO_POINTER_HISTORY is not yet there,
and B_LOCK_WINDOW_FOCUS has to be implemented somewhere else (its outside of the
scope of this class).


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

* Fixed the most obvious copy&paste bugs.
* no longer allocates focus messengers on the heap but keeps them around.


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

The basics of the new event handling - not yet connected to anything, and therefore
neither used nor tested. It's not even complete yet (support for Set[Mouse]EventMask()
is missing), but it will get there :)


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