Re: [Viking-devel] [PATCH] Make more portable .vik file, as don't save the map cache directory if it's the map cache default directory.
2010/10/6 Greg Troxel g...@ir.bbn.com: user preference file (NOT a .vik) sets path to cached maps each map layer just uses a standard place in the path, and there's no config allowed. It's an interesting point of vue. Currently, the map cache is associated to the *instance* of a map layer, not the map layer itself (as far as i know). For example, you can embed two Mapnik layers with different caches. As you spotted it, I think this is probably unecessary. A single cache per map type or a global path for map cache would be certainly enough. Other opinions? -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/
[Viking-devel] [PATCH] Fix display of rounded speed units scale markers in the speed profile.
The integer method only works when the speed unit is in m/s; thus for others
show the value to 1 decimal place.
---
src/viktrwlayer_propwin.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/viktrwlayer_propwin.c b/src/viktrwlayer_propwin.c
index af000b4..1a82930 100644
--- a/src/viktrwlayer_propwin.c
+++ b/src/viktrwlayer_propwin.c
@@ -536,16 +536,16 @@ GtkWidget *vik_trw_layer_create_vtdiag ( GtkWidget
*window, VikTrack *tr, gpoint
vik_units_speed_t speed_units = a_vik_get_units_speed ();
switch (speed_units) {
case VIK_UNITS_SPEED_KILOMETRES_PER_HOUR:
- sprintf(s, %8dkm/h, (int)(VIK_MPS_TO_KPH((mins +
(LINES-i)*(maxs-mins)/LINES;
+ sprintf(s, %6.1fkm/h, VIK_MPS_TO_KPH(mins +
(LINES-i)*(maxs-mins)/LINES));
break;
case VIK_UNITS_SPEED_MILES_PER_HOUR:
- sprintf(s, %8dmph, (int)(VIK_MPS_TO_MPH(mins +
(LINES-i)*(maxs-mins)/LINES)));
+ sprintf(s, %6.1fmph, VIK_MPS_TO_MPH(mins +
(LINES-i)*(maxs-mins)/LINES));
break;
case VIK_UNITS_SPEED_METRES_PER_SECOND:
sprintf(s, %8dm/s, (int)(mins + (LINES-i)*(maxs-mins)/LINES));
break;
case VIK_UNITS_SPEED_KNOTS:
- sprintf(s, %8dknots, (int)(VIK_MPS_TO_KNOTS(mins +
(LINES-i)*(maxs-mins)/LINES)));
+ sprintf(s, %6.1fknots, VIK_MPS_TO_KNOTS(mins +
(LINES-i)*(maxs-mins)/LINES));
break;
default:
sprintf(s, --);
--
1.7.1
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/
Re: [Viking-devel] [PATCH] Fix display of rounded speed units scale markers in the speed profile.
From: rw_nor...@hotmail.com To: viking-de...@lists.sf.net Date: Thu, 7 Oct 2010 20:44:47 +0100 Subject: [Viking-devel] [PATCH] Fix display of rounded speed units scale markers in the speed profile. The integer method only works when the speed unit is in m/s; thus for others show the value to 1 decimal place. --- I have some code in progress to make the scales more human friendly for both speed elevation profiles. E.g. Nice whole numbers: 1, 5, 10, 20, 100 whatever as the appropriate scale unit size. However this is not ready yet and also a reasonable change (need to adjust the actual profile drawing) so it will be a 1.0+ improvement. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/
Re: [Viking-devel] Multithread (Was: Plans for 1.0)
2010/9/15 Robert Norris : I would quite like the only known repeatable crash https://sourceforge.net/tracker/?func=detailaid=3009431group_id=83870atid=570954 about the map auto download and GPS auto following conflict to be solved too. I posted a bit about this on this mailing list a while ago. I only retrieve the comment you made on the ticket. If there is any other message about this topic, can you resent or send a URL to the archive? My thoughts at that time, would be that a more involved solution would be needed to get the threading to work properly. However I my efforts to make the DEM loading work in the background (using the background thread pool stuff), it also calls update draw had the same crash as the maps/GPS conflict. I realised the gtk_threads_enter/leave solved the issue for my DEM method and also should solve the GPS drawing crash. [Since that's how the current map drawing works when called from another thread]. NB DEM layer background loading is a 1.0+ change. It's in my local git repo. I believe the best way would be a mutex in the struct _VikViewport which could then control the access to gdk_draw_pixbuf inside the vik_viewport_draw_pixbuf function. Maybe I'll do that too I spend some time to look at multithread aspect of viking. My limited skills (in viking internals and GTK/thread model) make me suspicious about many code part. I understood that Gtk signals are thread-safe as they are executed in the main thread (the one running mainloop). So, I think most of the background.c code can be refactored to use signals instead of gtk lock. Why? Currently, all downloader threads regularly locks mainthread (and other threads) simply to refresh the progress view. IMHO, some signals can be much better as the UI aspect will be managed by a single thread: the main one. This is mostly possible here because information to exchange between downloader and UI is really simple. I don't know, it mostly works so why bother changing it? A good reference: http://library.gnome.org/devel/gtk-faq/stable/x481.html ATM downloader threads naturally run out side of the GTK lock, thus 'signals' from these threads in glib need to call gdk_threads_enter() before doing gtk stuff. Looking at the code, I do not understood the meaning of the trigger concept (between viklayer, vikwindow and vikviewport). Furthermore, I have the feeling that it is not really thread-safe concept. But as I don't understand, I can't be sure. No idea either - the half draw trigger thing is also mysterious. PS Has anyone heard from Quy Tonthat, Alex Foobarian or Evan Battaglia / what happened to them? -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/
