From: Piotr S. <pio...@gm...> - 2013-01-15 21:56:13
Attachments:
signature.asc
|
Hi All, This email will be rather long - it pertains to the weather plugin for LXPanel. A bit of a summary: I put together a custom widget which shows the current weather conditions for a configured location. The functionality has been wrapped in an LXPanel plugin [3] or a standalone application [4] [4.1] (which provides the LXPanel plugin library, in case the functionality is not accepted upstream, but the plugin is deemed useful). I would appreciate the community's feedback and would like to ask for the plugin to be included in mainline LXPanel source. Some background and details: I looked through a couple implementations of a weather applet [1] and [2] just to get an idea of what type information people would like to get from a weather app. I ended up using the Yahoo! Weather service as in [2] (it seems to be relatively accurate, but due to multiple server locations, the forecast for a given location on one server may be more up-to-date than on another server - a few minute delay). Given that LXDE is a lightweight desktop, I tried to make everything as efficient as possible and not use 'bulky' dependencies. The only additional dependency, other than the standard glib/gtk+ libraries, is libxml2. It is used to retrieve (using the nanoHTTP client) and parse the location and forecast information as made available by Yahoo!. I realize there are purists out there who might say even that is too much for LXPanel, so, in addition to the weather plugin [3], I used the same backend implementation to create a standalone weather application [4] [4.1]. Link [3] also contains an initial version of the Polish translation for the dialogs and messages as seen in the applet. While the applet/plugin uses the LXPanel configuration file and layout, the application uses a glib-style key-value group file (created in $HOME/.config/lxweather/ and named 'config'). I meant (and still do want) to document the interactions between the user and the application, but for now, screenshots will have to do. This [5] is what the plugin looks like once a location is configured. Similarly, this [6] is what the application shows (the only difference being that the app does NOT have the current temperature listed next to the icon). The configuration dialog is available through a right-click [7]. Current conditions can be seen by left-clicking on the icon/widget [8]. I tested the application and plugin on a Fedora 16_64 LXDE spin and the plugin itself on a Lubuntu 12.04 VM. While I think I fixed the most pressing bugs, I would appreciate any help with reviewing the code and letting either myself, or, if the plugin is accepted to LXPanel upstream, the list know if there are any issues with it. Thanks, and best wishes. Good luck as the maintainer of LXPanel, Henry! Piotr [1]: http://git.xfce.org/panel-plugins/xfce4-weather-plugin/ [2]: https://github.com/simon04/gnome-shell-extension-weather [3]: https://github.com/psipika/lxpanel.git weather_plugin-dev branch [4]: https://github.com/psipika/lxweather.git [4.1]: While the application will show forecast for multiple locations, at this time it is only possible to add/remove locations through the configuration file. It's a TODO item... [5]: http://img35.imageshack.us/img35/8615/pluginwithtooltip.png [6]: http://img842.imageshack.us/img842/676/applicationwithtooltip.png [7]: http://img820.imageshack.us/img820/7350/weatherpreferences.png [8]: http://img94.imageshack.us/img94/7154/currentconditions.png |
From: Andrej N. G. <an...@re...> - 2013-01-15 23:44:58
|
Hello! Piotr Sipika has written on Tuesday, 15 January, at 16:51: >This email will be rather long - it pertains to the weather plugin for >LXPanel. >A bit of a summary: >I put together a custom widget which shows the current weather >conditions for a configured location. The functionality has been wrapped >in an LXPanel plugin [3] or a standalone application [4] [4.1] (which >provides the LXPanel plugin library, in case the functionality is not >accepted upstream, but the plugin is deemed useful). >I would appreciate the community's feedback and would like to ask for >the plugin to be included in mainline LXPanel source. That is fantastic! I dreamed that someone sometime will make it and you've done it! Thank you very much! If nobody has any objections then I'll push your code into master GIT sometime later. :) For future extension of this it would be nice to have a forecast in right-click menu but even without forecast weather plugin is useful very much. [.......] >Link [3] also contains an initial version of the Polish translation for >the dialogs and messages as seen in the applet. Since translation system is still down, I think it's OK to put the translation directly into GIT for now. I'll add Russian and Ukrainian translations as well after it's pushed. >While the applet/plugin uses the LXPanel configuration file and layout, >the application uses a glib-style key-value group file (created in >$HOME/.config/lxweather/ and named 'config'). Probably that's appropriate. Though may be it would be better to have it in the place where lxpanel saves other configuration instead. >I meant (and still do want) to document the interactions between the >user and the application, but for now, screenshots will have to do. >This [5] is what the plugin looks like once a location is configured. I believe it should be self-explanatory. I'll try to build it a bit later and test it. >Similarly, this [6] is what the application shows (the only difference >being that the app does NOT have the current temperature listed next to >the icon). Is it possible to show the temperature too? And that setting should be configurable I believe (show icon / show temp. / show both). >The configuration dialog is available through a right-click [7]. Current >conditions can be seen by left-clicking on the icon/widget [8]. >I tested the application and plugin on a Fedora 16_64 LXDE spin and the >plugin itself on a Lubuntu 12.04 VM. While I think I fixed the most >pressing bugs, I would appreciate any help with reviewing the code and >letting either myself, or, if the plugin is accepted to LXPanel >upstream, the list know if there are any issues with it. I think users will report bugs into bugtracker instead of mailing list so better just look there time to time after. With best wishes. Andriy. |
From: Henry G. <hsg...@gm...> - 2013-01-16 04:24:19
|
On Wed, Jan 16, 2013 at 01:44:48AM +0200, Andrej N. Gritsenko wrote: > Piotr Sipika has written on Tuesday, 15 January, at 16:51: > >This email will be rather long - it pertains to the weather plugin for > >LXPanel. > > >A bit of a summary: > > >I put together a custom widget which shows the current weather > >conditions for a configured location. The functionality has been wrapped > >in an LXPanel plugin [3] or a standalone application [4] [4.1] (which > >provides the LXPanel plugin library, in case the functionality is not > >accepted upstream, but the plugin is deemed useful). > > >I would appreciate the community's feedback and would like to ask for > >the plugin to be included in mainline LXPanel source. Would be great if you could use panel_draw_label_text() (defined in src/panel.h) for the text on the panel. That way it will make use of the color and font size set globally in the panel configuration. > > That is fantastic! I dreamed that someone sometime will make it and > you've done it! Thank you very much! Yeah, my office doesn't have any windows... > > If nobody has any objections then I'll push your code into master > GIT sometime later. :) It will make a nice addition! > > [.......] Cheers, Henry |
From: Piotr S. <pio...@gm...> - 2013-01-16 20:47:46
|
Henry, All, > Would be great if you could use panel_draw_label_text() (defined in > src/panel.h) for the text on the panel. That way it will make use of the > color and font size set globally in the panel configuration. I can try to work it into the source, but the main idea is that the custom widget is self-contained - that is, it has no dependencies outside the standard glib/gtk+ ones. This enables complete code reuse between the plugin and a standalone app. Having said that, once the other issues are addressed (such as the ones from your other email, my response is forthcoming), I have no problem with the code for the plugin being modified such that it is tightly coupled with LXPanel - if the plugin is accepted into the mainline. Best! Piotr |
From: Henry G. <hsg...@gm...> - 2013-01-16 04:35:26
|
On Tue, Jan 15, 2013 at 11:22:51PM -0500, Henry Gebhardt wrote: > On Wed, Jan 16, 2013 at 01:44:48AM +0200, Andrej N. Gritsenko wrote: > > Piotr Sipika has written on Tuesday, 15 January, at 16:51: > > >This email will be rather long - it pertains to the weather plugin for > > >LXPanel. > > > > >A bit of a summary: > > > > >I put together a custom widget which shows the current weather > > >conditions for a configured location. The functionality has been wrapped > > >in an LXPanel plugin [3] or a standalone application [4] [4.1] (which > > >provides the LXPanel plugin library, in case the functionality is not > > >accepted upstream, but the plugin is deemed useful). > > > > >I would appreciate the community's feedback and would like to ask for > > >the plugin to be included in mainline LXPanel source. Another thing I forgot to mention: On startup the plugin takes a few seconds. I assume it is waiting for data? This shouldn't happen. Fast startup is essential, imho. Cheers, Henry |
From: Piotr S. <pio...@gm...> - 2013-01-16 19:46:21
Attachments:
signature.asc
|
Andriy, All, >> While the applet/plugin uses the LXPanel configuration file and layout, >> the application uses a glib-style key-value group file (created in >> $HOME/.config/lxweather/ and named 'config'). > > Probably that's appropriate. Though may be it would be better to have > it in the place where lxpanel saves other configuration instead. I'm not sure if using lxpanel's configuration location for a separate (albeit related) application is the right way to go. LXWeather is only related to LXPanel through the fact that it provides the plugin library for it. Like I mentioned, the plugin uses LXPanel's configuration, the application, in my opinion, should be separate from it. > Is it possible to show the temperature too? And that setting should > be configurable I believe (show icon / show temp. / show both). It might be, I tried showing both, but the mechanism to show weather status in the standalone application is the GtkStatusIcon - which has a fixed width. This means that, if I choose to show both the forecast and temperature, they will be 'squished'. If anyone knows a work-around for this (other than using two status icons, one for the image, one for the label), I'm open to comments and suggestions. > I think users will report bugs into bugtracker instead of mailing > list so better just look there time to time after. Sounds good. Thanks and best wishes. Piotr |
From: Piotr S. <pio...@gm...> - 2013-01-16 20:52:12
|
Henry, All, > Another thing I forgot to mention: On startup the plugin takes a few > seconds. I assume it is waiting for data? This shouldn't happen. Fast > startup is essential, imho. If this happens once the location is set (please let me know whether that's the case), then yes, it is most-likely waiting for data. The solution to this might be: On startup, show default icon (stock_warning) and use a g_timeout (2-5 seconds) to allow initialization to complete. Once the timeout expires, forecast retrieval is initiated. Does that sound like a valid approach? Cheers. Piotr |
From: Henry G. <hsg...@gm...> - 2013-01-16 22:50:03
Attachments:
shape.sh
|
On Wed, Jan 16, 2013 at 03:47:10PM -0500, Piotr Sipika wrote: > > Another thing I forgot to mention: On startup the plugin takes a few > > seconds. I assume it is waiting for data? This shouldn't happen. Fast > > startup is essential, imho. > > If this happens once the location is set (please let me know whether > that's the case), then yes, it is most-likely waiting for data. Yes, the location is set. > > The solution to this might be: On startup, show default icon > (stock_warning) and use a g_timeout (2-5 seconds) to allow > initialization to complete. Once the timeout expires, forecast retrieval > is initiated. > > Does that sound like a valid approach? I think the forecast retrieval always needs to be done either in a separate thread or with non-blocking calls (if that works -- I don't know how network programming really works, maybe there is another way). We don't want the panel to freeze for a few seconds just because the network is slow! If you want to simulate a crappy internet connection, try the attached script and the parameters therein. :) Also, I don't see anything blocking the inclusion of this into lxpanel. libxml2 is, if I see correctly, already an LXDE dependency (via gvfs -> libfm -> pcmanfm). Cheers, Henry |
From: Piotr S. <pio...@gm...> - 2013-01-17 01:02:35
|
Henry, > I think the forecast retrieval always needs to be done either in a > separate thread or with non-blocking calls (if that works -- I don't > know how network programming really works, maybe there is another way). > We don't want the panel to freeze for a few seconds just because the > network is slow! Yes, you're right. Once the initial forecast is retrieved, g_timeout_seconds used to get it periodically (which, to the best of my understanding, uses a separate thread). So I'll have to revisit the initial forecast retrieval. Thanks for bringing that up. > > If you want to simulate a crappy internet connection, try the attached > script and the parameters therein. :) Beautiful! Thank you! > Also, I don't see anything blocking the inclusion of this into lxpanel. > libxml2 is, if I see correctly, already an LXDE dependency (via gvfs -> > libfm -> pcmanfm). Very happy to hear that. I'll try to get the updates (along with Daniele's warnings) in by the end of the weekend. Cheers! Piotr |
From: Globe T. <its...@ya...> - 2013-01-20 16:06:11
|
I tried compiling this in Fedora 18 (using the git code, right now). ./configure ./make ... /bin/ld: lxweather-weatherwidget.o: undefined reference to symbol 'pthread_kill@@GLIBC_2.2.5' /bin/ld: note: 'pthread_kill@@GLIBC_2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line /lib64/libpthread.so.0: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[1]: *** [lxweather] Error 1 >From what I read on searching, -lpthread needs to be in the linking: can this be done automatically, without manual editing to the files so that it is included for perpetuity? Many thanks again for this plug-in. I am especially happy that you have chosen to make it as a standalone version (if needed). --- On Wed, 1/16/13, Piotr Sipika <pio...@gm...> wrote: > From: Piotr Sipika <pio...@gm...> > Subject: Re: [Lxde-list] LXPanel Weather Plugin > To: "Henry Gebhardt" <hsg...@gm...>, lxd...@li... > Date: Wednesday, January 16, 2013, 7:57 PM > Henry, > > > I think the forecast retrieval always needs to be done > either in a > > separate thread or with non-blocking calls (if that > works -- I don't > > know how network programming really works, maybe there > is another way). > > We don't want the panel to freeze for a few seconds > just because the > > network is slow! > > Yes, you're right. Once the initial forecast is retrieved, > g_timeout_seconds used to get it periodically (which, to the > best of my > understanding, uses a separate thread). So I'll have to > revisit the > initial forecast retrieval. Thanks for bringing that up. > > > > > If you want to simulate a crappy internet connection, > try the attached > > script and the parameters therein. :) > > Beautiful! Thank you! > > > Also, I don't see anything blocking the inclusion of > this into lxpanel. > > libxml2 is, if I see correctly, already an LXDE > dependency (via gvfs -> > > libfm -> pcmanfm). > > Very happy to hear that. > > I'll try to get the updates (along with Daniele's warnings) > in by the > end of the weekend. > > Cheers! > > Piotr > > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, > HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your > skills current > with LearnDevNow - 3,200 step-by-step video tutorials by > Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Piotr S. <pio...@gm...> - 2013-01-21 15:16:29
Attachments:
signature.asc
|
Hi All, Just a quick update on the plugin: I updated the code to take care of warnings as submitted by Daniele Forsi [1]. This was very useful as I got to revisit (and fix) some of the logic (available at github). The thing that will probably take a bit of time is the forecast retrieval multi-threading (as mentioned by Henry [2]), which, indirectly, affects the issue reported by 'Globe Trotter' [3] (pthread_kill has been removed in newer versions of the pthread/libc libraries; it's 'bad form' to use it, anyway). Essentially, it would be of most benefit to re-visit the entire logic and implement a consistent scheme for initialization and forecast retrieval. As it is now, I tried two different approaches, one for initialization and one for automatic retrieval. While the two work, they are too confusing and inconsistent to be put in a 'production' release. So, it'll probably take me a little bit of time to get the code in order and working properly - I'd like to say 2-3 weeks, but can't be 100% sure. Thanks for the wonderful feedback. Cheers, Piotr [1]: http://sourceforge.net/mailarchive/message.php?msg_id=30361254 [2]: http://sourceforge.net/mailarchive/message.php?msg_id=30357352 [3]: http://sourceforge.net/mailarchive/message.php?msg_id=30376149 |
From: Globe T. <its...@ya...> - 2013-01-21 22:27:42
|
Thanks, Piotr! I am looking forward to using this, in particular as a standalone application in linux. --- On Mon, 1/21/13, Piotr Sipika <pio...@gm...> wrote: > From: Piotr Sipika <pio...@gm...> > Subject: Re: [Lxde-list] LXPanel Weather Plugin > To: lxd...@li... > Date: Monday, January 21, 2013, 10:11 AM > Hi All, > > Just a quick update on the plugin: > > I updated the code to take care of warnings as submitted by > Daniele > Forsi [1]. This was very useful as I got to revisit (and > fix) some of > the logic (available at github). > > The thing that will probably take a bit of time is the > forecast > retrieval multi-threading (as mentioned by Henry [2]), > which, > indirectly, affects the issue reported by 'Globe Trotter' > [3] > (pthread_kill has been removed in newer versions of the > pthread/libc > libraries; it's 'bad form' to use it, anyway). > > Essentially, it would be of most benefit to re-visit the > entire logic > and implement a consistent scheme for initialization and > forecast > retrieval. As it is now, I tried two different approaches, > one for > initialization and one for automatic retrieval. While the > two work, they > are too confusing and inconsistent to be put in a > 'production' release. > > So, it'll probably take me a little bit of time to get the > code in order > and working properly - I'd like to say 2-3 weeks, but can't > be 100% sure. > > Thanks for the wonderful feedback. > > Cheers, > > Piotr > > > [1]: http://sourceforge.net/mailarchive/message.php?msg_id=30361254 > [2]: http://sourceforge.net/mailarchive/message.php?msg_id=30357352 > [3]: http://sourceforge.net/mailarchive/message.php?msg_id=30376149 > > > > -----Inline Attachment Follows----- > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, > HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your > skills current > with LearnDevNow - 3,200 step-by-step video tutorials by > Microsoft > MVPs and experts. SALE $99.99 this month only -- learn more > at: > http://p.sf.net/sfu/learnmore_122412 > -----Inline Attachment Follows----- > > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Piotr S. <pio...@gm...> - 2013-02-14 16:44:40
|
Another quick update on the plugin: I'm slowly reworking the logic to get the plugin up without slowing down the panel. In the process I'm also trying to incorporate fixes suggested by Daniele and Globe Trotter. This statement: > (pthread_kill has been removed in newer versions of the pthread/libc > libraries; is incorrect -- I simply made an assumption based on some missing packages in my F18 install. I hope to push the changes up to github soon. Thanks and best wishes. P |
From: Andrej N. G. <an...@re...> - 2014-02-18 02:55:35
|
Hello! Piotr Sipika has written on Thursday, 14 February, at 11:44: >Another quick update on the plugin: >I'm slowly reworking the logic to get the plugin up without slowing >down the panel. >In the process I'm also trying to incorporate fixes suggested by >Daniele and Globe Trotter. >This statement: >> (pthread_kill has been removed in newer versions of the pthread/libc >> libraries; >is incorrect -- I simply made an assumption based on some missing >packages in my F18 install. Since lxpanel is GLib/GTK application I would suggest to use GThread and GCancellable APIs, better don't call pthreads directly. And mentioned pthread_kill() is not reliable operation which may cause problems in some cases, avoid it, please. >I hope to push the changes up to github soon. Since I've merged your plugin into master branch it would be wonderful if you could continue work on it: 1) migrate it to new plugins API (feel free to ask me details). 2) use lightweight FmXmlFile API instead of heavy libxml one. 3) implement loading of info in another thread (you may use convenient API fm_run_in_default_main_context() to deliver results into the main thread). >Thanks and best wishes. Thank you too. Andriy. |
From: Piotr S. <pio...@gm...> - 2014-02-18 16:01:45
|
> Hello! Hi Andriy, > Since lxpanel is GLib/GTK application I would suggest to use GThread and > GCancellable APIs, better don't call pthreads directly. And mentioned > pthread_kill() is not reliable operation which may cause problems in some > cases, avoid it, please. Yes, I'll definitely do that. > Since I've merged your plugin into master branch it would be wonderful if > you could continue work on it: > > 1) migrate it to new plugins API (feel free to ask me details). > 2) use lightweight FmXmlFile API instead of heavy libxml one. > 3) implement loading of info in another thread (you may use convenient > API fm_run_in_default_main_context() to deliver results into the main > thread). I keep on trying to get going on the fixes and now that the plugin made it to master, I better get my stuff together... I'll get working on Daniele's suggestions, first (mostly cleanup and minor functionality tweaks). Then, I'll migrate over to tighter integration with libfm and the new API. > Andriy. Thanks for all the hard work, Andriy, nice to see LXDE moving forward. Cheers! Piotr |
From: Andrej N. G. <an...@re...> - 2014-02-19 13:45:11
|
Hello! Piotr Sipika has written on Tuesday, 18 February, at 11:01: >> 1) migrate it to new plugins API (feel free to ask me details). >> 2) use lightweight FmXmlFile API instead of heavy libxml one. After closer look into your plugin sources I should admit using the libxml2 may be unavoidable - the FmXmlFile provides just XML parser and composer but libxml2 also provides simple HTTP client interface which is used in your plugin. >> 3) implement loading of info in another thread (you may use convenient >> API fm_run_in_default_main_context() to deliver results into the main >> thread). >I keep on trying to get going on the fixes and now that the plugin made >it to master, I better get my stuff together... >I'll get working on Daniele's suggestions, first (mostly cleanup and >minor functionality tweaks). Then, I'll migrate over to tighter >integration with libfm and the new API. That is great! I've already done migration of 'cpu' loadable plugin so you can use it as example. >Cheers! >Piotr With best regards. Andriy. |
From: Piotr S. <pio...@gm...> - 2015-07-12 02:47:08
|
On 08/01/2014 08:33 PM, Andrej N. Gritsenko wrote: > Hello! Hi Andriy, All, > No updates from you, though I found some updates in your repository. It's been a while and I've made some more updates, details follow: > 1) the function gtk_weather_button_pressed() will be never called for > button 3 since the panel will catch and handle it, therefore the item > 'Refresh' should be added in callback .update_context_menu() instead of > creating unused popup menu. Yup. I don't consider it critical, but I understand the 'need' for it. Added it to the issue tracker [1]. > 2) gtk_weather_preferences_dialog_response() should never destroy the > preferences dialog because panel handles that thing. > 3) gtk_weather_create_preferences_dialog() should always create new > preferences dialog due to (2) and never use the same one again. I think you've taken care of these two on upstream/master, I've rebased on your changes and sprinkled some of my own magic there -- thanks. > 4) might it be better to use conditional compilation instead of using > conditional execution? That way we can omit some unused code when it's > used as panel plugin. It looks like that's what you did on master. I completely removed the app-specific code from the plugin -- it was just taking up space. The proper way of reusing code would have been for me to generate a shared library and go from there. Thanks for cleaning it up. I've also fixed: - the threading issue brought up by Henry Gebhardt 2 1/2 (!!!) years ago (essentially with a slow network, the weather plugin would slow down lxpanel's startup) [2] - the forecast for 'Tomorrow' was actually the forecast for 4 days from 'Today', due to a parsing bug [3] (the fix also effectively adds a requested feature [4]). All of the above fixes to the plugin are available for a 'pull' from the '1-threading' branch of my fork of the lxpanel repo [5] The standalone app got the same updates and can be cloned directly from its repo [6]. Review comments, questions, bug reports and feature requests are always welcome (and can be submitted directly via the app issue page [7]). Cheers! Piotr [1]: https://github.com/psipika/lxpanel/issues/2 [2]: https://github.com/psipika/lxweather/issues/5 [3]: https://github.com/psipika/lxweather/issues/2 [4]: https://github.com/psipika/lxweather/issues/1 [5]: https://github.com/psipika/lxpanel/tree/1-threading [6]: https://github.com/psipika/lxweather [7]: https://github.com/psipika/lxweather/issues |
From: Andrej N. G. <an...@re...> - 2015-07-13 10:36:44
|
Hello! Piotr Sipika has written on Saturday, 11 July, at 22:46: >On 08/01/2014 08:33 PM, Andrej N. Gritsenko wrote: >> 4) might it be better to use conditional compilation instead of using >> conditional execution? That way we can omit some unused code when it's >> used as panel plugin. >It looks like that's what you did on master. I completely removed the >app-specific code from the plugin -- it was just taking up space. The >proper way of reusing code would have been for me to generate a shared >library and go from there. Thanks for cleaning it up. Well, code with #ifdef does take any space after preprocessor really, but you still could use that code for your standalone application without copying it around. But that's your decision of course. >I've also fixed: > - the threading issue brought up by Henry Gebhardt 2 1/2 (!!!) years >ago (essentially with a slow network, the weather plugin would slow down >lxpanel's startup) [2] > - the forecast for 'Tomorrow' was actually the forecast for 4 days from >'Today', due to a parsing bug [3] (the fix also effectively adds a >requested feature [4]). >All of the above fixes to the plugin are available for a 'pull' from the >'1-threading' branch of my fork of the lxpanel repo [5] Thank you very much for all the work done. Although there is a small note on it. The commit where many different changes are all-in-one is very hard to be understood, to review ang get commented, and your biggest commit has at least 5 things in it: a) indentations changes; b) many data members renamed; c) bugs fixed; d) forecast feature improvement; e) fix for hang due to data retrieval in main thread. So in short, I have no big idea what to comment on it so I think it should be just merged with the master after we done with 0.8.x and will prepare 0.9.0. I hope you would take this into consideration on your further work and would split your further commits into few more atomic ones (i.e. with one kind of change in each) so they can be reviewed and commented. With best regards, Andriy. |
From: Piotr S. <pio...@gm...> - 2015-07-13 11:36:55
|
Hey Andriy, 13 lip 2015 06:39 "Andrej N. Gritsenko" <an...@re...> napisał(a): > The commit where many different changes are all-in-one is > very hard to be understood, to review ang get commented, and your biggest > commit has at least 5 things in it: a) indentations changes; b) many data > members renamed; c) bugs fixed; d) forecast feature improvement; e) fix > for hang due to data retrieval in main thread. So in short, I have no big > idea what to comment on it so I think it should be just merged with the > master after we done with 0.8.x and will prepare 0.9.0. I hope you would > take this into consideration on your further work and would split your > further commits into few more atomic ones (i.e. with one kind of change > in each) so they can be reviewed and commented. Of course. That makes complete sense and I will keep that in mind for my future work. Thanks. > With best regards, > Andriy. Best wishes, Piotr |
From: Andrej N. G. <an...@re...> - 2014-03-26 02:05:27
|
Hello! Piotr Sipika has written on Tuesday, 18 February, at 11:01: >I keep on trying to get going on the fixes and now that the plugin made >it to master, I better get my stuff together... >I'll get working on Daniele's suggestions, first (mostly cleanup and >minor functionality tweaks). Then, I'll migrate over to tighter >integration with libfm and the new API. How does the progress going on that? Cheers, Andriy. |
From: Piotr S. <pio...@gm...> - 2014-03-26 13:50:24
|
On 03/25/2014 10:05 PM, Andrej N. Gritsenko wrote: > How does the progress going on that? Slowly... Work is keeping me busier than normal. I'll provide more details this weekend. Best wishes! Piotr |
From: Andrej N. G. <an...@re...> - 2014-07-03 20:22:52
|
Hello! Piotr Sipika has written on Sunday, 30 March, at 21:27: >I took a bit of time this week and had a look as to what still needs to >be done. >I've started on cleanup and minor usability updates and will continue to >make those changes as I go through the debugger/valgrind. What is the current state of this work? I believe it is the time to make a release for LXPanel so we need some progress into this plugin as well. With best regards, Andriy. |
From: Andrej N. G. <an...@re...> - 2014-07-05 10:05:57
|
Hello! Piotr Sipika has written on Friday, 4 July, at 20:43: >On 07/03/2014 04:22 PM, Andrej N. Gritsenko wrote: >> What is the current state of this work? I believe it is the time to >> make a release for LXPanel so we need some progress into this plugin as >> well. >I'm 95% done migrating the plugin to the new API. >The only thing missing is saving configuration to the panel config file >-- I need to look over other plugins' source to figure out how and when >their configuration gets written to the file (would appreciate some help >with that - a point in the right direction - if you have a bit of time). This is pretty simple in fact - after your configuration dialog is closed (it can be handled connecting to the "response" signal of the dialog widget) or some value is changed (that if you prefer to apply your changes immediately so you would connect to individual dialog's widgets signals to catch changes) you can call either config_group_set_int() API or config_group_set_string() one to save new value into the config. The pointer to config for the plugin instance is given as a parameter on the instance creation so it may be remembered in the private data to use for that purpose. >I don't want to hold back the release, so my plan is to do the following >by the end of this weekend: >1) fix configuration persistence >2) fix the 'refresh' logic in the details screen >3) [possibly] move initial forecast retrieval from main thread Do not force yourself, please, we don't have any deadline yet and I don't think all other plugins will be migrated to new API in next few days anyway. And using separate thread for all retrievals is the most desired thing anyway, we'll rather wait you to finish that. :) >I just pushed some changes to github[1]. If you have any other comments, >or suggestions, please do let me know. Please, inspect LXPanelPluginInit description in the plugin.h header file - the config callback should never run configuration dialog but just compose it, you know you can handle different responces anyway, just connect to the "response" signal and use g_signal_stop_emission_by_name() API if you want to keep dialog still open after responce. >I'll provide details for completed functionality Sunday night (US >Eastern Time). >Sorry for the silence for the past 3 months -- real-life is keeping me >on my toes. Thank you very much for your work! There is nothing to be sorry for, we all are just volunteers here. :) With best regards, Andriy. |
From: Piotr S. <pio...@gm...> - 2014-07-05 16:41:41
|
> The > pointer to config for the plugin instance is given as a parameter on the > instance creation so it may be remembered in the private data to use for > that purpose. Ah yes! Thank you! > Please, inspect LXPanelPluginInit description in the plugin.h header > file - the config callback should never run configuration dialog but just > compose it, you know you can handle different responces anyway, just > connect to the "response" signal and use g_signal_stop_emission_by_name() > API if you want to keep dialog still open after responce. Thanks for that. I see how it's done in dclock and it looks like I'll have to further modularize the logic and separate creation from execution of the dialog. Very cool! Cheers! Piotr |
From: Andrej N. G. <an...@re...> - 2014-08-02 00:33:49
|
Hello! Piotr Sipika has written on Sunday, 6 July, at 19:05: >I'll put in some time here and there, and will provide status, hopefully >on a weekly basis. No updates from you, though I found some updates in your repository. Few notes on it: 1) the function gtk_weather_button_pressed() will be never called for button 3 since the panel will catch and handle it, therefore the item 'Refresh' should be added in callback .update_context_menu() instead of creating unused popup menu. 2) gtk_weather_preferences_dialog_response() should never destroy the preferences dialog because panel handles that thing. 3) gtk_weather_create_preferences_dialog() should always create new preferences dialog due to (2) and never use the same one again. 4) might it be better to use conditional compilation instead of using conditional execution? That way we can omit some unused code when it's used as panel plugin. With best regards, Andriy. |