Open Bug 265064 Opened 19 years ago Updated 8 months ago

Directional caret marker should be a bit longer

Categories

(Core :: Layout: Text and Fonts, enhancement)

x86
Windows XP
enhancement

Tracking

()

People

(Reporter: bugzillamozilla, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

The regression that caused Bug 264903 exposed the fact that Mozilla's BiDi caret
could be a lot more useful and obvious with a slightly longer tip (directional
marker).

I and other users commonly do the mistake of typing using the wrong language
because this caret is not as effective as it could be. This happens both in
Mozilla and in other Windows programs. A longer tip could really help solve this
problem and would give Mozilla one more edge over IE.

Ideally, there should be a hidden pref to set Mozilla to use the current caret,
but the new and improved one should be the default.

Prog.
I just want to add that I'm aware the debatable part of this request is the
straying away from Windows own caret shape (to a better one). However, there's
already at least one similar precedent: Mozilla handles BiDi caret visually
rather than logically.

See https://bugzilla.mozilla.org/show_bug.cgi?id=167288#c1

Botttom line: When non-native is better, then the hell with native solutions :-)

Prog.
Blocks: BidiCaret
The directional marker on the caret in Windows already varies from application
to application. Sometime it's a single line, sometimes a triangle, sometimes a
half triangle. Sometimes it changes in size if the caret itself changes in size
and sometimes it doesn't. What do you think is the ideal shape and behaviour?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #2)
> What do you think is the ideal shape and behaviour?

I prefer something that scales well to small caret sizes. A square tip, like we
have today, is a very simplistic shape that answers this requirement. It just
needs to be extended a little to be more effective.

Prog.

I like a triangular caret better. Of course with smaller sizes you anti-alias
the triangle or collapse it into a single pixel or a couple of pixels.
One thing that I found researching this bug is that we have no
nsIRenderingContext::InvertPolygon()

Either we need to:
1) implement InvertPolygon()
or
2) across columns or rows of pixels inverting rectangles something like this:
  2
 12
012
 12
  2
I think the patch in bug 264903 is a nice solution to this.
Depends on: 264903
This mockup is based on Simon Montagu's attachment 167393 [details] (see bug 264903,
comment 29).

Prog.
Attached image Bidi-Caret on GTK+
I really like how GTK+ draws the marker.  Unfortunately it's not like Windows, but it's so better in my (and GTK+ developers) opinion.

So, i'm on dividing the code, one for GTK+ (gtk2, gtk, and xlib backends) to draw it as GTK+ does, another one for Windows, Mac, etc.

Note that the current marker looks like Windows one.  If it's small, Windows' bidi caret is small too.
(In reply to comment #8)
> I really like how GTK+ draws the marker.  Unfortunately it's not like Windows,
> but it's so better in my (and GTK+ developers) opinion.
> 
> So, i'm on dividing the code, one for GTK+ (gtk2, gtk, and xlib backends) to
> draw it as GTK+ does, another one for Windows, Mac, etc.

By "as GTK+ does", do you mean including the double caret?
(In reply to comment #9)
> 
> By "as GTK+ does", do you mean including the double caret?
> 

I just talked about how marker should look like, not where and how many.  I like to see it under the base line, and that big.  Maybe it would be weired for Win users, so I don't say to change it for Win users.  (I can't remember whether Mac has a Bidi Caret, or how it looked like, so I say nothing about Mac too.)

I think for Win (which this bug is about) that's better to show it like the native one.  But AFAIR Win doesn't have a marker for LTR direction at all.
This is an RFE, really.
Severity: normal → enhancement
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
Assignee: mozilla → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.