SystemBeat Options

[CSM]

I've made many promises, and the one that I wasn't going to make public Widgets anymore will be broken right now. I'd post this on Alive (konspirator's forums) but very few people would see it.

Some backstory: I last posted some suggestions to the author of System Widget: too many preferences, so-so graphics ... and then he pulled a fake-trump card: college.* So I thought I would do the usual CSM-turnaround which some have experienced, rewrite the Widget and hand it back. I had some grandiose plans, but I didn't touch it until this last week (when I was away from the Internet and just plain had time). I have no idea now if I met or surpassed the original plans. This Widget is also the culmination of about two Widgets: Sys Monitor and System Widget. I'm not sure which, if any, particular ideas in this Widget were grabbed from either, but I do know that I tried to work to provide the same feature set as System Widget, minus SpeedFan support. I definitely wouldn't call this a "System Widget successor", as almost all of this is my work.

* It's fake because college doesn't mean you have to stop, it just means you need to better budget your time, and Widgets always come after classwork and spending time with your friends.

SystemBeat features some awesome graphics, uses some neat features that I wrote specifically for this Widget (which would appeal to other programmers, even if the user can't tell it's being used), and more. Do note that this Widget is not finished, by any means. I'm only posting it now (and in this manner), because I may work on it some more (and "finish" it), but I may not.

What doesn't work:
- Changing graph, gauge, or frame options. (I haven't written the necessary widgets to be able to build those dialogs yet, so they can't be integrated yet) Since this doesn't work, to create new (different) gauges or graphs, just change the "default" setting in the Widget preferences, then create a new gauge.

What does work:
- Creating new frames.
- Rearranging gauges, repositioning frames.
- Saving and loading of currently open frames/gauges.

What's next up to be done:
- Finish widgets necessary for fame and gauge option dialogs.
- Create and integrate new dialogs.
Possible (but not currently on the plan):
- Theming support (other than the 3 color preferences each gauge will have for usage)
(there is a global theme object, it just has to have a code to change it out with other themes)

Stuff developers might be interested in:
- Dialog class, very flexible, and themeable (to an extent). Very handy for nice, Widget (theme) integrated dialog that can simulate system modal dialogs.
- XMLtoDialog file, it parses XML and turns it into a Dialog with support for limited code execution, conversion of simple objects and arrays, constructor parameters, and any class that has a .frame or valueOf() that evaluates to a Y!WE Frame object.

Prerequisite screenshots:
The previews aren't very good (I mean, it's better than just clipping the upperleft corner of the original image) so please click the images to view the full size ones that back them.

Explanation(s):
Image left:
- The labels suck because, well, they're backed by Text objects, which also suck.
- The three different styles of gauge containers, one of which not available via normal means currently (see above about option dialogs).
- Items not available are disabled and less opaque. (there is a failure there, "McBain" is a WiFi network name, but I am neither connected to it, nor in range of it)
- Due to different scaling of the graph versus gauge values, the graph may not "report" any usage when a gauge will.
- Not visible: average max value (when it is higher than the current value) which is only available on gauges.

Image right:
- Dialogs are modal to the entire Widget.
- All dialogs (by default) get a title and two buttons (or a single centered button if one so chooses)
- That dialog was created via XMLtoDialog
- My PopupMenu sucks and thus is hard to differentiate between it and the background.


Download SystemBeat


I do not package the font I have chosen for the titles, and it's sad that I started creating some of my best (and better looking Widgets) so late. I can only hope one of my other endevours will not make hobby-Widgeteering a lost cause.

[Hunter890]

I definitely like the gui style you have been using in your latest widgets. I think I will integrate the dialogue class into my new "top secret" ( ) widget. Keep up the great work, and I can't wait to see future progress with this widget. (If you need any help, I'm here!)

Hunter

[CSM]

I should probably mention (given that I forgot yesterday) that there is a lot of stuff that doesn't work on Mac.

Right now, here is a list of stuff that doesn't work on Mac:
- Any of the multi-core CPU code.
- Networking code.*

* I can get the networking code working, but I need a dump of the output from "netstat -i -b" (the author of System Widget has code in there to test with said file, but sadly didn't include it).

Also for those who wish to borrow Dialog, it isn't simply a replace for alert(), and it certainly isn't blocking (for non-techies: alert() stops the code and waits for a reply before resuming. This allows us to put up a dialog and wait for a response with no "work" at all. Dialog, when set visible, does not wait. Instead, it calls onSave/onClose when the dialog is dismissed, and doesn't pass any "value" because Dialogs could have any number of things on them. So Dialog runs in parallel to the Widget code, whereas alert() runs in line).

[g6auc]

* I can get the networking code working, but I need a dump of the output from "netstat -i -b" (the author of System Widget has code in there to test with said file, but sadly didn't include it).

CODE

Last login: Sun Aug 31 08:47:07 on console
Welcome to Darwin!
woodhead:~ nhw$ netstat -i -b
Name  Mtu   Network       Address            Ipkts Ierrs     Ibytes    Opkts Oerrs     Obytes  Coll
lo0   16384 <Link#1>                         36423     0    3493712    36423     0    3493712     0
lo0   16384 localhost   ::1                  36423     -    3493712    36423     -    3493712     -
lo0   16384 localhost   fe80::1              36423     -    3493712    36423     -    3493712     -
lo0   16384 127           localhost          36423     -    3493712    36423     -    3493712     -
gif0* 1280  <Link#2>                             0     0          0        0     0          0     0
stf0* 1280  <Link#3>                             0     0          0        0     0          0     0
en0*  1500  <Link#4>    00:16:cb:8c:2d:f4        0     0          0        0     0          0     0
en1   1500  <Link#5>    00:16:cb:01:fc:35   167943     0  131178147    70080     0   15860597     0
en1   1500  woodhead.lo fe80::216:cbff:fe   167943     -  131178147    70080     -   15860597     -
en1   1500  (16)00:00:2c:ff:2e              167943     0  131178147    70080     0   15860597     0
en1   1500  192.168.1     woodhead.home     167943     -  131178147    70080     -   15860597     -
wlt1  1500  <Link#6>                             0     0          0        0     0          0     0
fw0*  2030  <Link#7>    00:16:cb:ff:fe:4b:c5:0a        0     0          0        0     0          0     0
woodhead:~ nhw$

[CSM]

Ooo! Thank you! I'll take a look at that later today and see where I get.

[CSM]

Same link as above, I updated the battery source* and a few other minor things. I tried as best as possible to make the changes backwords compatible, so you shouldn't have any issues. No GUI updates yet :-/

* It was calculating an invalid battery number when it attempted to flip it around (to match Y!WE's backwards listing of the batteries).

[CSM]

Version 0.1.4 is up (from version 0.1.3.2) ... this allows you to change the orientation of the gauge-display frames. I also temporarily (or possibly permanently) removed the option from the graph-display frame to customize it (as there is nothing to customize). In keeping with extreme usability, when I had originally designed the rotation feature I made sure that when rotated, the gauge did not "go anywhere". This means the top left of the frame will be in the same location rotated or not. Next up is to create the dialogs necessary for the gauges/graphs. Due to the CPU-gauge's average max value (some may have seen it if they just finished torture testing their CPU) I can't use the exact same XML file for both dialogs (what a shame). All I have left to implement is ColorBtn (visual flat-button for the color-chooser dialog) and TextField (a text-area with a black border). Then the dialogs should be done.

All that's left after I finish the remaining two dialogs is to make sure all gauges work on both platforms, and other miscellaneous stuff. Personally though, with the amount of system gauges out there in the gallery and elsewhere, I don't see any reason why this one is any better than any of the others. It's just my personal spin on it, and I don't tend to use my own Widgets, so it hasn't even displaced Neon Gauges from my desktop (though this Widget is very much like the original Widget I used for system-stats which is probably still dead and broken).

[Hunter890]

The battery gauge works for me know, and all of the others do too. I also tried out the rotation and that works as well. This is probably the most minimalistic system gauge widget, so it will stay on my desktop for a good long while. I would love to see this widget finished, so don't quit developing it!

[CSM]

The battery gauge works for me know, and all of the others do too. I also tried out the rotation and that works as well. This is probably the most minimalistic system gauge widget, so it will stay on my desktop for a good long while. I would love to see this widget finished, so don't quit developing it!

Minimalistic? You haven't seen minimalistic. Consider this: a single canvas-box with 2-pixel bars for each gauge-type and a single letter for each. If you mean spartan, then yes, I don't try to cram all the features into the interface, just what is necessary and appropriate.

Anyways, I think the checkbox is a bit hard to see, similar to how I think the popup-menu is hard to see. I think I might create separate theme entries for them, so that I can color them differently. That'll probably result in a very tiny incremental version change.

[Hunter890]

I found a bug. The widget will let you delete the last frame.

I found a bug. The widget will let you delete the last frame.

[CSM]

I found a bug. The widget will let you delete the last frame.

I don't believe you.

I always decrement the length of the array. Prove to me when this doesn't work:

CODE

    // Disable removal of the first frame.
    if(displays.length === 1) {
        displays[0].removable = false;
    }

[CSM]

Version 0.1.4.3 up ... checkboxes and popups now are solid color (easier to see) and you now cannot remove the only gauge in a frame after the Widget is just started.

[CSM]

version 0.1.5.0b is up. It's extra beta because I only added the customization dialog for the gauges, not the graphs. I will add that tomorrow night (I hope).

Also, I was thinking of changing the "Add Frame", "Remove Frame" to "Add Display", "Remove Display" etc, as I call them displays everywhere else. Haven't done that yet, but it will be in when I add the dialogs (unless I'm told to leave it).

[Cicerone Pavaloi]

Bug:
At first run on a new computer, the Remove Frame & Remove Graph menu items are not disabled.

Possible unwanted behaviour:
It is posible to remain with an empty frame. Remove Graph is some times enabled on frames with only a graph.
Ex: I have a frame with a graph or more, I add a new frame. Both frames have Remove Graph enabled.

And a suggestion, if I may:
When removing the last graph from a frame, you could auto-remove the frame also.

[CSM]

Bug:
At first run on a new computer, the Remove Frame & Remove Graph menu items are not disabled.

Okay, time to clear the reg and data folder and check this out fresh.

Bug:
Possible unwanted behaviour:
It is possible to remain with an empty frame. Remove Graph is some times enabled on frames with only a graph.
Ex: I have a frame with a graph or more, I add a new frame. Both frames have Remove Graph enabled.

I don't get this. I really don't. I on addition I disable the first item, then reenable it when something else is added. On removal, I do same checks ... I guess I'll have to check removal again. This is frustrating, it shouldn't be doing this. On top of this, yesterday, I just fixed the check on addition to make sure this wouldn't ever happen. Sorry to have to ask this, but did you test the latest copy?

Bug:
And a suggestion, if I may:
When removing the last graph from a frame, you could auto-remove the frame also.

This was intentional to prevent removal of the last graph. If the user no longer wants the frame, I want them to consciously do it, rather than "oops! I still wanted that frame".

[Cicerone Pavaloi]

did you test the latest copy?

I did a fresh download after this post:

version 0.1.5.0b is up. It's extra beta because [...]

Can't be sure which version the download has produced, because you have no version number in the about box.

[CSM]

Can't be sure which version the download has produced, because you have no version number in the about box.

Okay, fine, I'll fix that.

Also, I just tested the first-frame removability and I only was able to reproduce it once, but after I started investigating it, I couldn't get it to happen again. So I have no idea what's causing it (nor how to fix it). All displays are routed through addDisplay() which does check for first display, so ...

On top of that, the check I perform for removal of graphs is pretty absolute too ... so the only conclusion I can come to is the JS engine is slow enough at updating array lengths such that it sometimes reports false values to immediately following checks.

So all I can say is, just look over the code, I can't figure out why checks would fail and it would be stupid for me to put in wait(1) or other such to cover for a slow implementation.

The next version will have a version number in the about window.

[CSM]

Latest version is 0.1.5.3 Sorry for taking so long to actually get around to doing it and posting it.

Change-log:

- Added dialog for graphs and integrated it.
- Fixed bug in color-chooser-buttons where the color wasn't sent to the dialog (resulting in a choice of black).
- Fixed positioning bug where setting a custom label on graphs caused the label to move.
- Added version number to the about window.
- Turned off debug window.

This should be the final version, despite it being awesomely* Window's-centric. Hopefully there are no other bugs than the two (one?) Schroedinger's bugs already reported. And that's it for this project. Thanks for the diversion. Time to work on some other things now ... Anyone is welcome to continue what I've already done, just contact me.

* No, that's not the good kind of awesome.

[Hunter890]

I only have one bug, it's with the hdd sensor. When I go to customize it, the widget throws the error:

CODE

TypeError: filesystem.volumes[Number(type)] has no properties (gauge-hdd.js: Line 12)

This happens even if I don't select a new drive from the list.

//Edit: Found another one. The "Type" menu doesn't update when you select a new "Gauge". There is no error thrown in the debug window, though.

[CSM]

I only have one bug, it's with the hdd sensor. When I go to customize it, the widget throws the error:

CODE

TypeError: filesystem.volumes[Number(type)] has no properties (gauge-hdd.js: Line 12)

This happens even if I don't select a new drive from the list.

Ah, yeah ... I'll look into that.

//Edit: Found another one. The "Type" menu doesn't update when you select a new "Gauge". There is no error thrown in the debug window, though.

That one I think I noticed, but I was feeling extremely tired and thought maybe it was just me.