| Summary: | HTML reader in Akregator does not respect proxy settings. | ||
|---|---|---|---|
| Product: | [Applications] akregator | Reporter: | Dylan Griffiths <dylang> |
| Component: | akregator konqueror plugin | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
|
Description
Dylan Griffiths
2006-06-27 11:01:04 UTC
> If you have a proxy setup in Konqueror, these proxy settings are in no way > respected or honoured by Akregator when you get feeds. They are, at least in my setup. When I choose "manually specify proxy settings" and set a proxy there (using my university's proxy via an ssh tunnel), it uses that proxy, and shows the correct error message if the tunnel is down. What is your setup? (And, if you use konq's adblock feature, are the settings used in Akregator?) We had a bug report via mail about non-working proxy, but the reporter wrote me later that it did not work because his company's firewall blocked everything with "gator" in the browser identification. > If you're going to re-use Konq's settings, don't be half-assed about it. > Use the whole ass. We don't use even the half ass ;-) The browser just uses the generic KHTML options (including adblock and proxy settings) which are shared with konqueror (and also configured in its config dialog). Konq specific settings aren't used right now. The intention is to keep the internal browser in Akregator simple, and many options can't be applied without reimplementing the respective konqueror features. Only a few of them could, but that would need examination on feature-by-feature basis. Also, the config framework isn't perfect for sharing these settings, because you can't receive a notification in akregator when someone changes his settings in konqueror. So changes wouldn't get applied to akregator before akregator restart which is confusing for a user. > Feel free to mark this as a dupe of bug 118908 -- but that bug's been open a > long 6 months now. 6 months being "long" or not is a matter of definition ;-) There is nobody working on new features right now (me due lack of time), and there is a whole of bunch of other stuff with higher priority than making the internal browser more sophisticated. Just because a request isn't implemented short/mid-term, it doesn't mean the list is ignored. As soon as I have time again for development or somebody else jumps in, we consider the entries here. So adding wishlist items isn't futile. It's the best place to store a request. I can just give no time frame for any feature at the moment. Thanks for the quick response. Most of the bugs I've filed in the past 2 years have loafed around as unconfirmed or new in the db. I, personally, haven't had the time to fix anything since I went through KDEPID and removed a PalmPilot related category bug I found (since the fix they posted was incomplete, and I was sick of losing data). I'm also a big shy from Mozilla bugs that have lived for years, zombie-like! It turns out it's a pretty easy fix; at some point, Konqueror had gotten its proxy settings turned off. Going into it and turning them back on fixed the issue (it works as advertised, hooray!). So almost like the other proxy bug (which I read before posting this bug). I appreciate the work you've put into this tool; it's certainly handy. Now, if you can just fix bug 102359 properly (since it currently always starts maximized, regardless of what dimensions/statet it had when I closed it), I think we'd be looking at perfection. As for the Konq settings changing, Akgerator seemed to pick it up without me needing to restart it. Perhaps a side effect of some other KDE 3.5.3 changes? |