Re: [E-devel] Monitor Module Patch 2-r1
On Thu, 21 Jul 2005 18:45:00 +0200 FORT Yannick [EMAIL PROTECTED] babbled: Hello everyone; it's my first mail on this list ;) I've been in the computer world for a long time now - 20 years or so. and KB = kilobyte = 1024 bytes. MB = megabyte = 1024x1024 bytes. ie power of 2's always for memory or sizes on disk (of files). ALWAYS. hd manufacturers decided to play a nice trick and use 1000x1000 to play the numbers game of my disk is bigger than yours without having to do any engineering. somehow it stuck. networking has always talking in BITS as it generally has been serial lines thus they talk in bits and thus Mb == megabit - but they chose to use Kb = kilobit = 1000 bits and 1000x1000 bits for a megabit. this is just how it is - it is the way its done. personally i detest the hd size and network way of doing things. this is binary - computers. long live power of 2's. if u were to refer to current download speed or bandwidth used on a network device i would lean to converting it into KB or MB (1024 bytes or 1024x1024 bytes) and the bits be damned. in not sticking to these standards u will confuse people even more as these are how it has been done ever since the dawn of time... pretty much :) I really think the MiB standard MUST be used, if you don't respect standards, you surely want people to use .doc, .xls for office use, MSN as a chat protocol, THIS is stupid ... When i read MiB, i'm sure it's 1024*1024 B, but when i read MB, i don't know if it's 1000*1000 or 1024*1024, f***ing unrespected standards I learn at school Kilo is 1000x and Mega is 1000*1000x, why would it be different for Bytes ? Please use Kibi, Mebi Gibi, etc ... --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor Module Patch 2-r1
On Thu, 21 Jul 2005 09:00:55 -0400 Michael Jennings [EMAIL PROTECTED] wrote: On Thursday, 21 July 2005, at 11:59:54 (+0200), Martin Geisler wrote: Would you consider changing the texts to reflect the IEC standard of KiB for 1024 bytes, MiB for 1024 KiB, and GiB for 1024 MiB? Boy I hope not. Such nonsense has no place in Enlightened software. I think it makes things clearer in the long run if we begin using these units. No it doesn't. When you're dealing with bytes, units are multiples of 1024 instead of 1000. It doesn't get any clearer than that. Well, it IS a nonsense, but everyone already get used for 1024 multiplies, I think it is a bit too late for changing this. Only effect will be more clueless people. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor Module Patch 2-r1
On Thursday, 21 July 2005, at 15:22:14 (+0200), Jackob McRose wrote: Well, it IS a nonsense, but everyone already get used for 1024 multiplies, I think it is a bit too late for changing this. Only effect will be more clueless people. Resistance is NOT futile. You do not have to be assimilated. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- With every kiss our love is like brand new, and every star up in the sky was made for me and you. Still we both know that the road is long. But we know that we will be together because our love is strong. -- Firehouse, Love of a Lifetime --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor Module Patch 2-r1
Michael Jennings [EMAIL PROTECTED] writes: On Thursday, 21 July 2005, at 11:59:54 (+0200), Martin Geisler wrote: Would you consider changing the texts to reflect the IEC standard of KiB for 1024 bytes, MiB for 1024 KiB, and GiB for 1024 MiB? Boy I hope not. Such nonsense has no place in Enlightened software. I think it makes things clearer in the long run if we begin using these units. No it doesn't. When you're dealing with bytes, units are multiples of 1024 instead of 1000. It doesn't get any clearer than that. Well, reading through the Usage Notes section on Wikipedia is interesting. We're dealing with bytes in all six cases, but there are differences: * A MB of RAM is 1024 * 1024 bytes. * A MB on a harddisk is 1000 * 1000 bytes if you're the manufacturer, but 1024 * 1024 if youre the OS, * A MB on a floppy disk is 1000 * 1024 bytes, * A MB on a CD is 1024 * 1024 bytes. * A MB on a DVD is 1000 * 1000 bytes. * A MB/s on a bus means 1000 * 1000 bytes/s. You must admit that this context sensitive unit 'MB' is everything but clear with no less than three different interpretations. The difference between CDs and DVDs surprised me. I agree that it looks funny --- I always think of 'Men in Black' when I see 'MiB' somewhere :-) -- Martin Geisler GnuPG Key: 0x7E45DD38 PHP EXIF Library | PHP Weather | PHP Shell http://pel.sf.net/| http://phpweather.net/ | http://mgeisler.net/ Read/write EXIF data | Show current weather| A shell in a browser pgpm3pujSZ1JJ.pgp Description: PGP signature
Re: [E-devel] Monitor Module Patch 2-r1
On Thursday, 21 July 2005, at 15:50:20 (+0200), Martin Geisler wrote: Well, reading through the Usage Notes section on Wikipedia is interesting. We're dealing with bytes in all six cases, but there are differences: * A MB of RAM is 1024 * 1024 bytes. Agreed. * A MB on a harddisk is 1000 * 1000 bytes if you're the manufacturer, but 1024 * 1024 if youre the OS, Marketing ploys by manufacturers should not be allowed to redefine well-established nomenclature. * A MB on a floppy disk is 1000 * 1024 bytes, A 1440 floppy is correctly referred to as 1.4MB, not 1.44MB. Again...bad manufacturer. No cookie. * A MB on a CD is 1024 * 1024 bytes. Yup. * A MB on a DVD is 1000 * 1000 bytes. Same deal as a hard drive. It's a ploy. Just remember a standard DVD holds just under 4.5 GB. * A MB/s on a bus means 1000 * 1000 bytes/s. Ploy. You must admit that this context sensitive unit 'MB' is everything but clear with no less than three different interpretations. The only one of these that isn't well-defined and well-known is the bus speed example. If we allow learning curve to dictate our modus operandi, why aren't we all using MacOS and an iMac? Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- Unix is like a Vorlon: It is incredibly powerful, gives terse, cryptic answers, and has a lot of things going on in the background. -- Jeff Dubrule --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor Module Patch 2-r1
On Thursday, 21 July 2005, at 18:45:00 (+0200), FORT Yannick wrote: I really think the MiB standard MUST be used, if you don't respect standards, you surely want people to use .doc, .xls for office use, MSN as a chat protocol, THIS is stupid ... Your conclusion is not supported by your statements. You appear to be claiming that .doc and .xls are defiant of standards when, in reality, they are more standard than pretty much any other document format of their type. Even moreso as they move toward XML. When i read MiB, i'm sure it's 1024*1024 B, but when i read MB, i don't know if it's 1000*1000 or 1024*1024, f***ing unrespected standards Standards that are stupid should not be respected and should not be allowed to be called standards. When you read MB, you're dealing with 1024*1024 except when dealing with (1) manufacturer specs or (2) a stupid person. When you read MiB, you're dealing with (1) 1024*1024 and (2) someone who, like Microsoft, believes in catering to the lowest common denominator. I learn at school Kilo is 1000x and Mega is 1000*1000x, why would it be different for Bytes ? Because 2^10 is 1024, not 1000, and 2^20 is 1024*1024, not 1000*1000. Math is actually pretty simple, as it turns out. :-) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- I have failed over and over again in my life. And that is why I succeed. -- Michael Jordan --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor Module Patch 2-r1
Learning something in school in France does not make it a standard. And saying somebody MUST use something in HIS OWN program is just inappropriate. If you want a version with MiB, you can patch the sources :) On 7/21/05, FORT Yannick [EMAIL PROTECTED] wrote: Hello everyone; it's my first mail on this list ;) I really think the MiB standard MUST be used, if you don't respect standards, you surely want people to use .doc, .xls for office use, MSN as a chat protocol, THIS is stupid ... When i read MiB, i'm sure it's 1024*1024 B, but when i read MB, i don't know if it's 1000*1000 or 1024*1024, f***ing unrespected standards I learn at school Kilo is 1000x and Mega is 1000*1000x, why would it be different for Bytes ? Please use Kibi, Mebi Gibi, etc ... --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor Module Patch 2-r1
Michael Jennings [EMAIL PROTECTED] writes: If we allow learning curve to dictate our modus operandi, why aren't we all using MacOS and an iMac? :-) I guess it comes down to personal preferrence then... I like the idea of having prefixes with a fixed meaning: M = 10^6, Mi = 2^20, always. I just wanted to raise the issue in case the original author of the monitor hadn't thought of it yet. -- Martin Geisler GnuPG Key: 0x7E45DD38 PHP EXIF Library | PHP Weather | PHP Shell http://pel.sf.net/| http://phpweather.net/ | http://mgeisler.net/ Read/write EXIF data | Show current weather| A shell in a browser pgpHIEADKD5XB.pgp Description: PGP signature
Re: [E-devel] Monitor Module Patch 2-r1
On Thursday, 21 July 2005, at 19:00:11 (+0200), Martin Geisler wrote: I guess it comes down to personal preferrence then... I like the idea of having prefixes with a fixed meaning: M = 10^6, Mi = 2^20, always. If something more reasonable comes along, I might reconsider. But saying Kiba-Miba-Giba makes you sound like a drunken chimp with a lisp and an overbite. Try going into Best Buy or Fry's and asking for a spool of 700 Mibabyte CD-R's. Then tell me which is more confusing. :-) I'd also like to point out that it's 'k' and not 'K'. (And yes, it matters...see also pico and peta.) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- There's just something about debugging with a buggy debugger that reeks of rotten luck --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor Module Patch 2-r1
I have a proposition: Why not make it a configurable option? That way everyone will be happy. yay!! Long live the freedom of choise! Daniel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor Module Patch 2-r1
On Wed, 20 Jul 2005 19:52:57 -0500 (CDT) Edward Presutti [EMAIL PROTECTED] wrote: Please disregard that first patch I sent out earlier. This one is an updated version. It has been tested against current anon-CVS as of 19:40 CST. This patch has configuration save/load as well as the features specified in patch 2.0. Here's the complete changelog for this patch. ADDED : Configuration Menus! ADDED : Support for Interval Changing. Intervals for CPU, Memory, and Network are all adjustable. ADDED : Support for Network Interface changing. Monitor now scans for network interfaces on load and provides a menu with a list. ADDED : Option to ignore Cache or Buffer memory. ADDED : Save/load functions for all new configuration options using e_config. (Thanks to the guys on the e-devel list for pointing me in the right direction) CHANGED : Clean up some more warnings. CHANGED : Moved configuration items to the correct structure. After reviewing the code of the modules provided with E17, this seemed like the more approriate place for them. TODO : The memory icon definitely needs some cleaning. The more I stare at it, the more I don't care for it. Thanks, -- Ed Presutti (ekrunch on freenode) Thanks a lot! That patch works nice. Correct memory output now with ignoring cached and buffered, configurable network interface... awesome! The only thing that would be neat would be the alignment, like having the monitors aligned vertically, not horizontal. And maybe deactivate one if preferred would be cool... but those are just ideas to make it more customizeable. Regards Tom pgpNKk7mwcSgy.pgp Description: PGP signature
Re: [E-devel] Monitor Module Patch 2-r1
On Thu, 21 Jul 2005 10:33:00 +0200 gimpel [EMAIL PROTECTED] wrote: On Wed, 20 Jul 2005 19:52:57 -0500 (CDT) Edward Presutti [EMAIL PROTECTED] wrote: Please disregard that first patch I sent out earlier. This one is an updated version. It has been tested against current anon-CVS as of 19:40 CST. This patch has configuration save/load as well as the features specified in patch 2.0. Here's the complete changelog for this patch. ADDED : Configuration Menus! ADDED : Support for Interval Changing. Intervals for CPU, Memory, and Network are all adjustable. ADDED : Support for Network Interface changing. Monitor now scans for network interfaces on load and provides a menu with a list. ADDED : Option to ignore Cache or Buffer memory. ADDED : Save/load functions for all new configuration options using e_config. (Thanks to the guys on the e-devel list for pointing me in the right direction) CHANGED : Clean up some more warnings. CHANGED : Moved configuration items to the correct structure. After reviewing the code of the modules provided with E17, this seemed like the more approriate place for them. TODO : The memory icon definitely needs some cleaning. The more I stare at it, the more I don't care for it. Thanks, -- Ed Presutti (ekrunch on freenode) Thanks a lot! That patch works nice. Correct memory output now with ignoring cached and buffered, configurable network interface... awesome! The only thing that would be neat would be the alignment, like having the monitors aligned vertically, not horizontal. And maybe deactivate one if preferred would be cool... but those are just ideas to make it more customizeable. Regards Tom Oh heh. BUG BUG! It currently still shows KB in memory module where it should be MB :) cheers! pgp4x5dL5zpWf.pgp Description: PGP signature
Re: [E-devel] Monitor Module Patch 2-r1
On Thu, 21 Jul 2005 10:42:51 +0200 gimpel [EMAIL PROTECTED] wrote: Oh heh. BUG BUG! It currently still shows KB in memory module where it should be MB :) cheers! To answer myself i edited the mem_swap_get() and mem_real_get() stuff in e_mod_main.c line 488ff : MB to GB, KB to MB and B to KB they both seem to return KB values... if (bytes 1048576 ) snprintf(buf, 64, %ldGB, bytes/1048576); else if (bytes 1024 bytes 1048576 ) snprintf(buf, 64, %ldMB, bytes/1024); else snprintf(buf, 64, %ldKB, bytes); edje_object_part_text_set(face-mem, mem-real-text, buf); } etc etc.. Now it gives me 190MB memory in use, which is correct, KB would have been a bit few, even it would be kewl, hehe Regards Tom pgpk9il07bwlH.pgp Description: PGP signature
Re: [E-devel] Monitor Module Patch 2-r1
On Thu, July 21, 2005 3:42 am, gimpel said: On Thu, 21 Jul 2005 10:33:00 +0200 gimpel [EMAIL PROTECTED] wrote: Oh heh. BUG BUG! It currently still shows KB in memory module where it should be MB :) cheers! heh, oops. That's what I get for excessive copy/paste. I'm about to fly out for the day but i'll look into it later on. In reference to making it more modular... I agree! I'm looking into that for the next big patch. I'd really like to be able to enable/disable individual monitors, as well as add multiple copies of each monitor. (e.g. 2 network monitors for those of us w/ 2 nics.) Thanks for the input, I'm glad it's working for someone other than me! ;-) Ed --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor Module Patch 2-r1
gimpel [EMAIL PROTECTED] writes: On Thu, 21 Jul 2005 10:42:51 +0200 gimpel [EMAIL PROTECTED] wrote: Oh heh. BUG BUG! It currently still shows KB in memory module where it should be MB :) cheers! To answer myself i edited the mem_swap_get() and mem_real_get() stuff in e_mod_main.c line 488ff : MB to GB, KB to MB and B to KB they both seem to return KB values... Would you consider changing the texts to reflect the IEC standard of KiB for 1024 bytes, MiB for 1024 KiB, and GiB for 1024 MiB? I think it makes things clearer in the long run if we begin using these units. See http://physics.nist.gov/cuu/Units/binary.html and http://en.wikipedia.org/wiki/Binary_prefix for a bigger discussion. -- Martin Geisler GnuPG Key: 0x7E45DD38 PHP EXIF Library | PHP Weather | PHP Shell http://pel.sf.net/| http://phpweather.net/ | http://mgeisler.net/ Read/write EXIF data | Show current weather| A shell in a browser pgpMZw56bi1yT.pgp Description: PGP signature
Re: [E-devel] Monitor Module Patch 2-r1
On Thu, 21 Jul 2005 04:27:51 -0600 Tres Melton [EMAIL PROTECTED] wrote: On Thu, 2005-07-21 at 11:07 +0200, gimpel wrote: On Thu, 21 Jul 2005 10:42:51 +0200 gimpel [EMAIL PROTECTED] wrote: Oh heh. BUG BUG! It currently still shows KB in memory module where it should be MB :) cheers! To answer myself i edited the mem_swap_get() and mem_real_get() stuff in e_mod_main.c line 488ff : MB to GB, KB to MB and B to KB they both seem to return KB values... if (bytes 1048576 ) snprintf(buf, 64, %ldGB, bytes/1048576); else if (bytes 1024 bytes 1048576 ) snprintf(buf, 64, %ldMB, bytes/1024); else snprintf(buf, 64, %ldKB, bytes); Regarding the above snippet: What if bytes == 1048576? It prints lots of bytes. The second part of the 'else if' is unnecessary since it will have short circuited on the 'if'. And most importantly, I have 2GB of ram and at the point where I'm using 1.801GB I don't want the thing to say 1GB or even (2GB) with better rounding, I want to know that I'm using 1827MB. The same thing applies when talking about KB although that will probably never show up. I propose that the quantity is kept in the lower units up through 4 digits and roll on the fifth. That will provide a much more accurate display. if (bytes = 1024) snprintf(buf, 64, %ldGB, bytes/1048576); else if (bytes = 1) snprintf(buf, 64, %ldMB, bytes/1024); else snprintf(buf, 64, %ldKB, bytes); Just a thought, -- Tres Forwarded to the mailinglist! ;) The above was only a temporary fix to force it to show MB instead of KB. Not meant to be a real solution. if RAM 1GB is in use, it would simply (and ugly) round it up, right. Ed ^^ :) regards! tom pgpork0xx8uvo.pgp Description: PGP signature
[E-devel] Monitor Module Patch 2-r1
Please disregard that first patch I sent out earlier. This one is an
updated version. It has been tested against current anon-CVS as of 19:40
CST.
This patch has configuration save/load as well as the features specified
in patch 2.0.
Here's the complete changelog for this patch.
ADDED : Configuration Menus!
ADDED : Support for Interval Changing. Intervals for CPU, Memory, and
Network are all adjustable.
ADDED : Support for Network Interface changing. Monitor now scans for
network interfaces on load and provides a menu with a list.
ADDED : Option to ignore Cache or Buffer memory.
ADDED : Save/load functions for all new configuration options using
e_config. (Thanks to the guys on the e-devel list for pointing me in the
right direction)
CHANGED : Clean up some more warnings.
CHANGED : Moved configuration items to the correct structure. After
reviewing the code of the modules provided with E17, this seemed like the
more approriate place for them.
TODO : The memory icon definitely needs some cleaning. The more I stare at
it, the more I don't care for it.
Thanks,
--
Ed Presutti (ekrunch on freenode)
Index: e17/apps/e_modules/src/modules/monitor/e_mod_main.c
===
RCS file: /cvsroot/enlightenment/e17/apps/e_modules/src/modules/monitor/e_mod_main.c,v
retrieving revision 1.2
diff -b -u -3 -r1.2 e_mod_main.c
--- e17/apps/e_modules/src/modules/monitor/e_mod_main.c 19 Jul 2005 11:38:21 - 1.2
+++ e17/apps/e_modules/src/modules/monitor/e_mod_main.c 21 Jul 2005 00:37:50 -
@@ -14,6 +14,47 @@
static void_monitor_face_menu_new(Monitor_Face *face);
static void_monitor_face_cb_gmc_change(void *data, E_Gadman_Client *gmc,
E_Gadman_Change change);
+static void _monitor_mem_real_ignore_buffers_set_cb(void *data, E_Menu *m,
+ E_Menu_Item *mi);
+static void _monitor_mem_real_ignore_cached_set_cb(void *data, E_Menu *m,
+ E_Menu_Item *mi);
+
+static void _monitor_mem_interval_cb_fast(void *data, E_Menu *m,
+ E_Menu_Item *mi);
+static void _monitor_mem_interval_cb_medium(void *data, E_Menu *m,
+ E_Menu_Item *mi);
+static void _monitor_mem_interval_cb_normal(void *data, E_Menu *m,
+ E_Menu_Item *mi);
+static void _monitor_mem_interval_cb_slow(void *data, E_Menu *m,
+ E_Menu_Item *mi);
+static void _monitor_mem_interval_cb_very_slow(void *data, E_Menu *m,
+ E_Menu_Item *mi);
+
+static void _monitor_cpu_interval_cb_fast(void *data, E_Menu *m,
+ E_Menu_Item *mi);
+static void _monitor_cpu_interval_cb_medium(void *data, E_Menu *m,
+ E_Menu_Item *mi);
+static void _monitor_cpu_interval_cb_normal(void *data, E_Menu *m,
+ E_Menu_Item *mi);
+static void _monitor_cpu_interval_cb_slow(void *data, E_Menu *m,
+ E_Menu_Item *mi);
+static void _monitor_cpu_interval_cb_very_slow(void *data, E_Menu *m,
+ E_Menu_Item *mi);
+
+static void _monitor_net_interval_cb_fast(void *data, E_Menu *m,
+ E_Menu_Item *mi);
+static void _monitor_net_interval_cb_medium(void *data, E_Menu *m,
+ E_Menu_Item *mi);
+static void _monitor_net_interval_cb_normal(void *data, E_Menu *m,
+ E_Menu_Item *mi);
+static void _monitor_net_interval_cb_slow(void *data, E_Menu *m,
+ E_Menu_Item *mi);
+static void _monitor_net_interval_cb_very_slow(void *data, E_Menu *m,
+ E_Menu_Item *mi);
+static void _monitor_net_interface_cb(void *data, E_Menu *m,
+ E_Menu_Item *mi);
+
+
static void _monitor_face_cb_mouse_down(void *data, Evas *e, Evas_Object *obj,
void *event_info);
static void _monitor_face_cb_menu_enabled(void *data, E_Menu *m,
@@ -38,6 +79,12 @@
static E_Config_DD *conf_edd;
static E_Config_DD *conf_face_edd;
+static Flow_Chart *flow_chart_cpu;
+static Flow_Chart *flow_chart_net_in;
+static Flow_Chart *flow_chart_net_out;
+static Flow_Chart *flow_chart_mem_real;
+static Flow_Chart *flow_chart_mem_swap;
+
/* public module routines. all modules must have these */
void *
e_modapi_init(E_Module *module)
@@ -124,6 +171,12 @@
#define T Config_Face
#define D conf_face_edd
E_CONFIG_VAL(D, T, enabled, INT);
+ E_CONFIG_VAL(D, T, cpu_interval, DOUBLE);
+ E_CONFIG_VAL(D, T, mem_interval, DOUBLE);
+ E_CONFIG_VAL(D, T, net_interval, DOUBLE);
+ E_CONFIG_VAL(D, T, net_interface, STR);
+ E_CONFIG_VAL(D, T, mem_real_ignore_cached, INT);
+ E_CONFIG_VAL(D, T, mem_real_ignore_buffers, INT);
conf_edd = E_CONFIG_DD_NEW(Monitor_Config, Config);
#undef T
@@ -162,6 +215,12 @@
{
face-conf = E_NEW(Config_Face, 1);
face-conf-enabled = 1;
+ face-conf-cpu_interval = 1.0;
+ face-conf-mem_interval = 1.0;
+ face-conf-net_interval = 1.0;
+ face-conf-net_interface = strdup(eth0);
+ face-conf-mem_real_ignore_cached = 0;
+ face-conf-mem_real_ignore_buffers = 0;
monitor-conf-faces =
evas_list_append(monitor-conf-faces, face-conf);
@@ -184,6 +243,31 @@
/*
