Associate files with application

[alejandro]

Hi All,
I'm starting with autopackage and I'm trying to make a package wich
install my application and associate with the files that generates
with it.
I can't make the association between files and application.
The package installs the aplication and changes the MIME type of the
files but when I look in the list of associated applications is empty.

The version of autopackage is: 1.4.1
I'm installing the package like common user (not root), so the
<application>.xml and <application>.desktop files are installed in /
home/<user>/.local/...

Next lines are fragments of application.xml, application.desktop and
default.apspec that I'm using. I appreciate any suggestion.

application.xml:
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-
info" xmlns:apkg="http://autopackage.org/xdgmime-extensions">
<mime-type type="application/x-abc">
<glob pattern="*.abc" />
<apkg:icon>icon-ProjectFile-48.png</apkg:icon>
</mime-type>
</mime-info>

application.desktop:
[Desktop Entry]
Type=Application
Exec=myapp.sh %f
TryExec=myapp
Icon=icon-Application-48.png
MimeType=application/x-abc;
FilePattern=*.abc

default.apspec:
[Install]
installExe myapp myapp.sh
copyFiles data "$PREFIX"/share/myapp
installIcon hicolor
installLib lib/*
linkFile --silent /usr/lib/libtiff.so.4 "$PREFIX"/lib/libtiff.so.3
installMenuItem "" "myapp.desktop"
installMime myapp.xml

I appreciate if someone help to find whats wrong.

Thanks in advance.
Alejandro


--
Subscription settings: http://groups.google.com/group/autopackage/subscribe?hl=en

[Eugene Zolenko]

I'm using xdg-mime to install file associations. But otherwise only differences I see between your files and mine are:

- I don't have xmlns:apkg namespace and I don't have icon set in mime xml at all, it is picked up from desktop file that opens the file.

- I don't have FilePattern in the desktop file

- My mime xmls are named after the mimetype. So yours would be "x-abc.xml". I don't remember, but I think I had to rename them for a reason. (might be xdg-mime tool quirk, or might be some gnome quirk)

xdg-mime also has "query" command that lets you see what is associated with what. Even if you installed mimes with autopackage they should show up there (just another way to check stuff without killing various gnome processes).

Also, try using --no-path-adjust on installMenuItem, maybe it breaks your desktop file.

PS, heh I see you are doing this libtiff.so.4 thing too :).

[alejandro]

Hi and thanks for answer.
I've try everything you mentioned but I still have the problem.
Even I tried with xdg-mime query and the results were:
1)_ xdg-mime query filetype xxx.abc -> application/x-abc
2)_ xdg-mime query default application/x-abc -> "" (nothing)

The strange thing is that if I associate the *.abc with my application
through the file properties doesn't work neither

Any idea?

Thanks in advance.
Alejandro.

On 23 abr, 20:58, Eugene Zolenko <zolen...@gmail.com> wrote:
> I'm using xdg-mime to install file associations. But otherwise only
> differences I see between your files and mine are:
>
> - I don't have xmlns:apkg namespace and I don't have icon set in mime xml at
> all, it is picked up from desktop file that opens the file.
>
> - I don't have FilePattern in the desktop file
>
> - My mime xmls are named after the mimetype. So yours would be "x-abc.xml".
> I don't remember, but I think I had to rename them for a reason. (might be
> xdg-mime tool quirk, or might be some gnome quirk)
>
> xdg-mime also has "query" command that lets you see what is associated with
> what. Even if you installed mimes with autopackage they should show up there
> (just another way to check stuff without killing various gnome processes).
>
> Also, try using --no-path-adjust on installMenuItem, maybe it breaks your
> desktop file.
>
> PS, heh I see you are doing this libtiff.so.4 thing too :).
>

[Eugene Zolenko]

Another thing you can try is manually installing mime with xdg-mime.

Run 

export XDG_UTILS_DEBUG_LEVEL=3

xdg-mime install --mode system --novendor application.xml

And see if it complains about anything and if it works or not.

[alejandro]

Hi Eugene, and thanks for answer again.
I've tried to install mime types using xdg-mime and it works, better
than that, it helped me to correct the application.xml file. But my
real problem is how to associate my application with that mime type,
that is what I can't make.
When I use the ".package" it change the mime type of files, but
doesn't associate the application with them.
I don't know where trouble could be.

I was reading some pages (man, web, etc) and saw that there is a
command, like update-mime-database, "update-desktop-database" which
must be run after install a .desktop file. (see
http://library.gnome.org/admin/system-admin-guide/stable/mimetypes-registering.html.en).
Well, I've run that command but it never return.

I saw too that when I associate the application with files from file's
properties a "mimeapps.list" file is created in /home/user/.local/
share/applications/

How could I do that with my .package? Is there any instruction in
autopackage's api that let me do that and It is not documented?

Thanks again.
Alejandro.

On Apr 27, 12:42 pm, Eugene Zolenko <zolen...@gmail.com> wrote:
> Another thing you can try is manually installing mime with xdg-mime.
>
> Run
>
> export XDG_UTILS_DEBUG_LEVEL=3
> xdg-mime install --mode system --novendor application.xml
>

[Eugene Zolenko]

So it seems like you registered mime type properly, but your desktop file is not installed correctly or doesn't declare it can handle mime type properly.

Which distribution/desktop are you testing on and what kind of file is it? Some versions of gnome tried to be way too smart for their own good and were overriding file associations based on results of a scan. So if a file is a zip with renamed extension and supposed to have a special app to open it, gnome would detect that it really is an archive and open it in whatever app opens zip files on gnome.

I use xdg-desktop-menu to install .desktop files (because autopackage API can't create sub-menus). You can try that.

On Ubuntu 10 xdg-desktop-menu (and I would expect autopackage code too) doesn't work properly (needs to call update-gnome-menus-cache). But I'm not sure if that affects file associations at all.

BTW, did you try forcing you app to be default handler? Install mime type, then install desktop file, then run:

xdg-mime default app.desktop mimetype

[alejandro]

Hi Eugene,
I've tried with xdg-* commands and I could associate the application
with files, but I still can't open the application by double clicking
on a file.
To run my application I execute a bash script which could receive a
parameter. So in the file "application.desktop" I've the line:"Exec=/
home/user/.local/bin/myapp.sh %f"
And when I look the properties of any of the file that application
generates (after associate the application to them) the command line
to execute when receive a double click is "/home/user/.local/bin/
myapp.sh" (note that there isn't "%f")

I found differences between associate the application with xdg-mime
command and when I associate the application from file's properties:
1)_ When I associate the application from file's properties and edit
the command line that must execute on double click by adding the "%f",
the file "userapp-myapplicationnaem.sh-DS..x.desktop" is automatically
generated. This file is equal to application.desktop except for this:
"Exec=/home/user/.local/bin/myapp.sh %f %f"

2)_ the file mimeapps.list is generated automatically in /home/
user/.local/share/application. It's equal to defaults.list but after
equal sign ("=") it makes reference to "userapp-myapplicationnaem.sh-
DS..x.desktop"

Any idea?

Thanks again.
Alejandro.

On Apr 28, 3:54 pm, Eugene Zolenko <zolen...@gmail.com> wrote:
> So it seems like you registered mime type properly, but your desktop file is
> not installed correctly or doesn't declare it can handle mime type properly.
>
> Which distribution/desktop are you testing on and what kind of file is it?
> Some versions of gnome tried to be way too smart for their own good and were
> overriding file associations based on results of a scan. So if a file is a
> zip with renamed extension and supposed to have a special app to open it,
> gnome would detect that it really is an archive and open it in whatever app
> opens zip files on gnome.
>
> I use xdg-desktop-menu to install .desktop files (because autopackage API
> can't create sub-menus). You can try that.
>
> On Ubuntu 10 xdg-desktop-menu (and I would expect autopackage code too)
> doesn't work properly (needs to call update-gnome-menus-cache). But I'm not
> sure if that affects file associations at all.
>
> BTW, did you try forcing you app to be default handler? Install mime type,
> then install desktop file, then run:
> xdg-mime default app.desktop mimetype
>

> On Wed, Apr 28, 2010 at 8:41 AM, alejandro <ahmosto...@gmail.com> wrote:
> > Hi Eugene, and thanks for answer again.
> > I've tried to install mime types using xdg-mime and it works, better
> > than that, it helped me to correct the application.xml file. But my
> > real problem is how to associate my application with that mime type,
> > that is what I can't make.
> > When I use the ".package" it change the mime type of files, but
> > doesn't associate the application with them.
> > I don't know where trouble could be.
>
> > I was reading some pages (man, web, etc) and saw that there is a
> > command, like update-mime-database, "update-desktop-database" which
> > must be run after install a .desktop file. (see
>

> >http://library.gnome.org/admin/system-admin-guide/stable/mimetypes-re...
> > ).

[Eugene Zolenko]

1) It seems UI you are using to edit cmd line expects just the binary path and adds %f itself. That's why you get %f %f in generated desktop file. Desktop file you make yourself should contain one %f.

2) Not sure what is supposed to generate those...

What happens on double click? Does it show "open with" dialog, or does it seem to do nothing at all?

Can you post your shell script and check permissions on it. Maybe it assumes certain working directory or doesn't have executable bit set or needs some environment, or something simple like that.

Make sure this works:

$ cd /

$ /home/user/.local/bin/myapp.sh "path to file"

Also, there is a certain difference if your script starts with #!/bin/bash or not. All our apps have shell script wrappers (to bypass LD_LIBRARY_PATH), and I had to remove #!/bin/bash or some of them wouldn't start in some cases. I haven't figured out why and when exactly...

[alejandro]

Hi Eugene,

When I try to open files with double click nothing happens.
I check shell script permissions and it's ok (755) and $PATH have the
directory where the script is.
I also try deleting the #! /bin/bash but It doesn't work.
If I execute the script from command line it works fine.

Here is the script:

#!/bin/bash

CALLNAME=$0
CALLDIR=${CALLNAME%/*}
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:"$CALLDIR/../lib"
"$CALLDIR"/myapp "$1"

Thanks (one more time).
Alejandro.

On Apr 28, 9:08 pm, Eugene Zolenko <zolen...@gmail.com> wrote:
> 1) It seems UI you are using to edit cmd line expects just the binary path
> and adds %f itself. That's why you get %f %f in generated desktop file.
> Desktop file you make yourself should contain one %f.
>
> 2) Not sure what is supposed to generate those...
>
> What happens on double click? Does it show "open with" dialog, or does it
> seem to do nothing at all?
>
> Can you post your shell script and check permissions on it. Maybe it assumes
> certain working directory or doesn't have executable bit set or needs some
> environment, or something simple like that.
>
> Make sure this works:
>
> $ cd /
> $ /home/user/.local/bin/myapp.sh "path to file"
>
> Also, there is a certain difference if your script starts with #!/bin/bash
> or not. All our apps have shell script wrappers (to bypass LD_LIBRARY_PATH),
> and I had to remove #!/bin/bash or some of them wouldn't start in some
> cases. I haven't figured out why and when exactly...
>

[Eugene Zolenko]

That definitely looks like your file associations are ok, and your script is launched, but your app fails.

If you want to see exactly what's wrong, do something like this:

#!/bin/bash

set -x

{

# your code here

} > /tmp/myapp_std 2> /tmp/myapp_err

Then see if those files are created and what's inside.

Few things to fix in your script: 

- If you are building your binary with apg++, you already have ../lib rpath (check with readelf -d myapp, look for RPATH). In this case you don't need to set LD_LIBRARY_PATH, or rather, you need to set is to be empty. If you are not building with apg++, you should (http://www.autopackage.org/aptools.html). Or just set rpath yourself when you link (-Wl,--rpath -Wl,"\$origin/../lib").

- Change your call dir to this:

CALLDIR="$(cd "$(dirname "$0")"; pwd)"

(make it full absolute path, your original won't work if script runs from PATH I think)

- Change you launch command to this:

"$CALLDIR/myapp" "$@"

(passing all arguments to the app, no reason to cull them to 1)

[alejandro]

Thanks Eugene for all.
I'll try these changes and let you know the results.

Thanks.
Alejandro.

On Apr 29, 1:20 pm, Eugene Zolenko <zolen...@gmail.com> wrote:
> That definitely looks like your file associations are ok, and your script is
> launched, but your app fails.
>
> If you want to see exactly what's wrong, do something like this:
>
> #!/bin/bash
> set -x
> {
> # your code here
>
> } > /tmp/myapp_std 2> /tmp/myapp_err
>
> Then see if those files are created and what's inside.
>
> Few things to fix in your script:
>
> - If you are building your binary with apg++, you already have ../lib rpath
> (check with readelf -d myapp, look for RPATH). In this case you don't need
> to set LD_LIBRARY_PATH, or rather, you need to set is to be empty. If you
> are not building with apg++, you should (http://www.autopackage.org/aptools.html). Or just set rpath yourself when
> you link (-Wl,--rpath -Wl,"\$origin/../lib").
>
> - Change your call dir to this:
> CALLDIR="$(cd "$(dirname "$0")"; pwd)"
> (make it full absolute path, your original won't work if script runs from
> PATH I think)
>
> - Change you launch command to this:
> "$CALLDIR/myapp" "$@"
> (passing all arguments to the app, no reason to cull them to 1)
>

> ...
>
> read more »