Update desktop files

There's a problem with that. Moonbeam beat me to removing from the testing branch.

Thanks for the patch. Applied and pushed to testing.

So when the patch is applied python applets are broken but C applets function correctly.

Might have something to do with Bug #179232

So with the patch applied AWN claims it can find the .desktop file for applets with:

Type=Application
X-AWN-AppletType=Python

in the desktop file.

Here's a sample of the output:

** (awn-applet-activation:5676): WARNING **: This desktop file does not exist /usr/local/lib/awn/applets/mimenu.desktop

** (awn-applet-activation:5678): WARNING **: This desktop file does not exist /usr/local/lib/awn/applets/PySwitcher.desktop

Yet when I go to "/usr/local/lib/awn/applets/" those files are in the correct location. The also have the updated X-AWN-AppletType, field so I know they are not simply left over from a previous install.

Any ideas?

"Any ideas?"

Yes. The desktop files are fine and there is some very broken code somewhere else. I've spent a bit of time debugging it today and I"m rather puzzled at this point in time.

What I find interesting is I'm getting

** (awn-applet-activation:16721): WARNING **: No exec path found in desktop file /usr/local/lib/awn/applets/digitalClock.desktop

This is tested on or about line 137 of main.c in awn-applet-activation

for the python applets and it's exiting there.

ok... found the nature of the problem

The python script needs to be made executable.

It looks like When you set Type=Application gnomedesktopitem will not load the key (even if you use the get_string) if the file isn't executable. Umm... there's a few ways to work around this cleverness.... I'm not sure what the best one is.

But expect a fix sometime today.

I think there are two obvious ways to fix this.

1) Set the permissions to executable.
or
2) Use a different fieldname than Exec for python applets.

My preference is 1.

I can confirm that making the python script executable fixes the issue.

A third feasible option would be to change the Exec field in the desktop files to the form of

Exec=python /path/to/python/applet.py

+1 for the 3, more natural and more simple to do

Sounds good. I can do that and post a patch here.

"Sounds good. I can do that and post a patch here.:

I'm fine with that.

test with one first. I haven't confirmed whether it works correctly

Sounds good. I can do that and post a patch here.

Hold off on that... it appears that there is a problem with that method.

Well, here's the patch, but it doesn't seem to work here. =(

I added "Exec=python /path/to/python/applet.py"

eg: "Exec=python @LIBDIR@/awn/applets/MiMenu/mimenu.py"

Now the terminal output is:

python: can't open file '/usr/local/lib/awn/applets/python': [Errno 2] No such file or directory

"+1 for the 3, more natural and more simple to do"

Yeah... but it seems it's not the most backwards compatible (not at all). Though if that's the route to go the necessary changes can be made.

On the other hand I think option 1 is also a quite natural option - most python scripts are marked executable afterall.

Attached is a patch provided by malept.

It allows the marking of specific python files to be installed with +x.

This is my preferred resolution... as it maintains better compatibility with existing awn-applet-activation version (if a python app wants it to be work with both it's just a case of setting both fields to Python for now).

The arss applet has been patched to work with this. If this is acceptable the other python applets will need there Makefile.am s modified in a similar manner.

Well, it makes arss work, but now "make install" errors out with the following when it gets to the python-test applet

Making install in python-test
make[2]: Entering directory `/home/andrew/source-installs/development/awn-extra-testing/src/python-test'
make[3]: Entering directory `/home/andrew/source-installs/development/awn-extra-testing/src/python-test'
/usr/bin/install -c -m 755 "" "/usr/local/lib/awn/applets/python-test/"
/usr/bin/install: target `/usr/local/lib/awn/applets/python-test/' is not a directory: No such file or directory
make[3]: *** [install-exec-local] Error 1
make[3]: Leaving directory `/home/andrew/source-installs/development/awn-extra-testing/src/python-test'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/home/andrew/source-installs/development/awn-extra-testing/src/python-test'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/andrew/source-installs/development/awn-extra-testing/src'
make: *** [install-recursive] Error 1

"Well, it makes arss work, but now "make install" errors out with the following when it gets to the python-test applet"

removed python-test from the build system until the cause of that error message can be tracked down. Ran a full make, make install and it completed without error.

Pushed andrewsomething's patches for arss->digg python applets.

Made the necessary Makefile.am modifications for the python applets in question. Please test that these applets continue to function. Anyone who feels like doing some more of this work please post here. It's relatively straightforward... we just needed the modified Makefile.am files for the python (now completeted up to digg applet) applets... the desktop files are already done.

http://codebrowse.launchpad.net/~awn-testing/awn-extras/awn-extras-testing/revision/344

Well, I tried to modify the Makefile.am files for the python applets, but some thing isn't working right. I'm probably just being dumb. I attached what I did if any one wants to take a look.

sample error output:

make[3]: Entering directory `/home/andrew/source-installs/development/my-awn-extra-testing/src/file-browser-launcher'
make[3]: *** No rule to make target `file-browser-launcher.desktop', needed by `all-am'. Stop.

I ran into the same issue when I started... malept had the answer of course.

When a python applet is modified for the new build system it requires an entry added into configure.ac

Basically in the case above you need to add the following to AC_OUTPUT

src/file-browser-launcher/file-browser-launcher.desktop.in

Other than that the other thing that jumps out at me is that if something is assigned to APPLET_MAIN_FILE it needs to be removed from dist_applet_DATA

malept has pushed some more changes into testing, but there are some issues still. Certain applets still are working correctly. I was having the same problem on my end, that's why I hadn't submitted a final patch yet.

** (awn-applet-activation:4895): WARNING **: This desktop file does not exist /usr/local/lib/awn/applets/awngmail.desktop

** (awn-applet-activation:5002): WARNING **: This desktop file does not exist /usr/local/lib/awn/applets/medialogoback.desktop

** (awn-applet-activation:5022): WARNING **: This desktop file does not exist /usr/local/lib/awn/applets/medialogonext.desktop

** (awn-applet-activation:5024): WARNING **: This desktop file does not exist /usr/local/lib/awn/applets/medialogoplay.desktop

** (awn-applet-activation:5026): WARNING **: This desktop file does not exist /usr/local/lib/awn/applets/mimenu.desktop

Now the strange thing is that all these desktop file actually exist in those locations. What doesn't seem to exist are the program file that should be in "/usr/local/lib/awn/applets/applet-name"

"malept has pushed some more changes into testing, but there are some issues still. Certain applets still are working correctly. I was having the same problem on my end, that's why I hadn't submitted a final patch yet."

Looks like the python file isn't being given a +x. The Makefile appears to be working though. odd.

I see whats happening for at least some of these now. It has to do with APPLET_NAME and APPLET_MAIN_FILE in Makefile.python-applet. Look at the code:

appletdir = $(libdir)/awn/applets/$(APPLET_NAME)

install-exec-local:
            $(INSTALL) -m 755 "$(APPLET_MAIN_FILE)" "$(DESTDIR)$(appletdir)/$(APPLET_MAIN_FILE)"

Media-icon-back makefile.am:

SUBDIRS = icons
APPLET_NAME = medialogoback
APPLET_MAIN_FILE = medialogoback.py
include $(top_srcdir)/Makefile.python-applet
dist_applet_DATA = \
 COPYING \
 mediaplayers.py \
 $(NULL)

EG: I now have a directory /usr/local/lib/awn/applets/medialogoback and the applet files that are there should actually be in /usr/local/lib/awn/applets/media-icon-back

The media icon and gmail applets all have in common the fact that the desktop file has a different name than the directory the applet files should be in. I think renaming these might fix this.

I think we need to rename the actual files or add another field to the python makefile, I'm not sure what's better. In the example of the media icon back applet, changing the APPLET_NAME to media-icon-back results in:

make[1]: *** No rule to make target `media-icon-back.desktop', needed by `all-am'. Stop.

So APPLET_NAME is being used to define both the name of the .desktop and the file structure, but in these cases they are not the same.

"The media icon and gmail applets all have in common the fact that the desktop file has a different name than the directory the applet files should be in. I think renaming these might fix this."

ah... good eye.

One of the requirements of the new build system is that the desktop file name match the dir name (and obviously the Exec and such in the file need to be modified also). It may seem like an inconvenience but I actually tend to think that enforcing this match is probably a good thing.

This patch should fix:

media-icon-back
media-icon-next
media-icon-play
MiMenu
Pandora
tsclient-applet

All had the issue of the desktop file having a different name than the directory they were installed into.

Maybe we can finally close this? =)

Well, I lied. It fixes:

MiMenu
Pandora

But icons are being installed into the wrong directory for:

media-icon-back
media-icon-next
media-icon-play
tsclient-applet

Thanks,

Pushed the fixes for Mimenu and pandora.

malept, I believe, will be pushing a fix for the media-icon*

Alright, this really fixes the tsclient-applet.

"Alright, this really fixes the tsclient-applet."

applied and pushed.
 revision 390.