Changes between Initial Version and Version 2 of Ticket #467


Ignore:
Timestamp:
07/04/13 20:27:28 (7 years ago)
Author:
usul
Comment:

We will focus that kind of behaviiour in the new major release http://wiki.navit-project.org/index.php/User:Usul/UING

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #467

    • Property Keywords ui xml customization added; generic configuration removed
    • Property Milestone changed from to version 0.6.0
  • Ticket #467 – Description

    initial v2  
    11k, since im not native english and im not shure if im at the right place right here this texts is ganna be a little bigger, so sorry for that.
    22
    3 Im just working on an "as generic as possible" configuration for navits (internal) gui and ran into some disadvantages (that i couldnt find information or solution for)
     3Im just working on an '''"as generic as possible"''' configuration for navits (internal) gui and ran into some disadvantages (that i couldnt find information or solution for)
    44
    55my goal is the following:
    6 i created a base layout wich i moved out of the userspace
    7 i created a generic mapset config (for osm maps only) that will fetch all maps in a specific location (~/.navit/maps)
    8 now i want to do the same for skins and inconsets
     6* i created a base layout wich i moved out of the userspace
     7* i created a generic mapset config (for osm maps only) that will fetch all maps in a specific location (~/.navit/maps)
     8* now i want to do the same for skins and inconsets
    99so if the user creates or fetches another theme he should just copy it over to ~/.navit/skins/skin-name/ and it should be recognized by navit and ability sould be provided from the gui to switch the available skins
    1010same to iconsets i want to locate them to ~/.navit/icons/set-name
    1111and have the ability to choose from gui too
    12 a perfect thing for the last task would be to be able to define in navit.xml the pathes that should be searchd for available themes/iconsets plus having navit to only request one image format  e.g. right now navits requesting some icons in .png, some in .xpm and even some in .svg format.. i guess it would be a great thing if it would just request kind of a template  "poi_name.format", where the very best thing would be if the actual format could be defined in a configuration file belonging to the respective icon_set
     12a perfect thing for the last task would be to be able to define in navit.xml the pathes that should be searchd for available themes/iconsets plus having navit to only request '''one image format'''  e.g. right now navits requesting some icons in .png, some in .xpm and even some in .svg format.. i guess it would be a great thing if it would just request kind of a template  "poi_name.format", where the very best thing would be if the actual format could be defined in a configuration file belonging to the respective icon_set
    1313(navit looks for available iconsets (folders under ~/.navit/icons) -> fetching iconset's configuration file wich contains a list of items thats been covered (by name) and a configuration point named image format which contains the image format thats valid for the whole iconset) items that are not available in the user-chosen iconset should just silently be ignored
    1414
     
    1616
    1717now ive got one more point:
    18 the internal-guis menu should be customizable too (i know the icons can be replaced, but what i think of is just having the ability to define icons positions, menus backgrounds, and even just dropping unused items (e.g. in a system thats completely designed for touchscreen usage, there will be a systemwide onscreen keyboard, so it would be great to just remove navit's osk, cause its not nessecary then, and would make room to enlarge the (city-or-streets) list (wich needs scrollbars and/or up down buttons btw.)
     18the internal-guis '''menu should be customizable''' too (i know the icons can be replaced, but what i think of is just having the ability to define icons positions, menus backgrounds, and even just dropping unused items (e.g. in a system thats completely designed for touchscreen usage, there will be a systemwide onscreen keyboard, so it would be great to just remove navit's osk, cause its not nessecary then, and would make room to enlarge the (city-or-streets) list (wich needs scrollbars and/or up down buttons btw.)
    1919
    2020long speech short, internal gui needs a little more love and flexibility ;-)