I think the XOAP license key used has gone south. <error><err type="102">Invalid License Key.</err></error>
From: Colin Leroy <colin@xfce.org> To: Xfce Goodies <goodies-dev@xfce.org> Reply-To: Xfce Goodies development discussion <goodies-dev@xfce.org> Subject: [Goodies-dev] Data feed for the weather applet will soon die Date: Sun, 30 Oct 2011 13:07:44 +0100 Sender: goodies-dev-bounces@xfce.org X-Mailer: Claws Mail 3.7.10cvs56 (GTK+ 2.24.6; i686-pc-linux-gnu) Hi, I just found that in my spam folder. From what I understand, this means the weather applet will need a new data provider, because that new feed won't be free. HTH, Colin --- Begin forwarded message: Date: Thu, 13 Oct 2011 17:48:11 -0500 From: "The Weather Channel" <privacy2@twcweather.com> To: colin+weather@colino.net Subject: Important Notice regarding your weather.com XML Data Feed Can't view this message? Please click on the link below. http://twcweather.com/twc40/c2.php?TWC/67039321/26997/T/N/V/http://twcweather.com/twc40/wmws/TWC/1318544970034_971/w26988.php?custcode=TWC&bid=67039321&pbid_=67039321 ======================================================== The Weather Channel(R) weather.com Dear Registrant: We are writing to you because our records indicate that you are a registered user of the weather.com(R) XML Data Feed. http://twcweather.com/twc40/c2.php?TWC/67039321/26998/T/N/V/http://xoap.weather.com As a valued subscriber, we want to let you know that our data feed service offerings are changing. Beginning the week of October 10th, 2011, we will be launching a new subscription service, The Weather Channel(R) API. The Weather Channel(R) API is a subscription offering created by The Weather Channel specifically to provide developers with access to an easy to use weather data feed that they can use to power commercial applications across a variety of technology platforms. Key Features include: * access to the most comprehensive global forecast set available anywhere * white label solution (no logo; no links) * weather data provided by weather.com(R) * data may be accessed in either XML or JSON format * leverages a world class cloud-based Infrastructure * product support for the world wide web, the mobile web, downloadable web / PC applications, and downloadable mobile phone / smart phone applications * multi-language support for English, Spanish, French, German, & Portuguese What this means to you: In order to have access to an XML data feed from The Weather Channel, you will need to subscribe to The Weather Channel(R) API. This letter serves as formal notice to you that your access to the weather.com(R) XML Data Feed will terminate at midnight Eastern time on October 31, 2011. To evaluate The Weather Channel(R) API as an alternative to the weather.com(R) XML Data Feed, please click on the link below to go to http://twcweather.com/twc40/c2.php?TWC/67039321/26999/T/N/V/http://portal.theweatherchannel.com. If you have questions concerning this notice, you can call The Weather Channel at (770) 226-2329 or e-mail us at theweatherchannelapi@weather.com. We look forward to continuing our relationship with you. Best Regards, Scott H. Zucker Director, Revenue Management & Optimization The Weather Channel, LLC Phone: (770) 226-2329 Facsimile: (770) 226-2966 E-mail: theweatherchannelapi@weather.com Web: http://twcweather.com/twc40/c2.php?TWC/67039321/27000/T/N/V/http://portal.theweatherchannel.com --- End forwarded message -- Colin The Weather Channel Can't view this message? Please click here. Dear Registrant: We are writing to you because our records indicate that you are a registered user of the weather.com® XML Data Feed (http://xoap.weather.com.) As a valued subscriber, we want to let you know that our data feed service offerings are changing. Beginning the week of October 10th, 2011, we will be launching a new subscription service, The Weather Channel® API. The Weather Channel® API is a subscription offering created by The Weather Channel specifically to provide developers with access to an easy to use weather data feed that they can use to power commercial applications across a variety of technology platforms. Key Features include: • access to the most comprehensive global forecast set available anywhere • white label solution (no logo; no links) • weather data provided by weather.com® • data may be accessed in either XML or JSON format • leverages a world class cloud-based Infrastructure • product support for the world wide web, the mobile web, downloadable web / PC applications, and downloadable mobile phone / smart phone applications • multi-language support for English, Spanish, French, German, & Portuguese What this means to you: In order to have access to an XML data feed from The Weather Channel, you will need to subscribe to The Weather Channel® API. This letter serves as formal notice to you that your access to the weather.com® XML Data Feed will terminate at midnight Eastern time on October 31, 2011. To evaluate The Weather Channel® API as an alternative to the weather.com® XML Data Feed, please go to http://portal.theweatherchannel.com. If you have questions concerning this notice, you can call The Weather Channel at (770) 226-2329 or e-mail us at theweatherchannelapi@weather.com. We look forward to continuing our relationship with you. Best Regards, Scott H. Zucker Director, Revenue Management & Optimization The Weather Channel, LLC Phone: (770) 226-2329 Facsimile: (770) 226-2966 E-mail: theweatherchannelapi@weather.com Web: http://portal.theweatherchannel.com _______________________________________________ Goodies-dev mailing list Goodies-dev@xfce.org https://mail.xfce.org/mailman/listinfo/goodies-dev
*** Bug 8109 has been marked as a duplicate of this bug. ***
*** Bug 8107 has been marked as a duplicate of this bug. ***
Curiously, the ncurses based "ctw" weather client ("Curse the Weather:" http://opensource.hld.ca/trac.cgi/wiki/CurseTheWeather) is still working for me. Apparently it does not use the weather.com api. Perhaps the weather plugin could be adapted to use whatever method ctw is using?
It looks like he does use XOAP, but that it seems his license key still works. http://opensource.hld.ca/trac.cgi/browser/trunk/ctw/weatherfeed.py A google search for his license key shows that LiquidWeather also uses it, but they may have taken it from CTW. We should be good citizens though and contact Dan Cardamore (the author), ask him what black magic lies behind his key and whether we can use it (assuming it is somehow tied to him). I've tossed him an e-mail pointing to this bug.
*** Bug 8114 has been marked as a duplicate of this bug. ***
*** Bug 8112 has been marked as a duplicate of this bug. ***
*** Bug 8117 has been marked as a duplicate of this bug. ***
Dan: "I don't maintain CTW anymore. You're welcome to use the same license if you like, no idea why it works and your plugin stopped." I suggest we go ahead and use that for now: &par=1003666583&key=4128909340a9b2fc
I think the good long-term solution would be to switch to another provider - Gnome uses NOAA if I'm correct, but that's a lot more work...
(In reply to comment #10) > I think the good long-term solution would be to switch to another provider - > Gnome uses NOAA if I'm correct, but that's a lot more work... Agreed, but swapping out the license key will be a good stop-gap while the parser is changed. At a minimum, it will (slightly) reduce the number of bug reports...
*** Bug 8120 has been marked as a duplicate of this bug. ***
Downstream has a patch: https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/xfce4-weather-plugin&id=ea5bc563d6deeeb531a8509da684d36b3ad9a58e
*** Bug 8148 has been marked as a duplicate of this bug. ***
Created attachment 3959 Patch moving to lat/lon to store location Hi, I've started moving away from weather.com. First step is using lat/lon instead of location code to store the place. This patch does that. I suppose we could use http://api.yr.no, it seems good and use conditions are OK. I'm open to any proposals of course, and the simplest, the best.
(oh, and that patch contains patch from bug #7956)
I'm guessing you saw this: http://blog.programmableweb.com/2009/04/15/5-weather-apis-from-weatherbug-to-weather-channel/ I checked out the WeatherBug licensing, and it seems like we'd fall under the commercial license, which says that you can't show more than 36 hours of forecast. yr.no seems quite nice, actually. I'd vote for it.
*** Bug 8193 has been marked as a duplicate of this bug. ***
noaa provides a free xml feed based on lat/long covering the US. heres an example http://forecast.weather.gov/MapClick.php?lat=31.22830&lon=-86.86210&FcstType=dwml but i'm thinking you would ideally want a feed that covers the whole world.
FTR the plugin has started to be hacked to support yr.no. http://git.xfce.org/panel-plugins/xfce4-weather-plugin/log/ Any testing/patching is welcome.
(In reply to comment #20) > FTR the plugin has started to be hacked to support yr.no. > > http://git.xfce.org/panel-plugins/xfce4-weather-plugin/log/ > > Any testing/patching is welcome. Seems to work at the first glance except for the weather forecast. I get only a blank tab. If possible through the API it would be nice if it's possible to give the infos about the precipitation, too. Also if possible, it would be nice to give some infos on the details tab about the weather station(s) from which they have the data for the selected location.
Yes, I'm lacking time to continue... Still missing is the forecast, I hope I'll be able to do it sometime.
I decided to spent some time to find out how to gather and use data for the forecast tab. Initially, I've had plans to keep the same simple layout for the forecast tab that was used before switching to yr.no, but unfortunately that will not be possible easily. yr.no do not provide data for day/night intervals, and no formulas how to calculate the precipitation and weather symbols for 12 or 24 hours periods. The longest period you get via the API is 6 hours (0-6, 6-12, 12-18, 18-24), and I wonder if that assumption holds true for all locations. I've asked them how they calculate precipitation and weather symbols, but their mere response was "Thank you for your interest in our products. This is something we can consider in the future, but for the time being there are no additional documentation or formulas provided by us than what you find on api.met.no." So I guess it's time to think about a new design here. What data do we have, what do we want to use? The following data is available every 3 hours (starting at 0:00): * Temperature (°C) * Wind in degrees and by name * Wind speed (mps / beaufort) * Humidity (%) * Pressure (hPa) * Cloudiness (total cloud cover in %) * Fog (%) For _periods_ of 3 and 6 hours: * Precipitation (mm): "Precipitation is given for set intervals (one, three or six hours), if you need precipitation for other periods, you must compute it by yourselves. Weather symbols must be computed for the interval the symbol is going to represent, you can't just add them. This is the reason why you find some periods with only symbols and no precipitation." * Weather symbol (icon, calculated by using cloud, temperature, precipitation) The easiest way to present available data would be to take the longest periods (let's hope 6 hours are always available?) and print a list with (some of) the values, which means 4 values per day. An alternative: With some work, the times of sunrise and sunset can be calculated using latitude and longitude. That way, we could determine if a period belongs to "day" or "night" and get the highest temperature at day and the lowest temperature at night. We could also determine the highest wind speed of both day and night. Am I right that maximum / minimum values are what one expects from weather forecasts? Finally, I wonder how useful the precipitation (in mm) is to the average user? All in all, presenting data from api.met.no requires much more logic for preparation than with weather.com, which served all that data in the form of raw values. Any comments on these reflections and additional ideas would be greatly appreciated.
After some more thinking I decided to keep it simple and traditional and therefore present the retrieved values like this: Morning Midday Evening Night Monday Icon Icon Icon Icon Values Values Values Values Tuesday ... ... I've yet to determine and experiment which period (3 hours, 6 hours etc.) to take the icon and precipitation from and which values to show, but all in all that design won't be very different from the old one.
(In reply to comment #24) > I've yet to determine and experiment which period (3 hours, 6 hours etc.) to > take the icon and precipitation from and which values to show, but all in > all that design won't be very different from the old one. I would suggest to take the beginning or the middle time of each quarter (24/4=6 hours) of the day. That means: Morning (from 06:00 till 11:59) - weather at 06:00 or 09:00 Midday (from 12:00 till 17:59) - weather at 12:00 or 15:00 Evening (from 18:00 till 22:59) - weather at 18:00 or 21:00 Night (from 23:00 till 05:59) - weather at 23:00 or 03:00 Maybe a good idea is also to implement an optional time shift, so the time stamps could be shifted as a whole by a special number of hours. Or the user can decide freely about the four time stamps to display. I must say that I don't know how the old implementation works in detail.
(In reply to comment #25) Correction: Evening (from 18:00 till 23:59) - weather at 18:00 or 21:00 Night (from 00:00 till 05:59) - weather at 00:00 or 03:00
Another idea can be to show two columns if there is a big difference between the two forecasts in between a quarter of 6 hours. Due to it's only possible to get a forecast every 3 hours. You can name the columns best and worse.
(In reply to comment #25) > Maybe a good idea is also to implement an optional time shift, so the time > stamps could be shifted as a whole by a special number of hours. Or the user > can decide freely about the four time stamps to display. I must say that I > don't know how the old implementation works in detail. I'll think about this after implementing the basic functions of the forecast, it's already complicated enough without this. Instead of that, I'd rather implement something like a graph on another tab ("details" maybe?), showing the values on a timeline, and using all available point data there. But this is all planning for later. I'd like to keep the main forecast tab as simple as possible so that the most important data is easy and quick to grasp. As for the old implementation: I don't know that in exact detail too, but if my assumptions are correct the day/night data was simply provided by the XML, i.e. piece of cake. Thanks for your ideas. (In reply to comment #27) > Another idea can be to show two columns if there is a big difference between > the two forecasts in between a quarter of 6 hours. Due to it's only possible > to get a forecast every 3 hours. You can name the columns best and worse. I'll also write that on the list of possible features, though it sounds too confusing for a simple forecast tab. Thanks for your ideas and comments.
Created attachment 4506 Forecast data for yr.no I've written a basic patch for forecast data for yr.no. Right now, all it does is display basic information for each day; I wasn't able to figure out a good way to get day/night working, so I just display the forecast for right now, then for 24 hours from now, then 48 hours from now, etc. This is my first time contributing to an XFCE project, so please let me know if I've made any errors or violated any coding practices.
Created attachment 4514 Work in progress Update: I didn't have much time to work on this lately, but I got a partly working version, here's a screenshot of my work in progress. No code release yet, I really need to fix things up first. The algorithm that deals with the intervals needs more work and testing, but so far I'm quite satisfied with it. It seems the available intervals are the same for most locations and the data frequency is quite reliable, but one can never know. There's no guarantee it might change suddenly, so better be safe than sorry. There is no distinction between day and night yet, so it will never show you the moon ;-) This is a general issue of the current implementation but as far as I have seen it will be nearly trivial to fix. Luckily, the icons are still there. Another problem is related to localtime <-> UTC differences, only visible when you select a location far away from you. I'm not sure how much I need to rewrite to get this working properly and have not yet decided on the best way to do so.
Created attachment 4517 Possible Layout 1 So far everything's finished and handling forecast data is fine now. What's more, I got day/night working again for both the current weather and the forecast, but because sunrise/sunset data is not available - unlike in the old version -, I'm just using hardcoded times for now (night is from 9pm to 5am). What I'm not sure about is the layout, so I'll attach two screenshots here. I would be glad if someone could comment on this and tell me which one seems better (and why). The second version that I'll upload next (daytimes as a column on the left, days on the top) takes less vertical space and one could more easily add days to it. On the other hand, one possible won't want more than five days and I personally find the first layout easier to grasp (reading from the left to the right instead from up to down), but that might just be because I got to see the first layout more often the past days ;-) The design of the labels and cells etc. is not written in stone, and ideas for enhancement (e.g. use of colors and adding/removing fields) are still very welcome. I'm still thinking about using blue labels when precipitation is greater then 0.0 and maybe colorizing the rows/columns of each day differently so they are easier to distinguish.
Created attachment 4518 Possible Layout 2
Hi, Thanks guys for working on this, I have to say I didn't get a chance to continue that yr.no migration :-( Harald, concerning your layouts, I personally find layout 1 to be more easy to read, more usual I think.
Ok, so I will go on with layout 1 and try to improve it, I'm not quite satisfied with it yet. I had to change various parts of the code in various files to get forecast and night/day working. There are still lots of other minor things to fix and some things to get going again, e.g. problems with the subtitle getting too big in size causing the dialog to grow excessively, or the location dialog being too small, etc. In total, there are 27 open bugs concerning the weather-plugin: https://bugzilla.xfce.org/buglist.cgi?query_format=specific&order=relevance%20desc&bug_status=__open__&product=Xfce4-weather-plugin&list_id=6162 I have patches available for some of these bugs, know how to fix most of them and also could spare enough time to do so. In a mail to the xfce4-dev list and to you (colin@xfce.org) I have already made the proposal, but got no reponse so far: http://mail.xfce.org/pipermail/xfce4-dev/2012-May/029868.html, or see the bottom of the page http://mail.xfce.org/pipermail/xfce4-dev/2012-May/thread.html for the whole thread. I've contributed to many other plugins too and gained some experience with writing code for them. So with this I renew my proposal: Would it be ok for you if I help out and maintain (or co-maintain) the plugin?
I agree also with Layout 1, go for it. It looks more familiar and common. Never seen days organized in columns each in any forecast. Layout 2 looks confused to me. ;)
Hi Harald, > In a mail to the xfce4-dev list and to you (colin@xfce.org) I have already > made the proposal, but got no reponse so far: > http://mail.xfce.org/pipermail/xfce4-dev/2012-May/029868.html, or see the > bottom of the page > http://mail.xfce.org/pipermail/xfce4-dev/2012-May/thread.html for the whole > thread. I've contributed to many other plugins too and gained some > experience with writing code for them. So with this I renew my proposal: > Would it be ok for you if I help out and maintain (or co-maintain) the > plugin? I'm sorry, I even managed to miss that email. I'd be really glad if you want to maintain the Weather plugin - as can be seen, I'm doing a bad job at it :-/ I thought I'd be able to do it even with my second child just born, but obviously I can't, so I'll just focus on my main project for now :) So, yep, go for it !
Created attachment 4522 final-result.png (In reply to comment #36) > I'm sorry, I even managed to miss that email. I'd be really glad if you want > to maintain the Weather plugin - as can be seen, I'm doing a bad job at it > :-/ > > I thought I'd be able to do it even with my second child just born, but > obviously I can't, so I'll just focus on my main project for now :) I see, so you have a much more important project then ;-) Thank you (and the other contributors) for your good job on the plugin so far, I imagine moving to the new data provider was quite a lot of work. > So, yep, go for it ! Thanks for your encouragement, I'll do my best! Here is a screenshot of my final result. I've rotated the weekday labels so that they need less space, and the night descriptions are now generated correctly (a "sunny" night is not what most people are typically used to). Even and odd rows are now easier to distinguish, and the header rows/columns have a different background color too. Although I've tested this design with various standard gtk themes available and it went well with the colors used here in most cases, maybe it would be a good idea to let the user choose the colors. Although I haven't decided about that, perhaps time will show whether this is necessary or not. As far as I am concerned, this will be the last screenshot, now I'm gonna tidy up those patches and post them here, so other people can try them out.
Created attachment 4523 new-forecast-tab.patch Purely for convenience, here are the 11 pieces combined in an all-in-one patch, implementing the new forecast tab and night/day functionality and a little bit cleanup work. I will commit the single pieces to git as soon as some dev has given me access. It would be great if someone could test this, you will need to clone git to be able to successfully apply the patch. I don't know how well it works in other locations and would not be surprised if there's still something wrong and needs fixes. But please concentrate rather on the correctness of the times and forecast data than on the UI, I'm quite aware that there are some problems and that some features aren't working yet. Comments on code quality/issues are welcome too. Note: One thing you can't do is pick a location far away from you, that is in another timezone. Then the forecast tab and very probably the current weather info in the panel will be wrong/shifted.
(In reply to comment #38) > Created attachment 4523 > new-forecast-tab.patch > Thanks for your great work! Please find below some minor annotations. [...] > It would be great if someone could test this, you will need to clone git to > be able to successfully apply the patch. I don't know how well it works in > other locations and would not be surprised if there's still something wrong > and needs fixes. But please concentrate rather on the correctness of the > times and forecast data than on the UI, I'm quite aware that there are some > problems and that some features aren't working yet. Comments on code > quality/issues are welcome too. Besides there are only forecasts for the next nine times, the tenth is a gray icon with a question mark, all in all it looks fine and runs very stable in my system. Example: First forecast is for today (Tuesday) afternoon, so it goes till Thursday evening and a question mark for the night, though there are two additional completely empty rows for Friday and Saturday, you should remove those empty rows cause it looks as an error and confusing without any information (->Bug?). > Note: One thing you can't do is pick a location far away from you, that is > in another timezone. Then the forecast tab and very probably the current > weather info in the panel will be wrong/shifted. That's not a big issue, I guess. What about localtime versus UTC? If you need help with translation texts, let me know. But I am only aware of english and german. I hope that you could get access to git ASAP. Really, well done!
(In reply to comment #39) > Thanks for your great work! Please find below some minor annotations. Thanks a lot for testing. > Besides there are only forecasts for the next nine times, the tenth is a > gray icon with a question mark, all in all it looks fine and runs very > stable in my system. Example: First forecast is for today (Tuesday) > afternoon, so it goes till Thursday evening and a question mark for the > night, though there are two additional completely empty rows for Friday and > Saturday, you should remove those empty rows cause it looks as an error and > confusing without any information (->Bug?). I see, then it doesn't work as good as I hoped it would. Your XML data might have different time intervals than the ones I chose (and which worked good for my location and other ones I tested). It would help me to know the location (or longitude and latitude) and timezone so I can fetch the XML file myself and try to adapt the code to get better results. Or maybe everything works right, but I made a mistake somewhere. The grey icon with the question mark means that there is point data available (e.g. 12:00 to 12:00), but no interval data (12:00 to 15:00). Icons and precipitation are only available in interval data. Having two empty rows means it did not find enough data within the given limits (neither point nor interval data). You might try to increase the hours_limit in function find_timeslice in the file panel-plugin/weather-data.c and see if it helps. However, that might not be an optimal solution, as it might choose unreasonable intervals (don't know really). The XML feed usually provides forecast data for nine+ days, though the various intervals become more and more sparse with days further in the future. That's why you see data for three days, but not day 4 and 5. The algorithm uses the values I hardcoded, and in your case that means those are intervals that become more and more sparse. I can image a possible solution to this, but I need to find more problematic example data to test. > > Note: One thing you can't do is pick a location far away from you, that is > > in another timezone. Then the forecast tab and very probably the current > > weather info in the panel will be wrong/shifted. > > That's not a big issue, I guess. What about localtime versus UTC? It depends. The real problem here is that you have to take into account the timezone. It's not only localtime vs UTC (we already do that conversion), it's also transforming the times for another timezone. For that, you'd have to know the timezone of the remote location. When you can determine that somehow, it just needs a little math. > If you need help with translation texts, let me know. But I am only aware of > english and german. Thanks. At the moment, it's certainly better to wait. More changes will come and you won't want to do unnecessary work.
You should also consider to use the same column widths for both the horizontal and vertical day and time bars, It would look better.
Created attachment 4525 screenshot of my system Here you can see how it looks like with your patch from comment #38.
Created attachment 4526 Another screen shot (Stuttgart) Here, the gray icon for Thursday night is gone. Though, also two emtpy rows.
Created attachment 4527 Screenshot Lazio Fully populated rows for RM, Lazio, Italy
(In reply to comment #41) > You should also consider to use the same column widths for both the > horizontal and vertical day and time bars, It would look better. Yes, there are some weird things going on with resizing the widgets or the window. (In reply to comment #43) > Created attachment 4526 > Another screen shot (Stuttgart) > > Here, the gray icon for Thursday night is gone. Though, also two emtpy rows. Thanks, that will help me with debugging.
It turns out that the empty rows are caused by MAX_TIMESLICE being set to low, that is, the number of available timeslices is limited to 250. There are more than that in the forecast data for Stuttgart, and not all of them can be stored. Increase MAX_TIMESLICE to 500 or higher in weather-parsers.h and everything's ok. That's good because it means my code works fine ;-)
The weird size can be attributed to the subtitle being too long, which causes the window to be bigger. That's why it looks fine for some places, but wrong for locations with long names/descriptions like Stuttgart, Moscow,...
(In reply to comment #47) > The weird size can be attributed to the subtitle being too long, which > causes the window to be bigger. That's why it looks fine for some places, > but wrong for locations with long names/descriptions like Stuttgart, > Moscow,... No, I am talking about the first column on the left that shows the day names: Today, Tomorrow, ... Its width is too big in comparison to the horizontal header if you ask me. Though, we should think about if it's good to write the row names vertically or horizontally.
I think I can work around that, but I have no idea why GTK sizes it differently. In fact, it shouldn't, and if someone knows why please enlighten me! I don't want to set fixed sizes unless absolutely necessary because this could cause conflicts with different themes and translations. Personally I like the vertical layout of the day names. This way they are more compact and neatly arranged, in a similar fashion as the daytimes. Although when thinking again about the first problem, it might be necessary not to set a background color for the headers.
Ok, I found out how to fix the size/padding/spacing issues: I need to place the table / cell elements into GtkHBoxes _and_ GtkVBoxes, or maybe use GtkAlignments.
Created attachment 4529 new-forecast-tab.patch Unfortunately no answer yet from any dev about GIT access, so here's an updated patch with my current progress. It includes fixes for the UI issues mentioned before and incorporates enhancements in various other areas. I hope you like it.
Created attachment 4530 Screenshot It looks much better now, thanks. Go for a release!
Created attachment 4533 Forecast window Nice work. However the forecast window is too high for my netbook's small screen (1024x600). It would be nice if the window would fit and have scroll bars in small screens.
(In reply to comment #51) > Unfortunately no answer yet from any dev about GIT access Maybe try at [0] as suggested recently on the dev list. [0] https://releases.xfce.org/login/request
Created attachment 4538 scrolled-window-for-small-screens.patch Luckily it seems there are not that many different screen sizes in use on netbooks: http://liliputing.com/2009/04/a-thorough-examination-of-netbook-screen-sizes.html Jani Välimaa, please try this patch for small screens which will determine the screen height and add the scrolled window if needed. It will not work on multi-monitor setups because the monitor heights are added together and will certainly be bigger than the limit, but then you will hardly experience the problem there. Solving this is a bit tricky and I don't want to mess around with the current solution which works fine and does the sizing automagically on normal/bigger screens, without nasty scrolled windows. You might also try to change and optimize the value for the height in the gtk_widget_set_size_request line.
(In reply to comment #52) > It looks much better now, thanks. Go for a release! Not yet time for a release, there's still some work to do and verify, though mainly cleanup and translation stuff. I'd rather wait until I have completed all migration thingies, or the bug tracker will be spammed with things that are not working. But I've got access to git now and will commit the changes shortly. As for translations, I will write to the i18n mailing list when everything's finished and ready for release, so that the translators will have enough time to catch up before the new version gets launched. Thanks to all who help(ed) with testing.
(In reply to comment #55) > Created attachment 4538 > scrolled-window-for-small-screens.patch > > Luckily it seems there are not that many different screen sizes in use on > netbooks: > http://liliputing.com/2009/04/a-thorough-examination-of-netbook-screen-sizes. > html > > Jani Välimaa, please try this patch for small screens which will determine > the screen height and add the scrolled window if needed. It will not work on > multi-monitor setups because the monitor heights are added together and will > certainly be bigger than the limit, but then you will hardly experience the > problem there. Solving this is a bit tricky and I don't want to mess around > with the current solution which works fine and does the sizing automagically > on normal/bigger screens, without nasty scrolled windows. You might also try > to change and optimize the value for the height in the > gtk_widget_set_size_request line. Thx for the patch, it works. Tweaked the height a bit (used fixed value) and now the window shows today's and tomorrow's forecasts "by default" and others if you scroll down.
I've been working on the plugin the last couple of days and uploaded the changes to git a few minutes ago. If no severe problems occur - and apart from some cleanup tasks - I consider this ready for release. I think it's important to get this out ASAP because the old version is failing for more and more people (example: bug #9078). More improvements can be made later. The location auto-detection feature doesn't work at the moment (and IIRC it hasn't worked correctly for a long time) because the server has a configuration problem. Fortunately, Nick Schermer will try to fix this probably next week. (In reply to comment #57) > Thx for the patch, it works. Tweaked the height a bit (used fixed value) and > now the window shows today's and tomorrow's forecasts "by default" and > others if you scroll down. I have tried to fix this by making the number of forecast days configurable and by adding a scrolled window automagically when needed. It doesn't look as good with the scrolled window as without, but I did not have the time to make it look better.
*** Bug 8546 has been marked as a duplicate of this bug. ***
*** Bug 9078 has been marked as a duplicate of this bug. ***
I have decided to release the current work as 1.8.0. It should be stable, but there are some remaining issues related to the available data and the purpose of the plugin to display the *current* weather, and of course there's still a lot of work in other areas that needs to be done. Most of these issues can be solved or improved, and I don't know of better alternatives than met.no that are free and reliable. Any suggestions for improvement are welcome. Thanks for your work, patches and testing, I hope you enjoy it.
I noticed that the windchill is no longer accessible in weather infos. Is this an oversight, an error or a limitation of the new weather service used? Thanks.
(In reply to comment #62) > I noticed that the windchill is no longer accessible in weather infos. Is > this an oversight, an error or a limitation of the new weather service used? > Thanks. Please open a new bug for your request.
(In reply to comment #63) > Please open a new bug for your request. Done: https://bugzilla.xfce.org/show_bug.cgi?id=9564