STATUS 1. Done 2. Trivial, can do if want 3. Already done; needs some reworking 4. I tried; I can always try again! 5. a. done b. Brilliant! c. impossible 6. Dear Evan and list, I spent the afternoon today tinkering with Viking 0.1.0, and came up with the following list of criticisms. I hope that you all will find these constructive, and I do regret that I have time only to criticize and not contribute myself. Also, let me emphasize that Viking is damn cool, and these are only ways to make it even better. In terms of context, my current use of Viking is to plan backpacking trips. I basically download the topos of areas of interest, and then draw in potential routes using the track tool. I then export the images to the GIMP and hack them further. Here is one example: http://reidster.net/trips/halls-ck-lower-escalante-loop/ Comments, of course, welcome. Again, thanks for all the hard work on Viking! I hope to contribute myself one day. Reid Constructive Criticism for Viking --------------------------------- 1. Use autoconf/automake. Currently, if things (e.g. gtk, glib) are missing, the build simply fails, sometimes quite spectacularly. This will also bring in all sorts of handy niceties such as an "install" make target, etc. 2. The top-level map directories appear to have the form "tZsXXzYY". Does tZ stand for "type Z" where type is terraserver, google, expedia, etc.? If so, I suggest using a word rather than a number for greater transparency. 3. There ought to be a way to re-download map tiles, in case you mess with the files on disk like I did and download some aerial photos into the topo area. 4. Panning (which is scads faster than v0.0.9, BTW) leaves screen junk in the panned-into region. Perhaps this area could be filled in with a solid color (say, a light steel gray?) until the new image can be drawn? I do really like that panning is lightning-fast, and drawing new data is deferred until I stop dragging. 5. I like that downloading maps doesn't bring up a new window anymore. However, there needs to be more feedback on what is going on. I'd like to see the following: a. Status indicator somewhere saying how many maps are waiting to be downloaded. b. Map tiles which are blank but queued for download are highlighted in some way (say, color them pink?). c. Map tiles are drawn as soon as they are available. Currently, new tiles aren't drawn in until another redraw event comes in. 6. Changing zoom level to a large scale (e.g. zoom out 64x) is slow, esp. if you only use the 4x4 meter resolution topos, as I do. This slowness is fine, but I think there ought to be an indicator that Viking is thinking -- the watch cursor, perhaps. I don't think a full-blown percentage bar window is necessary. 7. Resizes to the layer info panel (or, the window config in general) should stored in the Viking file so they're persistent across sessions. 8. It should be clearer which tool is active. Each tool should have its own cursor. 9. Visibility of the start/end trackpoints of a track should be controllable independently of the visibility of interior points. I think that it would also be handy if, near the start/end trackpoints, "Foobar start" and "foobar end" could be drawn, since otherwise I forget the tracks' names and I don't remember which little symbol is the end and which is the beginning. 10. There should be a concept of a "current track". The current track should be drawn in a different color, and it should be highlighted in the list in the same color. The "Create Track" tool should extend the current track by adding on to the end point. Also, it's important to be able to have no current track; in this case the Create Track tool will start a new track. At the moment, I can't figure out how to start a brand new track after I've been editing one without restarting the program. Perhaps separate Begin Track and Extend Track tools would be a good idea? 11. Track colors are kind of strange under "Track drawing mode: draw by track". Here are some suggestions: a. Once a track is assigned a color, it should never change except by the user changing its color directly. (There might be a global "recolor tracks" command, in case the user wants help.) b. There needs to be more contrast between the auto-assigned colors, and the number of colors doesn't need to be too big. I would say, pick three or four contrasting colors and rotate between them. c. When a path is split at a trackpoint, the portion closer to the end point should be the one to change color. Perhaps a secondary dialog box listing the two new tracks, their names, and their colors, with opportunity to edit the last two items? d. A path's color should appear in its list entry, too. Perhaps a small square by the name? 12. I might further increase the contrast of the current trackpoint (selected with the edit trackpoint tool). Perhaps rather than changing its size, draw a big bold crosshair centered on it? 13. Tracks names should permit mixed-case. 14. IMO, being able to customize the background color is an unnecessary feature, and should be removed to ease maintenance. 15. I would rename the menu item "Zoom To..." to "Zoom to Custom..." and the "Zoom" submenu to "Zoom To". 16. Type size in the layer list should be configurable. 17. Perhaps dragging with the middle button should pan. I think this would complement well the existing center at location of middle click. 18. Deleting something big, like a track or a layer, should have a confirmation box. 19. It would be nice to have more information in the interface about which maps will be used depending on the "zoom level" of a map layer. For example, in a Terraserver topo layer, I had to discover by trial and error that <= 8x means "use 24,000:1 topo maps" and >= 16x means "use 100,000:1 topo maps". 20. Consider an XML file format rather than the existing ad-hoc one. 21. The ability to rotate and move waypoint text would be fabulous. 22. When moving waypoints, it would be great if a greyed copy of the waypoint text and dot moved with the mouse. 23. I'd like the ability to customize the waypoint dot symbol. Personally, I'd prefer an X to the dot.