This list is closed, nobody may subscribe to it.
2000 |
Jan
|
Feb
|
Mar
(1) |
Apr
(16) |
May
(3) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
2003 |
Jan
|
Feb
(7) |
Mar
(6) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
2004 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2005 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(7) |
Oct
(5) |
Nov
(5) |
Dec
(3) |
2006 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(11) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: rghetta <bir...@ti...> - 2018-06-09 18:03:19
|
Hello all: with traffic on EtherApe-users and EtherApe-devel mailing lists almost non existent, it's time to close them and switch all discussion to the forums. In a month or so the mailing lists will be made read-only and all subscribers removed. EtherApe-announce will remain active to handle release announcements as usual. |
From: rghetta <bir...@ti...> - 2018-06-09 17:57:00
|
EtherApe now is a pure GTK 3 application, with canvas supplied by GooCanvas (https://wiki.gnome.org/Projects/GooCanvas). While GooCanvas itself is in maintenance mode, is still the simplest canvas library available and with an API almost identical to gnome-canvas, too! Longer term, EtherApe ui should be completely redesigned and modernized, but this is for another day. This change was needed because several distributions are phasing out Gnome 2 libraries and EtherApe needs to update as well. Unfortunately, this mean dropping support for older distributions, for example CENTOS 5 and 6. At this time the EtherApe executable can still be built for those distributions, but not the project as a whole. |
From: <bc...@us...> - 2017-02-10 20:48:10
|
Thanks to the work of Zev Weiss, EtherApe 0.9.15 was released today. The central node ring setting now accepts multiple node specifiers (separated by any combination of spaces and/or commas), and also now understands glob syntax, so you can put for example 10.0.0.0/24, *.mydomain.tld, somehost.otherdomain.tld and it will do what you'd expect. There is now a compile-time configure option ('--with-c-ares', disabled by default) to enable DNS resolution via the c-ares library, supplanting EtherApe's built-in multithreaded gethostbyaddr(3)-based resolver. This is a fully non-blocking DNS library and thus has potential for better performance while using only a single background resolver thread, but also means that name-lookup is strictly DNS-based, and will thus not take /etc/hosts, NIS, or other name services into account. There is a slightly backwards-incompatible change in the syntax of the node-position file used with the '-P' flag added in release 0.9.14. It now uses the same CIDR notation plus hostname-globbing syntax used by the central node ring setting (instead of POSIX regular expressions). This provides simpler and more consistent syntax with essentially the same real-world utility, but may require some small changes to existing node-position files. Some examples: Old (regex) New (CIDR+glob) =============== =============== 172.16.2.[0-9]* 172.16.2.0/24 .*.mydomain.com *.mydomain.com fe80:.* fe80::/16 Additionally, each line of the node-position file may now include multiple such node-matching patterns (separated by spaces and/or commas as with the central node ring setting), so a single line might look like: *.mydomain.com, 10.0.0.0/24 3 (to put all nodes matching the given domain or CIDR range into column 3). As a security feature (privilege separation), packet-capture operations are now isolated in a separate background process. The new '-Z' flag can be used to specify a user to run the main (foreground) process as. Changes summary: * New option to use c-ares for DNS resolution. * Multiple node/subnets and glob syntax now supported for central node ring. * Node-matching syntax for '-P' flag's file now uses CIDR notation and hostname-globbing instead of regexes. * Multiple patterns can now be given on a single line of the node-position ('-P') file. * The columnar-layout ('-P') code has been changed to re-adjust the spacing of nodes within a column when the number of nodes decreases. The 10-column limit has also been removed. * The background-image feature introduced in 0.9.14 can now be turned off via a preference check-box. * The background of the protocol legend is now black so that lighter colors (e.g. yellow) are more readable. * There is now an option to display packet-capture statistics from libpcap in the main window (hover the mouse over them for an explanation in the status bar). * The show/hide state of the toolbar, protocol legend, and status bar are now preserved along with other preferences in the user's config file. * New '-Z' flag (or '--relinquish-privileges') can be used to run most processing as an unprivileged user. |
From: Zev W. <ze...@be...> - 2016-12-22 23:23:03
|
On Thu, Dec 22, 2016 at 09:04:56PM +0100, bc...@us... wrote: >On 22/12/2016 12:55, Zev Weiss wrote: >>Hi Riccardo, >>In commit 6ffe90 I added some logic to lift the arbitrary 10-column >>limit on the column layout code, but this commit seems to have >>re-introduced it (around line 394 or so of src/main.c, in the function >>parse_position_line()). Is there some particular reason that was >>needed, or would it be OK to take the '> 10' check back out? >> >>Thanks, >>Zev >Hmm, perhaps no. >There was a small problem with node_matches_spec_list crashing when >the column list had holes and at first I blamed the missing <10, then >forgot to remove the check after fixing the real bug. > >Ciao, >Riccardo Okay, thanks -- now back to unlimited in the latest commit. Zev |
From: <bc...@us...> - 2016-12-22 20:32:43
|
On 22/12/2016 12:55, Zev Weiss wrote: > Hi Riccardo, > In commit 6ffe90 I added some logic to lift the arbitrary 10-column > limit on the column layout code, but this commit seems to have > re-introduced it (around line 394 or so of src/main.c, in the function > parse_position_line()). Is there some particular reason that was > needed, or would it be OK to take the '> 10' check back out? > > Thanks, > Zev Hmm, perhaps no. There was a small problem with node_matches_spec_list crashing when the column list had holes and at first I blamed the missing <10, then forgot to remove the check after fixing the real bug. Ciao, Riccardo |
From: Zev W. <ze...@be...> - 2016-12-22 12:11:51
|
On Fri, Oct 07, 2016 at 05:46:20AM +0000, EtherApe Mercurial repository wrote: > >## Branch: default > ><div class="markdown_content"><p>move static data to common appdata struct, tweak radius slider, handle column corner cases</div> > >By R.Ghetta on 10/07/2016 05:30 >[**View Changes**](https://sourceforge.net/p/etherape/etherape/ci/a2d78a1cd298fc3a2ef25478d86433fc6217e9e4/) > > Hi Riccardo, In commit 6ffe90 I added some logic to lift the arbitrary 10-column limit on the column layout code, but this commit seems to have re-introduced it (around line 394 or so of src/main.c, in the function parse_position_line()). Is there some particular reason that was needed, or would it be OK to take the '> 10' check back out? Thanks, Zev |
From: <bc...@us...> - 2016-03-05 19:04:40
|
Zev Weiss in the past months has contributed several quality patches. It's a pleasure to announce he has now full committer rights for EtherApe. |
From: <bc...@us...> - 2016-02-07 11:11:39
|
With the work of several contributors, EtherApe 0.9.14 was released yesterday. EtherApe now users the system /etc/services file instead of its own. While this change make some customizations a bit harder, it guarantees an up-to-date services file. Note to packagers: /etc/etherape is not needed anymore. Central node option now undestands CIDR notation, allowing for a central ring of nodes, thanks to Zev Weiss. Static background image, courtesy of Glenn Feunteun. Nodes can be optionally arranged as columns, thanks to David Goldfarb. Changes summary: * autoconf updated to 2.69 * fixed incorrect WLAN control frames decoding * fix UTF-8 encoding of several files, thanks to StrPt. * read system services file instead of EtherApe one, thanks to Zev Weiss. * fix race condition on exit, thanks to Zev Weiss * central ring option, thanks to Zev Weiss * tweaks to preference windows to better work with tiling managers, thanks to Zev Weiss. * static background image (Glenn Feunteun) * arrange nodes in 'columns' (David Goldfarb) |
From: grongo <gr...@ya...> - 2015-08-28 18:53:32
|
Should be fixed on latest commit. Thank you for the tip. R On 27/08/2015 13:48, Ronald Henderson wrote: > Developers: > > > > Just compiled the latest mercurial commit: 935e35 and Etherape now crashes > when resizing its window. > > > > I believe it has to do with the new background feature. I do like the new > feature for customizing to an environment. If I do load a background image > it appears to resize normally. I believe the issue only occurs when a > background image is not defined (i.e., the default state). > > > > ---Thanks > > Ron Henderson > > Co-Author of NST > > ------------------------------------------------------------------------------ > _______________________________________________ > Etherape-devel mailing list > Eth...@li... > https://lists.sourceforge.net/lists/listinfo/etherape-devel > |
From: Ronald H. <rw...@ve...> - 2015-08-27 11:48:13
|
Developers: Just compiled the latest mercurial commit: 935e35 and Etherape now crashes when resizing its window. I believe it has to do with the new background feature. I do like the new feature for customizing to an environment. If I do load a background image it appears to resize normally. I believe the issue only occurs when a background image is not defined (i.e., the default state). ---Thanks Ron Henderson Co-Author of NST |
From: grongo <gr...@ya...> - 2015-07-26 16:18:10
|
Hi, I've committed your patch. Many thanks for your work! Riccardo |
From: grongo <gr...@ya...> - 2015-07-03 21:04:06
|
On 07/02/2015 07:06 PM, gle...@or... wrote: > Hello, > > I submitted a patch for background image printing on SourceForge. > Please tell me if there is anything to modify or improve. > > I will post another patch on fix nodes mode in a few days. > > Glenn Good, thanks. I'm currently away, with only very basic http and mail access, so cannot properly verify your patch before about half july, but at a quick glance its seems ok, thank you! Riccardo |
From: <gle...@or...> - 2015-07-02 17:22:19
|
Hello, I submitted a patch for background image printing on SourceForge. Please tell me if there is anything to modify or improve. I will post another patch on fix nodes mode in a few days. Glenn -----Message d'origine----- De : grongo [mailto:gr...@ya...] Envoyé : mercredi 1 juillet 2015 11:04 À : eth...@li... Objet : Re: [Etherape-devel] Enhancement idea, fix nodes mode On 06/29/2015 09:44 AM, gle...@or... wrote: > Hello, > > I am using Etherape for demonstrations and find it very efficient to introduce architectures to people. > > However, sometimes when the nodes move around it's not clear nor easy to understand. > In order to enhance the readability of the architecture I think that it would be good to have a fix mode where the nodes could be placed by the user. > This mode would be selected in a menu (an additional check box in the View menu for example) and the nodes could then be moved on the canvas by the user (with Drag and Drop or by typing X and Y coordinates in the node window). > A complement of this would be to have the ability to draw an image in the background. That way we could print an architecture image and pin nodes to their visual representations. > > At the moment I have implemented the background image printing and I am working on the fix nodes. > I saw activity on the mailing list and I would like to know what you think of this idea. Yes, it's a very good idea. Thank you for working on it! R > Best regards, > > Glenn > > > ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ Etherape-devel mailing list Eth...@li... https://lists.sourceforge.net/lists/listinfo/etherape-devel _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. |
From: grongo <gr...@ya...> - 2015-07-01 09:23:25
|
On 06/29/2015 10:00 AM, gle...@or... wrote: > Hello again, > > A question about SourceForge hosting. > SourceForge has received a lot of criticisms during the last years. Accusations of adding adwares, hijacking admin accounts etc... > The site is now considered harmful by google : http://i.imgur.com/FAv6VdV.png > Lots of software moved to others places (GIMP : http://www.itworld.com/article/2830524/was-the-gimp-right-to-leave-sourceforge.html , Notepad++ : https://notepad-plus-plus.org/news/notepad-plus-plus-leaves-sf.html , VLC : https://blog.l0cal.com/2015/06/02/what-happened-to-sourceforge/ , Nmap : http://seclists.org/nmap-dev/2015/q2/194 ) > > In order to preserve Etherape, it would be good to consider migrating the hosting to another place. > This website could help http://helb.github.io/goodbye-sourceforge/ Yes, I was wondering about it, too. Right now, I'm inclined to wait a bit, though. Sourceforge still hosts many projects, and I'd like to move etherape only as a last resort, since it would mean having users to resubscribe to mailing lists, change download links and so on. In short, bothering people excessively, at least for a low activity project like etherape and now that public outcry is forcing sourceforge to better behave. After a few months, with the dust settled, we will be in a better position to choose. Ciao, R |
From: grongo <gr...@ya...> - 2015-07-01 09:07:02
|
On 06/29/2015 09:44 AM, gle...@or... wrote: > Hello, > > I am using Etherape for demonstrations and find it very efficient to introduce architectures to people. > > However, sometimes when the nodes move around it's not clear nor easy to understand. > In order to enhance the readability of the architecture I think that it would be good to have a fix mode where the nodes could be placed by the user. > This mode would be selected in a menu (an additional check box in the View menu for example) and the nodes could then be moved on the canvas by the user (with Drag and Drop or by typing X and Y coordinates in the node window). > A complement of this would be to have the ability to draw an image in the background. That way we could print an architecture image and pin nodes to their visual representations. > > At the moment I have implemented the background image printing and I am working on the fix nodes. > I saw activity on the mailing list and I would like to know what you think of this idea. Yes, it's a very good idea. Thank you for working on it! R > Best regards, > > Glenn > > > |
From: <gle...@or...> - 2015-06-29 08:00:41
|
Hello again, A question about SourceForge hosting. SourceForge has received a lot of criticisms during the last years. Accusations of adding adwares, hijacking admin accounts etc... The site is now considered harmful by google : http://i.imgur.com/FAv6VdV.png Lots of software moved to others places (GIMP : http://www.itworld.com/article/2830524/was-the-gimp-right-to-leave-sourceforge.html , Notepad++ : https://notepad-plus-plus.org/news/notepad-plus-plus-leaves-sf.html , VLC : https://blog.l0cal.com/2015/06/02/what-happened-to-sourceforge/ , Nmap : http://seclists.org/nmap-dev/2015/q2/194 ) In order to preserve Etherape, it would be good to consider migrating the hosting to another place. This website could help http://helb.github.io/goodbye-sourceforge/ Best regards, Glenn _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. |
From: <gle...@or...> - 2015-06-29 08:00:33
|
Hello, I am using Etherape for demonstrations and find it very efficient to introduce architectures to people. However, sometimes when the nodes move around it's not clear nor easy to understand. In order to enhance the readability of the architecture I think that it would be good to have a fix mode where the nodes could be placed by the user. This mode would be selected in a menu (an additional check box in the View menu for example) and the nodes could then be moved on the canvas by the user (with Drag and Drop or by typing X and Y coordinates in the node window). A complement of this would be to have the ability to draw an image in the background. That way we could print an architecture image and pin nodes to their visual representations. At the moment I have implemented the background image printing and I am working on the fix nodes. I saw activity on the mailing list and I would like to know what you think of this idea. Best regards, Glenn _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. |
From: <bc...@us...> - 2015-05-29 20:54:55
|
Sorry, only today I discovered your messages. It seems that sf.net is not forwarding mails to me anymore. I apologize for leaving you in the dark so much, I understand the frustration of doing work and not having any response. Just be assured it was only an unfortunate accident. Yes, I'll be extremely happy to receive further contributions, but please add them as patches to the patch queue (Tickets|Patches). This way, if sourceforge continues to misbehave, at least I can handle your patches without using the horrible mail archive interface. I gave only a cursory glance to your current patches, but overall everything seems ok, with the exception of the c-ares one. Unfortunately AFAIK c-ares is a DNS-only library, like the older resolver used by EtherApe before rolling the current one. Several users asked for full name resolution (i.e. hosts file, NIS etc) and using gethostbyaddr_r with multiple threads seemed a reasonable compromise between simplicity and features. Perhaps c-ares could be reworked as a compilation option for those who only need DNS-style resolving ? Again, sorry for the delay, and thank you for your contributions. Riccardo > Submitted half a dozen or so patches a month ago, thus far not a peep in reply...ping? I still have further development planned -- should I just go ahead and start maintaining an independent fork? > > > Zev Weiss > > > |
From: Zev W. <ze...@be...> - 2014-08-29 08:04:48
|
Submitted half a dozen or so patches a month ago, thus far not a peep in reply...ping? I still have further development planned -- should I just go ahead and start maintaining an independent fork? Zev Weiss |
From: Zev W. <ze...@be...> - 2014-07-28 05:19:00
|
Hello, The below (trivial) patch changes the label of the "Start" button to better match the item in the "Capture" menu. Thanks, Zev Weiss commit b4809fb623c9958de2a19066f1b3512a29575e28 Author: Zev Weiss <ze...@be...> Date: 2014-07-28 00:15:48 -0500 Change label of "Start" button to "Play". Matches capture menu item now. diff --git a/glade/etherape.glade b/glade/etherape.glade index 887dc64..2f6490c 100644 --- a/glade/etherape.glade +++ b/glade/etherape.glade @@ -2337,7 +2337,7 @@ Daniel Nylander <property name="visible">True</property> <property name="has_tooltip">True</property> <property name="tooltip" translatable="yes">Start capture</property> - <property name="label" translatable="yes">Start</property> + <property name="label" translatable="yes">Play</property> <property name="use_underline">True</property> <property name="stock_id">gtk-media-play</property> <signal name="clicked" handler="on_start_menuitem_activate"/> |
From: Zev W. <ze...@be...> - 2014-07-28 01:38:55
|
Hi, This patch makes some of etherape's various auxiliary windows behave more nicely in a tiling WM environment (such as xmonad). Thanks, Zev Weiss commit 1249d3a76ad100301fdccf6b57731c5a900f59dc Author: Zev Weiss <ze...@be...> Date: 2014-07-27 20:10:07 -0500 Set some attributes on auxiliary windows. Gives friendlier behavior when run under a tiling window manager. diff --git a/glade/etherape.glade b/glade/etherape.glade index ec1d2a5..887dc64 100644 --- a/glade/etherape.glade +++ b/glade/etherape.glade @@ -48,6 +48,9 @@ <widget class="GtkDialog" id="diag_pref"> <property name="title" translatable="yes">EtherApe: Preferences</property> <property name="type_hint">dialog</property> + <property name="resizable">False</property> + <property name="window_position">center</property> + <property name="type_hint">dialog</property> <child internal-child="vbox"> <widget class="GtkVBox" id="dialog-vbox2"> <property name="visible">True</property> @@ -1408,6 +1411,7 @@ Square Root</property> <property name="title" translatable="yes">Select color</property> <property name="resizable">False</property> <property name="type_hint">dialog</property> + <property name="window_position">center</property> <signal name="delete_event" handler="gtk_widget_hide"/> <child internal-child="color_selection"> <widget class="GtkColorSelection" id="colorselection1"> @@ -1443,6 +1447,8 @@ Square Root</property> <widget class="GtkDialog" id="protocol_edit_dialog"> <property name="title" translatable="yes">EtherApe: assign protocol</property> <property name="modal">True</property> + <property name="resizable">False</property> + <property name="window_position">center</property> <property name="type_hint">dialog</property> <signal name="show" handler="on_protocol_edit_dialog_show"/> <child internal-child="vbox"> @@ -1933,6 +1939,7 @@ Square Root</property> <widget class="GtkAboutDialog" id="about1"> <property name="border_width">5</property> <property name="type_hint">normal</property> + <property name="window_position">center</property> <property name="has_separator">False</property> <property name="program_name">EtherApe</property> <property name="copyright" translatable="yes">Copyright 2001-2013 Juan Toledo, Riccardo Ghetta</property> |
From: Zev W. <ze...@be...> - 2014-07-28 00:18:56
|
On Jul 27, 2014, at 5:43 PM, Zev Weiss <ze...@be...> wrote: > > On Jul 27, 2014, at 2:59 AM, Zev Weiss <ze...@be...> wrote: > >> >> On Jul 27, 2014, at 2:49 AM, Zev Weiss <ze...@be...> wrote: >> >>> Hello, >>> >>> This patch extends and generalizes the idea of the center node to allow the user to specify a CIDR address range of nodes that are displayed on a smaller node ring inside the larger outer node ring. The intent is to allow you to put for example your own LAN on the central ring and leave the rest of the Internet displayed on the outer ring. >>> >>> This patch does not alter the label in the preferences dialog to indicate the expanded functionality; I have a separate patch that does so but it seems to have dragged in a lot of auto-updated noise in po/*.po so I wasn't sure if I should include it. I can send it separately as a subsequent patch if so. >>> >>> >>> Thanks, >>> Zev Weiss >>> <patch snipped> >> >> And of course as soon I sent that I realized a small improvement that could be made to the layout...relative to that patch, this one makes things a bit more readable. >> <snip> > > And as another small fix/improvement, this patch makes changes to the centered-nodes setting take effect immediately instead of whenever the next reposition would have happened anyway. > <snip> Another follow-on patch, making the relative scale of the inner node ring adjustable via a preferences slider. commit 8492b107c8bfeafec05cedecaebe5fa115247d84 Author: Zev Weiss <ze...@be...> Date: 2014-07-27 19:14:47 -0500 Make inner node ring scale adjustable. diff --git a/glade/etherape.glade b/glade/etherape.glade index 510956b..ec1d2a5 100644 --- a/glade/etherape.glade +++ b/glade/etherape.glade @@ -150,6 +150,48 @@ Average pkt size (In+Out) </packing> </child> <child> + <widget class="GtkVBox" id="vbox8"> + <property name="visible">True</property> + <property name="orientation">vertical</property> + <child> + <widget class="GtkLabel" id="label10"> + <property name="visible">True</property> + <property name="xalign">0</property> + <property name="label" translatable="yes">_Inner Ring Scale</property> + <property name="use_underline">True</property> + </widget> + <packing> + <property name="expand">False</property> + <property name="fill">False</property> + <property name="padding">2</property> + <property name="position">0</property> + </packing> + </child> + <child> + <widget class="GtkHScale" id="inner_ring_scale_slider"> + <property name="visible">True</property> + <property name="can_focus">True</property> + <property name="tooltip" translatable="yes">Inner ring radius as a fraction of outer ring size</property> + <property name="adjustment">0.5 0.01 1 0.01 0.25 0</property> + <property name="digits">2</property> + <property name="draw_value">True</property> + <property name="value_pos">right</property> + </widget> + <packing> + <property name="expand">False</property> + <property name="fill">False</property> + <property name="position">1</property> + </packing> + </child> + </widget> + <packing> + <property name="top_attach">6</property> + <property name="bottom_attach">7</property> + <property name="x_options">GTK_FILL</property> + <property name="y_options">GTK_FILL</property> + </packing> + </child> + <child> <widget class="GtkVBox" id="vbox6"> <property name="visible">True</property> <property name="orientation">vertical</property> diff --git a/src/diagram.c b/src/diagram.c index 343921d..3161589 100644 --- a/src/diagram.c +++ b/src/diagram.c @@ -1215,8 +1215,8 @@ static gint reposition_canvas_nodes(node_id_t * node_id, if (canvas_node->centered && data->center.n_nodes > 1) { /* For the inner ring, just move it halfway closer the the center point. */ - x = center_x + ((x - center_x) / 2.0); - y = center_y + ((y - center_y) / 2.0); + x = center_x + ((x - center_x) * pref.inner_ring_scale); + y = center_y + ((y - center_y) * pref.inner_ring_scale); } } } diff --git a/src/pref_dialog.c b/src/pref_dialog.c index c7530a2..48d59d3 100644 --- a/src/pref_dialog.c +++ b/src/pref_dialog.c @@ -102,6 +102,11 @@ initialize_pref_controls(void) pref.link_node_ratio); g_signal_emit_by_name (GTK_OBJECT (GTK_RANGE (widget)->adjustment), "changed"); + widget = glade_xml_get_widget (appdata.xml, "inner_ring_scale_slider"); + gtk_adjustment_set_value (GTK_RANGE (widget)->adjustment, + pref.inner_ring_scale); + g_signal_emit_by_name (GTK_OBJECT (GTK_RANGE (widget)->adjustment), + "changed"); spin = GTK_SPIN_BUTTON (glade_xml_get_widget (appdata.xml, "averaging_spin")); gtk_spin_button_set_value (spin, pref.averaging_time); spin = GTK_SPIN_BUTTON (glade_xml_get_widget (appdata.xml, "refresh_spin")); @@ -179,6 +184,11 @@ initialize_pref_controls(void) "value_changed", GTK_SIGNAL_FUNC (on_link_width_slider_adjustment_changed), NULL); + widget = glade_xml_get_widget (appdata.xml, "inner_ring_scale_slider"); + g_signal_connect (G_OBJECT (GTK_RANGE (widget)->adjustment), + "value_changed", + GTK_SIGNAL_FUNC + (on_inner_ring_scale_slider_adjustment_changed), NULL); widget = glade_xml_get_widget (appdata.xml, "averaging_spin"); g_signal_connect (G_OBJECT (GTK_SPIN_BUTTON (widget)->adjustment), "value_changed", @@ -290,6 +300,16 @@ on_link_width_slider_adjustment_changed (GtkAdjustment * adj) } void +on_inner_ring_scale_slider_adjustment_changed (GtkAdjustment * adj) +{ + pref.inner_ring_scale = adj->value; + g_log (G_LOG_DOMAIN, G_LOG_LEVEL_DEBUG, + _("Adjustment value: %g. Inner ring scale %g"), + adj->value, pref.inner_ring_scale); + ask_reposition(FALSE); +} + +void on_averaging_spin_adjustment_changed (GtkAdjustment * adj) { pref.averaging_time = adj->value; /* Control and value in ms */ diff --git a/src/pref_dialog.h b/src/pref_dialog.h index 6cad909..19c633b 100644 --- a/src/pref_dialog.h +++ b/src/pref_dialog.h @@ -35,6 +35,7 @@ void on_refresh_spin_adjustment_changed (GtkAdjustment * adj, GtkWidget * canvas); void on_node_radius_slider_adjustment_changed (GtkAdjustment * adj); void on_link_width_slider_adjustment_changed (GtkAdjustment * adj); +void on_inner_ring_scale_slider_adjustment_changed (GtkAdjustment * adj); void on_node_to_spin_adjustment_changed (GtkAdjustment * adj); void on_gui_node_to_spin_adjustment_changed (GtkAdjustment * adj); void on_proto_node_to_spin_adjustment_changed (GtkAdjustment * adj); diff --git a/src/preferences.c b/src/preferences.c index fc28033..4839b2b 100644 --- a/src/preferences.c +++ b/src/preferences.c @@ -101,6 +101,7 @@ void init_config(struct pref_struct *p) p->stationary = FALSE; p->node_radius_multiplier = 0.0005; p->link_node_ratio = 1; + p->inner_ring_scale = 0.5; p->size_mode = LINEAR; p->node_size_variable = INST_OUTBOUND; p->stack_level = 0; @@ -138,6 +139,7 @@ void set_default_config(struct pref_struct *p) p->averaging_time = 2000.0; p->node_radius_multiplier = 0.0005; p->link_node_ratio = 1.0; + p->inner_ring_scale = 0.5; p->refresh_period = 100; p->size_mode = LINEAR; p->node_size_variable = INST_OUTBOUND; @@ -216,6 +218,7 @@ void load_config(void) read_double_config(&pref.averaging_time, gkey, "averaging_time"); read_double_config(&pref.node_radius_multiplier, gkey, "node_radius_multiplier"); read_double_config(&pref.link_node_ratio, gkey, "link_node_ratio"); + read_double_config(&pref.inner_ring_scale, gkey, "inner_ring_scale"); read_string_config(&tmpstr, gkey, "colors"); if (tmpstr) @@ -274,6 +277,8 @@ void save_config(void) pref.node_radius_multiplier); g_key_file_set_double(gkey, pref_group, "link_node_ratio", pref.link_node_ratio); + g_key_file_set_double(gkey, pref_group, "inner_ring_scale", + pref.inner_ring_scale); g_key_file_set_integer(gkey, pref_group, "refresh_period", pref.refresh_period); g_key_file_set_integer(gkey, pref_group, "size_mode", pref.size_mode); g_key_file_set_integer(gkey, pref_group, "node_size_variable", @@ -365,6 +370,7 @@ void copy_config(struct pref_struct *tgt, const struct pref_struct *src) tgt->stationary = src->stationary; tgt->node_radius_multiplier = src->node_radius_multiplier; tgt->link_node_ratio = src->link_node_ratio; + tgt->inner_ring_scale = src->inner_ring_scale; tgt->size_mode = src->size_mode; tgt->node_size_variable = src->node_size_variable; tgt->filter=g_strdup(src->filter); diff --git a/src/preferences.h b/src/preferences.h index 1f46126..0c2b6e9 100644 --- a/src/preferences.h +++ b/src/preferences.h @@ -38,6 +38,7 @@ struct pref_struct * value, the GUI uses the log10 of the * multiplier */ gdouble link_node_ratio; /* link width to node radius ratio */ + gdouble inner_ring_scale; /* scale of inner ring in proportion to outer ring */ size_mode_t size_mode; /* Default mode for node size and * link width calculation */ node_size_variable_t node_size_variable; /* Default variable that sets the node |
From: Zev W. <ze...@be...> - 2014-07-27 22:43:39
|
On Jul 27, 2014, at 2:59 AM, Zev Weiss <ze...@be...> wrote: > > On Jul 27, 2014, at 2:49 AM, Zev Weiss <ze...@be...> wrote: > >> Hello, >> >> This patch extends and generalizes the idea of the center node to allow the user to specify a CIDR address range of nodes that are displayed on a smaller node ring inside the larger outer node ring. The intent is to allow you to put for example your own LAN on the central ring and leave the rest of the Internet displayed on the outer ring. >> >> This patch does not alter the label in the preferences dialog to indicate the expanded functionality; I have a separate patch that does so but it seems to have dragged in a lot of auto-updated noise in po/*.po so I wasn't sure if I should include it. I can send it separately as a subsequent patch if so. >> >> >> Thanks, >> Zev Weiss >> <patch snipped> > > And of course as soon I sent that I realized a small improvement that could be made to the layout...relative to that patch, this one makes things a bit more readable. > <snip> And as another small fix/improvement, this patch makes changes to the centered-nodes setting take effect immediately instead of whenever the next reposition would have happened anyway. commit 51f9d30f8f69391b891e1d7c1614dcc72fde0429 Author: Zev Weiss <ze...@be...> Date: 2014-07-27 17:41:22 -0500 Reposition nodes when centered_nodes changes. diff --git a/src/pref_dialog.c b/src/pref_dialog.c index ccc2b38..c7530a2 100644 --- a/src/pref_dialog.c +++ b/src/pref_dialog.c @@ -462,6 +462,7 @@ static void on_center_node_changed(GtkComboBoxEntry * cbox, gpointer user_data) pref.centered_nodes = g_strdup (str); g_free (str); cbox_add_select(cbox, pref.centered_nodes); + ask_reposition(FALSE); } void |
From: Zev W. <ze...@be...> - 2014-07-27 07:59:54
|
On Jul 27, 2014, at 2:49 AM, Zev Weiss <ze...@be...> wrote: > Hello, > > This patch extends and generalizes the idea of the center node to allow the user to specify a CIDR address range of nodes that are displayed on a smaller node ring inside the larger outer node ring. The intent is to allow you to put for example your own LAN on the central ring and leave the rest of the Internet displayed on the outer ring. > > This patch does not alter the label in the preferences dialog to indicate the expanded functionality; I have a separate patch that does so but it seems to have dragged in a lot of auto-updated noise in po/*.po so I wasn't sure if I should include it. I can send it separately as a subsequent patch if so. > > > Thanks, > Zev Weiss > <patch snipped> And of course as soon I sent that I realized a small improvement that could be made to the layout...relative to that patch, this one makes things a bit more readable. commit eda89ac9ab107ac35f25261de8ba5f3c89e76316 Author: Zev Weiss <ze...@be...> Date: 2014-07-27 02:56:09 -0500 Small inner-ring layout improvement. Makes things a bit more readable with small numbers of nodes. diff --git a/src/diagram.c b/src/diagram.c index 83b0db6..343921d 100644 --- a/src/diagram.c +++ b/src/diagram.c @@ -1075,6 +1075,13 @@ static void init_reposition(reposition_node_t *data, memset(&data->center, 0, sizeof(data->center)); memset(&data->outer, 0, sizeof(data->outer)); + /* + * Offset the starting angle on the center ring so that when there are + * relatively few nodes displayed (e.g. 4 central and 4 outer) the links + * obscure things less (by not overlapping node labels and other links). + */ + data->center.angle += M_PI / 4.0; + gnome_canvas_get_scroll_region (GNOME_CANVAS (canvas), &data->xmin, &data->ymin, &data->xmax, &data->ymax); |
From: Zev W. <ze...@be...> - 2014-07-27 07:49:26
|
Hello, This patch extends and generalizes the idea of the center node to allow the user to specify a CIDR address range of nodes that are displayed on a smaller node ring inside the larger outer node ring. The intent is to allow you to put for example your own LAN on the central ring and leave the rest of the Internet displayed on the outer ring. This patch does not alter the label in the preferences dialog to indicate the expanded functionality; I have a separate patch that does so but it seems to have dragged in a lot of auto-updated noise in po/*.po so I wasn't sure if I should include it. I can send it separately as a subsequent patch if so. Thanks, Zev Weiss commit 633acbd99e908233a6ef6413f67e29ba20944297 Author: Zev Weiss <ze...@be...> Date: 2014-07-27 01:21:16 -0500 Extend center node to allow a second smaller node ring. This allows specifying a CIDR range of addresses that will have their nodes distributed around a smaller concentric inner ring of nodes, so you can position e.g. your subnet on the inner ring and everything else in the outer ring. diff --git a/src/diagram.c b/src/diagram.c index 4a073ab..83b0db6 100644 --- a/src/diagram.c +++ b/src/diagram.c @@ -21,6 +21,8 @@ #include <config.h> #endif +#include <arpa/inet.h> + #include <gnome.h> #include "appdata.h" @@ -36,6 +38,7 @@ #include "conversations.h" #include "preferences.h" #include "export.h" +#include "util.h" /* maximum node and link size */ #define MAX_NODE_SIZE 5000 @@ -87,13 +90,40 @@ static gint canvas_link_update(link_id_t * link_id, canvas_link_t * canvas_link, GList ** delete_list); - -typedef struct +struct nodeset_spec +{ + enum + { + NS_HOSTNAME, + NS_CIDRRANGE, + NS_NONE, + } kind; + + union + { + struct + { + address_t addr; + unsigned nbits; + } cidrrange; + const gchar* hostname; + }; +}; + +struct node_ring { - GtkWidget * canvas; gfloat angle; guint node_i; guint n_nodes; +}; + +typedef struct +{ + GtkWidget * canvas; + + struct node_ring outer; + struct node_ring center; + gdouble xmin; gdouble ymin; gdouble xmax; @@ -102,7 +132,7 @@ typedef struct gdouble y_rad_max; gdouble x_inner_rad_max; gdouble y_inner_rad_max; - + struct nodeset_spec centered_nodes; } reposition_node_t; @@ -155,6 +185,9 @@ static gint traffic_compare (gconstpointer a, gconstpointer b); static gint reposition_canvas_nodes (node_id_t * node_id, canvas_node_t * canvas_node, reposition_node_t *data); +static gint reposition_canvas_nodes_prep(node_id_t * node_id, + canvas_node_t * canvas_node, + reposition_node_t *data); static gint check_new_link (link_id_t * link_id, link_t * link, GtkWidget * canvas); static gdouble get_node_size (gdouble average); @@ -361,9 +394,18 @@ diagram_update_nodes(GtkWidget * canvas) { reposition_node_t rdata; init_reposition(&rdata, canvas, displayed_nodes); + + g_tree_foreach(canvas_nodes, + (GTraverseFunc) reposition_canvas_nodes_prep, + &rdata); + + rdata.center.node_i = rdata.center.n_nodes; + rdata.outer.node_i = rdata.outer.n_nodes; + g_tree_foreach(canvas_nodes, (GTraverseFunc) reposition_canvas_nodes, &rdata); + need_reposition = FALSE; need_font_refresh = FALSE; } @@ -924,6 +966,103 @@ traffic_compare (gconstpointer a, gconstpointer b) } /* traffic_compare */ +/* + * Attempt to parse orig_specstr as an IP address or CIDR range + * (e.g. 192.168.1.0/24) in either v4 or v6 notation; if both fail, fall back + * to treating orig_specstr as a single hostname. + */ +static void parse_nodeset_spec(const gchar *orig_specstr, + struct nodeset_spec *nodeset) +{ + gchar *addr_str; + gchar *pfxlen_str; + long pfxlen; + gchar *slash; + gchar *specstr = g_strdup(orig_specstr); + + slash = strchr(specstr, '/'); + if (slash) + { + /* Split prefix-length off from address */ + *slash = '\0'; + pfxlen_str = slash + 1; + if (strict_strtol(pfxlen_str, 10, &pfxlen) || pfxlen < 0) + pfxlen = -1; + } + else + pfxlen = -1; + addr_str = specstr; + + if (inet_pton(AF_INET, addr_str, &nodeset->cidrrange.addr.addr_v4)) + { + nodeset->kind = NS_CIDRRANGE; + nodeset->cidrrange.addr.type = AF_INET; + if (pfxlen >= 0 && pfxlen <= 32) + nodeset->cidrrange.nbits = pfxlen; + else + nodeset->cidrrange.nbits = 32; + } + else if (inet_pton(AF_INET6, addr_str, &nodeset->cidrrange.addr.addr_v6)) + { + nodeset->kind = NS_CIDRRANGE; + nodeset->cidrrange.addr.type = AF_INET6; + if (pfxlen >= 0 && pfxlen <= 128) + nodeset->cidrrange.nbits = pfxlen; + else + nodeset->cidrrange.nbits = 128; + } + else if (*orig_specstr) + { + nodeset->kind = NS_HOSTNAME; + nodeset->hostname = orig_specstr; + } + else + nodeset->kind = NS_NONE; + + g_free(specstr); +} + +/* Like memcp(3), but bitwise (big-endian at the sub-byte level) */ +static int bitwise_memcmp(const void *a, const void *b, size_t nbits) +{ + int ret; + unsigned char a_last, b_last, mask; + size_t wholebytes = nbits / CHAR_BIT, rembits = nbits % CHAR_BIT; + + ret = memcmp(a, b, wholebytes); + if (ret) + return ret; + + mask = ~(rembits ? (1 << (CHAR_BIT - rembits)) - 1 : 0xFF); + a_last = *((unsigned char*)a + wholebytes) & mask; + b_last = *((unsigned char*)b + wholebytes) & mask; + + return a_last - b_last; +} + +/* Check if 'node' matches 'spec' */ +static int nodeset_match(const struct nodeset_spec *spec, const node_t *node) +{ + const address_t *nodeaddr; + + if (spec->kind == NS_HOSTNAME + && (!strcmp(node->name->str, spec->hostname) + || !strcmp(node->numeric_name->str, spec->hostname))) + return 1; + + if (node->node_id.node_type == IP) + nodeaddr = &node->node_id.addr.ip; + else if (node->node_id.node_type == TCP) + nodeaddr = &node->node_id.addr.tcp4.host; + else + return 0; + + if (nodeaddr->type != spec->cidrrange.addr.type) + return 0; + + return !bitwise_memcmp(nodeaddr->addr8, spec->cidrrange.addr.addr8, + spec->cidrrange.nbits); +} /* initialize reposition struct */ static void init_reposition(reposition_node_t *data, @@ -933,11 +1072,8 @@ static void init_reposition(reposition_node_t *data, gdouble text_compensation = 50; data->canvas = canvas; - data->angle = 0.0; - data->node_i = 0; - data->n_nodes = 0; - data->n_nodes = total_nodes; - data->node_i = total_nodes; + memset(&data->center, 0, sizeof(data->center)); + memset(&data->outer, 0, sizeof(data->outer)); gnome_canvas_get_scroll_region (GNOME_CANVAS (canvas), &data->xmin, &data->ymin, @@ -953,6 +1089,40 @@ static void init_reposition(reposition_node_t *data, data->y_rad_max = 0.9 * (data->ymax - data->ymin) / 2; data->x_inner_rad_max = data->x_rad_max / 2; data->y_inner_rad_max = data->y_rad_max / 2; + + /* FIXME: would be nice to re-parse only when changed, not every reposition */ + if (pref.centered_nodes) + parse_nodeset_spec(pref.centered_nodes, &data->centered_nodes); + else + data->centered_nodes.kind = NS_NONE; +} + +/* + * A preparatory pass to count how many nodes are centered and how many are on + * the outer ring (and mark each appropriately). + */ +static gint reposition_canvas_nodes_prep(node_id_t *node_id, + canvas_node_t *canvas_node, + reposition_node_t *rdata) +{ + node_t *node; + + if (!canvas_node->shown) + return FALSE; + + node = nodes_catalog_find((const node_id_t*)&canvas_node->canvas_node_id); + if (node && nodeset_match(&rdata->centered_nodes, node)) + { + canvas_node->centered = TRUE; + rdata->center.n_nodes++; + } + else + { + canvas_node->centered = FALSE; + rdata->outer.n_nodes++; + } + + return FALSE; } /* Called from update_diagram if the global need_reposition @@ -963,8 +1133,9 @@ static gint reposition_canvas_nodes(node_id_t * node_id, canvas_node_t * canvas_node, reposition_node_t *data) { + struct node_ring *ring; + gdouble center_x, center_y, oddAngle; gdouble x = 0, y = 0; - gdouble oddAngle; if (!canvas_node->shown) { @@ -973,8 +1144,11 @@ static gint reposition_canvas_nodes(node_id_t * node_id, return FALSE; } - oddAngle = data->angle; - + ring = canvas_node->centered ? &data->center : &data->outer; + + center_x = (data->xmax - data->xmin) / 2 + data->xmin; + center_y = (data->ymax - data->ymin) / 2 + data->ymin; + /* TODO I've done all the stationary changes in a hurry * I should review it an tidy up all this stuff */ if (pref.stationary) @@ -1006,40 +1180,38 @@ static gint reposition_canvas_nodes(node_id_t * node_id, } else { - if (canvas_node->is_new && *pref.center_node) { - node_t * node; - - /* center node specified, check to see if current node is centered */ - node = nodes_catalog_find((const node_id_t *)&canvas_node->canvas_node_id); - /* If it is one of the "centered" nodes change the coordinates */ - if (node) { - if (!strcmp(node->name->str, pref.center_node) || - !strcmp(node->numeric_name->str, pref.center_node)) { - canvas_node->centered = TRUE; - } - } - } - - if (canvas_node->centered) { - /* centered node, reset coordinates */ - x = ( data->xmax - data->xmin ) / 2 + data->xmin ; - y = ( data->ymax - data->ymin ) / 2 + data->ymin ; - data->angle -= 2 * M_PI / data->n_nodes; - } - else { - if (data->n_nodes % 2 == 0) /* spacing is better when n_nodes is odd and Y is linear */ - oddAngle = (data->angle * data->n_nodes) / (data->n_nodes + 1); - if (data->n_nodes > 7) + if (canvas_node->centered && data->center.n_nodes == 1) { - x = data->x_rad_max * cos (oddAngle); - y = data->y_rad_max * asin (sin (oddAngle)) / (M_PI / 2); + /* one centered node, reset coordinates */ + x = center_x; + y = center_y; + ring->angle -= 2 * M_PI / ring->n_nodes; } - else + else { - x = data->x_rad_max * cos (data->angle); - y = data->y_rad_max * sin (data->angle); + if (ring->n_nodes % 2 == 0) /* spacing is better when n_nodes is odd and Y is linear */ + oddAngle = (ring->angle * ring->n_nodes) / (ring->n_nodes + 1); + else + oddAngle = ring->angle; + + if (ring->n_nodes > 7) + { + x = data->x_rad_max * cos (oddAngle); + y = data->y_rad_max * asin (sin (oddAngle)) / (M_PI / 2); + } + else + { + x = data->x_rad_max * cos (ring->angle); + y = data->y_rad_max * sin (ring->angle); + } + + if (canvas_node->centered && data->center.n_nodes > 1) + { + /* For the inner ring, just move it halfway closer the the center point. */ + x = center_x + ((x - center_x) / 2.0); + y = center_y + ((y - center_y) / 2.0); + } } - } } @@ -1072,14 +1244,14 @@ static gint reposition_canvas_nodes(node_id_t * node_id, gnome_canvas_item_show (canvas_node->node_item); gnome_canvas_item_request_update (canvas_node->node_item); - data->node_i--; + ring->node_i--; - if (data->node_i) - data->angle += 2 * M_PI / data->n_nodes; + if (ring->node_i) + ring->angle += 2 * M_PI / ring->n_nodes; else { - data->angle = 0.0; - data->n_nodes = 0; + ring->angle = 0.0; + ring->n_nodes = 0; } return FALSE; diff --git a/src/pref_dialog.c b/src/pref_dialog.c index 5451b03..ccc2b38 100644 --- a/src/pref_dialog.c +++ b/src/pref_dialog.c @@ -261,7 +261,7 @@ on_preferences1_activate (GtkMenuItem * menuitem, gpointer user_data) cbox_add_select(cbox, pref.filter); cbox = GTK_COMBO_BOX_ENTRY(glade_xml_get_widget (appdata.xml, "center_combo")); - cbox_add_select(cbox, pref.center_node); + cbox_add_select(cbox, pref.centered_nodes); gtk_widget_show (diag_pref); gdk_window_raise (diag_pref->window); @@ -458,10 +458,10 @@ static void on_center_node_changed(GtkComboBoxEntry * cbox, gpointer user_data) { gchar *str; str = gtk_combo_box_get_active_text(GTK_COMBO_BOX(cbox)); - g_free(pref.center_node); - pref.center_node = g_strdup (str); + g_free(pref.centered_nodes); + pref.centered_nodes = g_strdup (str); g_free (str); - cbox_add_select(cbox, pref.center_node); + cbox_add_select(cbox, pref.centered_nodes); } void diff --git a/src/preferences.c b/src/preferences.c index 18f4cf3..fc28033 100644 --- a/src/preferences.c +++ b/src/preferences.c @@ -117,7 +117,7 @@ void init_config(struct pref_struct *p) p->text_color=NULL; p->fontname=NULL; p->colors=NULL; - p->center_node = NULL; + p->centered_nodes = NULL; p->averaging_time=3000; } @@ -160,8 +160,8 @@ void set_default_config(struct pref_struct *p) p->colors = protohash_compact(p->colors); protohash_read_prefvect(p->colors); - g_free(p->center_node); - p->center_node = g_strdup(""); + g_free(p->centered_nodes); + p->centered_nodes = g_strdup(""); } /* loads configuration from .gnome/Etherape */ @@ -195,7 +195,7 @@ void load_config(void) read_string_config(&pref.filter, gkey, "filter"); read_string_config(&pref.fontname, gkey, "fontname"); read_string_config(&pref.text_color, gkey, "text_color"); - read_string_config(&pref.center_node, gkey, "center_node"); + read_string_config(&pref.centered_nodes, gkey, "centered_nodes"); read_boolean_config(&pref.diagram_only, gkey, "diagram_only"); read_boolean_config(&pref.group_unk, gkey, "group_unk"); @@ -283,7 +283,7 @@ void save_config(void) g_key_file_set_string(gkey, pref_group, "filter", pref.filter); g_key_file_set_string(gkey, pref_group, "fontname", pref.fontname); g_key_file_set_string(gkey, pref_group, "text_color", pref.text_color); - g_key_file_set_string(gkey, pref_group, "center_node", pref.center_node); + g_key_file_set_string(gkey, pref_group, "centered_nodes", pref.centered_nodes); tmpstr = g_strjoinv(" ", pref.colors); g_key_file_set_string(gkey, pref_group, "colors", tmpstr); @@ -327,7 +327,7 @@ duplicate_config(const struct pref_struct *src) t->text_color = NULL; t->fontname = NULL; t->colors = NULL; - t->center_node = NULL; + t->centered_nodes = NULL; copy_config(t, src); return t; @@ -342,8 +342,8 @@ void free_config(struct pref_struct *t) t->text_color=NULL; g_free(t->fontname); t->fontname=NULL; - g_free(t->center_node); - t->center_node=NULL; + g_free(t->centered_nodes); + t->centered_nodes=NULL; g_strfreev(t->colors); t->colors = NULL; @@ -370,7 +370,7 @@ void copy_config(struct pref_struct *tgt, const struct pref_struct *src) tgt->filter=g_strdup(src->filter); tgt->text_color=g_strdup(src->text_color); tgt->fontname=g_strdup(src->fontname); - tgt->center_node=g_strdup(src->center_node); + tgt->centered_nodes=g_strdup(src->centered_nodes); tgt->stack_level = src->stack_level; tgt->colors = g_strdupv(src->colors); diff --git a/src/preferences.h b/src/preferences.h index b47ff4f..1f46126 100644 --- a/src/preferences.h +++ b/src/preferences.h @@ -45,7 +45,7 @@ struct pref_struct gchar *filter; /* Pcap filter to be used */ gchar *text_color; /* text color */ gchar *fontname; /* Font to be used for text display */ - gchar *center_node; /* Name of center node (optional) */ + gchar *centered_nodes; /* Name/IP/CIDR-range of nodes to center (optional) */ guint stack_level; /* Which level of the protocol stack * we will concentrate on */ diff --git a/src/util.c b/src/util.c index 0155a70..8d24add 100644 --- a/src/util.c +++ b/src/util.c @@ -394,6 +394,14 @@ type_to_str (const address_t * ad) } } /* type_to_str */ +int +strict_strtol(const char *str, int base, long *val) +{ + char *end; + *val = strtol(str, &end, base); + return (*str && !*end) ? 0 : EINVAL; +} + /************************************************ * * xml helpers diff --git a/src/util.h b/src/util.h index 395ac56..9936d86 100644 --- a/src/util.h +++ b/src/util.h @@ -53,6 +53,12 @@ extern "C" const gchar *address_to_str(const address_t * ad); const gchar *type_to_str(const address_t * ad); + /* + * strtol()-like that writes converted value to *val and returns an errno + * value (0 for success, non-zero for failure) + */ + int strict_strtol(const char *str, int base, long *val); + /* xml helpers */ gchar *xmltag(const gchar *name, const gchar *fmt, ...); |