Separate composer widget from composer window
In anticipation of inline composition, we need the composer widget to be separate from the window in which it lives. We introduce a new interface, ComposerContainer, that the thing that holds to ComposerWidget must implement. Separate composer widget from composer window In anticipation of inline composition, we need the composer widget to be separate from the window in which it lives. We introduce a new interface, ComposerContainer, that the thing that holds to ComposerWidget must implement. Basic inline composition Many of the details don't work, or don't work well, but the basics are in place. Allow only a single inline composition at a time With this, we introduce a dialog when you would try to add another. We also use this when changing the selected conversation with a composer open. Compose new messages inline, with no conversation selected Hook up composer accelerators only when focus is in composer editor It would be nice to only activate these accelerators when the composer has focus generally, but that doesn't seem to be easy to detect. Only disconnect accelerators if they're connected Maintain focus when composer is popped out The selection isn't, though. Fix Tab focus for embedded composer There are two things that needed to be fixed: The tab key doesn't usually advance focus for embedded widgets (huh?), so we handle tab presses by hand for ComposerWidgets. Also, the EmailEntrys do their own tab handling, which needs to know about the composer widget, not the toplevel widget in the embedded case. Remove close() from ComposerContainer interface I don't think it was actually doing anything, and it conflicts with the new close() method of Gtk.Window.
parent
9a8f7fb6
Please register or sign in to comment