Hi John, >> >> > * Approach #2 >> >> > >> >> > - Instead of having a separate xul element for the info label, add the >> >> > info text directly to the minibuffer input. >... >> The other thing that looks awkward is dealing with the initial fixed >> width of the input part of the textbox, before it starts expanding. >> Inserting spaces between the input and info portions would achieve this, >> but the width will vary according to the widths of the other characters, >> so a specific pixel width can't be set, leading to the info position >> wobbling. Perhaps there's some unicode space character for which we >> could set the width. > > What do you mean about the widths of spaces varying depending on the > widths of other characters? Surely not..
No; I'm referring to the width of the input portion of the textbox, not that of the individual characters. (Probably superfluous detail follows.) We want to provide some initial space in the input field, say 5ems, to display the input text, with the info displayed to the right (after some separation, say 1em). This initial width is needed to make it clear that this is an input text box; otherwise the info text appearing at the left of the box is confusing. It also looks better; in the usual short input case the info position is fixed. Only once this initial space is full does the input area start growing and the info moves to the right. To accomplish this with a single textbox implies inserting space characters between the input and info parts of the text. Because the individual characters have different fixed widths and the various space characters have fixed widths, there is no general solution to the problem of how many spaces to insert to give a certain pixel width. One can get within a half space width of the desired width, but the exact position will vary according to the characters in the input; i.e. to the left of the inserted spaces. >... >> > * Approach #4 >... > To my understanding, side-effects could only arise if there was a net > change to the selection after completion of the event in which the code > ran. (That is what my "XXX:" note is about.) Okay, thanks. >... > What do you think about the XBL idea? I like it a lot. I read your "might be favourable" comment as implying that this was merely sweeping the problem under the rug. But I agree with your reframing of the problem below, where a proper abstraction manages the issue. It probably won't be possible to entirely forget the complexity in future development, but this should contain it. > All approaches have complexity, but > it's a matter of where that complexity is that makes the difference; > whether it is local complexity to a single module (hints.js), leaky > complexity that infects other modules (minibuffer.js), or complexity that > can be wrapped up in a tidy abstraction and forgotten. I think we might > be able to use XBL to wrap up the entire stack&strut method in a > self-contained file, introducing a new XUL element <minibuffer-input/> to > be used in place of the textbox. This element would handle the > stack&strut mechanism internally and transparently. It would probably > just need to provide a method to switch it between normal mode and > stack&strut mode. Sounds good. How do you feel about the name "annotated-textbox" for the XBL binding; with minibuffer-input as the element that binds to it (if I've got my terms straight)? Regards, David _______________________________________________ Conkeror mailing list [email protected] https://www.mozdev.org/mailman/listinfo/conkeror
