* 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.
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
