Issue 72191

Hi Matthias,

please comment on this one and proceed as needed.

Frank

Dear developers,
any progress with this issue?
Thanks a lot for your attention.

move target from 2.x to 3.0

reassign to fl, set target 3.x, any volunteer to provide a proposal ?

As a simple proposal: in main menu
[View] - [Addressing (or Notation?)] - then radio-mark-checked submenu:
Classic OOo
Excel A1
Excel R1C1
etc

Created attachment 51170 [details]
Proposed UI selector for addressing type.

So could somebody from developers take a look at my spec and either comment or 
proceed with implementation?
Thanks a lot!

WBR,
KP.

I strongly object to the names of the cell reference styles ("Absolute",
"Relative (R1C1)", "A1", "Lotus") because they do not make the differences among
styles clear.  It is meaningless to describe styles as "absolute" or "relative"
(and hence the third sentence of the first paragraph of section 1 is wrong)
because an absolute or relative reference can be written in any of the styles
(e.g., $A$1, A1, R1C1, RC).  "A1" and "R1C1" are good; the names additionally
need to distinguish among the OOo, Excel, and Lotus variants of A1.  How about
"OOo A1", "Excel A1", "Excel R1C1", and "Lotus A1", along the lines of pmike's
suggestion?  Or the menu could give an example in each of the styles (like the
comments in "enum Convention" in source file "sc/inc/address.hxx"), followed by
"(OOo)", "(Excel)", or "(Lotus)" as appropriate; the full-generality examples
may be helpful to some users but overwhelm others.

Also, I suggest moving the choices into a submenu "Format -> Sheet -> Cell
Reference Style" so that it is clear to users what they are choosing.

I second that the naming (Absolute, Relative, ...) doesn't make sense. It should
be A1 vs. R1C1 instead. As the current implementation differs between OOo_A1,
XL_A1 and XL_R1C1, where  XL_... includes usage of the '!' sheet name separator
as well, technically only these could be the options offered at UI. The Lotus
style isn't much more than experimental. I also think this should not go into
the Format menu, the options are not related to formatting. In fact it shouldn't
go into any of the main menus, these easily get too crowded, and it is not an
option you'd need to switch frequently. IMHO it should go somewhere under
Tools.Options.Calc

>IMHO it should go somewhere under Tools.Options.Calc

I agree with er here.  Perhaps Tools.Options.Calc.Calculate would be a perfect
place for this?

Created attachment 51460 [details]
Updated to accomodate requests

Please see updated spec (sorry for colors and fonts - could not match on 
mockup).
If possible, could somebody specify i-Team Members?
Thanks a lot.

Two nits in the updated spec:
- The first entry under "Suggested accelerator keys" should say
"OpenOffice.org", not "OpenOffice".
- In section 3, "Configuration", it isn't clear which style "standard
addressing" refers to.  If it's OpenOffice.org A1 style, say that.

Also, I'm wondering why OOo Calc has Excel and OpenOffice.org variants of A1 but
only one kind of R1C1, which (based on the comment in address.hxx) seems to be
the analogue of the Excel A1.  I prefer R1C1 on its merits and don't care
personally about consistency with Excel; thus, if there were an OpenOffice.org
R1C1, I would use that.  Does the lack of an OpenOffice.org R1C1 indicate that
the OOo team has decided to adopt the Excel formats as recommended and just keep
the OpenOffice.org A1 for OOo backward compatibility?  If so, perhaps the
OpenOffice.org A1 should be labeled "Classic" or even "Legacy".

The third sentence in Section 1, "Detailed Specification", is still wrong.  It
should say "A1 or R1C1", not "relative or absolute".

Created attachment 51469 [details]
Updated

The updated specification looks good to me.  There are a few typos that don't
affect the meaning: "R1C1addressing" in the Abstract needs a space, the
Migration section needs a period, and "Default  setting" in Configuration has an
extra space.  I don't know if you care about fixing them.

@hashproduct:

Let's put it this way.  OO.o A1 style is what we have natively in OO.o today, so
we're stuck with it.  Excel A1 style is what the majority of spreadsheet users
are used to, so we have a good reason to support it.  The same reasoning applies
to Excel R1C1.  However, because there is no prior R1C1 equivalent address
convention in Calc, I see no reason to add such support.

If it were entirely up to me, I would just implement the Excel R1C1 without
adding yet another R1C1 style address convention just to be different from
Excel.  Lesser number of styles means lesser effort to maintain the code.

@kohei: OK.  I guess my question is which set of conventions is considered
"preferred" in current OOo Calc: Excel conventions or traditional OOo
conventions?  If OOo conventions, then it seems inconsistent not to offer an OOo
variant of R1C1; if Excel conventions, then I think the OOo A1 style should be
marked somehow as old/deprecated (even if it remains the default for best
compatibility).

@hashproduct: It is not a take-Excel-or-stick-with-OOO-style situation.  Why do
you want to pick only one convention and deprecate the rest?  Ultimately it's
not up to us to decide; if there is sufficient demand for either one it makes no
sense to deprecate any of them.  OTOH, if the majority of the users only use one
convention and don't care about the rest at all, then there is a good reason to
deprecate the rarely-used ones.  But now is not the time to make that decision.
 Quite frankly I don't know the answer to that.

@kohei: OK, I suppose it's reasonable to leave the three styles as they are for now.

Created attachment 51624 [details]
Updated spec to new selector control

kohei,
any progress?

@kpalagin: sorry I have not started it yet.  I'm on several other high-prio
issues at the moment.  I'll keep you informed.

Any news?

I'm starting to work on writing a spec for this feature.  Because this is a
little more than just implementing a R1C1 address convention, it needs to cover
broader range of topics.  So, I'll try to get it spec'ed out on the wiki page
with your submitted spec as the starting point.  I hope you don't mind me
switching to a wiki spec because that makes it easier for to update it.

Also, I'd like some input on the proposed UI.  I will attach a screenshot of the
current UI implementation in go-oo to see if anything needs to be changed before
upstreaming it.

Created attachment 55259 [details]
formula convention (syntax) option page

Changing the title to something more generic.

I'm taking ownership, and CC'ing fl.

accepting the feature.

Just FYI, there are still several known issues with the Excel A1 and R1C1 parser
that I'd like to fix before adding the UI bit.

kohei,
any news?

Thanks,
Helen

Yes, I'm still waiting for any input on my question in #desc26.  Or does no
input mean it's been approved?

Internally, we already have the implementation.  So, it's just a matter of
finding issues and fixing them (which we are already doing) & taking care of the
UI design bits.

Looks fine, IMHO.
I think you should upstream it ASAP, so that we can have it in 3.1.

Thanks a lot!
WBR,
KP.

@kohei: in #desc26 you mentioned "switching to a wiki spec", I didn't find any
though, is the attached document the spec we have?

No the spec is not there yet.  Haven't had the time.  But the question regarding
the UI is a separate matter.

BTW the spec will be at

http://wiki.services.openoffice.org/wiki/Calc/Features/Variable_formula_convention

It's still empty at the moment, but I will start filling it once I find the time.

With just 6 weeks left until Feature freeze I think we will miss 3.1 as well. 
Somethin is very wrong with the project.

@kohei:
I supplemented the spec. Please comment.
http://wiki.services.openoffice.org/wiki/Calc/Features/Variable_formula_convention

Thanks,
Helen.

@helen_russian: Looks very good!  Thank you. :-)

The only thing is that, open issues are those issues that will *not* be
addressed when this feature is introduced.  Since this issue will be resolved
once the feature is added, we can take out 72191 from the list of open issues.

But it's not critical, you can edit it out, or I'll do it when I do my editing,
whichever comes early.

Kohei, Eike,
please comment on updated spec.

Thanks,
Helen

Kohei, Eike,
taking into account that 3.0.1 and 3.1 releases are delayed by a month do we 
have a chance of having this feature in 3.1?

Regards,
Kirill.

Sorry.  I know you guys want this in ASAP, but I'm starting to doubt if we can
make it for 3.1.  This does not just involve the formula syntax, but also the
separators as well (See Issue 92056).

Looking at this thread we just had on the go-oo list
http://lists.go-oo.org/pipermail/dev-go-oo.org/2008-November/000957.html

We may need to change the UI a bit to allow toggling of localized separators. 
That will certainly delay inclusion of this feature upstream, I assume, unless I
hear otherwise from someone from Sun.

Aiya, the fine MS selection of carefully crafted separators.. Insane.

I don't see though why the separator's issue 92056 should be involved
for this Xl-R1C1/Xl-A1/OOo-A1 issue here? They can be treated
independently.

Anyway, parsing all three conventions isn't finished yet. Current
implementation of the Xl-R1C1 convention is fairly untested. Xl-A1
convention will be implemented in CWS mooxlsc for MOOXML import, which
changes also common parts of Xl-R1C1 that in turn then will be
completely untested. Any other independent feature relying on the new
address parser implementation will not make it into OOo3.1

>I don't see though why the separator's issue 92056 should be involved
for this Xl-R1C1/Xl-A1/OOo-A1 issue here? They can be treated
independently.

Yes, but they will likely share the same UI space in the configuration dialog. 
So, it's probably better to lump them together.

I am not sure if we have commercial customers for 92056, but IMHO localized 
separators are at most P4 (if not P5). 92056 does not have any votes and was 
filed 4 month ago.
OTOH, original request for R1C1 have been filed 5 years ago and collected 56 
votes which tells us that our users do need it.
Delaying R1C1 by at least 6 month just because of separators is mistake IMO.

Eike,
unless we release product the code would not get testing. Our users got used 
to issues, so a bit of untested code in x.y.0 should be fine and will provide 
required testing.

@kpalagin: As I said in #desc45 another reason this should not make it
into 3.1 is that the R1C1 parser will be completely untested then. CWS
mooxlsc will get integrated shortly before feature freeze. The R1C1
feature should be integrated early to some dev-milestone to be publicly
available for extensive testing before release.

Eike,
do we have any solid target for integration of this feature, like, say, m45, 
so that it gets testing?
Thanks.
Regards,
KP.

@kpalagin: No, there's no target for this. And what integration of the feature?
There isn't even a CWS having it implemented. Or, Kohei, am I wrong?

@er: no, you're not wrong.  There is no cws for this yet.  There are still more
issues with non-default formula syntax options in the core implementation that
I'm trying to work out.

Kohei,
any news?

Thanks,
Helen

I'll try to squeeze this in for 3.4, together with several other related
features (variable separators, and English function names).  I've just created
koheiformula04 for that.

Voting for this issue - because R1C1 cell references would be really useful.  

Not sure why this has to be a Excel compatibility mode, imho R1C1 deserves to
exist in it's own right.

on attend toujours les R1C1 (et pourquoi pas L1C1),
 pour pouvoir utiliser OO.

Also voting for this in support of RC notation, a major block for usability, not just to be like excel.  

Reset assignee on issues not touched by assignee in more than 1000 days.