* Follows MediaWiki or TracWiki style.
* Supports only level 2 headings, bold, italic and top-level
bullet paragraphs.
* Line break handling would need to be changed.
* Outputs a TextDocument.
* Bail early if the TextSpan length is 0.
* When the span starts with a space, the work
around for the app_server bug, which I should fix,
needs to offset by the other delta.
* Added convenience methods to derive the bold and italic
font face from the currently set font. May not yield
results depending on wether a specific face is available
for the font.
Ü * Changed test accordinly.
Also:
* Fixed off-by-one bug when extracting wrapped TextSpans until the
line's end text offset.
* ParagraphStyle::FirstLineInset() is now additional to LineInset().
* Potential Bullet::Spacing() is added to all lines as inset.
* Use TextDocumentLayout in TextDocumentView.
* Extend test case demonstrating paragraphs with
different alignments, something unsupported in
BTextView.
* TextDocumentView still only shows the first paragraph
of a TextDocument, but this time using the new
ParagraphLayout. A class for layouting all paragraphs
of a TextDocument is up next.
* A simple test app shows that TextSpans with different
CharacterStyles already work in one Paragraph. The test
is nowhere extensive and does not test for bugs in
corner cases.
* The biggest problem was that adding the wrapped
sub-TextSpan to the LineInfos was missing. Other
problems included missing handling of ascent and
descent per CharacterStyle.
I noticed while testing the nightly on vmware which, unlike vbox, includes
a video driver with DPMS support that this checkbox wasn't working.
This should fix it.
... just in case a long translation needs an extra line to fit
(in English 3 is enough) and because we've got enough room next
to the screen image to fit another line of text anyway.
* Since additional handlers put themself in the front the
handler list, asking the tablet handler last actually puts
its handler in the first position, as before my changes.
* The HID driver publishes devices for all handlers that claim
to know how to work with a device. I see how that is good for
a combo device like keyboard with built-in touch pad or a single
USB receiver for a keyboard and mouse. But I wonder about devices
that publish multiple alternative HID configurations. I think
my Wacom Tablet has a configuration for a regular mouse and the
configuration for the actual tablet. And the driver should publish
a device for one, but not the other. I also don't see in the code
how a specific configuration is made the active one before the
protocol is used.
Show the "Read-only" status for documents that are living on read-only
volumes and do not show unlock menu for such files.
* The enhancement pointed out by Sergei Reznikov (Diver). Thanks!
* The previous approach of combining tablet and mouse support
in MouseProtocolHandler was unintuitive and had the potential
problem that if a device has multiple HID descriptors, one
simulating a simple mouse, that one may be found first and
there is no mechanism of choosing the best handler for a device.
Now we can look for tablets before looking for mice.
* Implement pressure, eraser and tilt support. Untested. This
mostly comes from the patch in #7354, but eraser support should
work more like intended by the Be API.
* It appears that my Wacom Intuos 2 cannot be accessed via the
HID framework, except as regular mouse. So I couldn't actually
test these changes. I believe what worked before, i.e. QEMU
absolute mouse position support, should work as good as before.
Please shout if not!
* If more recent Wacom tablets /could/ work with these changes,
they will not, because the HID driver still explicitely ignores
Wacom devices and the dedicated Wacom driver will not pick up
newer devices, with its hard-coded and un-generic device support.
If we fail to lock the window in the kInitialTickRate time, quit the thread.
We were deadlocking causing #4260 because you could open several
threads by moving through the screen saver list quickly all trying to lock
the same window at the same time, classic deadlock.
During adding the second tab the view in the first one may change its
lines count in case the Terminal window was maximized. Send resize
notification to client rpogram on every reattaching view to window.
Fixes#9809
This allows the ScreenSaver window grow and shrink based on your
font size and translations.
Minimum is 446 px x 325 px so that there is enough space to accommodate
screen savers designed for BeOS.
Should fix#7369 and help #7332 a bit.
Margins go right to the edge now which prevents the tab view from looking
as liney.
Password window has also been converted to use the layout APIs, also,
the window now pops up in the center of the main ScreenSaver window.
The fade translations will have to be redone unfortunately, but it should be
easy as it is the concatenation of the previous strings.
* Completely unfininished and untested, won't even compile,
but is not included in the build. The idea being to wrap TextSpan
objects and split them onto Lines each containing their own
layouted TextSpan chunks. TextLayout will later be repurposed
to off-load the layout of individual text paragraphs to
ParagraphLayouts.
* In the methods that create a new style data object
by cloning the object and changing the respective
property, returning a Reference to a style data
object makes it easier on the calling side to deal
with the same object being returned or a new one.
* This is mostly still targeted at the use-case of parsing
some mark up text and building a static representation
of the styled document which can be layouted and rendered.
* Lots of TODOs and almost nothing is tested.
I was looking at the Leaves screensaver for reference and I noticed
this peculiarity. It saves a pointer to each slider control
just so that it can later read their values, but, the values are
already provided in the message in the be:value property, so just
use that instead.
