No subject

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.

>
> 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.

>
>> > Some more core behavior:
>> > =A0 =A0 =A0* If the user wants to add a new name from the Manage Names
>> > =A0 =A0 =A0 =A0dialog, then we now go to the "Add Names" dialog (that =
makes
>> > =A0 =A0 =A0 =A0adding new names really clear).
>> > =A0 =A0 =A0* If the user changes a name / expression in the Manage Nam=
es
>> > =A0 =A0 =A0 =A0dialog 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. Invalid entries in the expression line are much
harder to detect. I think these errors can only be detected if we
compile the formula.

>
> However, ignoring key presses might be possible in this case (first
> checking, then ignoring), but I don't like that - it doesn't tell the
> user what's wrong. And, many people do not look at the screen, so that
> defining a name might be a surprise.
>
> Finally, incorrect ranges (e.g. "A1:B") have to be covered as well.
>
> But, will think about that ... maybe there is a better solution.
>
>>
>> > =A0 =A0 =A0* The user should be always able to exit the current change=
 with
>> > =A0 =A0 =A0 =A0ESC (restores last entry before the started to edit the=
 field).
>>
>> 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.

>> > =A0 =A0 =A0* If the user selects more than one entry, then ...
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0* we deactivate the text fields (maybe even=
 the Scope
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0field)
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Paste (or Insert, no terminology decision=
 yet) inserts
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0all selected items.
>>
>> I hope I understand this correctly: it inserts the selected range
>> names into the currently selected cell in a format like
>> "Cappuccino;Chocolate;Cookies"?
>
> No.
>
>> Then, I see two problems:
>> # "Paste" shouldn't overwrite text when the current cell was
>> double-click/F2-edited before opening the Manage Names dialogue
>> (otherwise formulas might be deleted). Is that workable?
>> # How is it possible to handle inserting multiple range names
>> correctly? Some format work in certain formulas and when using certain
>> ranges, some don't, i. e. neither "Cappuccino+Chocolate+Cookies" nor
>> "Cappuccino;Chocolate;Cookies" is possible in all cases. Is clever
>> guessing based on existing formulas possible here?
>
> Today we do have two options:
> =A0 =A0 =A0* Insert one: the name is inserted (and if the user doesn't ed=
it
> =A0 =A0 =A0 =A0the cell, then the content gets replaced)
> =A0 =A0 =A0* Insert all: a list of all names and their ranges gets insert=
ed
> =A0 =A0 =A0 =A0(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.

>
>> > =A0 =A0 =A0* We could get rid of the "Modify" button -> improves the n=
umber
>> > =A0 =A0 =A0 =A0and 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 =96 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.

>
>> > =A0 =A0 =A0* Since we need to "reserve" space for the "Information Tex=
t"
>> > =A0 =A0 =A0 =A0above the edit entries, we now can explain the user tha=
t he
>> > =A0 =A0 =A0 =A0might also use formula expressions (if he adds a named =
range).
>> > =A0 =A0 =A0 =A0For the rest, I strongly suggest to keep the common nam=
ing (for
>> > =A0 =A0 =A0 =A0Calc and Excel users).
>>
>> Cool. But about the mock-up wherein two items are selected: you may
>> beg to differ, but I don't find "2 range names selected" to be very
>> useful information. I think this one could go.
>
> Hehe, I'm 60% for adding such information, because: a) the space is
> there (without layout management), and b) we can explain the user that
> several items are selected (he might not see that, since some items
> might be hidded due to scrolling).
>
> However, if we use the "balloon" style non-modal messaging, it needs to
> go anyway.
>
>
>> > =A0 =A0 =A0* Once we do have non-modal messages, the Information Text =
line
>> > =A0 =A0 =A0 =A0isn't needed anymore. Same info will be provided via me=
ssage
>> > =A0 =A0 =A0 =A0balloons (or similar).
>>
>> I find the majority of balloons to be aesthetically rather less
>> pleasing and will fiercely defend the humble yellow-coloured
>> information bar against attacks such as your own. :)
>
> Touch=E9! ;-)
>
>> > A final note: Please be aware that this is something new to
>> > LibreOffice ... we currently don't have such a dialog concept, althoug=
h
>> > I find it very promising. What do you think?
>>
>> Like it.
>
> Mmh, now let's ask the other 24.999.999 users ;-)))
>
> Astron, thanks for your feedback ... I really like to have your input
> (be aware that it sometimes needs a day until I know how to implement it
> properly).
>

Regards,
Markus