Qt-interest Archive, February 2007
Good way to 'uncheck' all buttons in an exclusive QButtonGroup?
Pages: Prev | 1 | 2 | Next
Message 1 in thread
Hi,
I have a QButtonGroup with a couple of normally exclusive buttons.
According to the documentation of QButtonGroup it is not possible
to uncheck a button by clicking on it. Another one has to be
selected.
Fine, but I need to reset all buttons under certain circumstances.
Currently I do:
QList<QAbstractButton *> allButtons = _mouseButtonGrp->buttons();
_mouseButtonGrp->setExclusive(false);
foreach(QAbstractButton *button,allButtons){
button->setChecked(false);
}
_mouseButtonGrp->setExclusive(true);
I suppose most here can feel with me why I hate this.
Is there a better (correct) way to do this?
Else I'd file a feature request for Trolltech for something
like _mouseButtonGrp->resetAll() + appropriate signal.
Or is the necessity to unselect all buttons that scarce,
that no one else needed such a feature?
Guido
--
[ signature omitted ]
Message 2 in thread
On 02.02.07 14:44:51, Guido Seifert wrote:
> Hi,
> I have a QButtonGroup with a couple of normally exclusive buttons.
> According to the documentation of QButtonGroup it is not possible
> to uncheck a button by clicking on it. Another one has to be
> selected.
>
> Fine, but I need to reset all buttons under certain circumstances.
>
> Currently I do:
>
> QList<QAbstractButton *> allButtons = _mouseButtonGrp->buttons();
> _mouseButtonGrp->setExclusive(false);
> foreach(QAbstractButton *button,allButtons){
> button->setChecked(false);
> }
> _mouseButtonGrp->setExclusive(true);
>
> I suppose most here can feel with me why I hate this.
> Is there a better (correct) way to do this?
You don't need that iteration if your buttongroup is exclusive, because
QButtonGroup has a proper API to fetch the currently checked button.
> Or is the necessity to unselect all buttons that scarce,
> that no one else needed such a feature?
I guess so, after all: What happens if the group is reset and thus no
option is selected and the user goes on in the app? If this is possible
within the app its IMHO quite natural to have a None button too, it the
app can't go on afterwards you don't need to reset all buttons, but just
make sure the right default is selected.
Seriously your usecase sounds like a a usability bug in your Ui.
Andreas
--
[ signature omitted ]
Message 3 in thread
> You don't need that iteration if your buttongroup is exclusive, because
> QButtonGroup has a proper API to fetch the currently checked button.
You are right. The iteration is not necessary. Unfortunately the
setExclusive(false)/setExclusive(true) seems to be.
> > Or is the necessity to unselect all buttons that scarce,
> > that no one else needed such a feature?
>
> I guess so, after all: What happens if the group is reset and thus no
> option is selected and the user goes on in the app? If this is possible
> within the app its IMHO quite natural to have a None button too, it the
> app can't go on afterwards you don't need to reset all buttons, but just
> make sure the right default is selected.
>
> Seriously your usecase sounds like a a usability bug in your Ui.
Not really. I have several buttons, which toggle certain behaviours of
the mouse. When I start the program, none of the radiobuttons are set
and the mouse has its default behaviour. With my radiobuttons I can
now choose between certain mouse functions. I do have a 'clear' button,
which is supposed to reset the system to its default behaviour with no
button selected. Of course I could make the clear button part of the radio
group and keep it selected, but I for me this feels wrong. 'None' is in
my program not a real state, which has to be marked by a pressed button,
but the absence of a deliberate selection.
Guido
--
[ signature omitted ]
Message 4 in thread
Guido Seifert wrote:
> Not really. I have several buttons, which toggle certain behaviours of
> the mouse. When I start the program, none of the radiobuttons are set
> and the mouse has its default behaviour. With my radiobuttons I can
> now choose between certain mouse functions. I do have a 'clear' button,
> which is supposed to reset the system to its default behaviour with no
> button selected. Of course I could make the clear button part of the radio
> group and keep it selected, but I for me this feels wrong. 'None' is in
> my program not a real state, which has to be marked by a pressed button,
> but the absence of a deliberate selection.
Then how about a "Default" button in the group ? From what you're saying
it sounds like a very real state in your application.
Alternately, consider having a "Select a different mouse behaviour"
checkbox that controls the availability of the button group : the user
has to explicitly request a non-standard behaviour in order to enable
the behaviour selection.
--
[ signature omitted ]
Message 5 in thread
Matthieu Dazy wrote:
> Guido Seifert wrote:
>> Not really. I have several buttons, which toggle certain behaviours of
>> the mouse. When I start the program, none of the radiobuttons are set
>> and the mouse has its default behaviour. With my radiobuttons I can
>> now choose between certain mouse functions. I do have a 'clear' button,
>> which is supposed to reset the system to its default behaviour with no
>> button selected. Of course I could make the clear button part of the
>> radio group and keep it selected, but I for me this feels wrong.
>> 'None' is in
>> my program not a real state, which has to be marked by a pressed button,
>> but the absence of a deliberate selection.
>
> Then how about a "Default" button in the group ? From what you're
> saying it sounds like a very real state in your application.
>
> Alternately, consider having a "Select a different mouse behaviour"
> checkbox that controls the availability of the button group : the user
> has to explicitly request a non-standard behaviour in order to enable
> the behaviour selection.
>
That is a good idea. A QGroupBox with the checkable option might help.
--Justin
begin:vcard
begin:vcard
fn:Justin Noel
n:Noel;Justin
org:ICS;Engineering
adr:;;54B Middlesex Trpk;Bedford;MA;01730;USA
email;internet:justin@xxxxxxx
title:Sr. Consulting Engineer / Certified Qt Instructor
tel;work:(617) 621-0060
url:http://www.ics.com
version:2.1
end:vcard
Message 6 in thread
On 02.02.07 15:54:14, Guido Seifert wrote:
> > Seriously your usecase sounds like a a usability bug in your Ui.
>
> Not really. I have several buttons, which toggle certain behaviours of
> the mouse. When I start the program, none of the radiobuttons are set
> and the mouse has its default behaviour. With my radiobuttons I can
> now choose between certain mouse functions. I do have a 'clear' button,
> which is supposed to reset the system to its default behaviour with no
> button selected. Of course I could make the clear button part of the radio
> group and keep it selected, but I for me this feels wrong.
For me it feels like the absolute right thing, from your description I'd
rather name it "Default" instead of none, I guess.
> 'None' is in my program not a real state, which has to be marked by a
> pressed button, but the absence of a deliberate selection.
But Default is a state in your program, at least from your description.
You can still have a reset-button, which resets this and all other
settings to the default value.
Anyway, its your app and your decision, so if you want no extra state
you have to live with the setExclusive calls.
Andreas
--
[ signature omitted ]
Message 7 in thread
How about a "None" radiobutton as part of your group? Maybe you could
not even add it to your form, but when you set it enabled, all the other
radiobuttons will be deselected.
ry
> Hi,
> I have a QButtonGroup with a couple of normally exclusive buttons.
> According to the documentation of QButtonGroup it is not possible
> to uncheck a button by clicking on it. Another one has to be
> selected.
>
> Fine, but I need to reset all buttons under certain circumstances.
>
> Currently I do:
>
> QList<QAbstractButton *> allButtons = _mouseButtonGrp->buttons();
> _mouseButtonGrp->setExclusive(false);
> foreach(QAbstractButton *button,allButtons){
> button->setChecked(false);
> }
> _mouseButtonGrp->setExclusive(true);
>
> I suppose most here can feel with me why I hate this.
> Is there a better (correct) way to do this?
>
> Else I'd file a feature request for Trolltech for something
> like _mouseButtonGrp->resetAll() + appropriate signal.
>
> Or is the necessity to unselect all buttons that scarce,
> that no one else needed such a feature?
>
> Guido
>
>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
"unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
>
--
[ signature omitted ]
Message 8 in thread
On Fri, Feb 02, 2007 at 05:51:51AM -0800, Ryan Bobko wrote:
> How about a "None" radiobutton as part of your group? Maybe you could
> not even add it to your form, but when you set it enabled, all the other
> radiobuttons will be deselected.
'None' button? Definitely no. Won't let me dictate how my GUI has to look
like by such a minor problem. :-)
Of course I could make an invisible button, but I don't think this would be a
more elegant solution than my current one.
Guido
--
[ signature omitted ]
Message 9 in thread
Guido Seifert wrote:
> On Fri, Feb 02, 2007 at 05:51:51AM -0800, Ryan Bobko wrote:
>
>> How about a "None" radiobutton as part of your group? Maybe you could
>> not even add it to your form, but when you set it enabled, all the other
>> radiobuttons will be deselected.
>>
>
> 'None' button? Definitely no. Won't let me dictate how my GUI has to look
> like by such a minor problem. :-)
>
>
>
Providing a 'None' button is actually correct UI design. If there are a
list of states and generally one is required let say A,B,or C. The user
is used to all these states. Suddenly, the app decides to add a new
hidden state lets call this "None".
Now the user doesn't really know what state the app is in from looking
at the UI. They would have to have some extra knowledge beyond what is
displayed on the screen to know that the "None" state exists and the app
is in that state. Kinda defeats the usefulness of the UI.
Even worse you have entered a state where the next selection by the user
is irreversible.
The user has entered the A state after the hidden "None" state. Now the
user doesn't want the A state they want "what they had before" which is
not selectable unless they trip your app into whatever sequence of
events for the "None" state.
My $0.03,
--Justin
begin:vcard
begin:vcard
fn:Justin Noel
n:Noel;Justin
org:ICS;Engineering
adr:;;54B Middlesex Trpk;Bedford;MA;01730;USA
email;internet:justin@xxxxxxx
title:Sr. Consulting Engineer / Certified Qt Instructor
tel;work:(617) 621-0060
url:http://www.ics.com
version:2.1
end:vcard
Message 10 in thread
> Providing a 'None' button is actually correct UI design. If there are a
> list of states and generally one is required let say A,B,or C. The user
> is used to all these states. Suddenly, the app decides to add a new
> hidden state lets call this "None".
It is A, B, C or none. But none is no real 'state'. It is the absence of
a deliberate selection between A, B, or C.
> Now the user doesn't really know what state the app is in from looking
> at the UI.
Sure he does: None of the selection buttons is pressed, therefore the mouse
has no special functionality.
> They would have to have some extra knowledge beyond what is
> displayed on the screen to know that the "None" state exists and the app
> is in that state. Kinda defeats the usefulness of the UI.
There is a 'clear' button, which deliberately clears all previous selections.
But this is not special state, which I want to mark with a permanently
pressed 'none' button.
> Even worse you have entered a state where the next selection by the user
> is irreversible.
> The user has entered the A state after the hidden "None" state. Now the
> user doesn't want the A state they want "what they had before" which is
> not selectable unless they trip your app into whatever sequence of
> events for the "None" state.
Not applicable in my design. :-)
Guido
--
[ signature omitted ]
Message 11 in thread
Guido Seifert schrieb:
>> Providing a 'None' button is actually correct UI design. If there are a
>> list of states and generally one is required let say A,B,or C. The user
>> is used to all these states. Suddenly, the app decides to add a new
>> hidden state lets call this "None".
>
> It is A, B, C or none. But none is no real 'state'. It is the absence of
> a deliberate selection between A, B, or C.
Yes it is a real state. Even if it is "just" a default- or idle-state,
it is a state.
>> Now the user doesn't really know what state the app is in from looking
>> at the UI.
>
> Sure he does: None of the selection buttons is pressed, therefore the mouse
> has no special functionality.
>
>> They would have to have some extra knowledge beyond what is
>> displayed on the screen to know that the "None" state exists and the app
>> is in that state. Kinda defeats the usefulness of the UI.
>
> There is a 'clear' button, which deliberately clears all previous selections.
> But this is not special state, which I want to mark with a permanently
> pressed 'none' button.
Where is the problem of adding the "default" radiobutton and removing
the "clear" button? To me that "clear" button looks like an
inconsistency in the ui, a crutch to get the mouse behaviour back into
its default state.
--
[ signature omitted ]
Message 12 in thread
> Where is the problem of adding the "default" radiobutton and removing
> the "clear" button? To me that "clear" button looks like an
> inconsistency in the ui, a crutch to get the mouse behaviour back into
> its default state.
I'd like to support Guido on this case; there *are* dialogs that have a
global "Clear" button to reset *all* entry widgets, and also a radio
button group that's mandatory to select from, while "None" is not a
valid value in that list. If there's no selection made for the radio
buttons, you can't submit the dialog...
Martin
--
[ signature omitted ]
Message 13 in thread
On 02.02.07 16:24:50, Martin Gebert wrote:
> >Where is the problem of adding the "default" radiobutton and removing the
> >"clear" button? To me that "clear" button looks like an inconsistency in the
> >ui, a crutch to get the mouse behaviour back into its default state.
>
>
> I'd like to support Guido on this case; there *are* dialogs that have a global
> "Clear" button to reset *all* entry widgets, and also a radio button group
> that's mandatory to select from, while "None" is not a valid value in that
> list. If there's no selection made for the radio buttons, you can't submit the
> dialog...
I agree here, but Guidos use-case is not such a dialog. He gave the reason
himself, he said that the radio buttons change the mouse-behaviour, but
its also allowed to use the default behaviour. So Default or "No
Specialities" is a valid state for his button group.
Andreas
--
[ signature omitted ]
Message 14 in thread
First: Thank you for all the answers. Of course all of you who gave me alternative
approaches to solve the problem are right. I could do it with an additional state.
I do not agree that my wish somehow breaks my GUI design.
These buttons a called 'radio buttons'. I once had a very old radio. I could
press a button to select a certain transmission range. When I selected another
range, the previous button was 'unchecked'. However, when I switched
the radio off, all buttons came up, even the off switch.
In my case not the whole program is stopped, but the usage of a certain
group of functionality.
Suppose I have three buttons: Red, blue, green. When I press the red one,
my mouse draws a red line, when I press the green one, it draws green.
Now I don't want to draw anymore, but work in some menus, save the image, whatever.
To do this I press the 'clear' button and all colour buttons are unchecked.
I did not select 'now draw invisible', or 'activate not drawing'. I did not
'activate' something, I switched something off. This is the reason why I don't
want the 'clear|default|whatever' button being checkable.
Another reason is that I might get several other buttons in different
buttongroups, which might be checkable. Checked means there is something
activated. If it is not checked, you don't have to worry about it. I don't want
the user to have to think whether a pressed button means something is on,
or somthing is off.
Guido
--
[ signature omitted ]
Message 15 in thread
> First: Thank you for all the answers. Of course all of you who gave me
> alternative
> approaches to solve the problem are right. I could do it with an
> additional state.
> I do not agree that my wish somehow breaks my GUI design.
>
> These buttons a called 'radio buttons'. I once had a very old radio. I
> could
> press a button to select a certain transmission range. When I selected
> another
> range, the previous button was 'unchecked'. However, when I switched
> the radio off, all buttons came up, even the off switch.
> In my case not the whole program is stopped, but the usage of a
certain
> group of functionality.
>
> Suppose I have three buttons: Red, blue, green. When I press the red
one,
> my mouse draws a red line, when I press the green one, it draws green.
>
> Now I don't want to draw anymore, but work in some menus, save the
image,
> whatever.
> To do this I press the 'clear' button and all colour buttons are
> unchecked.
> I did not select 'now draw invisible', or 'activate not drawing'. I
did
> not
> 'activate' something, I switched something off. This is the reason why
I
> don't
> want the 'clear|default|whatever' button being checkable.
>
> Another reason is that I might get several other buttons in different
> buttongroups, which might be checkable. Checked means there is
something
> activated. If it is not checked, you don't have to worry about it. I
don't
> want
> the user to have to think whether a pressed button means something is
on,
> or somthing is off.
>
> Guido
I have had to do the same loop, and the same, setExclusive calls before
and after the loop... Yes, I could have ask the group for the selected
item, and set that one to unchecked. But eitherway, the setExclusive to
false was required.
Scott
--
[ signature omitted ]
Pages: Prev | 1 | 2 | Next
