Re: Grouping UI elements
Hi Stuart, I think the problem is not with the used container (GtkBox or GtkGrid), but there is no a simple way to specify border to a container widget or to a custom PushButton and so people who implemented that two buttons were forced to use workarounds (GtkBox in GtkBox) to add the desired white, thin border (actually that is a white background which is partially covered with the inner GtkBox's green background). On the sidebar I don't find any similar custom pushbutton so I don't think it helps. Regards, Tamás ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Grouping UI elements
2014 Január 16, Csütörtök 14:43 GMT dátummal, Caolán McNamara ezt írta: > On Wed, 2014-01-15 at 14:25 +, Tamas Zolnai wrote: > > Main problem is that the 'Help' and the 'Extensions' buttons on the > > Start Center are in different GtkBoxes and so arrow key traversal > > doesn't work between them. > > So, actually containers are "invisible" to cursor traversal. So on > pressing "right" when the focus is on the Help button the Extension > button *is* considered as a candidate but is rejected because it has its > WB_GROUP bit set to state it's the start of a new group. > > The WB_GROUP bit on the button comes about because the containers are > not "invisible" to the PushButton *ctor* which checks if the preceding > window of its parent is a button and if it then defaults to grouping > with it and if it is not a button defaults to setting itself as the > start of a new group. > > So the trick to toggle off the WB_GROUP bit of the second button so that > when the "transparent" cursor traversal happens then it will allowed > to be part of the group starting with "Help" > > I've done that now with > http://cgit.freedesktop.org/libreoffice/core/commit/?id=9290998442166fae70431ee98aa9eb019bad24b3 > nBits &= ~WB_GROUP unsets the WB_GROUP bit and nBits |= WB_NOGROUP sets > the nogroup bit which suppresses vcl from resetting WB_GROUP again > > > Second I pick up "member_of" property and > > Window::SetAccessibleRelationMemberOf() method which is used not for > > only RadioButtons but for other elements too. For example: > > http://opengrok.libreoffice.org/xref/core/cui/source/dialogs/hlinettp.cxx#93 > > (an image button related with a fixed text). > > The manual calls of "SetAccessibleRelationMemberOf" etc are basically a > pre-widget layout hack to fake a hierarchy for accessibility. e.g. to > manually set all the widgets that visually appear to be subelements > under a FixedLine title as children of the fixedline. That generally all > goes away with the widget layout in favour of a VclFrame that contains > those widgets and we then delete the "SetAccessibleRelationMemberOf" > calls. (Similarly the manual SetAccessibleRelationLabeledBy stuff is > either a simple Mnemonic widget target for a label (or entered into > the .ui a11y section if the label isn't a "true" label but something > like a checkbox and doesn't have the feature to set a mnemonic target) > > > So secondly that came in my mind to modify the corresponding > > Window::ImplDlgCtrl() method to take account of member_of relation in > > case of arrow keys. > > ImplDlgDtrl is so horribly complicated, as is the rest of that family of > functions that I'd rather not touch them as much as possible :-) > > C. Ok, thanks for all this information and the commit. :) Tamás ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Grouping UI elements
On Wed, 2014-01-15 at 14:25 +, Tamas Zolnai wrote: > Main problem is that the 'Help' and the 'Extensions' buttons on the > Start Center are in different GtkBoxes and so arrow key traversal > doesn't work between them. So, actually containers are "invisible" to cursor traversal. So on pressing "right" when the focus is on the Help button the Extension button *is* considered as a candidate but is rejected because it has its WB_GROUP bit set to state it's the start of a new group. The WB_GROUP bit on the button comes about because the containers are not "invisible" to the PushButton *ctor* which checks if the preceding window of its parent is a button and if it then defaults to grouping with it and if it is not a button defaults to setting itself as the start of a new group. So the trick to toggle off the WB_GROUP bit of the second button so that when the "transparent" cursor traversal happens then it will allowed to be part of the group starting with "Help" I've done that now with http://cgit.freedesktop.org/libreoffice/core/commit/?id=9290998442166fae70431ee98aa9eb019bad24b3 nBits &= ~WB_GROUP unsets the WB_GROUP bit and nBits |= WB_NOGROUP sets the nogroup bit which suppresses vcl from resetting WB_GROUP again > Second I pick up "member_of" property and > Window::SetAccessibleRelationMemberOf() method which is used not for > only RadioButtons but for other elements too. For example: > http://opengrok.libreoffice.org/xref/core/cui/source/dialogs/hlinettp.cxx#93 > (an image button related with a fixed text). The manual calls of "SetAccessibleRelationMemberOf" etc are basically a pre-widget layout hack to fake a hierarchy for accessibility. e.g. to manually set all the widgets that visually appear to be subelements under a FixedLine title as children of the fixedline. That generally all goes away with the widget layout in favour of a VclFrame that contains those widgets and we then delete the "SetAccessibleRelationMemberOf" calls. (Similarly the manual SetAccessibleRelationLabeledBy stuff is either a simple Mnemonic widget target for a label (or entered into the .ui a11y section if the label isn't a "true" label but something like a checkbox and doesn't have the feature to set a mnemonic target) > So secondly that came in my mind to modify the corresponding > Window::ImplDlgCtrl() method to take account of member_of relation in > case of arrow keys. ImplDlgDtrl is so horribly complicated, as is the rest of that family of functions that I'd rather not touch them as much as possible :-) C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Grouping UI elements
Tamás, As you look at adjusting the UI grouping of the 'Help' and 'Extension' buttons, a currently annoying aspect of the Nested GtkBox's used is that each level of the box gets picked up and announced by screen reader AT. Although not set to focus, each GtkBox seems to get picked up as empty "White space", at least on the NVDA (2103.2) screen reader. It doesn't seem as annoying with the GtkGrid layout of the tool bars, buttons and menus for panels in the Sidebar. There does seem to be UI customization of the buttons there. Is that maybe a possibility for an adjustment of the SC UI? Stuart -- View this message in context: http://nabble.documentfoundation.org/Grouping-UI-elements-tp4092336p4092438.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Grouping UI elements
Hi Caolán, I'm working on part of this bug: https://bugs.freedesktop.org/show_bug.cgi?id=71764. Main problem is that the 'Help' and the 'Extensions' buttons on the Start Center are in different GtkBoxes and so arrow key traversal doesn't work between them. Nested GtkBoxes are necessary for special effect (thin border around the buttons) which I can't replace with a working solution with the same appearance. So I tried to find a way to solve this problem: - First I found a "group" property with which arrow key traversal can be specified explicitly but it just work for RadioButtons. Maybe it can be extend to other buttons, but RadioButton groups has a special meaning (only one item of the group is enabled), so I'm not sure it make any sense for other type of buttons. - Second I pick up "member_of" property and Window::SetAccessibleRelationMemberOf() method which is used not for only RadioButtons but for other elements too. For example: http://opengrok.libreoffice.org/xref/core/cui/source/dialogs/hlinettp.cxx#93 (an image button related with a fixed text). So this property can use for other UI elements, but this relation doesn't affect the arrow key traversal. So secondly that came in my mind to modify the corresponding Window::ImplDlgCtrl() method to take account of member_of relation in case of arrow keys. - The third and simplest one to override BackingWindow::Notify() method (BackingWindow implements of Start Center) and handle arrow keys. I can keep at this third solution, but maybe the need of adding groups is not a unique problem. So I'd like to ask some suggestions about what would be the best way to fix this bug, in your opinion. Thanks, Tamás ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
