include the OSS media add-on (node), since Haiku comes with it's own
version. Therefor you can now add the OpenSound optional package and
it will just work out of the box, unless you have native drivers that
fight over the hardware with OSS. It is no longer necessary to delete
the opensound.media_addon from the home/config/add-ons/media folder.
If you don't build from scratch, make sure you delete
generated/download/OpenSound.zip or the change won't take effect.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26064 a95241bf-73f2-0310-859d-f6bbb57e9c96
perfect in Haiku for me (HD Audio), while it adds a very noticable latency.
On C-Media, the difference between "policy 4" and "policy 5" is 2048 versus
32768 bytes, which is 16 times the latency. I added a note on why the same
policy on Haiku might give me troubles (C-Media versus HD Audio means
16 bits/sample versus 32 bits/sample) and if OSS does not double the buffer
size then I can see where the trouble is comming from. I should probably
figure out a more fine grained way of influencing the driver buffer size.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26062 a95241bf-73f2-0310-859d-f6bbb57e9c96
C-Media based sound card). In Haiku, I could test with HD Audio, and playback
has clicks. It doesn't seem to have to do with the "drift", which is now
correctly published, I am not sure what exactly is causing it, I would like to
test on different hardware yet.
* I have modified the buffering policy (4 will give about 2048 bytes internal
OSS buffer), which decreases the latency of the node to an acceptable value.
* I completely replaced the timesource publishing algo to be more reliable.
* Removed now unnecessary methods from OpenSoundDeviceEngine.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26059 a95241bf-73f2-0310-859d-f6bbb57e9c96
the scrollbar.
* Added notes about BeOS behavior to SetTarget(const char*).
* Reuse SetTarget(NULL) in the destructor.
* Initialize fTarget and fTargetName in the archive constructor.
* Added TODO about possibly restoring the target in the archive constructor.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26057 a95241bf-73f2-0310-859d-f6bbb57e9c96
can edit the settings file. The default are 10000 lines BTW.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26045 a95241bf-73f2-0310-859d-f6bbb57e9c96
selection which we update whenever the first mouse button is released.
This also enables copy'n'paste between Terminals.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26044 a95241bf-73f2-0310-859d-f6bbb57e9c96
updating the scroll range (ie: in ContainerWindow.cpp). IMO, the programatic ScrollBy method shouldn't depend on the
ScrollBars ranges or state. The original fix in r21336 was apparently hiding other BScrollBar or BView bugs that have been
fixed in the mean time.
The content was offseted when going back to list mode after moving icons on the left/up in icon mode. This fixes Tracker bug
#2312.
- Revert and fix changes to ContainerWindow.cpp in r18481 (cvs 1.37). The condition was broken, but it wouldn't ScrollBy()
anyway due to the previous problem. Fixing BView made the content autoscroll even if the lefttop corner of the extent was
already visible.
- Probably unrelated, fix changes to ContainerWindow.cpp in r18993 (cvs 1.38). PoseView()->Bounds().left/top < 0 is expected,
if for example in icon mode you move an icon close or crossing the left side of the window and then scroll left to adjust.
This fix ResizeToFit that wouldn't scroll the view correctly in some cases.
So we had a Tracker Bug uncovering a BView fix that was hiding another Tracker bug, everything is fixed hopefully, phew :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26043 a95241bf-73f2-0310-859d-f6bbb57e9c96
- we'll just use decimal chip number (68030, ...) to identify cpu, fpu, and mmu for simplicity.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26041 a95241bf-73f2-0310-859d-f6bbb57e9c96
the left/right cursor keys.
* Normalized the Ctrl-<cursor> escape sequences. Makes word navigation
in vim work.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26038 a95241bf-73f2-0310-859d-f6bbb57e9c96
worker thread. That sounds somehow reasonable, but has the problem that
signals to the process hit a thread that doesn't know how to handle
them. Fortunately the author already prepared the code to switch the
thread tasks. In the Terminal vim does now correctly react on window
resizes. Probably also fixes#2393.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26034 a95241bf-73f2-0310-859d-f6bbb57e9c96
wrapped to the next line and a subsequent LF would advance another line.
We behave like xterm now, i.e. visually the cursor stays on the same
line (on the last character), but the next character will be wrapped to
the next line.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26033 a95241bf-73f2-0310-859d-f6bbb57e9c96
buffer). These are the sequences our /etc/termcap uses (local less and
vim use the alternative screen buffer now). The ones already implemented
are used e.g. by the termcap of my Linux installation. A bit weird all
those different termcap files, some even with the same version
number.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26031 a95241bf-73f2-0310-859d-f6bbb57e9c96
less.
* Added /etc/vim/vimrc. Besides fixing key mappings it also disables
compatibility mode and adjusts some settings to make using vi a more
pleasant experience.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26028 a95241bf-73f2-0310-859d-f6bbb57e9c96
2KB. That's the currently recommended size of the buffer passed to
tgetent(). Our xterm entry is bigger, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26023 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Set TERM to "xterm".
* Removed unnecessary {Begin,End}ViewTransaction() in TermView::Draw().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26022 a95241bf-73f2-0310-859d-f6bbb57e9c96
been requested. The first call to a BView::Invalidate() will flush the link
so that app_server is notified as soon as possible. It makes no sense for
further calls to Invalidate() to flush also, since Flush() is not cheap. This
trick makes Invalidate() about 3.2 times faster, making it a cheaper operation.
I could not see any negative effects, I tested with apps that invalidate
multiple different parts inside a window in reaction to something. Thanks go to
Ingo who had the idea.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26020 a95241bf-73f2-0310-859d-f6bbb57e9c96
invoking it this way works at all; this avoids problems with readlink
programs that don't support the option.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26018 a95241bf-73f2-0310-859d-f6bbb57e9c96
