On Tue, Feb 07, 2012 at 07:13:37PM -0500, John J. Foerch wrote:
> I have at least one idea for a different approach that I would like to
> investigate, so I will post a followup after I have checked it out.
Notes from my experiments, three approaches:
* Approach #1
- similar to your patch, minibuffer-input flex turned off during hints
interaction, allowing info label to appear to the immediate right of
the input text.
- 'size' attribute used on minibuffer-input to dynamically size input
field.
hints.minibuffer_state would setup the initial value for 'size' in its
constructor, remove the attribute in its destroy method, and adjust it
in the handle_input method. Adjustment would have to be conditional on
the current width of the input-box. A threshold width would be
approximated by the width of the window, minus the width of the prompt,
minus a fudge-factor based on current font size. Window size changes
would have to be handled as well, because a person could resize the
window while in the hints interaction.
- the info label can be added as a child to minibuffer-input, rather than
as a sibling. This eliminates the need for excessive css to match
backgrounds, margins, paddings, and possibly even alignment. This can
be done dynamically, similar to how the current hints_url_panel is
inserted into the DOM.
minibuffer.input_element.inputField.parentNode.appendChild(info_label)
* 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.
* Approach #3
- Replace the minibuffer-input textbox by a richtext-editable object that
gives us more freedom to control layout.
--
John Foerch
_______________________________________________
Conkeror mailing list
[email protected]
https://www.mozdev.org/mailman/listinfo/conkeror
