#16 fix icon target dir and spec file

closed-accepted
nobody
None
5
2008-10-12
2008-09-17
No

Attached patch fixes icondir and the spec file.

There are only two legal desktop icon destinations: {datadir}/icons/{theme}/{size}/{class}/{image}.{sfx} for icons provided in multiple sizes and themes and {datadir}/pixmaps/{image}.{sfx} for single icon.

Discussion

  • Stanislav Brabec

    Please note that pixmaps dir (proposed in the patch) is deprecated according to the current xdg@lists.freedesktop.org discussion:

    As per the Icon Theme Specification and the Icon Naming Specification,
    your icon name should match the binary name of your application, and
    be installed in the hicolor icon theme's apps context directory.

    /usr/share/icons/hicolor/48x48/appname.png
    /usr/share/icons/hicolor/32x32/appname.png
    /usr/share/icons/hicolor/22x22/appname.png
    /usr/share/icons/hicolor/16x16/appname.png

    These are the most important sizes to provide with your application.

    But unless you prepare more sizes of the application icon, I see no problem with attached patch.

     
  • Guilhem BONNEFILLE

    I'm not sure to understand.

    I think we have to rename viking_icon.png to viking.png.

    But I'm not sure we have to install it elsewhere.
    Are you sure we have to provide 4 icons? Or could we just install our viking.png to /usr/share/icons/hicolor/48x48 (as it is a 48x48)?

     
  • Stanislav Brabec

    Here is a new patch, which uses icon path recommended by Freedesktop.

    Altogether with applying it, you need to do:
    svn mv src/icons/viking_icon.png src/icons/viking.png

    Path provided in the XDG mail cut-and-paste was incorrect.

    It is OK to provide just one icon, but 4 icons (or eventually scalable svg) are recommended.

    It also fixes following minor two-liners:
    - make distcheck fixed by adding missing files to po/POTFILES.in
    - missing BuildRequires were added to viking.spec.in
    - missing files in the list were added to viking.spec.in
    - desktop file GenericName and Categories: viking is not a network application (e. g. browser, mailer). It may be considered as a Graphics, but sub-category Maps does not exist there (maybe it may be Categories=Education;Science;Geography;Graphics;2DGraphics;GTK; as well): http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html

    Following tests were provided:

    - make distcheck works

    - Icon is visible in GNOME menu imediately after "make install"

    - Icon is visible in viking

    - desktop file-validate shows no warning

    Some distributions (openSUSE) don't know Geography category yet, so viking is displayed in unsorted icon stuff. But it is fault of distributions, not viking.
    File Added: viking-icon.patch

     
  • Guilhem BONNEFILLE

    Why did you remove Viking fro Graphics category?

    I feel a mismatch between your comment ("It may be considered as a Graphics") and the patch (removing from Graphics).

     
  • Stanislav Brabec

    "It may be considered as a Graphics" means: yes, viking can be considered as graphics software. Removing from Graphics means, that Freedesktop categories specification lacks better category for mapping software than Education;Science;Geography.

    So just now, the patch is correct.

    I have opened a thread on XDG mailing list to define better category, e. g.: "Categories=Graphics;Geography;":
    http://lists.freedesktop.org/archives/xdg/2008-September/009969.html
    Feel free to join discussion or comment there.

    But it may take a year or so before new category will be accepted and implemented in menu systems, so I propose the patch as is.

     
  • Stanislav Brabec

    Alternatively, you can use "Categories=Education;Science;Geography;Graphics;2DGraphics;GTK;". It will probably show viking twice in the menu system, once in Graphics and once in Science or Education. Exact look of the menu depends on /etc/xdg/menus/applications.menu contents.

    Here is the actual specification: http://standards.freedesktop.org/menu-spec/menu-spec-latest.html#category-registry
    You should to use at least one primary category. For each primary category you use, you should use at least one secondary category, which has this primary category listed as related category.

     
  • Guilhem BONNEFILLE

    What's the matter with two (or more) entries?

    The program evolution appears in Office and Network.

     
  • Stanislav Brabec

    The main purpose is an usability of the menu: Users should be able to find program quickly in the sub-menu where they would search for it. If there are two good fits, it is possible to use both, but the menu should not be over-populated by multiplicated entries.

    Regarding the current desktop menu specification:
    - If you want Geography, you must use Education (this is just now the only possible main category for Geography).
    - If you decide to use Graphics, you must pick one of registered additional categories: 2DGraphics VectorGraphics RasterGraphics 3DGraphics Scanning OCR Photography Publishing Viewer.

    Using unregistered categories or main+secondary combinations does not work well: Application ends in sub-menus like "Unsorted" or "Graphics->Unsorted".

    Personally I would search for viking in Science->Geography (it does not exist, only Education->Geography with possible additional Science tag) or maybe in Graphics->Geography/Maps (it does not exist as well and 2DGraphics seems to be the best fit there).

    The same category problem affects all other geo software: JOSM, Merkaator, TangoGPS,...

    Note: Before getting consensus on Categories, you can apply the rest of the patch.

     
  • Guilhem BONNEFILLE

    Patch is applyed (as a serie, I tried to keep small commits).

    I'm not aware of Desktop files. I'm just curious. Your version of desktop file is applied.

     
  • Guilhem BONNEFILLE

    • status: open --> open-accepted
     
  • Guilhem BONNEFILLE

    • status: open-accepted --> closed-accepted
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks