Requirement:
    Make editing readonly documents with multiple fields pleasant
	 ie. <tab><edit><tab><edit>

<michael_> caolan: around ?
<michael_> caolan: I have a word/forms query - from a lead,
<michael_> caolan: they have a document, with a load of read-only content & fields in it,
<michael_> caolan: they're used to pressing <tab> - to get to the next field, and typing content in directly.
<michael_> caolan: OO.o insists on click-directly-on-the-field, and then we get a sick pop-up ;-)
<michael_> caolan: is there a way to get a nice tab/edit/tab/edit experience [ some random setting somewhere ] ?
<caolan> michael_: I know, there are only two available options in writer, fixed width "forms", and variable width "fields" with the pop-up
<caolan> michael_: originally I tried the fixed width, which has the nice traversal behaviour, but crap visual appearance. 
<michael_> ah; so this is more of an import behavior things.
<michael_> I saw that the fields defaulted to an N space-char string ;->
<caolan> michael_: i.e. layout wrong, so the input field was the best I could do.
<caolan> michael_: yes. fixed with, guessing at len etc is a total failure layout wise, worse is the multiline behaviour.
<caolan> michael_: so input field is the best option, and I'm sure I logged a feature against UserExperience or OS for tab traversal/direct input for the input fields, or for a new field which operated the ms-way
<michael_> caolan: so we trade ergonomics for layout ?
>caolan< I'd hate to get the user in a really bad mood,
>caolan< this is for the proabation form for a US state :-)
<caolan> michael_: yes. the "fixed width" form control is actually a 1-1 mapping to the VBA input box, which is what the fixed width should be restricted to
>caolan< "ARGH - no tab!" "you're all going down forever"

<caolan> and vice-versa I can quote the german tax office about the problematic layout in the other case :-)
<michael_> haha,
<michael_> sigh - so there is no way to fix it,
<michael_> beyond re-working the document to use fixed-width fields,
<michael_> s/fields/form elements/
<caolan> there are 3 things in word, vba fixed, "ask" fields which popup a dialog, and these fields
<caolan> there are 2 things in writer, fixed uno control forms, and the input field which popups a dialog
<caolan> something has got to give, I hijacked the input field to serve as ask and this input field
<michael_> ok :-)
* michael_ is very slow here,
<michael_> so - starting again from scratch,
<michael_> there is essentially no feature in OO.o that will allow one a ~variable width, in-sheet-editable, tab-traversable field.
<caolan> yup
<michael_> you either get a big-square-ugly-box which is tab-traversible, or a nasty-pop-up-ergonomic-nightmare ?
<caolan> yup
<michael_> s/square/rectangular/
<michael_> neat :-)
<michael_> thanks for the insight,
<michael_> .
<caolan> perhaps adding a "next" button to the input field to go from input field to the next one without pain would be useful
<caolan> there's precedent in other fields I think
<michael_> I imagine, doing this generically is hard, inasmuch that the layout logic is much more complex for the in-doc-editable thing ?
<michael_> sure;
<michael_> but - grief; that pop-up dialog is sooo ugly,
<michael_> :-
<michael_> :-)
<michael_> man months for clueless me to fix this problem ?
<caolan> yeah, the in-doc thing is just a graphic/object, a big stupid square. fine for some small things like fill in x chars, but disasterous for free form text
<caolan> depends on what you want to do, add a next button -> easy, add a new field like the input box would be reasonably easy, but there are no other fields I think which are directly editable, so there's probably dragons there
<michael_> right;
<michael_> so - 2 months ?
<caolan> not a bad guesstimate I guess, oh yeah writer specific. Though worth seeing if excel has the same form fields, there was some overlap I heard at one stage
<caolan> i suppose there's some possible hack option with allowing tab traversal in a readonly document to include this type of field, and invoking the dialog on a keystroke when on such a field
<michael_> yes; that might fly,
