[Libreoffice-ux-advise] Input bar UX

Kohei Yoshida kohei.yoshida at suse.com
Mon Dec 12 08:44:08 PST 2011

On Mon, 2011-12-12 at 15:24 +0000, Noel Power wrote:

> On 12/12/11 14:00, Jan Holesovsky wrote:

> >    - jumping "Name Box" (and actually the icons too, but not that much)
> >      when you switch from and to large input bar
> This annoys me too, there is a hack in the toolbar code to prevent it 
> from doing what toolbars want to do which is display items in the middle 
> of the bar, the behaviour you see is the side-affect of this hack. I can 
> try and do it better, then again myself an Kohei discussed maybe 
> subverting the toolbar layout ( or lackof ) in a future implementation 
> step, I mean to return to this in anycase but probably this is not my #1 
> to fix at the moment

Yes.  So this is a technical limitation of using the ToolBox class from
vcl to manage the horizontal layout of the controls (inherited from the
old implementation).  ToolBox can only manage controls horizontally, but
we have little control over how it manages them vertically.

Noel and I discussed this, and the plan is to create our own container
Window to replace ToolBox in order to have more control over the
vertical placement of the child controls, to fix issues like this.  But
since doing that would be quite invasive, we may have to forgo that for
3.5 and wait until 3.6.  It's up to Noel. 

> >
> > - behavior of Ctrl-Enter
> >    - when in single line mode, and you hit that, it should automatically
> >      switch to the large input bar - now it just lets you with an empty
> >      line, and you see the entire picture only in the sheet
> personally I think it is reasonable behaviour, after you hit cntrl-enter 
> the inputbar still displays your current edit. Also, you can scroll 
> through the lines with the mouse. Plus the user does decide to display 
> one or (more) lines ( via the collapsed/expand button ). Even if you 
> expand the toolbar via switching to multiline mode you can also easily 
> exceed the display space again. Worth noting too that switching between 
> multiline and single line mode will resize the bar to the last expanded 
> size which could be as little as 2 lines wide so you could exceed that 
> vertical limit very quickly. So.. expanding might only give you very 
> temporary relief before you need to expand the bar even more ( via 
> dragging with the mouse ). This doesn't make auto switching that 
> sensible ( unless there is some extra heuristics there, then of course 
> probably people will be confused as to why sometimes it autoexpands and 
> sometimes not ;-) )

Yeah.  To me, the way it behaves currently may not be perfect, but is
reasonable & it was a conscious decision that we (Anurag and I) made
before Noel took over, based on the technicality (it makes the
implementation simpler) and the way our competitor behaves.  Of course,
if there is room for improvement I'm all for it, but different people
may see different optimal behavior for this, so it would be good to have
a good, detailed analysis from the UX side before making any changes.

> >
> > - behavior of the Bold / Italics / etc. buttons
> >    - when entering text in the large input bar, and hit the Bold etc.
> >      buttons (that are just above that), the formatting is shown only in
> >      the sheet, but not in the input bar (is that actually expected due
> >      to some implementation limitations?)
> again this is afaiks intentional and matches excel behaviour, there is 
> most likely some real reason why we don't support that ( probably 
> because inputbar is mostly for formulae and not writing prose ) Maybe 
> Kohei might know better

AFAIK there is no real reason except that we simply inherited this
behavior from the old implementation.  Excel has the same limitation
interestingly, but that has nothing to do with our decision (or lack

There may be a real reason why this limitation existed, but I'm not
aware of that at the moment.


Kohei Yoshida, LibreOffice hacker, Calc

More information about the Libreoffice-ux-advise mailing list