[Libreoffice-ux-advise] Merging Calc's label range functionality with named range.

Kohei Yoshida kohei.yoshida at suse.de
Thu Jul 18 05:25:45 PDT 2013


On 07/18/2013 08:09 AM, Eike Rathke wrote:
> Hi Kohei,
>
> On Wednesday, 2013-07-17 20:29:06 -0400, Kohei Yoshida wrote:
>
>> I'd like to merge Calc's label range functionality (which you can
>> find in the menu at Insert - Names - Labels) with named range
>> functionality. The named range functionality is found at Insert -
>> Names - Define/Manage/Insert. Also, the Create menu item in the same
>> menu sub-tree is also a part of the named range functionality.Here,
>> what I basically mean by "merging" is to remove this functionality
>> and provide some rudimentary mapping to the named range when
>> importing legacy documents that use this functionality.
> As I see it the Label functionality currently can't be replaced by named
> expressions (ranges):
>
> * The actual label name displayed is taken from a cell's content,
>    formula expressions using a label automatically change their display
>    label names whenever that cell content is changed.
>    * This is not possible with named ranges.
Sure. But is this *that* important to users?  To me the whole label 
range implementation is such a duplicate functionality for very little 
marginal difference, and I'm not really sure if that difference even 
matters.

>
> * One label names exactly one row or one column, expressions or
>    multi-column/row ranges are not possible.
>    * The named expressions dialog could restrict that though.

I don't see how that restriction could be useful.  You can define one 
column / one row only named ranges (or database ranges for that 
matter).  Is there a use case where having this restriction is useful in 
real life?

>
> * The label name can include spaces and other arbitrary characters that
>    in a formula expression would have special meanings, using such a name
>    in an expression is possible by enclosing the entire label name in
>    single quotes. A label name can even be a string that otherwise would
>    be a cell reference.
Yes.  And the fact that this can be a string is actually very scary to 
me.  This potentially makes tracking references very difficult without 
sacrificing performance.  Dropping it would enable us to optimize it 
further.

>    * A named range currently has to consist of alphanumeric+underscore
>      characters and can't resemble a cell reference.
>    * ODFF does provide means to store usage of such non-simple names
>      though with $$SingleQuoted but we need to implement that in the
>      formula compiler (anyway), see
>      http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part2.html#__RefHeading__1017964_715980110
>
> Furthermore we probably could use exactly the Label functionality for
> the GSoC "Enhanced Database Ranges" Table feature when it comes to
> in-Table formula expressions adressing the Table's rows or columns.
> Actually it would be necessary to support identical label names for
> different Tables (ranges) within one sheet, again this is not possible
> with named ranges.

I'd rather we extend the database range code to support these missing 
bits rather than piggybacking on top of the label range code.  I don't 
see it as a reason why we need to keep label range.

Kohei



-- Kohei Yoshida, LibreOffice Calc hacker, SUSE.


More information about the Libreoffice-ux-advise mailing list