of BFont. You can BFont::SetFalseBoldWidth(float) a width on a
BFont object, and it will cause the glyph shapes to be run through
an AGG "contour converter" so that they become thicker or thinner.
IIRC, this is commonly referred to as "false bold". The "width" value
is the distance in pixels that the new glyph outline will be offset
from the original outline.
It would be nice if someone could look at my change to View.h with
regards to the B_FONT_ALL flag.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19547 a95241bf-73f2-0310-859d-f6bbb57e9c96
so that we can draw the window borders using parallel access too.
Seems to improve things even further, using the app_server environment
with direct accelerant access on R5 looks pretty decent now, but
of cause still far from perfect. The global font lock could actually
be the problem now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19528 a95241bf-73f2-0310-859d-f6bbb57e9c96
Seems to make some difference too. Nothing dramatic though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19527 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added lha and tar mimetypes (TODO: sniffer rule, help appreciated)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19520 a95241bf-73f2-0310-859d-f6bbb57e9c96
(was only saved when switching from "export" to "save")
* make use of drop index when dragging and dropping paths in
list view
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19519 a95241bf-73f2-0310-859d-f6bbb57e9c96
LockExclusiveAccess() (meaning more or less access to the
frame buffer)
* extracted the AGGTextRenderer to be a global instance used
by each Painter instance (currently, it is thread safe because
of the global font lock, so there is some work left in this
regard)
* gave every ServerWindow it's own DrawingEngine instance, this
is work in progress. So far, there doesn't seem to be a regression,
but less fighting over the exclusive access to the frame buffer, now
each ServerWindow thread can draw in parallel. There is room for
improvement, plus I think I'm leaking the DrawingEngine...
* changed the locking for the software cursor. ShowSoftwareCursor()
can only be called if HideSoftwareCursor(BRect) returned true, or
if you called the generic HideSoftwareCursor(), since it needs
to keep the cursor lock and unlocks in Show...!
* some clean up and renaming in Decorator and friends
* moved PatternHandler.h to live along with the .cpp
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19427 a95241bf-73f2-0310-859d-f6bbb57e9c96
(and also improved performance of rendering icons, the background
was cleared for no reason on each Draw() call) However there
must be a bug still in the app_server which causes GetClippingRegion()
to return an out-of-date clipping region (R5 has the very same bug
though)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19413 a95241bf-73f2-0310-859d-f6bbb57e9c96
so frequently when unflattening R5 messages (each mouse event arrives
as an R5 message in the test environment): unflatten_r5_message()
retrieved the pointer to the message header, but afterwards cleared
the message... resulting in the header pointer to be invalid.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19412 a95241bf-73f2-0310-859d-f6bbb57e9c96
changes in the HWInterface (ie on mode switch)
* initialization and shutdown of the HWInterface instance no longer
go through DrawingEngine, which had nothing to do with it in the
first place
(this is in preparation of giving each ServerWindow it's own
DrawingEngine instance)
* small performance improvement in ViewLayer::ScrollBy()
* some cleanup in ServerConfig.h
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19391 a95241bf-73f2-0310-859d-f6bbb57e9c96
but use integer coordinates. These are now used in ViewLayer for the
coordinate system (layout, scrolling offset, view bitmap layout)
* modest performance improvements by inlining some very often used
methods, and by preventing to go down the entire layer tree too often,
for example InvalidateScreenClipping was always called in the deep
mode, therefor it is save to assume that the tree does not have to
be traversed as soon as the clipping is already invalid
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19390 a95241bf-73f2-0310-859d-f6bbb57e9c96
or something else, but I don't think the change is bad (changed
ServerProtocol.h from a local header to a system header)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19388 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Transformer menu is correctly enabled/disabled when a shape is selected
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19351 a95241bf-73f2-0310-859d-f6bbb57e9c96
* fixed bug in RDefExporter
* improved zooming, icon is now centered at program start
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19328 a95241bf-73f2-0310-859d-f6bbb57e9c96
commits seem to work fine (BTW, what an odd place for the TeamMonitor :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19314 a95241bf-73f2-0310-859d-f6bbb57e9c96
B_EDIT_ICON_DATA messages, doesn't load an icon yet
(won't look into it within the next 10 hours... ;-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19311 a95241bf-73f2-0310-859d-f6bbb57e9c96
-> Icon-O-Matic is launched, but it says the data is not valid...
don't know why yet (will commit a newer Icon-O-Matic next)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19310 a95241bf-73f2-0310-859d-f6bbb57e9c96
use Icon-O-Matic to create or edit icons
note to axeld: I'm messing with it right now, hope you're sleeping
and not messing with it too! :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19308 a95241bf-73f2-0310-859d-f6bbb57e9c96
* implemented SavePanel that let's you chose the Export format
* introduced DocumentSaver class and several implementations
* Document no longer remembers any entry_refs, but a native
and export document saver, for other export formats than
HVIF, it is no longer necessary to go through the file panel,
simply invoking Export will do
* this makes it much easier to have a custom saver that sends
a message with an HVIF icon to another app instead of saving
to a file
* cleaned up File menu
* last used export format is persistent
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19307 a95241bf-73f2-0310-859d-f6bbb57e9c96
there is some unfortunate code duplication in AppFileInfo,
because it cannot use BMimeType/BNode alone to retrieve icons,
now it works closer to the code in BIconUtils, this fixes
R5 icons not displaying for other icon sizes
* implemented a bilinear scaling function, I don't know if
it is very fast, but I hope it is reasonable. Now that I
see the results though, I wonder if R5 icons should be
scaled with nearest neighbor instead...
* corrected a small bug in the icon format stuff...
7 bit coords are -32-+95, not 96
* improved comment for BIconUtils function
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19302 a95241bf-73f2-0310-859d-f6bbb57e9c96
remembered for now
* fixed some annoying bugs:
- the snapping prevented some of the proximity checks from
working while editing a path or using the transform box,
now the Manipulators themself are responsible for mouse
snapping and can do so at the time it works best for them
- pressing the Esc key while using the transform box did
reset the transformation, but didn't exit the transform
mode (return to path editing)
* improved layout of some views when the window is resized
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19266 a95241bf-73f2-0310-859d-f6bbb57e9c96
* made the paper sheet just a bit lighter at the bottom
* created font folder icon
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19228 a95241bf-73f2-0310-859d-f6bbb57e9c96
and some unfinished paragraphs at the end, feel free to
comment and discuss
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19222 a95241bf-73f2-0310-859d-f6bbb57e9c96
* used new layout features in StyleView for Haiku version
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19212 a95241bf-73f2-0310-859d-f6bbb57e9c96
the layer bitmaps, all the Translater has to do is compose the layers, tested
and works with all my WonderBrush images, hopefully contains no memory leaks...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19211 a95241bf-73f2-0310-859d-f6bbb57e9c96
for applications, I kept the R5 icon around and the
vector icon is only used when compiling for Haiku,
for the mimetypes, I removed the R5 icon, as I don't
think they are used outside the Haiku build
naturally, I'm open for comments
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19193 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added mode for 1440x900, the numbers are just guessed, but work fine
with my monitor (after some fiddling), would be best to have some common
VGA communication code for all drivers to use and auto-detect the preferred
mode of the monitor
* messed around with the overlay brightness and contrast values to give
good looking video
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19192 a95241bf-73f2-0310-859d-f6bbb57e9c96
changed the save entry_ref to the appended file, instead of keeping it
* added cleaning up styles (removing duplicates) after importing from SVG
* compile fixes for rgb_color ==/!= rgb_color
* added Style::operator==(const Style& other)
* improved debug output when listeners are still attached
to a VectorPath upon destruction
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19188 a95241bf-73f2-0310-859d-f6bbb57e9c96
drawing icons, most importantly, don't switch from compositing
to pixel alpha, this fixes the drag bitmap generation, now
it looks beautiful
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18846 a95241bf-73f2-0310-859d-f6bbb57e9c96
bitmap was not completely transparent, but had a faint
shadow, I removed this, though it seemed to be on purpose,
I have no idea why... it looked like a bug
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18845 a95241bf-73f2-0310-859d-f6bbb57e9c96
with regards to drawing bitmaps with alpha channel, instead
of ignoring the bitmap alpha channel, it is further multiplied
with the high color alpha channel, so basically, you can
use the high color alpha as a "global" alpha value to
draw the bitmap with
* removed some duplicate code
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18843 a95241bf-73f2-0310-859d-f6bbb57e9c96
over the mouse cursor. The problem is actually something else:
non-straight lines extend a little past the calculated rectangle
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18842 a95241bf-73f2-0310-859d-f6bbb57e9c96
got fixed twice, any unoptimized lines were drawn at
a (0.5, 0.5) offset
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18841 a95241bf-73f2-0310-859d-f6bbb57e9c96
(this would fix the white background on disabled looking
icons if Tracker would still use B_CMAP8 icons)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18840 a95241bf-73f2-0310-859d-f6bbb57e9c96
compatible now. This fixes the last remaining drawing bug in
SoundRecorder.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18838 a95241bf-73f2-0310-859d-f6bbb57e9c96
a concurency problem in the DrawingEngine, so there is some debugging
stuff added, as well as some unnecessary locking removed there. The
problem was in Painter though, in that certain functions adjusted clipping
at the "rasterizer level", while some other functions didn't care about
that. Now the clipping is consistently set at the rasterizer level (rough
estimate to avoid scanline generation outside real clipping region bounds).
There are a number of bugs fixed by this, I'm going to find out later,
what their ticket numbers are... Mouse preflet draws the mouse now,
Backgrounds preflet draws the screen reliably... probably more, anything
to do with bitmaps, round rects and possibly ellipses.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18828 a95241bf-73f2-0310-859d-f6bbb57e9c96
its resources -> now also the vector icons (thanks Jérôme for
the hint)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18806 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Deskbar uses 32 bit icons now
* vector icons are now correctly converted to B_CMAP8 bitmaps
if no B_CMAP8 icon is available
* small fixes in Tracker (window mode menu)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18803 a95241bf-73f2-0310-859d-f6bbb57e9c96
for saving later
* added "Clean Up" feature to "Path" menu
* added "Freeze Transformation" to "Shape" menu (will apply the
current shape transformation onto the path and reset the shape
transformation to identity)
* small cleanup in ShapeListView
* implemented zooming in CanvasView
* added context menu while editing a path
* implemented undo/redo for transforming points
(press T or use context menu)
* added "Split Points" feature (path editing context menu), it will
make two points from one control point
* improved selecting path points with selection rect
* improved SVG import for zuMis BeOS icons (more precise scale)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18800 a95241bf-73f2-0310-859d-f6bbb57e9c96
* additional versions of SetIcon[ForType] and GetIcon[ForType] in BMimeType
and BAppFileInfo, which handle flat vector icon data
* changes in Tracker to support scalable icons (currently broken for
non-vector icons and needs cleanup) and drawing icons correctly with alpha
channel (large parts of this work done by Michael Lotz)
If someone feels like looking over the changes, that would be much
appreciated! :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18699 a95241bf-73f2-0310-859d-f6bbb57e9c96
because the SeekSlider knows if the knob position actually changed
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18634 a95241bf-73f2-0310-859d-f6bbb57e9c96
BMimeType and Tracker in general, nothing should have changed
visually, Tracker is now using 32 bpp icons though
I hope I have not broken anything...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18632 a95241bf-73f2-0310-859d-f6bbb57e9c96
-> Waldemar, could you please use this one? Do you need a transparent version?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18613 a95241bf-73f2-0310-859d-f6bbb57e9c96
Transformable, should have been part of the last commit...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18556 a95241bf-73f2-0310-859d-f6bbb57e9c96
clutter, straight from the sources of release 1.95.8, configured
to obtain expat_config.h, seems to work fine
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18552 a95241bf-73f2-0310-859d-f6bbb57e9c96
Stephan Aßmus