ignored even if it was not visible on the previous workspace (only normal windows
can be moved this way).
This fixes bug #765.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18585 a95241bf-73f2-0310-859d-f6bbb57e9c96
have already been released again, the temporary listener was still added.
This fixes bug #727.
* No longer removes temporary listeners if there are mouse buttons left pressed; ie.
if you press two buttons at once, the listeners are now only removed after you've
released them both. This is not only more logical, it's also how BeOS behaves :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18483 a95241bf-73f2-0310-859d-f6bbb57e9c96
this fixes bug #709, but it's not quite good in my opinion (Stephan, please could you review?)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18050 a95241bf-73f2-0310-859d-f6bbb57e9c96
i* thus the NOTE in Painter isn't valid anymore
* in Painter::_DrawBimap() moved scale computation after potential changes to BRects
* fix typo : right => bottom. This caused a bug in Haiku Mouse preferences app
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18017 a95241bf-73f2-0310-859d-f6bbb57e9c96
* ServerApp was accessing ServerWindow::Window() (while having the app window
lock held), but in fact, there was no guarantee it already existed, or was
added to the Desktop.
* Therefore, the Window() semantics have changed to only return a window in
case the window exists *and* has been added to the desktop (the latter
constraint might be lifted again, though). Therefore, it doesn't work
for offscreen windows, and should not be used within ServerWindow code
anymore.
* This fixes bug #686 and maybe others as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17878 a95241bf-73f2-0310-859d-f6bbb57e9c96
fix binary compatibility for several classes (I missed this before)
the soft synth loads by default /boot/beos/etc/synth/big_synth.sy (which I locally linked to a General Midi sf2 bank
tested with MidiSynth 1.6 on Haiku
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17864 a95241bf-73f2-0310-859d-f6bbb57e9c96
* removed the useless parts of AGG (which are only needed for the
interactive examples)
* make sure to jam -a libagg.a to solve any linking issues
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17838 a95241bf-73f2-0310-859d-f6bbb57e9c96
when enabled, and B_NORMAL_WINDOW_FEEL when disabled. IOW when enabled, no
other windows can interfere.
* Therefore, it's no longer necessary to have the screen_blanker window
use kWindowScreenFeel - it will set its window to full screen as long
as the blanker runs.
* Added a AS_APP_CRASHED notification in the app_server that will remove
all kWindowScreenFeels from the windows of the crashed app.
* This is now used by the debugger to ensure that the debugger alert will
be visible.
* Factored out a DesktopLink class out of the BRoster::_ActivateApp()
method. This class is now also used in the new BRoster::_ApplicationCrashed()
method as used in the debug_server (via BRoster::Private).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17785 a95241bf-73f2-0310-859d-f6bbb57e9c96
representing the interface for, well, MIME sniffer add-ons.
* Implemented the respective add-on manager and make use of it in
the MIME database code. Unfortunately the MIME DB code completely
lives in libbe.so and hence I had to put my code there too.
IMHO we should (one day) remove the direct (read-only) MIME DB
access from libbe and move everything into the registrar.
Currently the add-on manager supports built-in add-ons only; it
doesn't really load anything from disk ATM.
* Added a built-in text sniffer add-on to the registrar. It's based
upon the BSD file tool code.
This closes bug #250 (plain text files are identified as such, now).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17784 a95241bf-73f2-0310-859d-f6bbb57e9c96
Apparently, there was an integer overflow of some kind with BePYRO, but this version
if safe as well, and should look much better.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17716 a95241bf-73f2-0310-859d-f6bbb57e9c96
generated file from SystemKeymap.cpp to SystemKeymap.h.
* The keymap was even compiled into the input_server twice, as it was also
listed as source file.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17711 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Improved header output, it now looks a lot nicer.
* Fixed style issues of that header, too: replaced "s" prefix with the
correct "k" prefix.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17690 a95241bf-73f2-0310-859d-f6bbb57e9c96
smaller than the tab size. This fixes bug #642.
* There are remaining issues while resizing the window, though.
* Fixed warning.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17637 a95241bf-73f2-0310-859d-f6bbb57e9c96
* the tab keeps the relative position when the
window is resized (could be done nicer though,
now it uses two members)
* tab offset is no longer reset in _DoLayout(), ie
when any aspect of the decorator changes...
one issue that is left is sliding the vertical tab
of kLeftTitledWindowLook windows, but there might
be more... like when the look changes or stuff like
that
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17600 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added a few very small changes to make the tab sliding work perfectly
* added a comment on the purpose of WindowLayer::fLastMousePosition and
how it is supposed to be used to have the mouse cursor stick to what
is being dragged
* TODO: the tab offset doesn't necessarily have to be on [0..1], as long
as we update it during window resizing to keep the relative position
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17577 a95241bf-73f2-0310-859d-f6bbb57e9c96
Needs some cleanup, passed values should be inside [0:1].
Need to make sure changing the title doesn't reset the tab to left.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17571 a95241bf-73f2-0310-859d-f6bbb57e9c96
* fixed SetViewColor() - I have no idea why it compiled before
* changed SetHidden() to make less of a difference between
the top view and other views, the clipping is now always
rebuilt
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17527 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Mesa doesn't compile yet, as some PPC specific stuff seems to be
missing, Philippe?
* Cortex and some other stuff has been marked x86-only, although
it's more of a "GCC 2.95.3"-only.
* I'm not sure if it's a bug in GCC 4, or if that's what the C
standard demands, but sizeof(some_type::some_field) is not
valid anymore :-/
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17515 a95241bf-73f2-0310-859d-f6bbb57e9c96
it is added our removed to another view, this is
taken care of in View.cpp until we find something
better
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17511 a95241bf-73f2-0310-859d-f6bbb57e9c96
ViewLayer::SetViewBitmap() did not show the overlay, only updated it.
* Simplified overlay handling a bit, removed Overlay::Show(), and IsVisible(),
replaced Update() by Configure().
* Made similar changes in the HWInterface as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17504 a95241bf-73f2-0310-859d-f6bbb57e9c96
to bordered window (ie. VLC when switching back from full screen mode).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17503 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Overlay::SetView() no longer calls HWInterace::UpdateOverlay() if it's currently
hidden.
* ViewLayer::UpdateVisibleDeep() now calls _UpdateOverlayView() before showing
the overlay.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17489 a95241bf-73f2-0310-859d-f6bbb57e9c96
the overlay buffer changed. Found by Marcus.
As a result, the overlay window looks much smoother when moving it around (and it
even starts to move when you don't change the overlay bitmap at all...).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17484 a95241bf-73f2-0310-859d-f6bbb57e9c96
turned off - note also, that only the 32 bit mode is currently hardware accelerated!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17421 a95241bf-73f2-0310-859d-f6bbb57e9c96
in that we try really hard to let it succeed. If setting the desired mode failed,
we now try almost anything to get a working mode.
Since the kernel also knows the VESA mode, maybe we should better ask that one for
the current mode, as most drivers probably haven't got B_GET_DISPLAY_MODE implemented
in the we're using it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17355 a95241bf-73f2-0310-859d-f6bbb57e9c96
safe in the sense that it no longer clobbers fDisplayMode in case B_GET_DISPLAY_MODE
fails. This fixes bug #564 resp. #566.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17353 a95241bf-73f2-0310-859d-f6bbb57e9c96
Made sure that fDisplayMode is not modified if fAccSetDisplayMode failes,
as on my system fAccGetDisplayMode did return values that would crash
because of a virtual_width beeing 0.
Generally, this whole class is pretty broken, as the functions modify *some*
class member variables before eventually failing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17352 a95241bf-73f2-0310-859d-f6bbb57e9c96
This fixes bug #558; Cortex floating windows have the B_AVOID_FOCUS flag set.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17341 a95241bf-73f2-0310-859d-f6bbb57e9c96
using the "normal" B_OP_COPY for lines and such that works more
like B_OP_OVER actually (for example, the slider in VLC will look
much better, but also other stuff)
* combined Stroke and FillEllipse() into DrawEllipse() and fixed
some longstanding issues, ellipses are now correctly placed
(aligned) and of the correct size
* removed locking in the DrawingEngine drawing functions, since
you need to have the DrawingEngine locked anyways for the
clipping to stay what it is (and that's already the case elsewhere
in the code)
* simplified ConstrainClippingRegion, the NULL version was never
useful and also locking is removed, see above
summary: slight speed improvements, cleanup and bugfixes...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17329 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The overlay options as part of BView::SetViewOverlay() are now passed over
to the graphics driver - looks like the color key stuff cannot be turned
off (at least not via the Be API).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17323 a95241bf-73f2-0310-859d-f6bbb57e9c96
B_GET_ACCELERANT_CLONE_INFO (as that's what the caller actually wants).
Unfortunately, it's currently hard-coded to path names, that is, if there
is a driver out there that doesn't follow this quasi standard, it will
break this mechanism.
We should either change the driver interface to explicetly use path
names, or change the mechanism we're using (in BWindowScreen upwards to
the app_server) to the one as thought by Be.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17299 a95241bf-73f2-0310-859d-f6bbb57e9c96
immediately. Only if the mouse is released within a certain
time window (half a sec) and if it was not dragged (as on R5).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17285 a95241bf-73f2-0310-859d-f6bbb57e9c96
* If the window is on another workspace, the workspace will be
activated or the window will come to the current workspace
or nothing will happen depending on the windows flags. Tested
with WonderBrush, but I just now realise that it will also
fix activating a window in the Deskbar, which is on a different
workspace.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17284 a95241bf-73f2-0310-859d-f6bbb57e9c96
children of the view in question into account. Neither
are they included in the region being copied, nor are
views overdrawn by the copied contents. Also, the update
region is calculated from the region having been copied,
so that holes from children views are invalidated
correctly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17268 a95241bf-73f2-0310-859d-f6bbb57e9c96
will not try to retrieve the retrace semaphore again and again
if the graphics cards doesn't support it for some reason
* disabled BScreen::WaitForRetarce() for now, since it will just
hang on ATI Radeon at least
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17266 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The Decorator are temporarily using ui_color() - this needs to be changed
to use the DesktopSettings (when the decorator stuff gets refactored); right
now, the colors are fixed.
* Added B_WINDOW_TEXT_COLOR, B_WINDOW_INACTIVE_TAB_COLOR, and
B_WINDOW_INACTIVE_TEXT_COLOR to the UI colors, B_WINDOW_TAB_COLOR is no
longer deprecated. Note, however, that not every decorator may use these
colors.
* Removed unused and wrong (ie. hard-coded paths) stuff from ServerConfig.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17236 a95241bf-73f2-0310-859d-f6bbb57e9c96
read-only area shared between the Desktop and all applications.
* Right now, this area only contains the desktop colors, ie. B_PANEL_BACKGROUND_COLOR
etc.; ui_color() no longer needs to ask the server for these colors.
* The ui_colors are now maintained by DesktopSettings, though ColorSet is still there.
* The default colors are now hardcoded once and for everyone in InterfaceDefs.h, ie.
the app_server uses them as well.
* Desktop::Init() can now also return an error (but that is not yet accounted for).
* Cleaned up InterfaceDefs.h.
* Fixed wrong include in moreUTF8.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17232 a95241bf-73f2-0310-859d-f6bbb57e9c96
AGGTextRenderer (when switching the DrawState for font stuff)
* removed unused stuff from the font signature generation that
is used to synchronize the font cache
* finally nailed that bug that made glyphs of the wrong size appear
within lines of text (the problem basically was that outside code
messed with the freetype library instance while our glyph cache
thought the library was last setup by itself)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17217 a95241bf-73f2-0310-859d-f6bbb57e9c96
that application quits; this just prevented us to see who the culprit is.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17213 a95241bf-73f2-0310-859d-f6bbb57e9c96
source file.
* An overlay is now also hidden in case its is removed from the window.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17209 a95241bf-73f2-0310-859d-f6bbb57e9c96
is currently broken, mode switches probably fail or result in sudden death
(didn't try) it's good enough for Radeon cards and VLC (might work with
others as well).
* Implemented follow modes for view bitmaps (wasn't taken into account at
all before).
* Switched to a darker overlay color for now (dunno what exactly makes a
good candidate there, but this one is good enough for now).
* Added TODO about a race condition in AS_LAYER_SET_VIEW_BITMAP.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17208 a95241bf-73f2-0310-859d-f6bbb57e9c96
is managed for those bitmaps:
- the shared client memory mechanism is used to allocate a small overlay_client_data
structure that contains the actual buffer and a semaphore that you have acquire in
order to access it.
- LockBits()/UnlockBits() now have a function: you need to call them before accessing
the overlay buffer, and you need to keep that lock until you're done with it.
* The overlay cookie is now an extra member of the ServerBitmap class.
* Removed fInitialized from ServerBitmap - IsValid() now just checks the buffer associated
with the bitmap.
* ViewLayer::Draw() will now handle overlay bitmaps specially and will draw the overlay
color instead of any contents (this is currently in ugly pink, but will become some
dark color later on).
* All what's missing from actually being able to use overlays now is to configure
them so that they are shown on screen. VLC will now show an empty pink window when
overlay video is enabled.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17201 a95241bf-73f2-0310-859d-f6bbb57e9c96
Since ServerWindow removed itself from its ServerApp in _PrepareQuit(), it could
happen quite easily that the ServerApp was deleted before the ServerWindow - and
since deleting WindowLayer as part of that referenced the ServerApp, it crashed.
Now, adding/removing is both done by the ServerWindow in Init() respectively
the destructor.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17198 a95241bf-73f2-0310-859d-f6bbb57e9c96
current display_mode doesn't matter, only the one where the overlay is shown later
does.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17197 a95241bf-73f2-0310-859d-f6bbb57e9c96
created as the graphics driver does.
* Also, B_BITMAP_RESERVE_OVERLAY_CHANNEL should now work as expected.
* We're no longer using the B_OVERLAY_COUNT hook anymore - that one really
looks like a misconception to me; I don't see how it can be useful.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17196 a95241bf-73f2-0310-859d-f6bbb57e9c96
via the graphics driver (but not yet shown on screen).
I probably got the meaning of the "overlay count" wrong - I guess that you
can allocate any number of overlay bitmaps, but can only see "overlay count"
on screen at a time (right now, I only allow to create "overlay count" bitmaps).
Stephan?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17193 a95241bf-73f2-0310-859d-f6bbb57e9c96
ViewLayer (for example, fixes NetPositive rendering
HTML with a background image)
* use BRegion pool everywhere in ViewLayer
* WindowLayer update sessions distinguish between
different reasons for the update: exposed and requested -
on expose updates, the view backgrounds are cleared
immidiately (as on R5), to keep the time previous stuff
keeps showing as short as possible, while on requested
updates, the background clearing is delayed until the
client draws something, to keep the time until the client
fills a view with content as small as possible to reduce
flickering (might need more work, could be buggy yet)
* HWInterface and DrawingEngine support delayed syncing to
the graphics hardware at least for FillRect/Region. The
speed up gained by this is minor though.
* HWInterface cursor rendering uses a bit of rounding to
avoid the slight transparent shadow around the cursor
(I don't know if it is fully correct though, at least the
shasow disappeared)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17172 a95241bf-73f2-0310-859d-f6bbb57e9c96
handled correctly.
* The path of moved styles is now updated (also when their parent directories
are moved).
* FontManager::_AddPath() can no longer crash when you leave the _newDirectory
parameter set to NULL.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17163 a95241bf-73f2-0310-859d-f6bbb57e9c96
that it didn't reset the EventDispatcher's focus target even though the object
underneath that same pointer had change, which caused the EventDispatcher to
drop the event.
This fixes bug #416, and should fix bug #409, too.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17141 a95241bf-73f2-0310-859d-f6bbb57e9c96
we simply remove color data before storing the workspace color
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17130 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added support for kWindowScreenFeel (those are now on top of everything,
even menus can't disturb them).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17124 a95241bf-73f2-0310-859d-f6bbb57e9c96
necessary.
* Also, newly exposed window areas are now refreshed when a change
of feel also changed the window order.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17122 a95241bf-73f2-0310-859d-f6bbb57e9c96
