From: Henry G. <hsg...@go...> - 2012-02-18 14:19:15
|
Dear LXDE list members, I've been trying to fix the netstat plugin up a bit, with patches you can pull from the 'gtk2-fixes' branch at my usual place: git://github.com/hsgg/lxpanel.git It now compiles fairly cleanly, and doesn't segfault. However, I have not checked if it actually works other than reporting the correct values for my wifi connection. That being said, what to do with this plugin? It seems to mostly duplicate the functionality of NetworkManager or wicd. So is there any point in developing it further? What are your opinions/plans on this? Cheers, Henry |
From: PCMan <pcm...@gm...> - 2012-02-18 15:57:22
|
This plugin was introduced by Fred in 2008. At that time he wants to develop a lightweight network manager replacement (lxnm). The plugin was a companion of his lxnm. For personal reasons, he never finished lxnm and then quit the project. So of course lxnm was dropped from lxde, and lxnm is in an unmaintained status. Now network manager is already very mature and quite usable. Besides, its gnome-applet, despite the name gnome, mostly use gtk+ only. So I see no reason to maintain a duplicate. Cheers! On Sat, Feb 18, 2012 at 10:17 PM, Henry Gebhardt <hsg...@go... > wrote: > Dear LXDE list members, > > I've been trying to fix the netstat plugin up a bit, with patches you > can pull from the 'gtk2-fixes' branch at my usual place: > > git://github.com/hsgg/lxpanel.git > > It now compiles fairly cleanly, and doesn't segfault. However, I have > not checked if it actually works other than reporting the correct values > for my wifi connection. > > That being said, what to do with this plugin? It seems to mostly > duplicate the functionality of NetworkManager or wicd. So is there any > point in developing it further? > > What are your opinions/plans on this? > > > Cheers, > > Henry > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: <u-l...@ae...> - 2012-02-18 17:12:30
|
Hello, On Sat, Feb 18, 2012 at 11:57:12PM +0800, PCMan wrote: > Now network manager is already very mature and quite usable. > Besides, its gnome-applet, despite the name gnome, mostly use gtk+ only. > So I see no reason to maintain a duplicate. A general thought, if the plugin provides a visual feedback of the network status, it can be useful even for people not running Network Manager (like myself). Note that the Network Manager is not universally the best (or suitable) tool, while a visual feedback is nice to have. (guessing that the Network Manager's gnome-applet is not usable alone, or is it?) Regards, Rune |
From: Globe T. <its...@ya...> - 2012-02-19 15:10:23
|
I think the plugin can serve a useful purpose if we can get an idea of connection speeds, such as is done by conky (which is not a plugin) or to a small extent the xfce plugin. Right now, there is hardly any meaningful indication. So I would like to second Rune's suggestion. --- On Sat, 2/18/12, u-l...@ae... <u-l...@ae...> wrote: > From: u-l...@ae... <u-l...@ae...> > Subject: Re: [Lxde-list] lxpanel: netstat plugin fixes and discussion > To: "LXDE list" <lxd...@li...> > Date: Saturday, February 18, 2012, 12:12 PM > Hello, > > On Sat, Feb 18, 2012 at 11:57:12PM +0800, PCMan wrote: > > Now network manager is already very mature and quite > usable. > > Besides, its gnome-applet, despite the name gnome, > mostly use gtk+ only. > > So I see no reason to maintain a duplicate. > > A general thought, > > if the plugin provides a visual feedback of the network > status, it > can be useful even for people not running Network Manager > (like > myself). Note that the Network Manager is not universally > the best > (or suitable) tool, while a visual feedback is nice to > have. > > (guessing that the Network Manager's gnome-applet is not > usable alone, > or is it?) > > Regards, > Rune > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity > Planning > Cloud computing makes use of virtualization - but cloud > computing > also focuses on allowing computing to be delivered as a > service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: PCMan <pcm...@gm...> - 2012-02-21 09:03:30
|
A new netstatus applet is developed for lxpanel2 based on libgtop. To some extent this can provide the required information, in a more portable way. Lxpanel2 is now in my hard disk and will be pushed to online git repo recently. On Sun, Feb 19, 2012 at 11:10 PM, Globe Trotter <its...@ya...> wrote: > I think the plugin can serve a useful purpose if we can get an idea of > connection speeds, such as is done by conky (which is not a plugin) or to a > small extent the xfce plugin. Right now, there is hardly any meaningful > indication. So I would like to second Rune's suggestion. > > --- On Sat, 2/18/12, u-l...@ae... <u-l...@ae...> wrote: > > > From: u-l...@ae... <u-l...@ae...> > > Subject: Re: [Lxde-list] lxpanel: netstat plugin fixes and discussion > > To: "LXDE list" <lxd...@li...> > > Date: Saturday, February 18, 2012, 12:12 PM > > Hello, > > > > On Sat, Feb 18, 2012 at 11:57:12PM +0800, PCMan wrote: > > > Now network manager is already very mature and quite > > usable. > > > Besides, its gnome-applet, despite the name gnome, > > mostly use gtk+ only. > > > So I see no reason to maintain a duplicate. > > > > A general thought, > > > > if the plugin provides a visual feedback of the network > > status, it > > can be useful even for people not running Network Manager > > (like > > myself). Note that the Network Manager is not universally > > the best > > (or suitable) tool, while a visual feedback is nice to > > have. > > > > (guessing that the Network Manager's gnome-applet is not > > usable alone, > > or is it?) > > > > Regards, > > Rune > > > > > > > ------------------------------------------------------------------------------ > > Virtualization & Cloud Management Using Capacity > > Planning > > Cloud computing makes use of virtualization - but cloud > > computing > > also focuses on allowing computing to be delivered as a > > service. > > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > > _______________________________________________ > > Lxde-list mailing list > > Lxd...@li... > > https://lists.sourceforge.net/lists/listinfo/lxde-list > > > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Henry G. <hsg...@go...> - 2012-02-21 16:10:54
|
On Tue, Feb 21, 2012 at 05:03:19PM +0800, PCMan wrote: > A new netstatus applet is developed for lxpanel2 based on libgtop. > To some extent this can provide the required information, in a more > portable way. It seems, for the gtk2 version it might make sense to merge the 'netstat' and 'netstatus' plugins into a single monitor. I really like the tooltip and icon of 'netstat'. However, with lxpanel2 coming up, I probably won't do that. > Lxpanel2 is now in my hard disk and will be pushed to online git repo > recently. Looking forward to it! Cheers, Henry > > On Sun, Feb 19, 2012 at 11:10 PM, Globe Trotter <its...@ya...> wrote: > > > I think the plugin can serve a useful purpose if we can get an idea > > of connection speeds, such as is done by conky (which is not a > > plugin) or to a small extent the xfce plugin. Right now, there is > > hardly any meaningful indication. So I would like to second Rune's > > suggestion. > > > > --- On Sat, 2/18/12, u-l...@ae... <u-l...@ae...> wrote: > > > Hello, > > > > > > On Sat, Feb 18, 2012 at 11:57:12PM +0800, PCMan wrote: > > > > Now network manager is already very mature and quite usable. > > > > Besides, its gnome-applet, despite the name gnome, mostly use > > > > gtk+ only. So I see no reason to maintain a duplicate. > > > > > > A general thought, > > > > > > if the plugin provides a visual feedback of the network status, it > > > can be useful even for people not running Network Manager (like > > > myself). Note that the Network Manager is not universally the best > > > (or suitable) tool, while a visual feedback is nice to have. > > > > > > (guessing that the Network Manager's gnome-applet is not usable > > > alone, or is it?) > > > > > > Regards, > > > Rune > > > |
From: Piotr S. <pio...@gm...> - 2012-03-06 15:40:27
|
On 02/18/2012 09:17 AM, Henry Gebhardt wrote: > > I've been trying to fix the netstat plugin up a bit, with patches you > can pull from the 'gtk2-fixes' branch at my usual place: > > git://github.com/hsgg/lxpanel.git Hi Henry, I'm hoping to take a bit of time and do some diffs between your tree, Alexandra's [1] and the latest LXPanel git repo. I'd like to see which lxpanelx fixes made it into the tree and which are still outstanding (lxpanelx development is a bit faster paced than LXPanel and I'd like to see what other improvements that project made since the last rebase). Alexandra, if you have a plain-text list of the patches you applied to your tree, I'd be very interested in seeing it - it will save me time when looking through the code. It would be nice to have someone with write-access to the repo do a 'sweep' of the patches on the tracker at regular intervals (once per month would be sufficient) and apply those that are a) straight-forward and/or b) thoroughly documented/tested. I realize everyone has time/life constraints, so not sure how feasible that is -- or maybe updated [public] git repositories are preferred over patches... > It now compiles fairly cleanly, and doesn't segfault. However, I have > not checked if it actually works other than reporting the correct values > for my wifi connection. > > That being said, what to do with this plugin? It seems to mostly > duplicate the functionality of NetworkManager or wicd. So is there any > point in developing it further? > > What are your opinions/plans on this? Based on lxpanel/lxpanel2 discussions [2], I'd say lxpanel will be 'around' for a while. If you have time and feel like it, I think that merging netstat and netstatus would not be a bad idea. If lxpanel2 comes out before work is complete, lessons learned can be applied to the GTK3 version. That's my take on it, others might disagree. Whatever you decide, thanks for your work so far! All the best! Piotr [1] https://sourceforge.net/mailarchive/message.php?msg_id=28764862 [2] https://sourceforge.net/mailarchive/message.php?msg_id=28920913 |
From: Henry G. <hsg...@go...> - 2012-03-06 18:30:29
|
On Tue, Mar 06, 2012 at 10:38:42AM -0500, Piotr Sipika wrote: > On 02/18/2012 09:17 AM, Henry Gebhardt wrote: > > > > I've been trying to fix the netstat plugin up a bit, with patches you > > can pull from the 'gtk2-fixes' branch at my usual place: > > > > git://github.com/hsgg/lxpanel.git > > I'm hoping to take a bit of time and do some diffs between your tree, > Alexandra's [1] and the latest LXPanel git repo. Good to know! I just re-organized my tree a little. There are now two branches: 'gtk2-fixes' and 'gtk2-features'. Please (list members) consider merging them, depending on how strict the "feature freeze" is. :) > I'd like to see which lxpanelx fixes made it into the tree and which > are still outstanding (lxpanelx development is a bit faster paced than > LXPanel and I'd like to see what other improvements that project made > since the last rebase). Can we convince the lxpanelx author to contribute and (as time goes on) merge upstream? > > Alexandra, if you have a plain-text list of the patches you applied to > your tree, I'd be very interested in seeing it - it will save me time > when looking through the code. I think a rebase of Alexandra's branch would be great. I'd be happy to do it. But if you have time, that would be even better... > > It would be nice to have someone with write-access to the repo do a > 'sweep' of the patches on the tracker at regular intervals (once per > month would be sufficient) and apply those that are a) straight-forward > and/or b) thoroughly documented/tested. How does one get commit access? > > I realize everyone has time/life constraints, so not sure how feasible > that is -- or maybe updated [public] git repositories are preferred over > patches... Sourceforge is a bit cumbersome in my opinion. Is the "Bugs"/"Feature Requests"/"Patches" distinction useful? All of them should eventually have patches, right? ... > Based on lxpanel/lxpanel2 discussions [2], I'd say lxpanel will be > 'around' for a while. If you have time and feel like it, I think that > merging netstat and netstatus would not be a bad idea. If lxpanel2 comes > out before work is complete, lessons learned can be applied to the GTK3 > version. Good point, I'll keep it in mind. Greetings, Henry |
From: Piotr S. <pio...@gm...> - 2012-03-08 00:28:56
|
On 03/06/2012 01:29 PM, Henry Gebhardt wrote: >> I'm hoping to take a bit of time and do some diffs between your tree, >> Alexandra's [1] and the latest LXPanel git repo. > > Good to know! > > I just re-organized my tree a little. There are now two branches: > 'gtk2-fixes' and 'gtk2-features'. > I did the easier thing first: I took your gtk2-fixes, added my patches from the tracker [1] and [2], and cleaned up all of the compilation warnings. Most of the warnings were improper GTK casts and I made sure that what was being cast to/from was in the same object hierarchy. The git repo is the master branch at: https://github.com/psipika/lxpanel I'm currently running the recompiled lxpanel and all looks fine, but the more testing hands, the better. If everything ends up looking good, I'd suggest pushing these updates upstream before new development takes place. > Can we convince the lxpanelx author to contribute and (as time goes on) > merge upstream? I think one of the more 'senior' members on this list attempted to contact the lxpanelx developer, but I'm not sure what came out of it. > I think a rebase of Alexandra's branch would be great. I'd be happy to > do it. But if you have time, that would be even better... After having looked through her source and diffing against a snapshot of lxpanelx I made a while back, I think it'll be easier for me (or anyone) to do just that. I'll attempt to go through the changes made to lxpanelx since it forked from mainstream lxpanel (unless this point is already known?) and try to group updates together based on what is desired - hoping the list will help with that one. In fact, I'd encourage you, or anyone with a bit of time to devote to lxpanel, to do that and keep track of which changes (i.e. lxpanelx rev number) a person is applying to their tree. This way we'll avoid duplicate attempts and we'll know exactly what's being done. > How does one get commit access? No clue, but Julien would know :) > Sourceforge is a bit cumbersome in my opinion. Is the "Bugs"/"Feature > Requests"/"Patches" distinction useful? All of them should eventually > have patches, right? Yes, but I think the distinction is important for record-keeping purposes (whether that's the actual use, I don't know). Thanks again, and all the best! Piotr [1] - http://sourceforge.net/tracker/?func=detail&aid=3496687&group_id=180858&atid=894871 [2] - http://sourceforge.net/tracker/?func=detail&aid=3496689&group_id=180858&atid=894871 |
From: Julien L. <gi...@ub...> - 2012-03-12 23:09:27
|
Le 03/08/2012 01:27 AM, Piotr Sipika a écrit : > I did the easier thing first: I took your gtk2-fixes, added my patches > from the tracker [1] and [2], and cleaned up all of the compilation > warnings. > > Most of the warnings were improper GTK casts and I made sure that what > was being cast to/from was in the same object hierarchy. > > The git repo is the master branch at: https://github.com/psipika/lxpanel > > I'm currently running the recompiled lxpanel and all looks fine, but the > more testing hands, the better. > > If everything ends up looking good, I'd suggest pushing these updates > upstream before new development takes place. Is this git repo contains all fixes from the different git repos ? Just to be sure to only have 1 merge to do :) >> > Can we convince the lxpanelx author to contribute and (as time goes on) >> > merge upstream? > I think one of the more 'senior' members on this list attempted to > contact the lxpanelx developer, but I'm not sure what came out of it. I already contacted him, but it doesn't really want to work upstream ... >> > How does one get commit access? > No clue, but Julien would know :) An admin of the project need to give you commit access. I think only PCMan is actually an active admin of the project. >> > Sourceforge is a bit cumbersome in my opinion. Is the "Bugs"/"Feature >> > Requests"/"Patches" distinction useful? All of them should eventually >> > have patches, right? > Yes, but I think the distinction is important for record-keeping > purposes (whether that's the actual use, I don't know). And just for the record, I just hate this type of distinction. It's really hard to keep track of bugs and corresponding fixes, sometime double posted ... Regards, Julien Lavergne |
From: Piotr S. <pio...@gm...> - 2012-03-13 01:43:05
|
2012/3/12 Julien Lavergne <gi...@ub...> > Is this git repo contains all fixes from the different git repos ? Just > to be sure to only have 1 merge to do :) > > The gtk2-fixes branch contains the fixes from Henry's gtk2-fixes together with cleaning up all the compilation warnings. I still have to get through Alexandra's repository and the fixes she cherry-picked from lxpanelx, but I will do that as I go through the bug/feature tracker (comparing what's requested to what's already been done). > >> > Can we convince the lxpanelx author to contribute and (as time goes > on) > >> > merge upstream? > > I think one of the more 'senior' members on this list attempted to > > contact the lxpanelx developer, but I'm not sure what came out of it. > I already contacted him, but it doesn't really want to work upstream ... > > Pity, as it looks like he's making a lot of progress on his fork... Thanks! Piotr |
From: Henry G. <hsg...@go...> - 2012-03-12 23:37:13
|
On Tue, Mar 13, 2012 at 12:09:17AM +0100, Julien Lavergne wrote: > Le 03/08/2012 01:27 AM, Piotr Sipika a écrit : > > I did the easier thing first: I took your gtk2-fixes, added my patches > > from the tracker [1] and [2], and cleaned up all of the compilation > > warnings. > > > > Most of the warnings were improper GTK casts and I made sure that what > > was being cast to/from was in the same object hierarchy. > > > > The git repo is the master branch at: https://github.com/psipika/lxpanel > > > > I'm currently running the recompiled lxpanel and all looks fine, but the > > more testing hands, the better. > > > > If everything ends up looking good, I'd suggest pushing these updates > > upstream before new development takes place. > Is this git repo contains all fixes from the different git repos ? Just > to be sure to only have 1 merge to do :) Yes, all fixes are in psipika's branch, unless you are also willing to merge my 'gtk2-features' branch. :) Those are not huge features, but if you are strict... Should I rebase or merge that into one branch? ... ... > >> > Sourceforge is a bit cumbersome in my opinion. Is the "Bugs"/"Feature > >> > Requests"/"Patches" distinction useful? All of them should eventually > >> > have patches, right? > > Yes, but I think the distinction is important for record-keeping > > purposes (whether that's the actual use, I don't know). > And just for the record, I just hate this type of distinction. It's > really hard to keep track of bugs and corresponding fixes, sometime > double posted ... Julien, since you are effectively the lxpanel maintainer, do you want us to apply patches from the "bug/patch/feature"-tracker (if they look ok) for you to merge? Cheers, Henry |
From: Piotr S. <pio...@gm...> - 2012-03-13 01:48:00
|
> > Yes, all fixes are in psipika's branch, unless you are also willing to > merge my 'gtk2-features' branch. :) Those are not huge features, but if > you are strict... Should I rebase or merge that into one branch? > > If you could re-base it, I'd appreciate it - this way, I'll just do a pull and continue development starting with your changes. > Julien, since you are effectively the lxpanel maintainer, do you want us > to apply patches from the "bug/patch/feature"-tracker (if they look ok) > for you to merge? > > I think we should, but we should keep the list informed about what's being done - to avoid duplicate work. As soon as I get some time, I'll try to put something together to keep track of what's being worked on. Thanks again for your contributions and help. Great to see a bit of movement here... :-) All the best! Piotr |
From: Julien L. <gi...@ub...> - 2012-03-18 16:33:54
|
Le 03/13/2012 12:36 AM, Henry Gebhardt a écrit : > Yes, all fixes are in psipika's branch, unless you are also willing to > merge my 'gtk2-features' branch. :) Those are not huge features, but if > you are strict... Should I rebase or merge that into one branch? Thanks, I merged psipika branch :) > Julien, since you are effectively the lxpanel maintainer, do you want us > to apply patches from the "bug/patch/feature"-tracker (if they look ok) > for you to merge? Yes, you can look at them, they may be interested. Regards, Julien Lavergne |