On Wed, Feb 08, 2012 at 11:44:19PM +1030, David Kettler wrote:
> 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.
Hi David,
I'm going to take these topics out of order..
> > * 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.
Agreed. I had only tested it with a monospaced font, so hadn't noticed
that problem. We can rule this approach out.
> > * 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.
I don't see it as subverting a feature so much as I consider it strange
how specifically "SELECTION_URLSECONDARY" is named, as if in implementing
this, the Mozilla team couldn't think of any other possible uses for a
secondary selection than to highlight parts of an URL. There may also be
other types of secondary selections, but a badly chosen name wouldn't stop
me from using it if it turned out to be the best suited mechanism.
Depending on how hacky it turns out to be to keep the the insertion point
out of the info area and to keep the box scrolled appropriately, this
could actually be a very elegant solution to the problem.
> > * 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.
I would have thought this an elegant approach, and it could have made the
minibuffer a more powerful tool in other ways, but it seems we have to
rule it out, as Mozilla does not support richedit fields in XUL. They
have conflicting documentation on the subject, but I experimented and was
unable to get any results.
> 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.
I don't consider this feature viable unless we can get the
auto-positioning of the info working. Without that, the UI just feels
incomplete and amateurish. It looks broken when input text is long and
there is nothing in the info field.
> 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.
I think of this as the stack&strut method --- let's use the word strut
instead of shadow. The complexity that this method adds is both up front,
in what you mentioned, and hidden, in that all future development that
involves the minibuffer will force the developers to stop and take account
of this non-obvious mechanism. It makes the minibuffer itself harder to
understand, all for the sake of dealing with a corner case of an optional
feature in a single module's minibuffer use. I *might* be more favorable
to it if the mechanism could be abstracted away into XBL and work
transparently.
But it turns out there is another way to get the pixel width of the text
inside of an input box:
* Approach #4
- Add this method to minibuffer.prototype:
input_text_width: function () {
var field = this.input_element.inputField;
//XXX: if we wanted to be really thorough, we could clone all
// ranges, but let's be practical...
var start = field.selectionStart;
var end = field.selectionEnd;
field.select();
var sel =
field.QueryInterface(Ci.nsIDOMNSEditableElement).editor.selection;
var w = sel.getRangeAt(0).getBoundingClientRect().width;
field.selectionStart = start;
field.selectionEnd = end;
return w;
}
- Minibuffer-input becomes flex 0 during hints operation.
- Minibuffer-input is sized during hints interaction by doing a bit of
arithmetic whenever input or window/prompt metrics change.
- This approach requires XULRunner >=2, and while our current minimum
target version is 1.9.1, I do not consider that to be a deal-breaker,
because the feature in question is a minor optional feature, so it
would be okay to have it available only when the XULRunner version was
high enough.
--
John Foerch
_______________________________________________
Conkeror mailing list
[email protected]
https://www.mozdev.org/mailman/listinfo/conkeror
