Connect slot to an int function !?

[wysota]

Sigh...this is bad. Really bad. Just applying encapsulation willy-nilly is just not the way to do things.

Good thing I didn't say anything like that.

Answer: NO! Why? One word: composition. The fact that mapping from one thing to another is a specific and unique responsibility has not changed. Put that stuff into an object responsible for just that and then USE that object within the object you want to couple it to.

I don't see how using a signal mapper is in any way better than any of the other presented designs.

Well, unless you can show me where I'm wrong my answer is a very certain NO! Why? Because NONE of the objects in question depend upon it!

Objects don't depend on it, the overall functionality does. The sole fact that you need to create this object in addition to the objects you really need makes it a dependency. It's just an adapter between two data types but as such the functionality of the two incompatible interfaces depends on existance of this object. Existance of the show_m slot is meaningless to the whole problem, the method itself is useful without appointing shortcuts to widgets. The whole point is to extend the infrastructure to accept such shortcuts and not to map indices. Sure you can add several adapters doing nothing more than mapping between types or brewing coffee but that doesn't change the fact they won't make the original object accept shortcuts to popping up widgets.

You'll have to point out where you showed it wouldn't work because I not only missed it the first time but can't find it when I try to backtrack. In fact, I can only see where you claimed it didn't matter.

Geeez man...

tabWidget->addTab(new QCalendarWidget);
tabWidget->addTab(new QDial);
QSignalMapper *mapper = ...;
QShortcut *sh1 = ...; // to popup the calendar
QShortcut *sh2 = ...  // to popup the dial
mapper->setMapping(sh1, 0);
mapper->setMapping(sh2, 1);
connect(sh1, SIGNAL(activated()), mapper, SLOT(map()));
connect(mapper, SIGNAL(mapped(int)), tabWidget, SLOT(setCurrentIndex(int)));
 
// some other scope, maybe written by some other person...
// this breaks the design:
tabWidget->insertTab(0, new QWidget); // now sh1 points to the QWidget and sh2 points to the calendar, oops...

tabWidget->addTab(new QCalendarWidget);
tabWidget->addTab(new QDial);
QSignalMapper *mapper = ...;
QShortcut *sh1 = ...; // to popup the calendar
QShortcut *sh2 = ...  // to popup the dial
mapper->setMapping(sh1, 0);
mapper->setMapping(sh2, 1);
connect(sh1, SIGNAL(activated()), mapper, SLOT(map()));
connect(mapper, SIGNAL(mapped(int)), tabWidget, SLOT(setCurrentIndex(int)));

// some other scope, maybe written by some other person...
// this breaks the design:
tabWidget->insertTab(0, new QWidget); // now sh1 points to the QWidget and sh2 points to the calendar, oops...

To copy to clipboard, switch view to plain text mode 

Now you can't possibly break this unless you really try it (WARNING, pseudocode!):

class TabWidgetWithShortcuts : public QTabWidget {
  Q_OBJECT
public:
  TWWS(...) : QTW(...) {}
  void registerShortcut(int page, QShortcut *sh) {
    if(page not in [0, count()-1] ) return;
    m_list[page] = sh;
    connect(sh, SIGNAL(destroyed(QObject*)), this, SLOT(_q_onShDestroyed(QObject*)));
    connect(sh, SIGNAL(activated()), this, SLOT(_q_activated()));
    emit shortcutRegistered(page);
  }
  void unregisterShortcut(int page) {
    if(!m_list.at(page)) return;
    disconnect(m_list.at(page), SIGNAL(destroyed(QObject*)), this, SLOT(_q_onShDestroyed(QObject*)));
    disconnect(sh, SIGNAL(activated()), this, SLOT(_q_activated()));
    emit shortcutUnregistered(page);
    m_list[page] = 0;
  }
  QShortcut *shortcut(int page) const { 
    // check bounds, etc.
    return m_list.at(page);
  }
protected:
  void tabInserted(int at) {
    m_list.insert(at,0);
  }
  void tabRemoved(int at) {
    unregisterShortcut(at);
    m_list.removeAt(at);
  }
private:
  QList<QShortcut*> m_list;
private slots:
  void _q_onShDestroyed(QObject *o) {
    // remove shortcut from list
  }
  void _q_activated() {
    QShortcut *sh = qobject_cast<QShortcut*>(sender());
    if(!sh) return;
    setCurrentIndex(m_list.indexOf(sh));
  }
signals:
  void shortcutRegistered(int);
  void shortcutUnregistered(int);
}

class TabWidgetWithShortcuts : public QTabWidget {
  Q_OBJECT
public:
  TWWS(...) : QTW(...) {}
  void registerShortcut(int page, QShortcut *sh) {
    if(page not in [0, count()-1] ) return;
    m_list[page] = sh;
    connect(sh, SIGNAL(destroyed(QObject*)), this, SLOT(_q_onShDestroyed(QObject*)));
    connect(sh, SIGNAL(activated()), this, SLOT(_q_activated()));
    emit shortcutRegistered(page);
  }
  void unregisterShortcut(int page) {
    if(!m_list.at(page)) return;
    disconnect(m_list.at(page), SIGNAL(destroyed(QObject*)), this, SLOT(_q_onShDestroyed(QObject*)));
    disconnect(sh, SIGNAL(activated()), this, SLOT(_q_activated()));
    emit shortcutUnregistered(page);
    m_list[page] = 0;
  }
  QShortcut *shortcut(int page) const { 
    // check bounds, etc.
    return m_list.at(page);
  }
protected:
  void tabInserted(int at) {
    m_list.insert(at,0);
  }
  void tabRemoved(int at) {
    unregisterShortcut(at);
    m_list.removeAt(at);
  }
private:
  QList<QShortcut*> m_list;
private slots:
  void _q_onShDestroyed(QObject *o) {
    // remove shortcut from list
  }
  void _q_activated() {
    QShortcut *sh = qobject_cast<QShortcut*>(sender());
    if(!sh) return;
    setCurrentIndex(m_list.indexOf(sh));
  }
signals:
  void shortcutRegistered(int);
  void shortcutUnregistered(int);
}

To copy to clipboard, switch view to plain text mode 

Go ahead, be picky... The hell with it, I'll add some signals to it, it's almost compilable anyway. Look maa... no signal mappers!

By the way, you can do the same with QActionGroup without the dedicated list as QActionGroup already has one embedded.

I don't know who "Daniel" is, but if it's "high_flyer" then I really suggest you reevaluate his proposed solution. It's not even valid C++, as has been pointed out already.

The idea matters, correctness of the code is exercised against a compiler. I'm sure you make syntax errors in your code too as we all do. If you want to find a flaw you will always find it in anything and at the same time you'll miss the bigger picture.

[nroberts]

Good thing I didn't say anything like that.

You very much did: "...where you do the encapsulation is meaningless."

I don't see how using a signal mapper is in any way better than any of the other presented designs.

And yet you've countered none of my arguments.

Objects don't depend on it, the overall functionality does. The sole fact that you need to create this object in addition to the objects you really need makes it a dependency.

I'm sorry but I just can't make it past this point. I'm talking over your head or something because this statement just proves you don't get it. You don't even know what I'm talking about when I say the word "dependency".

This isn't me trying to be rude. It's just a sad truth. When I'm using the word "dependency" in the context of design decisions I'm using the word in a very specific, technical way. The fact that a certain behavior is desired and must be implemented somewhere does not create dependencies. In the language of program design, "dependencies" exist when one "entity" is in some way bound to the existence of another...in that it requires it to exist.

Some types of dependencies that can exist in a design are dependency to an interface, dependency of a name, etc... For example, any entity that contains the statement, "new Object," depends on the name "Object" and anything necessary to build it. An entity that contains a line of code like, "instance->doX()," depends on the name "instance", the identity of what instance IS, and the member of that interface, doX().

The signal/slot mechanism in Qt removes dependencies like this. Say I have two objects:

struct X : QObject
{
  Q_OBJECT
 
signals:
  void sig();
};
 
struct Y : QObject
{
  Q_OBJECT
 
public slots:
  void s();
};

struct X : QObject
{
  Q_OBJECT
  
signals:
  void sig();
};

struct Y : QObject
{
  Q_OBJECT

public slots:
  void s();
};

To copy to clipboard, switch view to plain text mode 

These two objects exist within the same program. They perform their specific functions within the behavior of that program. However, as you can see, there are absolutely no dependencies between the two. I could remove either one and use it, unchanged, in another program that doesn't have the other class.

They do both depend on QObject, and further they both depend on and obey that interface created by the MOC when the Q_OBJECT macro is used. Because they do this, and because of the way the QObject interface works, I can connect these two otherwise unrelated objects together to generate new behavior.

This kind of thing, having two objects that you wish to use together remain independent of each other by binding both to a higher abstraction, is called "Dependency Inversion" BTW.

So, say we add a user requirement that means I need new behavior that must be thrown into the mix here. The addition of a new class does not create a dependency on that class to these other two if I don't cause them to be bound to the existence of that new object. Yes, the behavior of the program depends on the existence of code, somewhere, that does what the new object does. It may even require that this code happen sometime between the emitting of X's signal and Y's slot. X and Y, and this new object (Z) do not depend on each other though. I could remove any of them, put them together in different ways or not at all, and generate new behavior in new programs...or even within the SAME program....and here's the important part that is WHY we try to remove dependencies: I don't have to change any of them to do so.

Another very important aspect of this is that I can add Z between X and Y only BECAUSE they do not depend on each other.

THAT is what developers and designers are talking about when they say, "dependency" and there are many levels of abstraction upon which we use the term. At the component level, at the application level (X.exe depends on Y.exe), and also at the class level and lower.

Of course, I have a feeling that you already know all of this and are just using the same old, "look over HERE!!!," method of argument where you distract your opponent and readers by switching between the meanings of words. For instance, when arguing about the temperature of water someone might say, "It's cold," and then you'd respond with, "No, it's nose isn't running. It doesn't even have one." Yes, we could say that the behavior of the program depends on the existence of the code I'm proposing to encapsulate within a smaller object instead of embed into another that's already doing other things. We could say that but we both know that the discussion is about dependency in DESIGN.

I did skim the rest of your stuff....don't see anything new. I have to be honest in not being very interested though because clearly you either don't understand the language of program designers or you're up to dishonesty. Either way I'm not particularly interested in "discussing" with someone that is not interested in curing their ignorance any more than "discussing" with someone that only wants to appear right, no matter what it takes.

[wysota]

And yet you've countered none of my arguments.

The purpose of me being here is something more than countering your arguments. Note that I didn't comment on your opinions in the thread until you started commenting mine. I just don't see why you are defending the approach so much and trying to prove it is superior to some other approach when clearly they all suffer from the same problems.

I'm sorry but I just can't make it past this point. I'm talking over your head or something because this statement just proves you don't get it. You don't even know what I'm talking about when I say the word "dependency".

Maybe. But who said the word "dependency" has only a meaning when talking about objects? If you want a more scientific expression I can say that the signal mapper is tightly coupled with the tab widget if it is to provide the functionality desired. Otherwise if the tab widget ignores the presence of the signal mapper, you get the problem which I demonstrated earlier and which you gladly ignored. You can either see a context of using some objects or not. It seems you are focusing solely on syntax without taking a broader look at the context. It's ok, it's your will but don't say others are wrong only if they look at the situation from a broader perspective.

This isn't me trying to be rude. It's just a sad truth.

That is to be judged by each person subjectively.

Of course, I have a feeling that you already know all of this and are just using the same old, "look over HERE!!!," method of argument where you distract your opponent and readers by switching between the meanings of words.

Right. That's the real purpose for this site being here. So that one can distract others.

I did skim the rest of your stuff....don't see anything new.

Too bad you just skimmed it but I can understand it's hard for you to say this design was indeed better than what you had suggested. There is nothing new there, it's just a correct approach to solving the problem. It doesn't rely on any external objects, the encapsulation is correct, it does its job and it's secure. Which can't be said about a unilateral relationship between an external signal mapper and the widget container.

I have to be honest in not being very interested though because clearly you either don't understand the language of program designers or you're up to dishonesty. Either way I'm not particularly interested in "discussing" with someone that is not interested in curing their ignorance any more than "discussing" with someone that only wants to appear right, no matter what it takes.

You really have a high self-esteem, don't you? You think your solutions are correct ones because they are yours and you can't find a flaw in them and everything else somebody else suggests just has to be wrong simply because your approach is by definition *the best*. And when you run out of arguments, you start making the discussion personal. What's the purpose, I ask you?

[high_flyer]

@nroberts:

ither way I'm not particularly interested in "discussing" with someone that is not interested in curing their ignorance any more than "discussing" with someone that only wants to appear right, no matter what it takes.

you should read you own words, and act on it, especially the last part of the sentance.
You ignorance may not be so much in the technical issues, which clearly you seem to know quite a bit about, but about conduct, and proper manner in discourse.
That too, is an important skill, and it seems you ignorance in that department, is larger than the your technical knowledge.
Maybe its not ignorance, it seems more likes its exactly what is in the sentence of yours that I quoted.
Too bad really, since I think your non emotional contribution to the thread was good, and interesting.

May we close this thread now please?
It brings no new value to anyone anymore.