Bug 104471

Hi,
Are you sure that it's not a problem in gnome ?

Regards

This is KPDF related code:
    // this calls the above 'openURL' method
    bool b = KParts::ReadOnlyPart::openURL(url);
    if ( !b )
        KMessageBox::error( widget(), i18n("Could not open %1").arg( url.prettyURL() ) );
    return b;

This means that "url" is "file:/home/sits/%i" then "file:/home/sits/%m" then finally the right URL.
This *could* mean that KPDF is called using a string like:
# kpdf %i %m Desktop/pdfaccess.pdf

Tests (nicolas: please do):
- how many kpdfs are launched? (1-2-3?)
- does it happens again on next executions?
- can you check the associations of application/pdf or application/x-pdf mimetypes (file associations) ?

Thanks a lot!

Seems to me that gnome isn't expanding %i, %m, %c properly. (Note also the %c --- it's not changing that properly, too) They should never get to the app.  IMHO, INVALID

the reporter on Mandriva Linux Bugzilla have answered this:

"Well it's easily reproducable if you have GNOME installed (hint hint) but anyway:

- 3 are launched but the next one will not start until you have OK'd the error
dialog of the previous one.
- This is reproducable every time.
- Where do I do this? Surely you can do this as well as I can by looking at
/usr/share/applications/kde/kpdf.desktop (which says application/pdf btw)?

Another thing to note is that the Exec line for kdpf is:
Exec=kpdf %i %m -caption "%c"

%i, %m and %c don't strike me as being non-portable between DEs and there is no
mention of % codes in http://standards.freedesktop.org/menu-spec/menu-spec-0.9.html"

hint hint, why should i have gnome installed?

Can i know why you are looking at the menu-spec and not at the desktop-spec http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-0.9.4.html that defines 

%c The translated Name field associated with the desktop entry.
%i The Icon field of the desktop entry expanded as two parameters, first --icon and then the contents of the Icon field. Should not expand as any parameters if the Icon field is empty or missing.
%m (the mini-icon associated with the desktop entry, this should be expanded as two parameters, --miniicon and the content of the MiniIcon field, it can also be ignored by expanding it to no parameters). (This last one is deprecated, ok)

So it seems is more a gnome fault than a kpdf fault, isn't it?

Not related to the bug, but taking the opportunity to comment:
Shouldn't the Exec= line mention %U somewhere?

KPDF supports multiple URLs being passed on its command-line. It doesn't seem that %f is correct.

Thiago we don't have any %f :-D
Maybe that's the problem? I think i'll install gnome this afternoon and check, it'll be quicker.

> Thiago we don't have any %f :-D 

Actually, you do. The fact that there is no %u, %U or %F implies that the program takes %f: one, single filename. Since KPDF can open multiple files, and they can be given as URLs, %U should be used.

Now, this could be the cause of the bug in GNOME: there are %-substitutions, but no %[ufUF]. In any event, they have a bug they should fix.

I'm the original reporter. I didn't know this bug had gone upstream and that I was talking to you via a third party. If I had I would have posted here directly.

OK to the questions:
hint hint, why should i have gnome installed?
Well maybe you want to test interoperability or because it makes it easier/quicker to work out whether an issue is valid or not.

Can i know why you are looking at the menu-spec and not at the desktop-spec?
Because I made a stab in the dark to explain why it was happening and no one told me any better. I knew I was looking for something and I presumed that since the files that set up the handler were menu ones, any parameters would be specified in the document descriping menu files. Perhaps if there had been some more instructions saying "parameters are defined over in this url" I would have found the right one. As it happens you corrected me here.

Further to your comments I shall try punting the downstream bug to a mandriva GNOME dev to see what they say.

CVS commit by aacid: 

fix gnome's unability to understand that if there is no %u, %U or %F implies that the program takes %f
Add %U as we can accept a full list of url's
Backporting in a moment
BUG: 104471


  M +1 -1      kpdf.desktop   1.6


--- kdegraphics/kpdf/shell/kpdf.desktop  #1.5:1.6
@@ -65,5 +65,5 @@
 GenericName[zh_CN]=PDF 查看器
 GenericName[zu]=Umboniseli we PDF
-Exec=kpdf %i %m -caption "%c"
+Exec=kpdf %U %i %m -caption "%c"
 Icon=kpdf
 Type=Application

Hi Sitsofe the bug has been "fixed" in our part but you could try to contact the gnome guys and told them they have a bug in their .desktop handling, the thing is that Mandr(ake|iva) uses "old" 2.8.3 instead of 2.10.1 where this may have already been fixed.

I have to admit I'm a shade unclear as to the exact nature of the GNOME bug. Is it the case that with a %u/%U/%F no %f is implictly added to the end AND all percentage args are treated as not being special? Or is it as Comment #3 puts it that % parameters other than %u/%U/%F/%f are never understood? How is your patch (which I have tested and worksforme) working around the problem? Does GNOME disgard everything after a %U?

This is a guess, I don't know GNOME code nor have I tested:

.desktop Exec= lines can have a number of %-substitutions, including some that contain the URL, pathname, filename or dirname of the associated file. When none of the %-tags indicating what the program is able to handle, the spec says %f should be assumed.

This means:
Exec=kpdf
should be understood as:
Exec=kpdf %f

Whereas
Exec=kpdf -caption "%c"
should be understood as:
Exec kpdf -caption "%c" %f

GNOME probably detects the absence of %-tags in the first case, and the presence of at least one %-tag in the second. The thing is, %c (and %i and %m) does not contain any part of the filename/URL selected, so %f should still be added. The bug must be here.

Surely if %f were not being added at all then the wanted file would ever be opened at all? In my original bug I said the following happened:
"kpdf pops up two error dialogs. The first says:
Error - %c
Could not open file:/home/sits/%i

After dismissing that dialog another pops up saying:
Error - %c
Could not open file:/home/sits/%m

After dismissing that dialog kpdf opens the requested PDF."

Ok, another guess:

it sees there is no %f, %F, %u or %U, so it decides there is no %-tag. Therefore, it just appends the filename to the Exec= line, without processing it. The result is it runs:
  kpdf %m %i -caption "%c" /tmp/file.pdf

Makes more sense now.

The problem was acknowledged to be a weakness in gnome-vfs downstream and a bug and patches have gone to upstream GNOME. Thanks for your narrowing this down despite my obstinate comments : )

Salut les copains - lal discussion entre Montel, Ross, Orlovich sans oublier Lécureuil qui je l'espère me comprendra sans doute,à défaut des précités ... la discussion ne manquait pas d'intéret, mais plus prosaïquement il se trouve que j'ai eu la surprise après avoir nagiqué au milieu de votre discussion d'imprimer une sorte de "Jack-pot" ...

plus précisément ... une première page en Français (premier émerveillement) titrant "Manuel de KPDR" suivi de la table des métières du dit Manuel, toujours en français ...

Ici ça se gate ... toutes les pages suivantes c'était la discussion entre les une dizaine d'anglophones dont les 4 "précités"

je me dis que si la table des matières existe en bel et bon Frrançais, le pages formant le corps du Manuel doivent se trouverl quelque part ...

Hélas je n'arrive pas à les trouver ...

une Grand Merci à celui qui me permettra de les trouver et de les imprimer.

A bientôt.

joel.gazel@wanadoo.fr

Please speak English on KDE bugs not realted to localization. And please don't remove other people's CC from the bug CC list.