Annoyance with menu launch

[deepster]

This bothers me and I am hoping that someone can tell me what dumb mistake I am doing.  I have a qt application that launched fine from a terminal window, but never shows up when lauching from the "Applications" menu.  All I get is "Please wait..." and then it goes away.  My .desktop file contains the full path to the app.  I have no problems running the app from a terminal window (full path or no).  Anyone seen this?

My .desktop file looks like this:
[Desktop Entry]
Comment=Test
Exec=/opt/Qtopia/bin/test
Icon=Test
Type=Application
Name=Test

Thanks,
-- Brian

[Stubear]

I think your problem is the Exec line, from memory you CAN'T add the path as Qtopia adds the /home/Qtopia/bin/ path to whatever is in the Exec line.

Therefore your .desktop file is trying to run /home/Qtopia/bin/opt/Qtopia/bin/test which I'm guessing doesn't exist.

Have a look at some of the other apps' .desktop files and you will find that none of them have full paths.

Stu

[deepster]

Yeah, that's how I had it first before I put in the full path, but that didn't work either.

[deepster]

Double-checked the process list and my application is running, but it is nowhere to be found on the screen.  Any thoughts?

[zenyatta]

Could it be a users/permissions problem? I used to have problems on my desktop trying to run GUI programs as root because some KDE temp file somewhere belonged to my non-root account. Perhaps this could be similar if you are using one of the ROMs that doesn't run everything as root.

z.

[tumnus]

At least on the Sharp ROMs, if you look for the lines containing "runqpe" in the script /home/QtPalmtop/qpe.sh which launches Qtopia, there are two similar lines, but one is commented out. If you uncomment that, comment out the other line with "runqpe" and restart Qtopia then all command line messages originating from Qtopia (such as application messages/failures) will be logged to /home/zaurus/log.<date>

Try tapping your application's icon and look what gets logged if you still cannot figure it out. Remember to revert qpe.sh when you're done as the log file can get fairly big.

I'm guessing you can do something similar on an OZ ROM but it is probably done differently.

[Stubear]

Double-checked the process list and my application is running, but it is nowhere to be found on the screen.  Any thoughts?

If the process is runngi but has fallen of the the screen - this happens to me when I run java apps without a taskbar icon - you will have to kill it before the icon will work.

My understanding is that when you click an icon to start a program it check whether it is already running and if it is brings it to the front with a qcop command, if not it starts the app. If the app doesn't understand qcop commands (ie java, sdl apps) then it won't come to the front, but qtopia doesn't know that.

Code: [Select]

killall will get rid of all the processes called <appname> and then the icon should work

Stu

[deepster]

Thanks for the feedback.  The log shows absolutely no errors.  The application is running as user 'zaurus'.  I have seen where an application fails because it doesn't have /tmp permissions, but the application exits in that case.  My application is still running.  I have to go and kill it.

But, from what stubear said, I just tried to launch my application again from the menu to see what it would do and what do you know, up comes the app.  It is as if the application gets launched and immediately put in the background.  It disappeared while it was running, so I went back and launched it again and it came to the forgraound in the state I had left it in.  Now have to figure out why that is happening.  I don't have an icon in the taskbar even though I specify one in my desktop file.

[zenyatta]

I used to have a similar issue with my first Python programs. Say I have a script /opt/QtPalmtop/bin/my_launcher that goes like this:

Code: [Select]

python /path/to/my_app.pyWhat happens is that while Qtopia thinks the app's name is "my_launcher", the app itself thinks it's called "python", thus ignoring its qcop messages. I solve it by putting

Code: [Select]

sys.argv[0] = "my_launcher"into my_app.py start-up code.

Don't know if this will help you but the symptoms are similar. Try "qcop QPE/Application/your_app_name quit()" to see what name your app listens to. More details are at http://doc.trolltech.com/qtopia1.7/html/qcop.html

[deepster]

qcop QPE/Application/test quit() returns "SlSharedManager: can't get proc entry".  Tried it for several other apps and get the same thing.  SL-6000L...

Looks like my application is launching, but going to the background.  I may be to blame for not seeing it initially, as I would click the desktop twice, and thus the application would loose foreground focus.  But, I get no icon on the taskbar for the application.  So, I can't switch back to the application once it looses focus.  Anyone seen this?

[deepster]

Ok, this is how I "solved" my problem.  Originally, I had a main function that created a QApplication object.  The QApplication object would then launch dialogs prompting the user for information.

I changed this to match the Trolltech doc for QT 1.7. http://doc.trolltech.com/qtopia1.7/html/mainfunc.html when it is up.  Check Google cache if it isn't.

I now have a main.cpp file which  does

QTOPIA_ADD_APPLICATION("myapp", MyMainWindow)
QTOPIA_MAIN

MyMainWindow is a QMainWindow object which launches the dialogs.  Once I changed to this implementation, my application had an icon in the taskbar and had no "background" issues.  Didn't know that this format was 'required' for normal application operation.

Thanks all for your help!

[tumnus]

Have you had a look at the example app in the Qtopia SDK? It's actually a lot simpler than that.

For Qtopia, you're supposed to use QPEApplication instead of QApplication. There's a few other QPE versions of QT objects, such as QPEMenubar that automatically works with the Menu key. In general, using the QPE versions of objects will make your app work better with Qtopia without having to add extra code.