-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I have built a spec file for rasmol 2.7.5
http://www.five-ten-sg.com/rasmol.spec
based on an earlier one from Mandrake. It now builds and seems to run on Fedora 12. This spec file clearly needs some changes:
1) There were some menu icon references to files that are no longer in the package, but there is a rasmol_48x48.xpm image. What is the preferred mechanism to create menu icons, where do they go, etc?
2) There does not seem to be much point in creating gui icons for this, since it seems to be intended to run from a command prompt in a terminal. The program uses stdin to read commands, and the data is then displayed in a graphic window. Unless there is an easy way to create an icon that launches a gnome-terminal which in turn runs the rasmol binary, and allows the user to then type commands into that terminal session.
On Tue, 2009-11-24 at 15:05 -0800, Carl Byington wrote:
- There were some menu icon references to files that are no longer in
the package, but there is a rasmol_48x48.xpm image. What is the preferred mechanism to create menu icons, where do they go, etc?
Follow the fd.o icon theme specification: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
the short version is that at a minimum you should stick an icon with the same name as the binary, extension / file format .png, in /usr/share/icons/hicolor/48x48/apps . If upstream provides icons in any other resolution, include those in the appropriate directory; if upstream provides an SVG, include it in /usr/share/icons/hicolor/scalable/apps . The .desktop file should list the icon as simply the main part of the filename, with no extension (so if the icon is rasmol.png , the .desktop file should state Icon=rasmol ). However, see below...
- There does not seem to be much point in creating gui icons for this,
since it seems to be intended to run from a command prompt in a terminal. The program uses stdin to read commands, and the data is then displayed in a graphic window. Unless there is an easy way to create an icon that launches a gnome-terminal which in turn runs the rasmol binary, and allows the user to then type commands into that terminal session.
...that sounds like you shouldn't ship a menu entry at all, to me. As you say, it would be rather pointless. But I dunno if there's a policy requirement that you should anyway.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
the short version is that at a minimum you should stick an icon with the same name as the binary, extension / file format .png, in /usr/share/icons/hicolor/48x48/apps .
That did not work for me, but if I put the converted .png icon in /usr/share/icons it works nicely.
...that sounds like you shouldn't ship a menu entry at all, to me. As you say, it would be rather pointless. But I dunno if there's a policy requirement that you should anyway.
It turns out to be trivial to have the desktop file launch the program from within a gnome-terminal
Terminal=true
which does exactly what I want.
Updated spec file at http://www.five-ten-sg.com/rasmol.spec incorporating many changes from Terje Rosten. Thanks!
On Wed, 2009-11-25 at 12:04 -0800, Carl Byington wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
the short version is that at a minimum you should stick an icon with the same name as the binary, extension / file format .png, in /usr/share/icons/hicolor/48x48/apps .
That did not work for me, but if I put the converted .png icon in /usr/share/icons it works nicely.
That's the 'old' system and really shouldn't be used. What you probably missed is the bit I missed from my original email - when using the new system you need to add these snippets:
%post touch --no-create %{_datadir}/icons/hicolor &>/dev/null || :
%postun if [ $1 -eq 0 ] ; then touch --no-create %{_datadir}/icons/hicolor &>/dev/null gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : fi
%posttrans gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
to the spec. Otherwise the icon cache doesn't get updated so the icon won't be available.
...that sounds like you shouldn't ship a menu entry at all, to me. As you say, it would be rather pointless. But I dunno if there's a policy requirement that you should anyway.
It turns out to be trivial to have the desktop file launch the program from within a gnome-terminal
Terminal=true
which does exactly what I want.
ah, I see. I misunderstood you as suggesting that you need to pipe data to rasmol at startup to make it useful, obviously that's not the case :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 2009-11-25 at 12:17 -0800, Adam Williamson wrote:
That's the 'old' system and really shouldn't be used. What you probably missed is the bit I missed from my original email - when using the new system you need to add these snippets:
Thanks! That works nicely. New spec file at:
http://www.five-ten-sg.com/rasmol.spec
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
koji scratch build now works.
http://www.five-ten-sg.com/rasmol.spec http://www.five-ten-sg.com/rasmol-2.7.5-5.fc12.src.rpm
2009/11/29 Carl Byington wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
koji scratch build now works.
http://www.five-ten-sg.com/rasmol.spec http://www.five-ten-sg.com/rasmol-2.7.5-5.fc12.src.rpm
[..]
Cool! Update your review request.
On 11/24/2009 10:50 PM, Adam Williamson wrote:
But I dunno if there's a policy requirement that you should anyway.
FWIW, the policy says:
"If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window."
https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files
So, the rasmol app doesn't meet that criteria, so a .desktop file is not required (although, it is worth noting that it is also permitted if the maintainer wishes to do so).
~spot
-
Adam Williamson -
Carl Byington -
Rakesh Pandit -
Tom Callaway