* 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
window with a modal window. This also completes the fix for bug #439.
* Made some methods const that should have been const in the first place.
* Note, there is now a Desktop::_WindowHasModal() and WindowLayer::HasModal() -
the latter only works in the current workspace.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17121 a95241bf-73f2-0310-859d-f6bbb57e9c96
all windows, and after them floating all windows. This is different from BeOS
(where floating all windows are on top of modal all windows), but the way its
now seems to be more logical. This fixes bug #453 - there remains a problem
with open menus, though, but that has to be solved differently by introducing
a new feel.
* Also, modal app windows are now blocking floating app windows.
* Simplified WindowLayer::Frontmost() and Backmost() a bit, moving more stuff
into HasInSubset().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17119 a95241bf-73f2-0310-859d-f6bbb57e9c96
the same as the normal one (one less renderer to update
the color of)
* added a special B_OP_COPY implementation for text, which
is in fact what the implementation was until now, so
just like on R5, you have to specify the correct low color
or you will see artifacts for the anti-aliased pixels
* implemented B_OP_COPY just like B_OP_OVER (only it draws
the low color too like it should). So all apps that
used B_OP_COPY to draw anything can continue to do so
without having to worry about the low color, it will
be anti-aliased against the actual background instead of
the low color (which made especially no sense when drawing
with the low color). Although this change makes it a bit
slower to use B_OP_COPY, Haiku is now much more compatible.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17117 a95241bf-73f2-0310-859d-f6bbb57e9c96
though the first workspace color isn't kept between boots
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17116 a95241bf-73f2-0310-859d-f6bbb57e9c96
to cut down on BRegion related allocations, cannot really tell
if it speeds things up
* used the new BRegion pool in WindowLayer and ViewLayer whereever
a BRegion was used on the stack
* fixed the debugging stuff in MultiLocker - it will get you into
the debugger if you
- try to nest read locks
- try to write lock when your are a reader already
- don't match up nested locks when your a writer
-> but only if you #define DEBUG 1 in the .cpp, is off by default now
* went over WindowLayer, ServerWindow, Desktop and a few other places
and fixed the locking for use with the MultiLocker, the "a reader can
not become a writer" is especially tricky, feel free to review the
changes
* activated the MultiLocker, I tested this quite a bit, if there are
problems simply turn on DEBUG and you should drop into the debugger
right where the problem is... hope all is good
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17046 a95241bf-73f2-0310-859d-f6bbb57e9c96
That was probably what Joshua Austin meant on the mailing list, slightly misleading, though :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16998 a95241bf-73f2-0310-859d-f6bbb57e9c96
This lightens the problem in bug #98 a bit, but doesn't completely fix it; you
still don't see any items in that list on the switch, but they now appear again
when you scroll around there.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16997 a95241bf-73f2-0310-859d-f6bbb57e9c96
color differs. This fixes bug #373.
* The workspaces window is now invalidated when the workspace color is
changed, so that it shows the correct color then.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16979 a95241bf-73f2-0310-859d-f6bbb57e9c96
Note, this code needs to be reviewed for PPC; do they really work with little endian RGBA?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16960 a95241bf-73f2-0310-859d-f6bbb57e9c96
it and rebuilding it on the server side (that causes a huge speed
up for regions containing many rects)
* There is a method in ServerLink that could have been used, but I
actually needed to add the direct BRegion support to LinkReceiver
* added LinkReceiver as a friend to BRegion class
* ServerApp and ServerWindow keep the CursorManager locked after they
have retrieved a cursor until they have called Acquire() on the
cursor. (Axel: what good is using atomic* stuff in Acquire() and
Release() if we have to protect this by a lock anyways?)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16957 a95241bf-73f2-0310-859d-f6bbb57e9c96
it only cures the symptoms, ie. bug #194 remains valid (broken file types when built
from Linux).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16954 a95241bf-73f2-0310-859d-f6bbb57e9c96
a window is closed, too (only happened when a new window was shown
before). This is done via the new Desktop::_SendFakeMouseMoved()
method. This fixes bug #342.
* The MouseFilter now always sets Desktop::fWindowUnderMouse, so that
one can differentiate between no window under mouse, and decorator
under mouse.
* EventDispatcher::SendFakeMouseMoved() now expects a BMessenger instead
of an EventTarget as target - this guarantees that it can safely be
called with any window now (instead of only the current window).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16953 a95241bf-73f2-0310-859d-f6bbb57e9c96
* FillRect() doesn't use the HW acceleration if the rects
are too small (< 100 pixel area, about the sweet spot on
my box) -> the same change should be used for FillRegion as
well. (4x speed up of rendering large amounts of small rects)
* replaced dynamic allocation and freeing of blit_params and
fill_rect_params in the accalerant based HWInterfaces on the
heap with caching to make using the accelerated functions a
little less expensive
* fixed a bug in bypassing Painter for B_OP_OVER when the
pattern was B_SOLID_LOW (nothing should be rendered)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16841 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Removed DisplaySupport.h, wasn't needed anymore.
* Removed private color set functions from InterfaceDefs.cpp - we might want
something similar, but definitely not like that.
* Minor cleanup, added some missing licenses.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16831 a95241bf-73f2-0310-859d-f6bbb57e9c96
even though we might need something similar, we can't use it (since it was
based on BGet++).
* Removed BGet++, it's not used anymore.
* Removed ServerMemIO class, was never used.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16830 a95241bf-73f2-0310-859d-f6bbb57e9c96
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
was a bit strange anyway - this closed bug #317.
* The selected window now gets a selection frame in case it can be moved.
* If the window cannot be moved, a new workspace isn't selected either.
* When choosing a workspace, the one currently selected also gets a selection
frame.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16823 a95241bf-73f2-0310-859d-f6bbb57e9c96
chose the front window as our next focus window - but this proved
to be problematic with B_AVOID_FRONT windows. Therefore, we now
simply chose the top-most window as the next focus window.
This fixes bug #281, and potentially also fixes bug #181.
* This also revealed another bug in SetFocusWindow(): when the window
to have focus already had focus, but were hidden before, the focus
did not change; if that window was subsequently removed, the app_server
would have crashed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16811 a95241bf-73f2-0310-859d-f6bbb57e9c96
in HWInterface::_DrawCursor(). Axel, even though we
understood the problem, we didn't really fix it back
then: When the sync flag was set to true in
BView::SetViewCursor(), the link was only flushed,
which means that the function still returned before the
ServerWindow thread processed the message. This means
that the race condition (the cursor being immediately
deleted after SetViewCursor returns, which might be
processed in ServerApp thread before the SetViewCursor
request in ServerWindow thread) still existed. I changed
SetViewCursor now to do a real sync (wait for the
ServerWindow reply) before returning. The alternative
would be to set the fPendingViewCursor flag in either case.
Anyhow, I could reproduce the error quite reliably before
this change, and now it is gone... here is to hoping!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16809 a95241bf-73f2-0310-859d-f6bbb57e9c96
these should be public (they don't match any basic Be naming style
anyway :-).
* Put the code that's used by the app_server where it's needed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16804 a95241bf-73f2-0310-859d-f6bbb57e9c96
windows to other workspaces so much easier that even I managed to get it
right...
* Moving windows on another workspace is now working as well.
* Fixed a positioning bug in Desktop::SetWorkspace() - was only visible in
case the window was in more than one workspace, but not in all.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16777 a95241bf-73f2-0310-859d-f6bbb57e9c96
can't move them to another workspace, and you currently don't see a
window moving that is not in the current workspace. (this fixes bug #135)
* Desktop::SetWindowBehind() didn't update the WorkspacesLayer.
* Changed Desktop::MoveWindowBy() to be able to move window on any workspace.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16776 a95241bf-73f2-0310-859d-f6bbb57e9c96
This should fix bug #124 and makes much nicer screenhots.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16769 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Extended ConvertBits() to properly handle negative offsets and overlapping lines
* Implemented blitting the software cursor to the bitmap returned from ReadBitmap()
Note: In the future we will have to directly use the final graphics buffer for ReadBitmap() if we want DirectWindow output too (R5 includes it). I don't know how R5 handles the hardware cursor though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16766 a95241bf-73f2-0310-859d-f6bbb57e9c96
removed and deleted) windows must not be the mouse event window (ie. while
dragging or resizing the window).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16749 a95241bf-73f2-0310-859d-f6bbb57e9c96
likewise, while the user moves a window around, programmatical moves are ignored
as well.
This fixes bug #264.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16743 a95241bf-73f2-0310-859d-f6bbb57e9c96