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. 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. >... >> 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. 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 _______________________________________________ Conkeror mailing list [email protected] https://www.mozdev.org/mailman/listinfo/conkeror
