Why are actions limited to menus and toolbars?

I have a menu which contains a list of checkable items. I want to create a dockwindow which also contains the same list of checkable items, so when I tick an item in the menu it it automatically ticked in the dock window.

Keeping seperate GUI elements in sync like this is exactly what QAction is designed for so I was suprised to see it only works for menus and toolbars! Why is that? Do I have to provide the syncrhonisation manually?

QToolBar inherits QDockWindow, so i think you can use it instead QDockWindow :rolleyes:

Quote:

---

Originally Posted by zlatko

QToolBar inherits QDockWindow, so i think you can use it instead QDockWindow :rolleyes:

---

Do you mean I can use a QToolbar in a QDockWindow? I don't want to do that.

Or Do you mean I can use QActions in a QDockWindow the same way as I can use them in QToolbar?

I mean that you must use QToolBar instead QDockWindow

Use QToolButton objects.

Quote:

---

Originally Posted by wysota

Use QToolButton objects.

---

I have tried that but I specifically want to use checkboxes. My menu consists of checkable items and I want my dock window to contain a list of checkable items also.

I notice that QWidget has an addAction() method. I thought that I could create a QCheckbox then call addAction() on it to syncronise it with the action, but that doesn't work. What's the point of QWidget::addAction()?

Quote:

---

Originally Posted by Paul Drummond

What's the point of QWidget::addAction()?

---

Well, docs say about this:

Quote:

---

All QWidgets have a list of QActions, however they can be represented graphically in many different ways. The default use of the QAction list (as returned by actions()) is to create a context QMenu.

---

As I understand, it is just for example for simplifying constructing of context menus and so on. At least it is an easy way to pass a set of actions to a widget for later usage without needing to dangle them around as member variables or so..

Basically you could try adding your checkboxes where ever you wish, and then connecting check boxes' toggled(bool) signals to according QAction::toggle(bool) slots. This could work as long as the check boxes are't tri-state (which wouldn't make sense either).

Someone's a bit dulled.. :)

Here's a tiny example of syncing QActions with QCheckboxes. All behaviour done with Designer.. All I did was connecting toggle(d) signals 'n slots between checkboxes and actions to both directions and voilá!

Quote:

---

Originally Posted by Paul Drummond

I have tried that but I specifically want to use checkboxes.

---

A checkbox is equal to a button with checkable property set to true.

Quote:

---

Originally Posted by wysota

A checkbox is equal to a button with checkable property set to true.

---

Yeah, but it doesn't look the same does it!?!! I want a little white box that I can tick. When using a QToolbutton with the checked property set, it just sets the button to be "pressed".

Quote:

---

Originally Posted by Paul Drummond

Yeah, but it doesn't look the same does it!?!! I want a little white box that I can tick. When using a QToolbutton with the checked property set, it just sets the button to be "pressed".

---

Well... yes, that's how tool buttons usually behave :)

Quote:

---

Originally Posted by wysota

Well... yes, that's how tool buttons usually behave :)

---

That's my point, I want CHECKBOXES! :)

I understand what QAction does. You define an action once then the menu item and toolbar button associated with the action are sync'd. It's just a shame QAction is limited to menus and toolbars that's all.

It's quite easy for me to do the synchronisation myself, I just didn't want to if QAction did it for me, but it obviously doesn't.

Thanks guys for helping to make this clear to me.

Hmm... when I think of "action" I belive this is something that I can trigger. With checkboxes I don't see how marking it as checked or not triggeres some action. Of course, an action can be checkable, but it still is (logically) associated with some action being taken. For me it would make more sense to associate an action with a QPushButton more than with QCheckBox. But we have QToolButton for that :) An action associates things like text, icon, tool tip, etc. not only a slot which will get run after activating the widget. Both QPushButton and QCheckBox (and QRadioButton too) are just not meant for actions. If you want, you can always subclass them and add a feature of associating an action with each of them. There is a changed() signal in QAction. I belive you can use it for that.

What about checkable menu items then? They can be associated with actions. I can't see how QToolButton and QMenuItems are "special" in that they are the only widgets that can be syncronised with QAction. A Checkbox is a button just like a QToolButton so it should work with QAction IMO.

A checkbox can have 3 states..

Quote:

---

Originally Posted by jpn

A checkbox can have 3 states..

---

You are missing my point. There is no point arguing that a QAction can't work with a checkbox!!!! It works with checkable menu items!!! :D

Code:

---

class QActionCheckBox : public QCheckBox {
  Q_OBJECT
public:
  QActionCheckBox(QAction *act, QWidget *p = 0);
  const QAction *action() const { return _action; }
  void setAction(QAction *a){ initAction(a); }
private:
  QPointer<QAction> _action;
  void initAction(QAction *a);
protected slots:
  void updateAction();
};
 
QActionCheckBox::QActionCheckBox(QAction *act, QWidget *p) : QCheckBox(p){
   if(_action) initAction(act);
}
 
void QActionCheckBox::initAction(QAction *a){
  _action = a;
  if(_action){
    connect(_action, SIGNAL(changed()), this, SLOT(updateAction()));
    connect(this, SIGNAL(stateChanged(bool)), _action, SLOT(setChecked(bool)));
    updateAction();
  }
}
 
void QActionCheckBox::updateAction(){
  if(!action) return;
  setEnabled(_action->isEnabled());
  setText(_action->text());
  if(_action->isCheckable()) setChecked(_action->isChecked());  
}

---

Satisfied? You can make a designer plugin with this class and place this widget on a form. I haven't checked it but even if it contains errors, the idea is simple, so you'll be able to modify it.