On Sun, Feb 12, 2012 at 07:28:01PM +1030, David Kettler wrote:
> Hi John,
>
> Thanks for your detailed responses. I see this as an important feature
> for conkeror; I think that is why I'm willing to put up with more
> complexity in its implementation than it would need if the platform was
> more reasonable. It looks like any implementation is more complex than
> seems reasonable.
>
> As an aside, I got the idea for the deck&strut method from
> http://www.blackfishsoftware.com/node/47
>
> Another aside; I wonder what reference materials you use for XUL, etc.
> A couple of your suggestions can't be derived from the mozilla
> documentation.
>
> >> > * Approach #2
> >> >
> >> > - Instead of having a separate xul element for the info label, add the
> >> > info text directly to the minibuffer input.
> >...
> > 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.
>
> 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..
> I wonder where you learnt about SELECTION_URLSECONDARY; I can't find any
> documentation for it. There are other selection types though, which may
> also be usable.
I was thinking about this problem in the most basic terms.. all we really
want to do is have some auxiliary text that appears to be in the
minibuffer input, but differentiated by style. I remembered that Firefox
has two different styles of text in its url bar to set off the domain from
the rest of the url, so I went looking in the source to see how they did
it. It doesn't seem to be documented, and maybe that means it only exists
in Firefox, not sure.
> >> 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.
>
> Okay. It's straightforward to hide the info display when it's empty,
> which would avoid that specific problem. But it's still not great.
>
> >...
> > 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.
>
> Well, let's try the other methods before revisiting this. But I think
> they'll all add complexity that will affect future development. BTW, I
> think that the hints interaction is such a fundamental part of conkeror
> usage that it rates higher than "a single module's minibuffer use". And
> I'd like this info display to be useful to all users. I won't debate
> "corner case" though.
>
> > 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;
> > }
>
> Wow, thanks very much. I had a good look for ways to get the text width
> from the textbox; this is the first solution I have seen. I was
> concerned that that this would affect the X primary selection, but it
> doesn't seem to. I wonder if there's any other state that this affects.
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.)
> I'll follow up with an implementation of the feature using this
> approach, but it's not very satisfactory. Apart from a few kludges,
> which can hopefully be addressed, it's certainly overly complex.
>
> Regards, David
What do you think about the XBL idea? 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.
Thanks for the patch using the pixel-based method.. it's good to know our
options.
--
John Foerch
_______________________________________________
Conkeror mailing list
[email protected]
https://www.mozdev.org/mailman/listinfo/conkeror
