Brainstorm

@Jiri-Rohlicek So it looks like the package manager put it somewhere where your user doesn't have to sufficient permissions. Sadly, I don't know how to fix it.

@SGaist and @Kent-Dorfman Thanks for your inputs.

@Mani_kandan As @jsulm and I have been saying. If you have data in a file you want to encrypt you have to read the file to get the data to encrypt, so there is no point keep asking whether you can do it without reading the file content. If you want to save the encrypted data back to a file you can do that. If you want the encrypted data to end up back in the same file as you read the encrypted data from: either read all the file content into memory, encrypt it, and write it back to the file you originally read from; or, read it a chunk at a time from the original file, write it encrypted a chunk at a time to a new, temporary file, and rename the new file to the original file right at the end.

@Mani_kandan said in in qt using openssl how to encrypt and decrypt the file: So can you help me out how to encrypt the file OpenSSL is not Qt. This is Qt forum. Why don't you read OpenSSL documentation (https://www.openssl.org/docs/)?

Ok, I think that these are the modules under the LGPL. I'm reading right now. If I find some troubles I will write here. Edit: I found this that maybe could be of help to someone.

@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.