* Move most of MIME database support out of libbe and into registrar
* Use the (async) MessageDeliverer instead of a synchronous SendMessage in _SendMonitorUpdate
This fixes a deadlock when the message port of a MIME database watching
application gets full as documented in bug #1311.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23423 a95241bf-73f2-0310-859d-f6bbb57e9c96
B_MOUSE_MOVED message does not already contain the same buttons as a
following B_MOUSE_DOWN message... fixes mouse clicks being ignored
when you are moving the mouse at the same time when clicking
(using Haiku's mouse input_server device on BeOS or ZETA)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23421 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Beginnings of devfs interaction to properly publish/unpublish under Haiku
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23412 a95241bf-73f2-0310-859d-f6bbb57e9c96
* handle one more allocation failure in device_added
* improved style consistency in a few places
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23409 a95241bf-73f2-0310-859d-f6bbb57e9c96
Currently it's optional, you must define HAIKU_INCLUDE_3RDPARTY in [User]BuildConfig.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23408 a95241bf-73f2-0310-859d-f6bbb57e9c96
Missing ThemesPopupText stuff I used from zeta, will write a better, BAlert based one anyway.
Still needs a container app an Haiku support.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23406 a95241bf-73f2-0310-859d-f6bbb57e9c96
and you never pressed any key on the usb keyboard, you could suddenly
be flooded with a random key...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23403 a95241bf-73f2-0310-859d-f6bbb57e9c96
should fix detection of Audigy2 Value (it was trying to check the revision id instead of the device id)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23399 a95241bf-73f2-0310-859d-f6bbb57e9c96
* If two intersecting windows didn't change their position but their
order, the dirty region wouldn't contain the region that would need
to be updated because of that order change. This fixes bug #827.
* When a hidden window was on the new workspace (but not on the old one),
its region would be included in the dirty region, but shouldn't have
been. This caused the app_server to update a larger region than
necessary.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23398 a95241bf-73f2-0310-859d-f6bbb57e9c96
which already existed in the region backend ported from XOrg
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23394 a95241bf-73f2-0310-859d-f6bbb57e9c96
* save the fd so we can use it :)
* open the pty read-write else it won't work...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23393 a95241bf-73f2-0310-859d-f6bbb57e9c96
Actually getlogin didn't belong to usergroup.c in the first place anyway.
And definitely not to the kernel.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23391 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Some restructuring and cleanup
This keeps the input_server from polling a removed device continuously.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23388 a95241bf-73f2-0310-859d-f6bbb57e9c96
That way menubars are navigable via keyboard. There are still glitches,
but menu keyboard navigation works now.
Minor optimization: cache the value of CountItems() instead of calling
it multiple times.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23387 a95241bf-73f2-0310-859d-f6bbb57e9c96
Worked quite well in latest zeta, so it's already tested :)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23385 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Actually enable the periodic schedule so that any interrupts work over EHCI
For those who wait for OHCI: You can now attach your USB 1.1 mouse or keyboard
to a USB 2.0 hub and it should work.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23382 a95241bf-73f2-0310-859d-f6bbb57e9c96
couldn't be read from a file, Tracker would try 10 times with a 10 ms
timeout - but only if the creation time equals the modification time!
That was obviously supposed to be a check if the file was recent...
Now that computers are faster (even when running Haiku), it may
actually take less than one second to copy a file, so most files on
the Haiku image satisfied this thoughtful and future-proof check.
(And no, even the original BFS does not automatically increase the
modified time on close.)
* Now, mmlr came up with a better check: we just check the file's
creation time against the current time to see if it's a recent file.
That should work a bit more reliable :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23376 a95241bf-73f2-0310-859d-f6bbb57e9c96
