Samples about cs_signal HOT 7 OPEN

1. I would like to ensure you have seen our API documentation for the cs_signal library. If not, it can be found at http://www.copperspice.com/docs/cs_signal/index.html

2. We have noted to add some examples to our existing documentation. In the meantime, please take a look at the test suite for cs_signal at https://github.com/copperspice/cs_signal/tree/master/test

3. You mentioned there are subtle differences. Can you please elaborate on what you have found?

from cs_signal.

1. I generally start there but end up digging into implementation anyways. Tests and samples have been more helpful.
2. As mentioned in my previous comment, tests and samples speak more than HTML pages. If I can build something and put a few breakpoints to walk the logic, that's the best. This has been a little harder than I would like with missing Windows specific build tools.
3. Logically they do the same thing but function signatures for some of the most common functions differ. Most importantly connect takes an instance as parameter and not a pointer. When one is using Qt that's never the case and so was caught surprised.

Also, using cs_signal with a Copperspice application took a attempt or two. When you are within a Widget subclass, a call to connect will resolve to QWidget::connect instead of CsSignal::connect, and so you have to add the namespace explicitly. Subtle differences but calling them out for beginners (especially for ones with little to no clue about Qt or its concept of signals and slots). In my particular use case, I have a library that uses CsSignal (but no Copperspice) and an app that uses Copperspice. A simple sample demonstrating such functionality (which I think is the intended purpose of splitting the signal logic out of Copperspice, or at least a reason) in action would have helped.

from cs_signal.

Also, using cs_signal with a CopperSpice application took a attempt or two.

We embedded the CsSignal library into CopperSpice so normally there would be no need to link with both. We designed CsSignal as a stand alone library for C++ users who are not using CopperSpice but want the Signal/Slot mechanism.

It sounds like you might be using both CsSignal and CopperSpice in your application. Can you confirm this? If you have a reason to use link with both CsSignal and CopperSpice then the explicit namespace would be required.

We will think about where we could document the fact that the CsSignal library is not required when linking with CopperSpice.

from cs_signal.

Apologies for late follow up.

Yes, we are using both cs_signal and copperspice. We are building a number of static libraries that finally become part of a larger CS application. As a design/architecture choice, we do NOT want the libraries to have a dependency on CS. The generated libraries can be part of an application that is not a CS application. We do have a good case for signaling though and cs_signal fits the bill quite well here. I can surely foresee us building a headless version of our application that is not dependent on CS but still dependent on cs_signal.

May be this wasn't the intended use case you had in mind.

from cs_signal.

Thanks for your feedback. Indeed, this was not a use case we take advantage of at the moment. Can you elaborate a bit on what documentation you think would be helpful? As far as I know, we do not have other users linking with CsSignal in one part of their application and CopperSpice in another part. I'm glad that you got this configuration working, because I can definitely see the value of signals and slots in a headless context.

from cs_signal.

In context to documentation, adding a specific section talking about using the library with and without copperspice would help. The section can talk about what the differences are and things/issues/errors to look out for. These can be illustrated with a small program which can also serve as a playground for beginners.

Also, I haven't tried it but, if possible, even throw in some documentation and a sample with cs_signal and Qt working together in the same program.

As I mentioned earlier in my comment, the differences are very subtle but simple examples of different use cases (and why the differences if they aren't obvious) go a long way in getting engineers comfortable to new tech. At some level, its all about getting wider acceptance and building a community around the tech.

cs_signal, as an independent library, was one big reason for us to choose copperspice. We knew early on that we don't want to bring in the heavy weight Qt into our core libraries. That's a dependency we can't afford. With cs_signal we saw a way around that and it was the right decision. We have our test framework also working without any UI components. We are able to implement a whole batch of tests as a console program which otherwise would have required us to program via UI (which isn't impossible to do, just harder to maintain long term).

from cs_signal.

Apologies for late follow up.

Yes, we are using both cs_signal and copperspice. We are building a number of static libraries that finally become part of a larger CS application. As a design/architecture choice, we do NOT want the libraries to have a dependency on CS. The generated libraries can be part of an application that is not a CS application. We do have a good case for signaling though and cs_signal fits the bill quite well here. I can surely foresee us building a headless version of our application that is not dependent on CS but still dependent on cs_signal.

May be this wasn't the intended use case you had in mind.

This is actually the exact same approach for our project: have separate libraries and modules/plugins that use CsSignal but no other CopperSpice compontents. However some of these libraries will end up in a CopperSpice GUI and there will be signalling from library to GUI.

from cs_signal.