macOs Qprocess, calling a unix exec
-
Hello, im a super noob learning Qt and i thought id jump into making a nice little gui for an application that runs in the terminal/command prompt called avrdude. everythings going great so far i first made a console application that calls avrdude via QProcess. it works great on both mac and windows. now i have added a gui and the code itself is almost identical but for some reason it doesnt work.
QString exePath {}; QString comPort{}; QString config {}; if (os == "macOs") { comPort = "/dev/"+ connectedPort; exePath = "avrdude/mac/avrdude"; config = "-Cavrdude/mac/avrdude.conf"; } if (os == "windows") { comPort = connectedPort; exePath = "avrdude/win/avrdude"; config = "-Cavrdude/win/avrdude.conf"; } QStringList args =(QStringList() << config << "-v" << "-patmega32u4" << "-cavr109" << "-P" << comPort << "-b57600" << "-D" << updateString ); QProcess pro; pro.waitForStarted(); pro.start(exePath,args); pro.waitForFinished();This code runs as a console app perfectly on mac and windows. It also runs perfectly on windows as a Gui application but on mac it doesn't work as a Gui application. it simply runs the command, doesn't do anything then finishes. i tried catching errors with QProcess. unknown error. programme doesnt crash , it completes, it just doesnt open the terminal and run the args. Maybe i have to open the terminal directly first and then run the args. i notice on window running the avrdude.exe opens the command prompt whereas on mac it doesnt know what to do with the unix exec file avrdude.
@MatthewFelton said in macOs Qprocess, calling a unix exec:
on mac it doesn't work as a Gui application
If you are making a GUI app, you should use the asynchronous API and not the blocking, synchronous one.
Take advantage of
QProcesssignalsThis also allows better error management with
stateChangedanderrorOccurredsignals -
@MatthewFelton said in macOs Qprocess, calling a unix exec:
on mac it doesn't work as a Gui application
If you are making a GUI app, you should use the asynchronous API and not the blocking, synchronous one.
Take advantage of
QProcesssignalsThis also allows better error management with
stateChangedanderrorOccurredsignals@Pl45m4 are you saying this might help with using qprocess::error() in determining what is wrong ? having a quick read of this and being a complete beginner is this saying something about it blocking if called from the main thread because if so I do infact have this class running in a worker thread.
-
@Pl45m4 are you saying this might help with using qprocess::error() in determining what is wrong ? having a quick read of this and being a complete beginner is this saying something about it blocking if called from the main thread because if so I do infact have this class running in a worker thread.
@MatthewFelton said in macOs Qprocess, calling a unix exec:
I do infact have this class running in a worker thread
This may or may not have anything to do with your Mac problem, but why do you have any threads, especially if you are beginner? Large numbers of beginners put threads in when there is no need, and threads are a major source of complexity/bugs. If you try your code from the main/single UI thread does it make any difference to the bad behaviour?
-
Hello, im a super noob learning Qt and i thought id jump into making a nice little gui for an application that runs in the terminal/command prompt called avrdude. everythings going great so far i first made a console application that calls avrdude via QProcess. it works great on both mac and windows. now i have added a gui and the code itself is almost identical but for some reason it doesnt work.
QString exePath {}; QString comPort{}; QString config {}; if (os == "macOs") { comPort = "/dev/"+ connectedPort; exePath = "avrdude/mac/avrdude"; config = "-Cavrdude/mac/avrdude.conf"; } if (os == "windows") { comPort = connectedPort; exePath = "avrdude/win/avrdude"; config = "-Cavrdude/win/avrdude.conf"; } QStringList args =(QStringList() << config << "-v" << "-patmega32u4" << "-cavr109" << "-P" << comPort << "-b57600" << "-D" << updateString ); QProcess pro; pro.waitForStarted(); pro.start(exePath,args); pro.waitForFinished();This code runs as a console app perfectly on mac and windows. It also runs perfectly on windows as a Gui application but on mac it doesn't work as a Gui application. it simply runs the command, doesn't do anything then finishes. i tried catching errors with QProcess. unknown error. programme doesnt crash , it completes, it just doesnt open the terminal and run the args. Maybe i have to open the terminal directly first and then run the args. i notice on window running the avrdude.exe opens the command prompt whereas on mac it doesnt know what to do with the unix exec file avrdude.
@MatthewFelton said in macOs Qprocess, calling a unix exec:
i notice on window running the avrdude.exe opens the command prompt whereas on mac it doesnt know what to do with the unix exec file avrdude
One more thing besides the Qt / thread stuff:
Does the stuff you are passing toQProcesswork at all when putting it in a Mac Terminal?
You've mentioned that Mac doesn't seem to find (or being able to run) theavrdudeexecutable?!
If debugging is the process of removing software bugs, then programming must be the process of putting them in.
~E. W. Dijkstra
-
@MatthewFelton said in macOs Qprocess, calling a unix exec:
i notice on window running the avrdude.exe opens the command prompt whereas on mac it doesnt know what to do with the unix exec file avrdude
One more thing besides the Qt / thread stuff:
Does the stuff you are passing toQProcesswork at all when putting it in a Mac Terminal?
You've mentioned that Mac doesn't seem to find (or being able to run) theavrdudeexecutable?!@MatthewFelton said in macOs Qprocess, calling a unix exec:
i first made a console application that calls avrdude via QProcess. it works great on both mac and windows. now i have added a gui and the code itself is almost identical but for some reason it doesnt work.
?
-
@MatthewFelton said in macOs Qprocess, calling a unix exec:
i notice on window running the avrdude.exe opens the command prompt whereas on mac it doesnt know what to do with the unix exec file avrdude
One more thing besides the Qt / thread stuff:
Does the stuff you are passing toQProcesswork at all when putting it in a Mac Terminal?
You've mentioned that Mac doesn't seem to find (or being able to run) theavrdudeexecutable?!@MatthewFelton said in macOs Qprocess, calling a unix exec:
i notice on window running the avrdude.exe opens the command prompt whereas on mac it doesnt know what to do with the unix exec file avrdude
!
:)
No idea whether the command works at all now or not. @MatthewFelton should verify that first before digging deeper into
QProcessand why it does or doesn't work. -
@MatthewFelton said in macOs Qprocess, calling a unix exec:
I do infact have this class running in a worker thread
This may or may not have anything to do with your Mac problem, but why do you have any threads, especially if you are beginner? Large numbers of beginners put threads in when there is no need, and threads are a major source of complexity/bugs. If you try your code from the main/single UI thread does it make any difference to the bad behaviour?
@JonB The code is a little more complicated than the snippet I showed you. I'm using a worker thread because I have a while loop looking for the Arduino and it was stopping my Gui from drawing when the arduino was unplugged. its all good. I have an interface class talking between the threaded class and my QML Gui and everything working great. apart from the QProcess issue on mac. so just to re-iterate.
I created a console application first. Its works for both mac and windows. I then created a GuiApplication and utilized the console app code. On windows the GuiApplication works as expected but on mac the GuiApplication does not. Its like it doesnt call the exepath... or does call the expath but doesnt input the arguments. I have tested the same code in the terminal and it also works. And as previously stated the exact same code is also currently working on mac for the console application.
-
@JonB The code is a little more complicated than the snippet I showed you. I'm using a worker thread because I have a while loop looking for the Arduino and it was stopping my Gui from drawing when the arduino was unplugged. its all good. I have an interface class talking between the threaded class and my QML Gui and everything working great. apart from the QProcess issue on mac. so just to re-iterate.
I created a console application first. Its works for both mac and windows. I then created a GuiApplication and utilized the console app code. On windows the GuiApplication works as expected but on mac the GuiApplication does not. Its like it doesnt call the exepath... or does call the expath but doesnt input the arguments. I have tested the same code in the terminal and it also works. And as previously stated the exact same code is also currently working on mac for the console application.
Hi,
How do you move the helper executable to the right on macOS ?
On macOS you do not have a single executable file for a GUI application like you have for a CLI application. A bundle is created by default.
-
Hi,
How do you move the helper executable to the right on macOS ?
On macOS you do not have a single executable file for a GUI application like you have for a CLI application. A bundle is created by default.
-
@SGaist it's a Unix executable. Not a bundle. It's designed to be used in the terminal
I am talking about your application not the helper.
-
@SGaist as a complete beginner I don't actually know what that means sorry.
Check the macOS deployment chapter in Qt's documentation. It's nicely explained.
-
Check the macOS deployment chapter in Qt's documentation. It's nicely explained.
-
@SGaist ok .. but I'm not deploying yet. I'm still building.
That is clear. However, the build still generates a bundle as described there. Hence my question about where your helper application is stored with regard to where the application executable can actually be found which should be in the generated bundle.
