G'day John, > The shadow-label approach to the input sizing problem is very > creative
I saw this idea referred to on a blog somewhere, which I can't find now. I should have credited that. > but quite honestly it makes me cringe to think of adding > that much complexity to the minibuffer for the sake of a small > effect. I would like to rule it out as an option. I agree that this solution is more complex than is desirable. However, it also has some nice properties, so pardon me while I continue to discuss it. The main complexity is that three extra UI elements are added to the minibuffer; they are not visible; they are only there to influence the layout. The other ugliness is the copying of styles from the input textbox to the shadow label. It may be possible to retain the current approach with fewer elements and without the style copying, perhaps by incorporating your idea of placing the label as a child, not a sibling, of the input. I'll experiment with this. But the nice thing is that once that's all set up, it mostly takes care of itself. And the expansion looks smooth and natural. All that is needed in update() is to copy the input text to the shadow; the layout is handled automatically. Other approaches require attention to the layout in update() and also on resize and on change in the prompt. BTW; this feature is very usable with just the first patch. For short inputs the expansion is not required and surely a long input is unusual. It is still works, although the input scrolls rather than grows. > * Approach #1 > ... > - 'size' attribute used on minibuffer-input to dynamically size input > field. I don't think anything based on character count will be satisfactory. There are two problems. 1) The blank space in the input field will depend on the characters typed; an "l" and "m" will expand the field by the same amount, but the apparent space between the input and the info will vary. It doesn't look good. 2) When the input field has expanded to fill the minibuffer, further characters will expand the minibuffer, causing re-layout of the content buffer. To avoid this, the width will need to be checked and the input field flexed at some point. But then as the field is edited further, there's no good way to know when to revert back to a fixed (and updated) width. > ... > * Approach #2 > > - Instead of having a separate xul element for the info label, add the > info text directly to the minibuffer input. > > - Use a secondary selection type (like SELECTION_URLSECONDARY) to style > the info text. > > - Somehow prevent the insertion point from entering the info part of the > input. I'm not at all familiar with use and styling of the selection, but it seems like it would be workable. I'm concerned that it's subverting a feature that's intended for another use; but perhaps that use is not applicable here. I think that in addition to tracking the insertion point it would be desirable to keep the displayed portion of the string as far to the left as possible, to ensure that the input is displayed in preference to the input. > * Approach #3 > > - Replace the minibuffer-input textbox by a richtext-editable object that > gives us more freedom to control layout. That seems like a bigger hammer than is warranted. Regards, David _______________________________________________ Conkeror mailing list [email protected] https://www.mozdev.org/mailman/listinfo/conkeror
