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


Hi Markus,

officially, I'm not at the computer anymore :-) Therefore I'll try a
quick reply ...

Am Montag, den 24.10.2011, 22:53 +0200 schrieb Markus Mohrhard:
2011/10/24 Christoph Noack <christoph@dogmatux.com>:
Am Montag, den 24.10.2011, 01:49 +0200 schrieb Astron:
[...]
From the technical point of view I don't like that idea. I think
without loosing too much performance we can only synchronize two
entries: either table-model or selected element- table. But then we
have a big problem how we get the model into that. The problem behind
that is that we should not change the model for every changed
character while typing a longer entry. I think changing the name
forces us to delete the old name and insert a copy with the new name
and changing the expression forces a recompilation of the formula.

Dumb question - what does "loosing performance" mean here? Do you think
it might work if the table is updated after (one example) 300 ms of
non-activity of the user (who stopped typing when changing the name)?


So why the separation ... my aim was to let people easily and quickly
add a new range name (there is a shortcut for calling that dialog). This
Define Name dialog should only use very few screen space. The Manage
Names is meant for organization / advanced use (non-modal).

Originally, I even wanted to provide a simple way to switch from the
Define Name dialog to the Manage Names dialog ... but I had to change
the Manage Names dialog (so that Adding / Editing names becomes more
clear), so that this doesn't work anymore.

However, I still think that separation makes sense.

Why don't we use this dialog for add and modify. I think we had that
idea in our inital discusion in Munich. That would make it clear when
we change something and we still have table and model synchronized.

That's true ... but managing ranges does imply rather common changes
like the range or the name of the range. At least Microsoft added a
"shortcut" to rename items - I assume they did run into the same issue.
The shortcut is an entry like featuring own accept/reject buttons.
Something I had hoped to avoid...

Some more core behavior:
     * If the user wants to add a new name from the Manage Names
       dialog, then we now go to the "Add Names" dialog (that makes
       adding new names really clear).
     * If the user changes a name / expression in the Manage Names
       dialog and this entry is invalid ...

Can we restrict the characters that can be entered to the valid ones?
Pressing an invalid key could simply result in nothing, except for
maybe a slightly annoying beep (and non-modal information).

Oh, my colleagues would love to have such a beep when working in an
open-plan office ;-)))

As far as I know, it is currently not possible to know the characters in
advance, because the valid characters are influenced by localization
settings and some other stuff. We may only know that "something" is
wrong - any input has to be evaluated by the expression parser.

I think I already implemented somenthing in this direction. I think
the Add and the modify button are only enabled if the name is valid. I
still think that allowing all characters and showing a warning that
some characters are not allowed is better than too much magic that
nobody understands.

Do we know the characters being not allowed in advance? In my statement
above, I guessed we don't know them ... that was my understanding in
Munich.

Invalid entries in the expression line are much
harder to detect. I think these errors can only be detected if we
compile the formula.

How long does that take usually / worst-case? (just curious, I need to
learn some new aspects)

[...]
Yes. And the change should be revertible with an Undo button (is that
what the "Back" button is for?).

Yes. I assumed that people might run into problems rather often, so Undo
triggers (guess!) Undo. I placed it within the dialog, since this kind
of "non-modal" dialog is rather seldom in LibO. Maybe it is not needed
in the long-run.


I like the undo inside the dialog much better that using global undo
for that. The advantage of the old range name undo was that it just
saved the state before and after executing the dialog. That made only
one undo entry for several changes. Now we would have maybe 20 entries
that are only created because we added range names or modiefied some
of them.

Okay, I need to think about that ... Undo is sometimes a bit neglected
and is handled very differently.

[...]
Today we do have two options:
     * Insert one: the name is inserted (and if the user doesn't edit
       the cell, then the content gets replaced)
     * Insert all: a list of all names and their ranges gets inserted
       (I propose the same behavior for multiple selected items)

Should we really keep the old behaviour for insert one? I know that as
soon as I get the dialog non modal it might work but I don't see the
use of the old behaviour then.

I understood that to be an important use case ... from our
discussions :-) Do you think people don't need to insert single range
names in formulas?


     * We could get rid of the "Modify" button -> improves the number
       and meaning of the buttons

Good. In the current interface it is used confusingly (not that there
isn't precedent for this in other LibO dialogues – colour options, I
am looking at you!).

;-) Yes, the "Add" and "Modify" is a pain ... especially in combination
with a list / a matrix of already existing elements that get changed.
That's why I thought about multiple use cases, so that any change is
"Modify" and adding is made a separate step.

I'm a bit lost here. I don't know what aou are talking about.

Then please don't consider this section too much - but there is a common
pattern of having elements (colors, range names, gradients) and the need
to modify / add / delete elements quickly. Separate dialogs (see above)
make it too slow, input elements plus modification buttons cause issues
(because you always screw up one or two use cases users will need).

[...]

Okay, have to go ... thanks for the nice discussion!

Cheers,
Christoph


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.