UI: Table Text Flow Break shows only 1 option button. Should be 2
Steps to Reproduce:
1. Open Writer
2. Insert a table
3. Table -> Properties -> Text flow tab
4. Check break -> Notice one. Notice before selected
5. Press OK
6. Table -> Properties -> Text flow tab
7. Notice column to be selected to
Only one selection bullet
Should be 2 (as previous)
User Profile Reset: No
Version: 126.96.36.199.alpha0+ (x64)
Build ID: f845f74afaf087a46c82ee4209e29caca0980b71
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win;
Locale: nl-NL (nl_NL); UI-Language: en-US
author Justin Luth <firstname.lastname@example.org> 2019-06-15 22:15:32 +0300
committer Justin Luth <email@example.com> 2019-06-27 06:09:43 +0200
commit d35171456bc230efdaa9426da1398b2db7fa0df8 (patch)
parent ae823e4633a76d13cebc6432b9e44b9b2862326b (diff)
tdf#125609c10 vcl/button: enforce only one radio selected on init
This patch does not solve the main LO 6.2 problem in bug 125609,
but fixes the related problem from comments 10/11.
This patch fixes two different scenarios:
1.) Sometimes buttons could fall through the other safety nets and
have multiple radio buttons selected in a single group at display time.
Since ImplInitStyle can be called multiple times for the same
button, ensure that once everything is imported (IsRadioCheckEnabled)
that any calls to this double-check that only one button is enabled.
First come, first served if by programmer error multiple are marked as
IsChecked in the same group. This problem existed pre-LO 6.2,
so it had nothing to do with tabstops specifically.
2.) This patch specifically fixes the 6.2 regression with the
Grammalecte extension Graphic Options dialog box. In this case
Dialog::GrabFocusToFirstControl ended up being treated as a "click"
on a tabstopped, unchecked radio, because setting the state
never called the SetState/Checked function, but only the Init,
and so the uncheckAllOther function never removed any tabstops.
Adding CC to Justin Luth
That patch was backported to 6.3.
Can you post a screenshot or something? I'm not replicating any missing radio buttons with Ubuntu 20.04/LO 6.4. I always see all four page/column before/after.
Created attachment 160396 [details]
Sorry, it's about being pre-selected. Comparison 188.8.131.52 and 7.0
Doesn't happen for me in Ubuntu 16.04 with compiled master either. Marking as Windows only.
The Page and Before radio buttons should not be grouped together in anyway because Page toggles with column and Before toggles with After.
This is probably another instance of bug 128625.
The identified, problematic commit is now unnecessary (but should still be correct) since the specific problem it was trying to correct has been reverted.
Proposal: just completely remove the patch from LO 6.4, so that stable is not affected by any problems that this has unmasked that haven't been caught yet.
https://gerrit.libreoffice.org/c/core/+/93522 Revert "tdf#125609c10 vcl/button: enforce only one radio selected on init"
But do not revert in master so that these UI config problems will be exposed and can be fixed up. The UI config file in question here is sw/uiconfig/swriter/ui/tabletextflowpage.ui
I don't have a development environment for non-GTK3, so I hope Caolán can replicate this. My guess is that because both page and before do NOT specify a group, that they are grouping with each other at the vcl button level. (But what do I know about UI...)
<object class="GtkRadioButton" id="before">
+ <property name="group">before</property>
Should be fixed in LO 6.4.5 with today's revert of comment 1's patch.
This still needs to be fixed in master.
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":
Resolves: tdf#132581 allow disabling the auto-group RadioButton feature
It will be available in 7.0.0.
The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
I think the .ui file itself is ok in the sense that the group is defined ok in it, I think the problem arises during the parse when various things are set on the button before the group is setup the button does the legacy fallback "look for contiguous buttons and assume its a group" thing which we don't want it to do cause we're using explicit groups
It's ok now. The same are check before and after the OK.
Version: 184.108.40.206.alpha1+ (x64)
Build ID: 0e3196c49b84651df20b770d5cd7f0bbb19dfc40
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win;
Locale: ro-RO (ro_RO); UI: en-US