Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Multiple QAction vs disconnect/connect to single one
Qt 6.11 is out! See what's new in the release blog

Multiple QAction vs disconnect/connect to single one

Scheduled Pinned Locked Moved General and Desktop
1 Posts 1 Posters 858 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • ? Offline
    ? Offline
    A Former User
    wrote on last edited by
    #1

    This might be an actual conceptual question but I reckon some of more experienced people around here could answer me. I have finally decided on a deisgn for an action manager that is akin to the one used in Qt Creator. Except I used different approach. Basically these two boils down to either:

    Qt Creator ActionManager:

    1. Have one QAction object for every specific action you want. For example if you want different behaviour for "Copy" action depending on a widget that has focus you create a QAction for each of these widgets and register those under the same name (i.e. "copy") with the ActionMananger. The manager then switches these in the menu so user's "click" on frontend action (the one that appears to him) is on the correct backend action (the one of the focused widget).

    My idea/design:
    2) Have single QAction for every desired action and connect/disconnect to it during runtime based on widget focus and set of predefined connections.

    I chose the second approach but I am second guessing myself now. :-)

    What I see as pros and cons. The first approach is very clear and you can step into it without any knowledge of existing actions and menus. That is perfect for Qt Creator with its plugins infrastructure. The issue is that there are LOTS of QAction objects and LOTS of existing connections. Also it requires A LOT of duplicated code when instances of same widgets must have their own set of actions and connections.

    The second approach relies on the old connection syntax, pre-records the signals and slots of desired connections (as const char*) and replace the senders and receivers in those "templated" connections with currently focused widget. Benefits are much shorter code (you write connection of same widget type once), a lot less QAction objects and a lot less connections. The cons are the use of old connection syntax, less control over the actual connections (i.e. when you do not know what the pre-defined connections are) and the fact that the connecting and disconnecting all happens on runtime and that is for sure much more expensive than switching bunch of QAction objects in a menu.

    I am asking for you comments on this issue. Especially related to the use of many connects/disconnects during runtime vs having all of it established once (during compile time thus in memory from the start) and just do the switching during runtime. Thanks for your time. :-)

    1 Reply Last reply
    0

    • Login

    • Login or register to search.
    • First post
      Last post
    0
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Get Qt Extensions
    • Unsolved