@Violet-Booth and how is this related to the Qt framework?

If I may, there's no need for the loop, you should be able to directly stream the list object and not go manually with that loop.

thank you, @eyllanesc, now it works as I expect...thank you very much for so much assistance and readiness :)

@eyllanesc, so is there any other way to extract the exact name of the default audio input file? Am I right, that the first element of the returned value of QAudioDeviceInfo::availableDevices(QAudio::AudioInput) is the DeviceInfo of the default audio input device?

@SpyerGame indeed, has been deprecated now four years after I answered this question. Do you mean you would like an alternative ?

@duck18
I am sure this will be much easier with QML

@Piotrek102 Do this in a thread to avoid any delay call(==>as less as possible) since it may take a while to get all storage info. GUI is not blocked in this way.

I've decided to implement something different. Thank you for your reply

Hi and welcome to devnet,

Which version of Qt are you using ?
On which OS ?

@macfanpl said in Why isn't qt so popular:

Really....... @thierryhenry14 meant that development of C++ stopped long ago

Thats just wrong, c++20 is a thing, you know, this not just an update for the std-library but includes core features thats compiler vendors have to implement
like concepts, three-way comparison etc.

and 23++ already has ton of stuff that is in the making, above all reflection (hope never dies :D)

Sorry for the late reply, I was really busy the last few days.

No need to get angry, you asked for an opinion, which is what I gave. Nobody said you must listen to my/our opinion.

@thierryhenry14 said in Using a single shared Object as a message bus in the entire application?:

Before Qt 5 we didn't even have compiler checks on connect() calls, didn't stop people from writing great Qt 4 apps.

I guess, but on that particular note before Qt5 signals were private (for the mentioned reasons). The fact that you can now emit a signal from outside the object is an implementation detail. Don't get me wrong, I've done it, it's sometimes useful if you have coupled objects (like a manager class that may need to force the emission through its underling), but it still is frowned upon.

Regarding DBus...

The DBus mention was just as an example, no one implied you should use it for objects communication. It wasn't designed for this, on the contrary it was conceived as an IPC layer.

b) I would need to constantly convert between C/C++ types and Qt types, write serialization/deserialization code, etc, which is a nightmare

Actually Qt has a DBus implementation, but that's really moot.

c) I would lose the automatic thread safety you get from Qt's AutoConnection (I know there's caveats, but for the most part it works great)

Again, you could simply pump messages through the event loop. I don't see how using a signal-slot call is somehow better or different.

This sounds horrible to me. I'm not seeing what I'm gaining by using "a real bus".

You gain (some) decoupling of the implementation from the data interface. Or to phrase it another way:
Why would unrelated components need to know what others implement, support, demand or represent. To give you an example, how does my radar control care about what data types are marshaled through and what interfaces are implemented by my data processing. Why would the radar component need to be recompiled (or possibly changed) to accommodate completely unrelated changes.

Regarding my QObject bus being singleton...what is your justification for saying this?

Just by merit of it coupling everything together. Everybody knows about it and it knows about everything.

The AppMessageBus in my example holds no state as you can see, it just has signals.

It doesn't hold its own state, it is a state for the whole application though. It basically does what QCoreApplication will have done - manage event dispatching. Btw, beside some initialization of unrelated (to this case) code, this is essentially the crux of the application object.

Also, having the technical ability to use QCoreApplication doesn't mean I should do it.

Of course, to reverse that argument though, having the technical ability to emit from outside a QObject doesn't necessarily mean that you should do it, right?

Btw, if you look at my example, it's not a global variable, I give it as a constructor argument to the components that need it.

So? That's simply an implementation detail. I create my singleton objects (whenever I need them) in main(), similarly to how QCoreApplication does it, but does that make them less global?

I have found all my jobs through this forum here, actually :-) Perhaps you don't need to search for other channels.

@AnneRanch
As @artwaw has said. In that example mdichild.h has class MdiChild : public QTextEdit. If you replaced that with, say, class MdiChild : public QTabWidget you would be making the top-level widget of the subwindow be the tab widget you talked about wanting. Of course you would then have to make other changes in mdichild.h/.cpp to reflect that change.

@AnneRanch said in Image processing using Qt:

It uses QML and to be honest there is not much to see how QML makes life easier.

Pure opinion, but I'm purely a c++ hacker and QML always seemed like hype to me anyways.

My early openCV was analysing thermal video point clouds of bats emerging from roosts after dark...and demonstrating the technical challenges of accurately counting the bats as they pass thru the frame when the customer wanted to do it on the cheap with low framerate cameras and wouldn't impose scene rules for how the emergence point should be framed. Tracking overlaying blob movement in successive frames is easy. Point clouds are way too random, especial when the point velocities can approach 70mph.

Hi and welcome to devnet,

You are here on a user forum, if you want it discuss that kind of feature you should open feature request. Note that Qt Creator already does some aggregation if enabled.

There's also the KUserFeedback module that might interest you.

Hi and welcome to devnet,

It's partially that. It also has to do with the fact that access to the graphics server is disabled by default to the root user for security reasons.

@tanim2607 said in copyavailable(), undoavailable():

can u correct the code for me??

It's your job.
As I wrote: connect a slot to copyAvailable signal.
If you have problems/don't understand something then ask concrete questions. But don't ask others to write code for you - you will hardly learn anything this way...

@Andelo
Since Qt works with RPi, I cannot see that the choice between C++ and Python (PyQt/PySide) has anything to do with the solution. Use whichever you prefer as a programming language. What experience do you have with each one?