It unloads any media_format mappings when an add-on
becomes unavailable, and consequently reloads the
supported formats and similar when the same add-on
becomes available again. Previously it would only
load previously unkown add-ons by node-monitor
events (unkown name). What also works is that user
add-ons shadow/hide system add-ons when installed,
and the system add-on will become effective immediately
when removing the user add-on again. One thing to
note is that certain IDs will not stay consistent.
I am not aware of an application for which it could
be a problem, most should rememeber codecs by name.
In any case, I only tested add-on events a lot, and
not so much the effects of unstable media_file_format
IDs, so it's possible there are regressions, though
only when installing new versions of add-ons, which
previously mostly required a media_server restart
anyway.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38282 a95241bf-73f2-0310-859d-f6bbb57e9c96
everything more readible.
* Once I understood better how everthing is supposed
to work, I've fixed some bugs.
* The most important problem was that AddDirectory()
placed the wrong entry (resolved symlinks) into the
entry list it keeps for each directory. This resulted
in the mechanisms not working at all when an add-on
was a symlink.
* There was a hidden TODO, which would mean that moving
an add-on from one watched directory into another,
like from home/config/add-ons/... into common/add-ons/...
would drop the client application (media_server,
input_server, ...) into the debugger.
* The fFormerEntries list did not seem to serve any
purpose. Basically it would not disable add-ons
removed from a watched directory unless it changed
it's name at the same time. I've removed it completely,
since it didn't seem to be an optimization
(entry cache) either.
* Each actual add-on file is now node-monitored for
stat changes. So if you have a link in the add-on
folder, and the linked to add-on changes, it triggers
a reload of the add-on now. This will make it much
more pleasant to develop add-ons and have them affective
immediately.
I tested with a fresh image, but there are no immediate
regressions I am aware of. I could imagine that messing
with certain add-ons can have a bad effect now, like
removing the keyboard input_server add-on may trigger the
keyboard to stop working immediately without an input_server
restart, but Tracker should warn before it happens.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38280 a95241bf-73f2-0310-859d-f6bbb57e9c96
problem (since + binds stronger than >>)
Stephan: please review, esp since I don't know how to test this!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38279 a95241bf-73f2-0310-859d-f6bbb57e9c96
Stephan: please yell if you dislike the formatting of the large expressions now
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38278 a95241bf-73f2-0310-859d-f6bbb57e9c96
* no need to overload ScrollTo() with a non-related method - renamed local
ScrollTo() to ScrollToBlock()
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38268 a95241bf-73f2-0310-859d-f6bbb57e9c96
* make BDADDR_* macros refer to value types instead of addresses
* adjust all interfaces using bdaddr_t* to use (mostly const) refs instead,
which IMHO makes the interface & code clearer
* that got rid of a couple of const incorrectness casts
* some cleanup along the way
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38265 a95241bf-73f2-0310-859d-f6bbb57e9c96
Fix some more #pragma export warnings treated as errors on ppc.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38258 a95241bf-73f2-0310-859d-f6bbb57e9c96
PowerPC was special-cased to not include posix/regex.h but a local copy.
This caused a warning for undefining __STDC__ and a pointer signedness error.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38257 a95241bf-73f2-0310-859d-f6bbb57e9c96
#pragma export on
and
#pragma export off
result in warnings on ppc, which are now treated as errors.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38256 a95241bf-73f2-0310-859d-f6bbb57e9c96
As an interim solution for fixing the build,
download an ICU package from Haiku Ports.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38254 a95241bf-73f2-0310-859d-f6bbb57e9c96
Coverity was complaining because we did a half-ass check against NULL only to
pass that NULL pointer on to a function that deref'd it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38248 a95241bf-73f2-0310-859d-f6bbb57e9c96
* BBitmap could leak fWindow in operator=()
* two copy constructors didn't initialize the members properly, which
could cause crashes in _CleanUp()
* minor cleanup
Actually found this while staring at CID 254-257, which were false alarm, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38246 a95241bf-73f2-0310-859d-f6bbb57e9c96
really should get rid of the current mail kit some day.
* Fixed another memory leak I stumpled upon.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38245 a95241bf-73f2-0310-859d-f6bbb57e9c96
* when I changed InsertText() to adjust the caret position recently, I
forgot to drop that adjustment from all callers - _HandleInputMethodChanged()
was still doing it, leading to out of bounds access
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38243 a95241bf-73f2-0310-859d-f6bbb57e9c96
which has rather desastrous consequences - thanks to Stippi for the heads
up :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38242 a95241bf-73f2-0310-859d-f6bbb57e9c96
and there's even a comment that says we are leaking memory.
Coverity doesn't complain, though, so I wonder if I'm wrong. Please someone
have a second look.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38241 a95241bf-73f2-0310-859d-f6bbb57e9c96
Also small style fixes.
Added a TODO about unloading the addon.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38240 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Automatic whitespace cleanup.
* This also fixes the build; I wanted to commit this earlier.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38237 a95241bf-73f2-0310-859d-f6bbb57e9c96
API will call AddDirectory() in whatever random thread, not in the AddOnMonitor
looper thread however. The looper thread will try to process pending node
monitor events every second which may happen concurrently to the thread
adding to the fPendingEntries list for initial processing of new directories.
Could have affected any of the AddOnMonitor clients, like media_server and
input_server.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38235 a95241bf-73f2-0310-859d-f6bbb57e9c96
