--Cette ligne, et les suivantes ci-dessous, seront ignorées--
M src/preferences/appearance/Jamfile
M src/preferences/locale/Jamfile
M src/preferences/bluetooth/Jamfile
M src/preferences/cpufrequency/Jamfile
A data/catalogs/preferences/appearance/ua.catkeys
A data/catalogs/preferences/locale/ua.catkeys
M data/catalogs/preferences/locale/fr.catkeys
A data/catalogs/preferences/bluetooth/ua.catkeys
A data/catalogs/preferences/cpufrequency/ua.catkeys
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33686 a95241bf-73f2-0310-859d-f6bbb57e9c96
must have been my very own stupid idea. It's removed now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33685 a95241bf-73f2-0310-859d-f6bbb57e9c96
one or two remove messages were generated, as the query code produces
remove/create notifications on renames. Will check next if that also happens
on BeOS, as it doesn't really make much sense.
* This should fix the wrong mail count of the Deskbar replicant when you delete
mail.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33683 a95241bf-73f2-0310-859d-f6bbb57e9c96
wait status and therefore would return directly without actually blocking.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33681 a95241bf-73f2-0310-859d-f6bbb57e9c96
first I tried adding support for changing the format during running the node
connection, but later found out that this is not implemented in the system
mixer (it has this weird setting to allow input format changes, but if you
do this, the media_server will just crash, since the backend does not support
it yet). Also, the Media Kit documentation is extremely lacking in this regard.
I ended up re-establishing the node connection when the audio format is
supposed to change, just like it is already done for video. This means that
audio files now play with their native channel count and frame rate. But it
isn't so well tested yet, if 48 kHz for example introduce some clicks. The
channel count should not be a problem though, I've also tested that with some
movies and it works fine.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33678 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Unfortunately, there are remaining issues, but this is something I need to
discuss with Stippi: B_OP_COPY does not work as expected due to anti-aliasing
anymore, but there is no replacement one could possibly use to get the desired
effect without having to clear the background every time.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33676 a95241bf-73f2-0310-859d-f6bbb57e9c96
them more BeOS compatible while still keeping them somewhat flexible.
* _GrowStream() did actually not check if the double indirect region was already
filled up - this caused it to overwrite innocent memory. This fixes the bug
Rudolf showed me on this laptop that happened while copying a large file.
* Loosened file size restriction on a heavy fragmented disk: the indirect block
does not require a minimum array size anymore; before, you just couldn't let
a stream grow into the indirect range if it couldn't allocate NUM_ARRAY_BLOCKS
(4) blocks in a row. This considerably reduced the maximum file size in this
case.
* Removed no longer valid TODO.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33675 a95241bf-73f2-0310-859d-f6bbb57e9c96
to avoid recurring problems during migration of subversion checkouts
(restored binary files that were garbled by subversions during checkout)
* added appropriate svn:mime-type property for problematic (binary) files
* removed a single (mistyped) svn:mimetype property
* dropped svn:eol-style property for cleanup (they all contained 'native')
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33670 a95241bf-73f2-0310-859d-f6bbb57e9c96
a button or within the bar background within the timeout for the repeat-thread,
the thread would exit and there would be no repeating. I think there is still
a race condition somewhere since I managed to see it stall once again, probably
because it locks the looper twice in the loop...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33666 a95241bf-73f2-0310-859d-f6bbb57e9c96
manager and inform it that the video target, ie the view will be gone. The
Controller needs to use the SetTo() method in order to actually close down
the nodes properly in the destructor. Otherwise asynchronous threads will use
the BMediaFile and tracks after it has been deleted (until the NodeManager
destructor is executed).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33662 a95241bf-73f2-0310-859d-f6bbb57e9c96
Restore ignoring the BIOS provided width and height in case the timings
suggest a bigger dimension. Also re-add the corresponding comment. Should
fix#4810 and might affect #4807 as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33652 a95241bf-73f2-0310-859d-f6bbb57e9c96
turned on. That should explain Bruno's problems to get debug output from an
accelerant. Thanks to Michael for the hint!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33651 a95241bf-73f2-0310-859d-f6bbb57e9c96
high contention of the read lock (I experimented with the VM page mapping
lock)), it actually hurt the compile performance pretty obviously.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33647 a95241bf-73f2-0310-859d-f6bbb57e9c96
Quad are all reported as "Core 2", because the CPU count is already reported
separately.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33646 a95241bf-73f2-0310-859d-f6bbb57e9c96
makes the reader case a lot less expensive, and should relieve the thread
spinlock contention a bit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33643 a95241bf-73f2-0310-859d-f6bbb57e9c96
that. But I didn't think of any better solution either... Hopefully these are
all, but I will find out once I built a complete image.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33641 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Rewrote Devices application. -> Thanks a bunch!! Nice work!
* Put Devices onto the image.
Changes by myself:
* Merge some code from the old "preflet" which the new app still relied on.
* Fixed some coding style issues. I didn't review all of the code yet, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33640 a95241bf-73f2-0310-859d-f6bbb57e9c96
