* The bullet paragraphs were already working, now we have
bold and italic plus the heading style. The links in the
original changelog are not yet supported.
* Also include the terminating \0 in the loop
over the characters, in order to consume the
last paragraph correctly when it's not finished
by a line break.
* 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.
