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
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
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
this saves us some locking headaches and solves a possible deadlock in
ServerApp::Activate().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16688 a95241bf-73f2-0310-859d-f6bbb57e9c96
when it's not over a view of the application.
* The application cursor is no longer applied when the mouse cursor is over
the border (or tab) of a window.
* Gave up and imitate BeOS behaviour: the mouse cursor now always get the
shape the view below dictates, ie. it will no longer fall back to the
default cursor outside the focus window.
* The window is now set to the default in case there is no window under it
at all (ie. if Tracker isn't running).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16685 a95241bf-73f2-0310-859d-f6bbb57e9c96
tab that doesn't become gray, even if another window gets focus), adopting the
R5 behaviour.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16684 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the view currently under the mouse, or the application cursor, if the view doesn't
have its own cursor (ie. it will no longer set the wrong cursor in certain situations).
* AS_DELETE_CURSOR has no longer an influence on the application cursor, as this grabs
a ref for its own use - this fixes bug #275.
* AS_SET_CURSOR no longer sets the cursor when the application is not active.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16678 a95241bf-73f2-0310-859d-f6bbb57e9c96
deleted when the local BCursor object is gone. This should fix bug #275 (ScummVM
should no longer have two cursors), not tested yet, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16676 a95241bf-73f2-0310-859d-f6bbb57e9c96
used for the drag bitmap, see NOTEs on why that is...
* moved reference counting of the ServerCursor from Desktop into
HWInterface where it is actually used
* I hope to have fixed the problems with _DrawCursor when dragging
something. At least the reference counting of the ServerCursor was
for real, since the HWInterface rejected changes to the cursor while
something was dragged, which caused the old cursor to be Released() and
deleted each time the mouse moved...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16657 a95241bf-73f2-0310-859d-f6bbb57e9c96
take an empty region as an indication to remove the clipping, but on R5,
this is actually valid... this patch fixes the problem
* the ViewState::clipping_region is now consistently used to memorize
the user defined clipping of the view state instead of being sometimes
used to cache the current view clipping
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16656 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added some comments
* Added some checking to avoid noop shifts
* Added buffer length checks
* Implemented (as Stephan suggested) a version of ConvertBits() that takes offsets.
This new version allows to move a region of the source into a region (possibly not at the same point) on the dest while converting colorspaces on the fly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16592 a95241bf-73f2-0310-859d-f6bbb57e9c96
supported. (makes VLC run without changes)
* B_BITMAP_CLEAR_TO_WHITE causes the server to
clear the bitmap to white... :-)
* removed weird comment
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16578 a95241bf-73f2-0310-859d-f6bbb57e9c96
Colorspace conversion is not done yet so that it only works correct in 32bit modes.
Also drawCursor is not respected yet. Partially fixes bug 197.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16573 a95241bf-73f2-0310-859d-f6bbb57e9c96
free to continue (it would be nice to be notified before, though, in case
I get to it again in the next weeks).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16561 a95241bf-73f2-0310-859d-f6bbb57e9c96
* instead a fitting display mode from the list, and having a fallback
"ignore frequency" mode, the closest available screen mode is now
chosen.
* The display_mode's frequency of the mode found is now adapted to the
requested frequency, as it's done in the screen preferences panel.
* Removed the fallback 8 bit mode for now; instead, we should have
_FindMode() deviate from the color space as well, if needed.
* This all fixes the problem that you suddenly had an (still badly
supported) 8 bit mode after reboot, instead of the one originally
chosen in the screen mode preferences.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16558 a95241bf-73f2-0310-859d-f6bbb57e9c96
windows to front (or minimize them).
* Desktop::ActivateWindow() no longer crashes in case the window to be activated
is not on the current workspace - instead, it doesn't do anything at this
point. IOW it doesn't handle workspace activation at all, yet.
* Renamed ServerWindow::GetWindowLayer() to ServerWindow::Window().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16550 a95241bf-73f2-0310-859d-f6bbb57e9c96
holding the window lock.
* Run() is now called before creating the window in the app_server when
Show() is called for the first time (which is now checked with fRunCalled
instead of some thread arithmetics).
* Minimize() now sends the show level of a window to the app_server, so that
it can actually determine if minimizing or maximizing the window should
have any effect. This fixes bug #225.
* fShowLevel's meaning is now reversed; when it's above zero, it now means
the window is shown (before, a level less than 1 meant shown). This definitely
better fits its name :)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16536 a95241bf-73f2-0310-859d-f6bbb57e9c96
without a lock).
* Renamed private methods to start with the '_' symbol.
* Removed superfluous SetLayer[Font]State() and moved back those one-liners into their
AS_* handlers.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16535 a95241bf-73f2-0310-859d-f6bbb57e9c96
steal the focus of the focus window.
This fixes bug #181.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16532 a95241bf-73f2-0310-859d-f6bbb57e9c96
* AS_GET_STRING_WIDTHS now uses this method to send the strings to the app_server;
ie. it no longer sends the whole strings, and it saves sending the string length
separately.
* BFont::StringWidth() will now always return 0.0f in case of an error (instead of
some random value)
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16525 a95241bf-73f2-0310-859d-f6bbb57e9c96
colors with full saturation in the part where
the cursor is transparent
* fixed leakage of cursor data (placed making the
copy it in the wrong bracket)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16523 a95241bf-73f2-0310-859d-f6bbb57e9c96
* all cursors owned by a team are visually different,
or (iaw) an already existing cursor is reused when
it is set by the client again
* changed various occurances of cursor data from "int8*"
to "uint8*"
* ServerCursors also remember the R5 data from which
they were created
* the reference counting and destruction of
ServerCursors changed: The cursor knows it is attached
to a CursorManager and one can simply use
ServerCursor::Acquire() and Release() and the reference
counting and everything is being taken care of
* destroying a ViewLayer will now correctly release a set
ServerCursor
* fixed a race condition when setting a cursor through
BView::SetViewCursor(): If the client code looks like this:
BCursor cursor(cursorData);
someView->SetViewCursor(&cursor, false);
there is a relatively high chance the BCursor destructor
told the ServerApp thread to destroy the cursor before
the ServerWindow thread got to "acquire" the cursor for
use by the view layer. The very same problem is likely the
reason that SetViewCursor works to unreliably on R5, even
when the "sync" flag is set to "true" (although it should
theoretically work in that case).
all these fixes make WonderBrush work fine again with the
new support of custom cursors.... coded by axeld and myself
(the joys of pair programming :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16521 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added more char codes to is_white_space(), should be all I think
Sorry if I stepped on your toes Stephan, but I wanted these changes flushed before I leave for holidays :-).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16501 a95241bf-73f2-0310-859d-f6bbb57e9c96
omitted. This fixes bug #181, or at least the part of it I can reproduce.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16442 a95241bf-73f2-0310-859d-f6bbb57e9c96
all those error output from the app_server.
* AS_LAYER_DELETE now gets a token, no longer frightening choice of parent.
* Removed locking in RemoveChild(); it has to be called locked now.
* Removed AS_LAYER_DELETE_ROOT as it's no longer needed.
* Removed support from BView for being PR3 compatible.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16424 a95241bf-73f2-0310-859d-f6bbb57e9c96
B_MODIFIERS_CHANGED message.
This fixes bug #175 (which was probably caused by a bug in our old BMessage implementation,
see TODO item in line 141).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16414 a95241bf-73f2-0310-859d-f6bbb57e9c96
Should probably be cleaned up a little. This fixes bug #146.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16377 a95241bf-73f2-0310-859d-f6bbb57e9c96
correctly when Tracker is not running; obviously, the background is cleared in
Tracker before it had the chance of changing the view color.
Maybe the app_server needs to detect the background view of the desktop and
change the view color manually :-/
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16376 a95241bf-73f2-0310-859d-f6bbb57e9c96
often seen error message.
I'll investigate if convert_from_utf8() is supposed to return an error for empty
strings.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16327 a95241bf-73f2-0310-859d-f6bbb57e9c96
used by the Deskbar (for "Hide All" and "Show All"). The latter doesn't work
correctly yet, though, it just maximizes all windows of that application.
* Added a TODO to ServerWindow AS_MINIMIZE_WINDOW on how to make it work correctly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16315 a95241bf-73f2-0310-859d-f6bbb57e9c96
got lost, before.
It might not work 100% correctly yet, but it works good enough to hide the Tracker
status window from the Deskbar, and thus, fixing bug #133.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16314 a95241bf-73f2-0310-859d-f6bbb57e9c96
