Hi, Context for the ML: we have reverted
commit 2d4b87f0c1bfd97185a89c18d5b7680d11a958d6 Author: Michael Stahl <[email protected]> Date: Mon Aug 18 18:08:37 2014 +0200 ODF export: don't write invalid "group-name" attribute Radio buttons are grouped via their "form:name" attribute already. Change-Id: I9f8b27a2904d947c3d4665495d36961e3e41d2c6 in master and libreoffice-4-4 because: 1) It made the change also for "dlg:group-name" to property "Name" which maps to attribute "dlg:id", where there was no reason for it, and where it broke hard since the implementation assumes and checks unicity of the name (as the XML attribute name "id" suggests). dlg: is user (script) dialogs (the thing managed by Tools / Man 2) It also didn't correctly plan for backwards compatibility in forms (its target) at several levels: * properly handling existing files with a form:name and a *different* form:group-name on the same RadioButton, leading to RadioButton supposed to be in the same group that are NOT, and thus not mutually exclusive anymore. * there *must* be a way to retrieve a specific RadioButton through public API. * old scripts should continue to work This thread is to consider whether, and how exactly, we can do something like that for 4.5. The issue the reverted commit tried to fix is that *currently* in LibreOffice RadioButtons (in forms *and* in dialogs), RadioButtons (that is "checkboxes" that are automatically mutually exclusive within their group) work as follows: * They have something which is displayed UI-wise, as "Name" property, like every control. It is stored in the XML as form:name or dlg:id, respectively. In both cases, it is actually also programmatically a property "Name" in the Model of the control. In dialogs, this name has to be unique, and can be used to programmatically get the control object. In forms, the name need not by unique, but since it is AFAIK the most convenient / robust way to programmatically retrieve a control object (the other way is by index, which is not that stable...), I usually recommend to use unique names and retrieve controls by name. * They have something which is shown UI-wise as "Group Name" property, which is specific to RadioButtons. The current behaviour is that every RadioButton that has the same "Group Name" are mutually exclusive. Note that (for database bound controls), they do not have to be bound to the same field. In both cases, it is actually also programmatically a property "GroupName" in the Model of the control. This seems to be managed by the control container model, the corresponding interface is css::awt::XTabControllerModel Note that if a RadioButton has an empty GroupName, then it is put into a group named after itself. So if RadioButton "A" has no GroupName, but RadioButton "B" has GroupName "A", then "it works", they are grouped. In dialogs, it is stored as a dlg:group-name attribute. In forms, it is stored as a form:group-name attribute. Now, the problem that the reverted commit tried to fix is that in ODF, form:group-name does not exist, but the grouping behaviour is attached to form:name. RadioButtons that are supposed to be grouped are supposed to have the same form:name. See http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-form_radio Frankly, after giving it some thought and the difficulties it raises, my first questions are: 1) Has _any_ implementation of ODF which implements forms *ever* done it this way, conforming to the standard? 2) If not, with some luck all implementations do it like we do, and then shall we consider adapting the standard to current behaviour for ODF 1.3 rather than shoehorning ourselves into a possibly badly designed corner of the standard? About form:name see http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1417450_253892949 It says: This may be used to give a form or control element an identity, which is can be used for scripting or for submitting the content of controls. This clashes with the reuse of form:name that form:radio makes. If you "force" several controls to have the same name, how are you *ever* supposed to use the name "for scripting". You have just destroyed the value of a name, which is getting the named thing so that you can interrogate and manipulate it. I think that is a *bug* in the standard. What would it take to conform to the "form:radio" part of the standard and still have a modicum of backwards compatibility? It seems obvious to me that we have to decouple property names in our APIs and attribute names in the XML. Existing code must be able to continue using properties "Name" and "GroupName" like it always did, and it should work in the same way. The same for the "getByName" interface of control containers. But "Name" property should not necessarily go to ":name" attribute in the XML file. In the case of RadioButtons, at least in forms, it is pretty clear that the "GroupName" property would have to go to ":name" attribute. We then need some other attribute to store the "Name" property. 1) "form:id" is not acceptable, since form:id must be equal to an xml:id and xml:id has unicity requirement (across the whole XML document!) which "Name" does not currently have. Currently, form:id and xml:id are set as "control1", "control2", etc and are AFAIK not exposed in the API; I understand xml:id as *detail* of the *file* *format* (the serialisation), not part of the *data* *model*. 2) form:title is for a "tooltip" and what audio user agents are supposed to read. This seems not a good place for a "Name" there, more for a "Description". Plus I guess that this is where we already stick what the UI calls "Help text"? 3) We could stick it somewhere in form:properties. *But* what bothers me is what should happen to other controls? Does their "Name" still go in "form:name"? I'm unhappy about the difference in treatment. If we follow for other controls the same as with RadioButton, then what do we make of what other implementations put in form:name? How do we allow, for interoperability with other implementations, the user to *set* what is put in form:name? I don't see any way to have good backwards (and hopefully forwards) compatibility. Do you? In my opinion, if we follow the "form:radio" part of the standard, we don't follow (to the fullest) the "form:name" part of the standard. Except for older versions (and forks) of the same codebase as us, what other implementations do we need to interoperate with? What do *they* do? Once (if) we solve these issues, we can think about whether we align Dialog RadioButton to the Forms behaviour or not. -- Lionel _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
