These are just some minor suggestions for future UN*X versions. Perhaps some of them might be relevant enough for an official release.
- Menu entries.
The current version does not create them. At least KDE and GNOME now have a unified desktop menu. The specification is here:
http://standards.freedesktop.org/deskto ... 0.9.4.html
Basically, everything that we need is a plain text file in /usr/share/applications and a PNG icon in /usr/share/pixmaps.
The plain text file should be named xnview.desktop and contain the following:
[Desktop Entry]
Name=XnView
GenericName=Image Viewer
Type=Application
Exec=xnview
Icon=xnview.png
Categories=Application;Graphics;Viewer
The PNG icon should be named xnview.png and be 48x48 in size. The best icon would be the same that is compiled into the executable, i.e. the same as the favicon.ico from this website.
The xnview.desktop file can also be extended by specifying the MIME types that XnView can handle, but it's not strictly necessary.
These paths, /usr/share/applications and /usr/share/pixmaps, are unified for at least the major Linux distributions, i.e. RedHat, Fedora, Mandriva, SuSE, this means that a single RPM for all distributions is sufficient. The tarball release should also contain these files for people who want to manually copy them where they belong.
- HTML help.
It has been discussed before, I just want to mention it once again. I did a chmdump on the Windows CHM file successfully and got single HTML pages and images. chmdump is available here:
http://sourceforge.net/projects/modchm/
Don't build the apache module, instead change into the chmdump directory and run make. It will compile a simple chmdump program. You need chmlib in order to compile chmdump:
http://66.93.236.84/~jedwin/projects/chmlib/
The resulting files are a little bit Windows-specific, but still helpful. Only an index.html is missing, but it can be generated.
The HTML help should be installed somewhere in /usr/share/doc/XnView.
By the way, /usr/doc and /usr/man are no longer allowed by the Filesystem Hierarchy Standard. /usr/share/doc and /usr/share/man are correct:
http://www.pathname.com/fhs/pub/fhs-2.3.html
- JPEG 2000 rendering support.
I know that JPEG 2000 generation is difficult, but rendering should not be. The Windows version uses JasPer for that. JasPer itself is highly portable and has very friendly, permissive licensing terms.
There are so few JPEG 2000 viewers out there for UN*X, it's sad. I know only /usr/bin/display from the ImageMagick package and a patched version of XV, but XV is hopelessly outdated and the patch is unofficial and ImageMagick is mainly a command-line tool and not a viewer for the desktop.
It would be so nice if XnView brought JPEG 2000 to UN*X, maybe it's possible to port the JPEG 2000 rendering support from Windows to UN*X.
Please add further suggestions here,
David
Suggestions for future UN*X versions
Moderators: XnTriq, helmut, xnview
Another idea, also related to desktop integration:
XnView could expose to the desktop environment which file types it can handle. This can be done by installing a file named "XnView.xml" into "/usr/share/mime/packages" and running "/usr/bin/update-mime-database /usr/share/mime" afterwards from the RPM package.
This way, XnView will immediately appear in the context menu of file types that it can handle, very similar to what it does on Windows. This works for both KDE and GNOME. I can help with these things if you wish, writing the ".desktop" and ".xml" and ".spec" files and so on.
Another thing is that XnView seems to call the web browser in a strange way. If no web browser is opened and I open XnView from the shell and click "Visit XnView's Web Site", it says "netscape: command not found", but if either Mozilla or Firefox is already running, it opens a new window in the already running one, even if it is not Netscape.
And some very minor suggestions as well: The RPM can be localised, it's actually very easy, just put "Summary(fr)" and "Summary(de)" and "%description -l fr" and "%description -l de" under "Summary" and "%description" in the ".spec" file.
I will add more suggestions as soon as they come.
XnView could expose to the desktop environment which file types it can handle. This can be done by installing a file named "XnView.xml" into "/usr/share/mime/packages" and running "/usr/bin/update-mime-database /usr/share/mime" afterwards from the RPM package.
This way, XnView will immediately appear in the context menu of file types that it can handle, very similar to what it does on Windows. This works for both KDE and GNOME. I can help with these things if you wish, writing the ".desktop" and ".xml" and ".spec" files and so on.
Another thing is that XnView seems to call the web browser in a strange way. If no web browser is opened and I open XnView from the shell and click "Visit XnView's Web Site", it says "netscape: command not found", but if either Mozilla or Firefox is already running, it opens a new window in the already running one, even if it is not Netscape.
And some very minor suggestions as well: The RPM can be localised, it's actually very easy, just put "Summary(fr)" and "Summary(de)" and "%description -l fr" and "%description -l de" under "Summary" and "%description" in the ".spec" file.
I will add more suggestions as soon as they come.
OK, by reading the executable with the "strings" tool I found out that it is not true that "netscape" is hard-coded. XnView uses the $WEBBROWSER environment variable and defaults to Netscape only if $WEBBROWSER is not set.
But that reminds me of something else: Would't it be nice to have all these things documented? I couldn't find that documented anywhere, only by examining the executable directly. What do other people think about that? I can help writing such a document.
But that reminds me of something else: Would't it be nice to have all these things documented? I couldn't find that documented anywhere, only by examining the executable directly. What do other people think about that? I can help writing such a document.
Re: Suggestions for future UN*X versions
I couldn't compile the packaged chmdump on my 64 bit machine - Your procedure works.