Community:SummerOfCode08:TSF

My attempts at adding Text Services Framework support to the Mozilla platform as part of Google Summer of Code 08. (wish me luck!)

Summary

This is the end of week 4, (end of "full-time" week 1 for me since I had school and exams the first three weeks :/), and I have made stubs for the implementation, implemented several easy-to-implement methods, and made a basic outline of my design. --Darchons 10:48, 20 June 2008 (PDT)

Outline/Progress

Development

• Startup code
  • nsWindow::nsWindow
• Shutdown code
  • nsWindow::~nsWindow
• ITextStoreACP implementation (14 out of 26 implemented)
  • AdviseSink
  • UnadviseSink
  • RequestLock
    • addnsWindow input block (not required now but would be nice to have)
  • GetStatus
  • QueryInsert
  • GetSelection
    • add NS_QUERY_SELECTED_RANGE_TEXT event
  • SetSelection
    • add NS_SELECTION_CLEAR event
    • add NS_SELECTION_ADD_RANGE event
  • GetText
    • (use NS_QUERY_TEXT_CONTENT event)
  • SetText
    • (call SetSelection then InsertTextAtSelection)
    • can we prevent painting during the method?
  • GetFormattedText
    • somehow make use of nsDataObj
  • GetEmbedded
  • QueryInsertEmbedded
  • InsertEmbedded
  • RequestSupportedAttrs
  • RequestAttrsAtPosition
  • RequestAttrsTransitioningAtPosition
  • FindNextAttrTransition
  • RetrieveRequestedAttrs
  • GetEndACP
  • GetActiveView
  • GetACPFromPoint
    • add hit test event
  • GetTextExt
    • NS_QUERY_CHARACTER_RECT
  • GetScreenExt
    • add query bound event?
  • GetWnd
  • InsertTextAtSelection
    • NS_TEXT_TEXT
  • InsertEmbeddedAtSelection
• Notification code (0 of 7 implemented)
  • onAttrsChange
  • onStartEditTransaction
  • onEndEditTransaction
  • onLayoutChange
  • onSelectionChange
  • onStatusChange
  • onTextChange

Testing/Debugging

• Writing tests
• Tablet input
• Speech recognition

Thoughts

I was an extension developer for a while before this, but it definitely feels different to be working directly on the Mozilla trunk :) and as with a lots of things there are some goods and bads

One major goodness is how easy it is to do some of the stuff that I was doing.

Extreme example: Getting a window handle (HWND) to the Firefox window. In my extension I had to, (there are probably easier ways to do this that I haven't found)

• Start off with a nsIDOMNode
• Check for accessible attribute on the node
• If exists, get the nsIAccessible
  • QI to nsIAccessNode
• If doesn't exist, get the accessibility service ("@mozilla.org/accessibilityService;1")
  • QI for nsIAccessibleRetrieval
  • Call nsIAccessibleRetrieval::getAccessibleFor to get a nsIAccessible
  • QI to nsIAccessNode
• Call nsIAccessNode::GetAccessibleDocument to get a nsIAccessibleDocument
• Call GetAccessibleDocument::GetWindowHandle to get the HWND

It's not very pretty and you have to hope that accessibility is working (and included in the build, which thankfully is the default)

Now, for what I'm doing now,

• Start off with a pointer to nsWindow
• Call nsWindow::GetWindowHandle to get the HWND

The difference between the two is pretty big.

Now one bad thing is that in my extension I could pretty much use everything that the platform offers, as long as it accomplishes my goals.

But right now I'm working under the widget component which is lower-level to content, layout, etc. And I cannot directly use most of the stuff from these high-level components from widget otherwise that would break the abstraction. So it feels more constricted in a way than when writing an extension. But there are alternatives and these shouldn't cause problems.

Quirks

Firefox 3 is crashing on me constantly, and most of them aren't even getting caught by the crash report thingy :(