XFCE 4.2Beta1 and 2 has a problem parsing the ".desktop" entries normally put by KDE in /usr/share/applink. Several KDE-original entries only have: [Desktop Entry] Encoding=UTF-8 Hidden=true --------- Error messages go into .session-errors file in home user directory and amount to 1M per day of use: (xfce4-panel:17411): libxfce4util-WARNING **: Unable to parse .desktop file '/usr/share/applnk//Applications/kalarm.desktop' I think that the error is not really of XFCE, but in any way for those that have KDE installed there is not much to do, except editing one by one, adding for instance an entry with "OnlyShowIn=KDE;" - atopugh work, or uninstall KDE if possible (for me, it is not!) But if it is possible to silent ignore those entries, it would be good.
In complement of bug submission, I want just to add something that I saw in the parsing errors and looked at freedesktop.org in Desktop Entry Specification 0.9.4: - all errors in my situation happen with files that have only the entries described before, in particular with a "Hidden=true" one. From the specs, it seems that this entry is used to mean a "deleted" entry: "Hidden should have been called Deleted. It means the user deleted (at his level) something that was present (at an upper level, e.g. in the system dirs). It's strictly equivalent to the .desktop file not existing at all, as far as that user is concerned. This can also be used to "uninstall" existing files (e.g. due to a renaming) - by letting make install install a file with Hidden=true in it." IMHO these files should be ignored by xfce4-panel; from a forum comment by Benedikt, it seems that the understanding is that KDe is putting garbage in desktop files. I hope that this could be of help.
hmm... from the looks of where the error message is, our .desktop file parser is failing to even read the file properly (rather, it reads the file, but can't make sense of it). that doesn't really have anything to do with the lack of proper entries in it. not sure what's going on here, but i'll look into it if i get the chance.
Regarding Benny's comment, in one of my machines, I did an experience, changed all the .desktop files listed in error messages to include the entry OnlyShowin=KDE;" and now there is no more error messages. So I still think that the handling of the "Hidden" entry is not correct, in discarding the .desktop file that includes it.
(In reply to comment #3) > Regarding Benny's comment, in one of my machines, I did an experience, changed > all the .desktop files listed in error messages to include the entry > OnlyShowin=KDE;" and now there is no more error messages. what comment of benny's are you referring to? > So I still think that the handling of the "Hidden" entry is not correct, in > discarding the .desktop file that includes it. i'm not sure i know what you mean. are you saying that, even if "Hidden=true" is in the file, we should show it in the menu? at any rate, that's not the problem here; the XfceDesktopEntry parser isn't even able to parse the file, so we're not even getting to the point where we can decide whether or not to include it or not.
(In reply to comment #4) >> Regarding Benny's comment, in one of my machines, I did an experience, changed >> all the .desktop files listed in error messages to include the entry >> OnlyShowin=KDE;" and now there is no more error messages. >what comment of benny's are you referring to? Benedikt Maurer in xfld.org forum commented en passant that the parsing error message is caused by some fault .desktop entries inserted by KDE and could be ignored. That prompted me to search why KDE is accepting and I saw the common pattern of all files with errors. >> So I still think that the handling of the "Hidden" entry is not correct, in >> discarding the .desktop file that includes it. >i'm not sure i know what you mean. are you saying that, even if "Hidden=true" >is in the file, we should show it in the menu? at any rate, that's not the >problem here; the XfceDesktopEntry parser isn't even able to parse the file, so >we're not even getting to the point where we can decide whether or not to >include it or not. Not even if "Hidden=true" is present, but BECAUSE it is in the file, you should abort the processing without any message, skipping and not including it, as it means that it a "deleted" and possibly incomplete file. It seems that the code is not prepared for this particular case. I hope that now my hypothesis is clear to you; sorry if my Brazilian English sometimes makes things more difficult to understand.
(In reply to comment #5) > Not even if "Hidden=true" is present, but BECAUSE it is in the file, you should > abort the processing without any message, skipping and not including it, as it > means that it a "deleted" and possibly incomplete file. It seems that the code > is not prepared for this particular case. ok, that's fine, and that's the intended behavior. the problem is that there's either something wrong with the files themselves, or something wrong with the .desktop file parser in xfce. we don't even get to the point where we can see if there's a Hidden= field at all; the parser fails to understand the file's contents. could you attach one of the problem files to this bug?
Created attachment 92 .desktop sample for bug 438 Sample .desktop file that is parsed with error by xfce4-panel (Bug 438)
File attached. It is a text file with the same contens I put in the original bug submission. By the way, why xfce4-panel parses .desktop files over and over, to rebuild the menu? It shouldn't be easier to let the user to ask fot the reparsing?
(In reply to comment #8) > By the way, why xfce4-panel parses .desktop files over and over, to rebuild the > menu? It shouldn't be easier to let the user to ask fot the reparsing? it doesn't do it over and over. it just watches for directory changes on the file system and rebuilds when needed. easier? sure, from the development side, but not from the user's point of view. (btw, it's not the panel, it's the menu plugin. xfdesktop does the same thing.)
This is a strange bug. Hope we can find the problem soon.
Right, I just dumped the file in /usr/share/applications/ and I don't see any problems. Brian, benny, have you been able to reproduce this bug?
actually, i haven't gotten around to trying yet, as this is pretty low on my priority list. jasper, did it print out any warnings when regenerating the desktop menu?
(In reply to comment #12) > actually, i haven't gotten around to trying yet, as this is pretty low on my > priority list. jasper, did it print out any warnings when regenerating the > desktop menu? Ok, update. I do not get the error with xfdesktop or the menu plugin, but I do get it from appfinder. Any ideas?
(In reply to comment #13) > (In reply to comment #12) > > actually, i haven't gotten around to trying yet, as this is pretty low on my > > priority list. jasper, did it print out any warnings when regenerating the > > desktop menu? > > Ok, update. I do not get the error with xfdesktop or the menu plugin, but I do > get it from appfinder. Any ideas? Right, I have just removed the warnings from the library. There may be valid reasons why the parsing fails (like not having the entries the app is looking for). The warnings should be gone in the next pre-release (RC1). Thanks.