Date: prev next · Thread: first prev next last
November 2011 Archives by date, by thread · List index


Hi everyone..,

Please bear with me, if this mail seems incoherent ... that might be
due to my mental state right now... And I'm sorry for the silence, but
I'd been planning to reply, but I wanted to have proper time.
In general, I still second Christoph's view.

Eike brought up a pretty good point, though:
con modeless dialog:

- marking a range in the spreadsheet can no longer automatically be
used for the expression line ( nice feature in my opinion )

Mmh, I had hoped it would still be available when e.g. editing the
expression ... click in the field, select the cell range. To me, the
"mode change to edit" is much saner communicated than today.

Thinking through Christoph's proposal, I can kind of see how it might work:
Giving the expression field focus would put the spreadsheet part of
the window (cells + headers + tabs) in a mode where it behaves like it
does in today's modal dialogue. If you then select any part of the
content, it would be used as the range expression (immediately after a
selection is made, the expression field would lose focus[1], the
content area would react normally again). Or, if you select any part
of the main window/dialogue "chrome" [2] (all of it still shown as
active), the expression input field would lose focus.
Does that compute? Is that too complicated for users?

For Markus's use case (see mail above), this still wouldn't cut it
(but see below). I think we all can agree that this will never be
possible in a modal dialogue.

However, Markus's current use also wouldn't work with today's
mock-ups, because we have integrated the "Insert" functionality into
the dialogue. "Insert" needs to have a cell to insert the range name
into and this cell must be selected somehow prior to inserting. If the
expression line always got the focus if any spreadsheet cell was
selected ... there'd be trouble.


By the by, as you've started doing pro/con lists (very helpful – a few
of things at least I hadn't thought about before):
one more pro:
Inserting should work much better. With a modal dialogue, inserting
will always be pretty awkward, because you can't build an expression
with the range inside a spreadsheet cell easily. Also, we'll have to
discuss what happens when a range name is inserted: should the "Manage
Names" window close (from the user's perspective that might be
unexpected) or should it just stay put (in the case where the user
wants to just quickly insert a name, less efficient)?

one more might-be con:
The case of multiple open spreadsheets. I think that's solvable with
enough code, but initially it might seem daunting to handle.


Quoting from Eike again:
The allowed characters are defined in ODF OpenFormula
5.11 Named Expressions
http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part2.html#__RefHeading__1017964_715980110
with the 'Identifier' EBNF and actually do not depend on localization or
separators used.

However, showing a list of characters that are not allowed is way out of
the possible, as it would encompass hundreds (or thousands?) control
characters and separators of the Unicode range. Provide a positive list
similar to the EBNF definition (but just saying "Allowed are letters,
digits and underscore and the name must not represent a cell address" or
some such for simplicity), or/and dynamically display the first invalid
character encountered.

Your positive list is pretty long even in English (would be two lines
within the notification bar) ... I'll just count that as a point pro
ignoring invalid keystrokes (I still like the idea, yes).

By the way, looking at the linked spec, I noticed that even
Christoph's proposed UI overhaul lacks a way to use external sources.
Is that by design?


In closing: I won't try to give any final opinions here. It's of
course up to Markus to decide what he wants to code. And doing the
changes in two steps might be unsatisfying initially for everyone
involved, but it'll also give us the chance to hear some feedback from
a wider audience.
I'll update both my modal and my non-modal proposals in the coming days.


Astron.


[1] I hope that wouldn't overly optimise the dialogue for the common case
[2] this term copyright Mozilla, Google 2000–2011

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.