GNOME Bugzilla – Bug 725126
Maps doesn't load tiles
Last modified: 2015-02-10 00:49:49 UTC
At work we are stuck behind an HTTP proxy and Maps 3.10 doesn't cope well with it at all (I'm getting placeholder tiles instead of real tiles). This might very well be a Champlain issue, but reporting here for now until I have done more research.
There is a property on the champlain network tile source, called proxy-uri: https://developer.gnome.org/libchamplain/unstable/ChamplainNetworkTileSource.html#ChamplainNetworkTileSource--proxy-uri I guess that could be used. You can try setting that to your proxy uri on our source in maps, if it works we can figure out how to do it best automagicly.
Or if champlain should do it automagicly.
(In reply to comment #2) > Or if champlain should do it automagicly. Yeah, I don't think apps should need to tell champlain how to download its tiles. I think champlain needs to explicitly tell libsoup to use proxy through SoupProxyResolver* APIs.
Created attachment 270286 [details] [review] Use SoupSession API to get default proxy resolving SoupSession is no longer an abstract class in libsoup and SoupSessionAsync is deprecated. SoupSession is capable of async with the use of queue_message, just like the code right now. When using SoupSession you get automatic resolving of the default proxy, as long as you do not set the proxy-uri property.
Created attachment 270287 [details] [review] Update documentation of proxy-uri property. SoupSession resolve the default proxy when the proxy-uri property is absent. Setting the proxy-uri will override the default proxy. This patch updates the doc to make that apparent.
Created attachment 270288 [details] [review] Update required version of libsoup In order to use the new SoupSession API we need 2.42 of libsoup.
Created attachment 270289 [details] [review] Do not depend on libsoup-gnome-2.4 Everything in libsoup-gnome is deprecated.
Created attachment 270290 [details] [review] Do not depend on libsoup-gnome-2.4 Everything in libsoup-gnome is deprecated.
Bit of a RFC these patches. Mattias: does this work for you?
Jonas: I will come back to this when I have time to test. Might be able to stay at work after hours some day soon. Either that or install a proxy at home.
Awesome work btw!
libchamplain should already use the proxy automatically if libsoup-gnome is used. If libchamplain is compiled only against libsoup, the automatic proxy detection doesn't work. @Mattias, could you check if it works when you use libsoup_gnome? (I've just tried and it works for me.) @Jonas: The patches look nice, the only thing I'm worried about is the dependency on a libsoup version which is 3 months old (for instance I have an older version on my machine). I don't want to force people to install the latest linux distros in order to use libchamplain. For this reason I'd prefer to wait for some time before applying these patches until the required libsoup version gets more widespread.
(In reply to comment #12) > libchamplain should already use the proxy automatically if libsoup-gnome is > used. If libchamplain is compiled only against libsoup, the automatic proxy > detection doesn't work. > > @Mattias, could you check if it works when you use libsoup_gnome? (I've just > tried and it works for me.) > > @Jonas: The patches look nice, the only thing I'm worried about is the > dependency on a libsoup version which is 3 months old (for instance I have an > older version on my machine). I don't think we should need to require too latest of libsoup version. I recall libsoup-gnome was deprecated long time ago. The libsoup version in GNOME 3.10 should be fine(?). > I don't want to force people to install the > latest linux distros in order to use libchamplain. Only the latest version of libchamplain. They don't need to upgrade to latest version of libchamplain. If they really must, they can at the same time also update to latest libsoup. Besides we can bump the minor version/soname. Keeping in mind that Maps is the only maintained app that makes use of libchamplain and the fact that Maps depends on latest GNOME APIs, I don't see any real issues here. > For this reason I'd prefer > to wait for some time before applying these patches until the required libsoup > version gets more widespread. I think its more likely that people use Maps in environment with proxies (all big companies have proxy setups) than someone wanting latest of libchamplain but not the latest of libsoup.
(In reply to comment #12) > libchamplain should already use the proxy automatically if libsoup-gnome is > used. If libchamplain is compiled only against libsoup, the automatic proxy > detection doesn't work. > > @Mattias, could you check if it works when you use libsoup_gnome? (I've just > tried and it works for me.) Yeah, I think so as well. At least when I set a bogus system wide http proxy, Maps will not work for me, with jhbuild of libsoup and libchamplain on their master branches. > > @Jonas: The patches look nice, the only thing I'm worried about is the > dependency on a libsoup version which is 3 months old (for instance I have an > older version on my machine). I don't want to force people to install the > latest linux distros in order to use libchamplain. For this reason I'd prefer > to wait for some time before applying these patches until the required libsoup > version gets more widespread. Hi, I think I might be missing something. As far as I can see libsoup 2.42 came out almost a year ago: https://mail.gnome.org/archives/ftp-release-list/2013-March/msg00216.html Where do you see 3 months?
> Hi, I think I might be missing something. As far as I can see libsoup 2.42 came > out almost a year ago: > https://mail.gnome.org/archives/ftp-release-list/2013-March/msg00216.html > > Where do you see 3 months? Ah, OK, I was simply just looking at the dates here http://ftp.gnome.org/pub/GNOME/sources/libsoup/ but they correspond to the latest minor release.
(In reply to comment #13) > I think its more likely that people use Maps in environment with proxies (all > big companies have proxy setups) than someone wanting latest of libchamplain > but not the latest of libsoup. It's not a question of whether to have proxy support or not - libchamplain should clearly work over proxy, there's no question about it. But that is already the case when you use libsoup-gnome. So the question is rather whether to use the deprecated calls for a little longer or not without any user-noticeable effect. I strongly suspect Mattias built libchamplain on his machine without libsoup-gnome development package installed but normally distributions build it against libsoup-gnome.
libsoup-gnome has been deprecated since GNOME 3.0 came out in spring 2011. You can bump your libsoup requirement up to 2.34.0, replace SOUP_TYPE_PROXY_RESOLVER_GNOME with SOUP_TYPE_PROXY_RESOLVER_DEFAULT, and drop the use of libsoup-gnome, and then you'll have working proxy resolution for all libsoup users. (Assuming you don't want to depend on 2.42; if you don't care about that, then the patches here are better/more modern.)
Great, thanks for the info, Dan. This is what I prefer for now so I have applied all patches from Jonas except for the first one and used the above option in soup_session_async_new_with_options(). The possible future transition to the modern API is just a matter of replacing this call with soup_session_new(). I have tested this (with some super-suspicious Chinese proxy) and it works. @Mattias, does the latest code in libchamplain master solve your problem?
Review of attachment 270287 [details] [review]: Applied.
Review of attachment 270290 [details] [review]: Applied.
Review of attachment 270288 [details] [review]: Applied and changed the required version to 2.34
Review of attachment 270286 [details] [review]: Using the older API for now, this can be easily applied in the future.
Review of attachment 270286 [details] [review]: Perhaps we can put patches like this in a separate 0.13 branch? With them marked as 'rejected' and this bug marked as fixed (as it should be), we'll probably forget about it.
(In reply to comment #16) > I strongly suspect Mattias built libchamplain on his machine without > libsoup-gnome development package installed but normally distributions build it > against libsoup-gnome. It was the default installed gnome-maps from F20 that I tested against at work. gnome-maps on F20 at home shows that it is indeed built agains libsoup-gnome $ ldd /usr/lib64/libchamplain-0.12.so.0 [...] libsoup-gnome-2.4.so.1 => /lib64/libsoup-gnome-2.4.so.1 (0x00000030ca000000) libsoup-2.4.so.1 => /lib64/libsoup-2.4.so.1 (0x00000030bf400000) [...] (In reply to comment #18) > [...] > I have tested this (with some super-suspicious Chinese proxy) and it works. Great! > @Mattias, does the latest code in libchamplain master solve your problem? I will try to test at work when I get the time!
(In reply to comment #23) > Review of attachment 270286 [details] [review]: > > Perhaps we can put patches like this in a separate 0.13 branch? With them > marked as 'rejected' and this bug marked as fixed (as it should be), we'll > probably forget about it. It could actually be applied to 0.12 a bit later as well, I just wanted not to depend on a version which is relatively new. In this case, I don't know if it's worth it maintaining a separate branch - it's really just renaming a function call at 2 places and even if the old call is dropped from libsoup in the future, the fix will be obvious and trivial. The major thing, which is the removal of libsoup-gnome, is already in master thanks to the patches from Jonas.
(In reply to comment #25) > (In reply to comment #23) > > Review of attachment 270286 [details] [review] [details]: > > > > Perhaps we can put patches like this in a separate 0.13 branch? With them > > marked as 'rejected' and this bug marked as fixed (as it should be), we'll > > probably forget about it. > > It could actually be applied to 0.12 a bit later as well, I just wanted not to > depend on a version which is relatively new. In this case, I don't know if it's > worth it maintaining a separate branch - it's really just renaming a function > call at 2 places and even if the old call is dropped from libsoup in the > future, the fix will be obvious and trivial. The major thing, which is the > removal of libsoup-gnome, is already in master thanks to the patches from > Jonas. Cool, I'm glad we sorted this out.
Any objections to marking this as fixed?
(In reply to comment #27) > Any objections to marking this as fixed? Not from me if it now works for Mattias.
This works fine for me now, so let's close this. Sorry for not getting back to this earlier.