[Libreoffice-ux-advise] Manage Names Dialog hit master

[Stefan Knorr (Astron)]

Hi Markus,

> Could you give some details how you managed that. I should at least
> confirm that this is really a gnome3 problem and not a generic one.

Hm, not really. It was an empty spreadsheet and I just selected some
cells, added them as a named range and then opened Manage Names,
pressed the Shrink button and it crashed. I couldn't reproduce it so
far.

>> In Manage Names:
>> * all outer margins should be 5 UI units wide (these are very
>> different right now)
> done

Mostly, yes, but the input fields looked too long still (I tested
yesterday afternoon for the last time).


>> * the line above the Help/OK/Cancel buttons needs to be better
>> positioned (centred between the button above and below) as well, I
>> guess it should have 5 units padding above and below it (curiously,
>> the Print dialogue nominally seems to use an 8 units thick line..?)
>
> Do you really suggest that this line should be 8 units thick? I think
> that the 2 or 3 units I use at the moment look nice.

Not really. I believe, the reason why it is often 8 units thick in
other dialogues is that the these lines are the same lines that are
used in LibO to separate sections of dialogues, for this, there's text
added to the line (which apparently need 8 units of height). I guess,
the lines were often simply copied/pasted in src files (it doesn't
hurt, the lines always seem 2px high).


>> * the tick boxes below the Range Options expander should be a bit
>> closer to the expander [snip]
> I hope that it is better now. This part is a bit tricky because some
> parts need to be solved in code and it seems that the units do not map
> nicely.

Looks good, yes.


>> *Other UI problems:
>> ** tabbing through the Manage Names dialogue seems quite illogical, as
>> pressing Tab often to goes backwards (ideally it should go top left to
>> bottom right while respecting logical sections of the dialogue) – I
>> didn't check Define Names, sorry
>
> I know, I don't really know how the tab order is defined through the
> src file. I need to dig into that next week

Maybe that's defined by the numbers after VCL element names in the
header file..? (Just a wild guess, haven't checked at all.) Or maybe
just the sorting of the elements in the src file..?


>> ** the non-modal information bar needs a yellow background colour, the
>> current Notes background colour, although very light, would probably
>> suffice for the moment, but we could also go with straight yellow
>> (#FFF000) or maybe use a system colour...
>
> I still have problems applying colors to the elements. I think we
> should not hardcode colors but use the style colors.

I don't really think I can help here. One thing I did find quite often
in src files was an attribute called MaskColor [1], I am unsure,
though, what it does. It is used frequently on ImageButtons and is
usually #FF00FF which leads me to believe that the given colour is the
one that should be made transparent in the associated bitmap (in the
dark ages, before alpha transparency came along).
On the whole, I agree with you, in that the colour shouldn't be
hardcoded, but I think it is better to hardcode it than to not use any
(special) colour at all.


> The problem should now be solved. You can click at a separator in the
> header bar and drag it. then the size of the column should be
> increased. That did not work until saturday.

Good to hear it does now.


Great work, btw.

Regards,
Astron.


[1] http://opengrok.libreoffice.org/xref/core/dbaccess/source/ui/misc/WizardPages.src#158