same results here, maybe you could investigate /etc/xdg/menus/applications.menu , http://www.freedesktop.org/wiki/Specifications/menu-spec?action=show&redirect=Standards/menu-spec and http://standards.freedesktop.org/desktop-entry-spec/latest/ , xdg-utils seems promising too.
please, share if you find out wy to have more categories lead menu entry to disappear.
Converted packages don't have Applications menu shortcuts(34 posts) (7 voices)
Install package desktop-file-utils-extra, validate .desktop files in this way:
$ desktop-file-validate ./bleachbit.desktop
./bleachbit.desktop: hint: value "GTK;System;Settings;" for key "Categories" in group "Desktop Entry" contains more than one main category; application might appear more than once in the application menu
./bleachbit.desktop: warning: key "Encoding" in group "Desktop Entry" is deprecated
$ desktop-file-validate ./bleachbit-root.desktop
./bleachbit-root.desktop: hint: value "GTK;System;Settings;" for key "Categories" in group "Desktop Entry" contains more than one main category; application might appear more than once in the application menu
./bleachbit-root.desktop: warning: key "Encoding" in group "Desktop Entry" is deprecated
Cite from SliTaz /etc/xdg/menus/applications.menu:
<!-- System Tools--> <Menu> <Name>System</Name> <Directory>SystemTools.directory</Directory> <Include> <And> <Category>System</Category> <Not><Category>Settings</Category></Not> </And> </Include> </Menu> <!-- Settings --> <Menu> <Name>Settings</Name> <Directory>Settings.directory</Directory> <Include> <And> <Category>Settings</Category> <Not><Category>System</Category></Not> </And> </Include> </Menu>
In other words, entry appears in System if it is in System Category and not Settings. And vice versa. System and Settings are antagonists here.
Utilities=(Utility) and not(System,Graphics)
Multimedia=(AudioVideo) and not(Utility)
System=(System) and not(Settings)
Settings=(Settings) and not(System)
Utility;System → System
Utility;Graphics → Graphics
Utility;System;Graphics → System and Graphics
AudioVideo;Utility → Utilities
System;Settings → nowhere
I think, we need to change System rule to make it less strict [PS. commited]. Like this:
<!-- System Tools--> <Menu> <Name>System</Name> <Directory>SystemTools.directory</Directory> <Include> <And> <Category>System</Category> </And> </Include> </Menu>
Also, I want to tell, that Categories like GTK, GNOME, Qt have no the least sense to our Application menu, we can delete them.
And, interesting, if SliTaz menu works with sub-menus? Like Games→Board. Hmm, worth a try ;)
In addition, I want to tell a word about TazPkg convert. It's just a repacking from one form of archive to another (plus rewrite some package related infos). It's not TazPkg fault if converted package have no menu entry (if original package have no it).
Yahoo, it works! :D
@mojo, thanks, that worked for me, too, but TazPKG now gives notification that I have 1 upgrade package and it's, wait for it... BleachBit 0.9.3. :D Oh, man!
I'd like to point out, if it's not clear already, these are both originally Debian installation packages from official websites which are converted with TazPKG, otherwise untouched. So, any inconsistency or antagonism or conflicting entries, lines, etc is automatically created during the conversion.
This and with respect to Aleksej's post, am I right to assume that this will be a common problem with converted packages?
Package conversion isn't perfect, which is why the
tazpkg packcommands exist. Together they can allow you to modify packages to correct any bugs that may come up.
bleachbit 0.9.4 can't be an offical debian package:
if you refer to
as the source of your download, please check desktop file inside the deb and you will find that it's different from the ones inside official debian packages.
i think tazpkg did not alter it.
tazpkg proposing to downgrade bleachbit it's, in my opinion, a fault, but this is another matter.
you could recook bleachbit upgrading to 0.9.4 or you could try
tazpkg block bleachbit
@Trixar_za: That's OK, but what is the bug with Opera, then? Its .desktop file, to be specific? BTW, I've desktop-file-validate'd it and got no result, no output message at all, nothing. So, I assume it's a good thing, but it's still not working as it should.
Funny thing is "get-opera" from Packages list downloads an Opera v12.02 Debian package, converts it to tazpkg format and installs it. It worked in the begining, when the OS installation was relatively fresh, but now it is broken the same way as "my" converted one: has no shortcut. The installer removed existing Opera installation.
This is the Categories line:
Anyway, I'm getting really tired of this.
As a temp "solution", I've reinstalled 12.12 and made a shortcut on the desktop, so that'll do for now. The problem isn't solved, just avoided.
@ernia: I never said it were an official package, just that it's a .deb one. Does it change anything? I don't think so.
If you don't look inside them you will never know.
I don't need to know. Debian devs could go on for months, years even and not declare, in this instance, BleachBit v0.9.4 an official Debian version, whereas Red Hat could take just two days to do the same for Fedora or RHEL. And when I use both .deb and .rpm for conversion, I must get two absolutely equal .tazpkgs, by definition. I got these .debs by chance, not conscious choice, could've easily been .rpms.
You're expecting Ubuntu/Debian in 35Mb except SliTaz is not Ubuntu/Debian and some assembly is required when using it.
I tell people one of the reasons I use SliTaz is because it provides you with the tools to fix the problem yourself. I created http://trixarian.net/SliTaz using Debian packages and the three tazpkg commands I mentioned above. If your dropping SliTaz because one package is out of date by a single zero point version and very little code changes then I'm sorry, but you're being unreasonable. I'll also call bullshit on claiming it's an 'official' package, when it's not even in the official (stable) repository of Debian or Ubuntu. Just to spite you, I'll up Bleachbit's version.
not to mention that the wrong desktop file comes from his deb, debian's debs are ok.
but he didn't bother to test.
While I'm at it: It does created the shortcuts, but not where our package places them. If memory serves it puts the shortcuts of the converted Debian package in the Utilities menu and not the System Tools menu like ours. Also the "Bleachbit as Administrator" shortcut won't work without modification.
WTF? "Just to spite me"?
Where did I write that I expect Slitaz to be Ubuntu or Debian, or mentioned anything about not using it anymore just because of this? Stop putting words in my mouth.
Concerning BleachBit (or Opera, or any other piece of software), I got a notification of a new version inside the program itself, so I went to its official site and got the new version.
"OFFICIAL" as in: PROGRAMS' OFFICIAL WEBSITES (opera.com, bleachbit.sourceforge.net). Not some OS' definition what's official. Call bullshit as much as you like. Start reading correctly and you will see I in which context I used the term "official". http://forum.slitaz.org/topic/converted-packages-dont-have-applications-menu-shortcuts/page/2#post-20641 Ernia made this confusion, not me.
Tazpkg claims it can convert a proper .deb package (doesn't say it has to be "an official package", whatever that means) to a Slitaz-friendly .tazpkg. I have done that and installed it, nothing more. So, if it puts certain files in the wrong dirs, as you wrote above, then it's Tazpkg's fault, not mine, and the program doesn't deliver what it claims.
@ernia: you wrote at least twice you can't help me. You made enough confusion with this "official" stuff. Please, stop posting and polluting.
@everyone else, if you have similar problems and solutions for them, please, post them. They are appreciated.
You must log in to post.