General and Desktop

@SimonSchroeder Waw, this is realy helpfull (and not just a squeam in horror ;-), thank ypu! I will have a close look into your library and rework the whole lot in this way. Will take some time, but I'll give you feedback when it's done.

@Pl45m4 C++ or static Qt linking/building? I don't know what that mean ... @SimonSchroeder I'm not sure where you got the idea that specifically, static methods cannot be called by different threads. Maybe I'm overthinking the fact that a static method will have all variable globals acces at the same time by multiple threads. Sins i have a real time programmation background, i'm overthinking everthing that touch shared ressources. And if you need to access protected methods maybe they should have been public instead. The method I want is public, but on an object i don't want to instanciate. And i maybe don't know how to call if it's instancied already. With Qt creator debugger i don't know where to search to find an existing instanciation of the object i need. @SGaist Out of curiosity, why do you need to reinstantiate the whole application ? Because the method i need is in a object where the constructor instanciate tons of other things. The whole application is maybe an exaggeration, I admit, but the whole data management, definetly -- I think it's a clear lack of experience on my part whit Qt, i say many thing that are maybe confusing experts with my approximate understanding of what i have on my hands and what i understand of Qt. I'm also really far to be an Expert on C++. The fact is that my static thing "work" by compilation and simple test, but i don't know if it may cause issue later that i may not have knowed

Hi @JoeCFD , our application supports Qt 5.6.3. Since we are not modifying the application layer, we are continuing to use version 5.6.3.

Refer to these classes for <QCamera>、<QCameraViewfinder>、<QCameraImageCapture>, which should solve your problem

My Qt 5.15.2 and 5.15.13 instances perform the same way as the Qt 6 version above. Still could be a 5.15 vs. 5.9 difference. Could it be that Qt VS Tools is not passing the include path to moc?

Not sure why I am having so many problems in something which looks very straightforward. Nothing really seems to work. [image: b0f3e8c1-3c1d-40c6-9ad7-168ea335d4db.png] The only time that I have been successful in the User Interface displaying a non-default translation language was with QLocale::setDefault. I believe that I am just going to go and try with this approach. My overall language detection logic in main.cpp is going to be something like: 0. Check if user has already explicitly set an application language If that is the case, skip to step 3 This information is going to be stored in an external configuration file outside the application. 1. Detect user's default locale with QLocale::QLocale() 2. Check if user's default locale has an available translation in the application If they do not, either do nothing else, or explicitly change the current locale to match with the default translation language (for the sake of readability) I need to think exactly how I am going to match the results but QLocale has both QLocale::language() and QLocale::name() and that should be more than enough. 3. Change default locale to expected locale using QLocale::setDefault I am not planning in adding my languages to my application. So, I am not really worried about having a big switch statement.

@Zbigniew-Sch hi, Based on the documentation of the function, it should work. Did you check the permissions of the content of the folder you are trying to remove ?

@Akash_shinde said in QT 5.15.5 not working on i.MX93 platform: segmentation fault or core dump Did you analyze them?

@shreya_agrawal said in Hide Grid Widget: How can I do it? Remove gridWidget from the layout or change its size to 0

Hi, Is this the Qt version that comes with your distribution ? If not, can you try that one ? Did you also check with a more recent version ? 6.9 was released no too long ago.

Did you try to restart your machine once between two runs to check if it still comes up ?

@Don-Burner said in Throwing from QFuture::onFailed(): I use std::set_terminate, so unhandled exceptions call my terminate handler. EDIT: I thought std::terminate() always called std::abort(). Turns out, it calls the current terminate handler. In short, calling std::terminate() within QFuture::onFailed() works, at least for my purposes. Thanks!

Just in case, the systray example from Qt's documentation works as expected on macOS so it I think it would be good to compare the two code bases to see what is being done differently. The MacOSSysTray implementation takes quite a lot of detours to achieve the same outcome as the systray example. So I would suggest to simplify things there.

@jeremy_k I appreciate it. I successfully implemented that feature.

@Christian-Ehrlicher said in Remove default file association: You can't do this with Qt as it's to OS-specific. You are certainly right about the first part. However, I would claim that this is something (at least up to a certain point) that could actually fall into the realm of Qt. All operating systems have some sort of file type association. Windows and macOS should be pretty straight forward. I am not entirely sure about Linux if this is related to the window manager. There is certainly a certain standard with xdgutils. But, I believe this is mostly for the command line and not used by every window manager. A lot of people would already be covered by supporting Gnome and KDE (maybe another 1 or 2 window managers). What I'm saying is that it is not too crazy to expect this to be part of Qt. QSettings properly stores configuration according to common platform rules (even uses the registry on Windows).

@sirspot Hi and welcome to devnet, Please provide a complete minimal compilable example that shows this behavior.

Sorry, I've misunderstood your goal. So QCoreApplication::applicationDirPath is the simple way to do it.