hide it (because of different argument types, BRect vs. IntRect).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24302 a95241bf-73f2-0310-859d-f6bbb57e9c96
more than one of them at the time.
* Changed ViewLayer::FindView() to FindViews() that collects all views
with the given flag set, not just the first one.
* Made ViewLayer::AttachedToWindow() and DetachFromWindow() virtual,
WorkspacesLayer now overloads them to register itself with the window and
the desktop.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24300 a95241bf-73f2-0310-859d-f6bbb57e9c96
works fine without those, the keymap file will be generated.
* Supplied the removed lines as example in UserBuildConfig.sample for how
to supply these settings during image generation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24298 a95241bf-73f2-0310-859d-f6bbb57e9c96
Tracked down the root cause of the issue worked around in r24228.
The behavior that was occurring in this case was as follows:
Vision created a BInvoker off the heap, containing a BMessage likewise
off the heap. It then called BAlert::Go with this invoker. When any of
the buttons in the BAlert were pushed, _SendMessage would enqueue the
message into the target looper (in this case, Vision's window) and wake
it up with write_port_etc. However, in some cases this would result in
a reschedule such that Vision's looper executed before _SendMessage() was
able to complete all its processing. Upon receiving this message, Vision
destroyed the BInvoker in question, which in turn deleted its owned
BMessage -- which was the message that was still in the middle of _SendMessage()!.
Consequently it would crash a few lines later when it hit IsSourceWaiting() and
tried to check flags off its header off the already destroyed this. To fix this,
we now do the AddMessage/write_port_etc last before returning. Also removed the
sanity checks added in r24228 so we don't mask other problems of similar nature.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24297 a95241bf-73f2-0310-859d-f6bbb57e9c96
still. This way keyboard menu navigation works much better.
Unfortunately I can't apply the same trick for BMenu since it opens the
submenu with a delay, and that won't work anymore.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24296 a95241bf-73f2-0310-859d-f6bbb57e9c96
would have returned the second item in place of the first. Also return
NULL, not false, when there are no "next items".
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24294 a95241bf-73f2-0310-859d-f6bbb57e9c96
MakeFocus(false) can not be trusted, since it is virtual and might not call
the BView version.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24293 a95241bf-73f2-0310-859d-f6bbb57e9c96
registrar.
* Added the constant names to the force parameter (as comments for now).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24292 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added VLC optional package. (I repackaged the latest BeBits version and
put it on www.yellowbites.com, which is a) much faster to download at
least from Germany and b) has the Haiku vector icon.)
* Exchanged the Pe package for a recent SVN build which also has the Haiku
vector icon.
Going to test all these changes on a Linux host soon, seems to work fine
on a BeOS host.
NOTE: The WonderBrush package has gotten a silent update, it includes the
icon in the resources now too, like the other packages with Haiku icon and
also fixes a problem in the Navigation view.
NOTE 2: The build system does not download packages again if generated/download
already contains a .zip with the name of the optional package. So you need
to delete those to get the recently updated Vision, Pe and WonderBrush
packages.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24291 a95241bf-73f2-0310-859d-f6bbb57e9c96
B_ASYNCHRONOUS_CONTROLS flag. If anyone does encounter an app that
breaks because of this, please let me know, but a few tests with various
apps seem to show no issues.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24290 a95241bf-73f2-0310-859d-f6bbb57e9c96
built directly out of Haiku's build sys, which is to say against haiku's
headers, etc. directly, and b) includes Stephan's HVIF icon (thanks!).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24289 a95241bf-73f2-0310-859d-f6bbb57e9c96
under vesa and supported mode). Changed message of the vesa warning
alert. TODO: additional warning text (see discussion)
* apply now stays deactivated if you only change the workspace count as
it is applied instantly already.
* disabled current workspace menu item for now since it is not
implemented. see ticket #696
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24280 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Implemented missing functionality
- Added debug.h from other media addons for nicer debug.
- Instead of using the MediaNode inside the View, the node should control the view and the window in the case it is instantiated from an addon.
- During the connection process the VideoNode tried to allocate overlay buffers. This can fail for multiple reasons like there is already someone using overlay or it is not supported at all due to driver limitations. In that case try to get non overlay buffers. If this fails, the Connect() can still return an error.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24273 a95241bf-73f2-0310-859d-f6bbb57e9c96
next window to get focus after the current one is gone. This fixes the
strange behaviour when using right-click to send the current window to
the back.
* When FFM is active, Desktop::SendWindowBehind() will now choose the
new focus window to be the one under the mouse, overriding the focus
list.
* Desktop::SendWindowBehind() will now also call _SendFakeMouseMoved()
if necessary.
* Removed Desktop::fFocusFollowsMouse; it was not used or
maintained anywhere.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24269 a95241bf-73f2-0310-859d-f6bbb57e9c96
help. However it appears I might have fixed the GL apps drawing over
other windows. Cannot reproduce this problem anymore, but it may be
that this bug doesn't show on my new setup (32bit double buffered VESA).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24267 a95241bf-73f2-0310-859d-f6bbb57e9c96
Either app_server doesn't start it, or it exits right away...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24262 a95241bf-73f2-0310-859d-f6bbb57e9c96
* when a path is given that isn't on devfs, use its device instead.
Allows doing eject /foo without greppin the output of /bin/df.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24259 a95241bf-73f2-0310-859d-f6bbb57e9c96
errors. This object should never be deleted directly as it's ref counted,
only when its last ref is Release()'d.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24258 a95241bf-73f2-0310-859d-f6bbb57e9c96
disabled by default. Appears to work correctly though, so
enabling it since it produces far less flicker here.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24255 a95241bf-73f2-0310-859d-f6bbb57e9c96
Why not just #include <thefile> instead of using prefixes ?? :p
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24249 a95241bf-73f2-0310-859d-f6bbb57e9c96
/boot/home/config/settings.
* The Bootscript will check for the existance of this file and updates the
mime database with all the applications and preflets that come with the
install. Then it removes the indicator file.
This fixes the problem that all the apps are not known to the system until
you run them once. Ie "Open With..." and such stuff works out of the box.
Feel free to find a more elegant way, I just found this simple and effective.
:-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24247 a95241bf-73f2-0310-859d-f6bbb57e9c96
we now split more than 2GB MTRR slot, we might improve this and split more and more.
this could fix the bug #1711.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24244 a95241bf-73f2-0310-859d-f6bbb57e9c96
