rinigus / systemdatascope

SystemDataScope is a GUI for visualization of collectd datasets
MIT License
8 stars 6 forks source link

[Feature request] Events view integration #37

Open Self-Perfection opened 7 years ago

Self-Perfection commented 7 years ago

Please allow adding graph to events view like weather app adds forecast widget to events view.

In my case I'd like to add CPU sleep graph to events view. My Jolla C frequently stops sleeping and squanders charge fast so I have to pay attention to this graph and restart aliendalvik or even whole device to conserve charge. Currently I keep SystemDataScope GUI always running and check it's cover, but it seems to me graph in events view would be much more convenient.

Or as alternative: can anyone propose easy method to be notified if device has not slept for past hour?

rinigus commented 7 years ago

That's an interesting idea and maybe we should develop it further before implementing it. Then, when the design is ready, it would be possible to think about technical aspects.

As you do, I run SDS in the background always to see the CPU sleep graph. And, exactly as you do, I intervene if the device looses CPU sleep for "unknown" reasons. It did not bother me enough to make a separate view for the sleep.

So far, I have never seen graphs on events view. Maybe persistent text notification with CPU sleep % during last 5, 30, and 60 minutes would be more appropriate? Also, if you have used media players, they set some data on lock screen - maybe that would be a decent place to display this statistics?

Sending out notification on loss of sleep is also a good idea and maybe we could add that as well.

One simple technical question: if you would have these extra views, would you prefer not to have SystemDataScope GUI running and start it only if you wish to examine the details? Or is this an additional output of GUI? I am asking it since the technical details would probably depend on whether I can interact with events view and lock screen via GUI or whether I should consider writing an extra daemon for it.

Self-Perfection commented 7 years ago

Maybe persistent text notification with CPU sleep % during last 5, 30, and 60 minutes would be more appropriate?

I don't like this option. It seems parsing text description to wordless concept "everything is fine" or "seems something is broken" would require a bit of strain and extra half a second.

Sending out notification on loss of sleep is also a good idea and maybe we could add that as well.

Cool, I like it. I tried collectd briefly, it has "notification" targets. Probably this notification can be implemented natively with collectd?

Also, if you have used media players, they set some data on lock screen - maybe that would be a decent place to display this statistics?

Cool idea, have not considered it at all. My attitude is the same as with persistent notification: graph is always appropriate but I don't want text info hanging around if device is generally in normal state. Also I'm afraid displaying on lock screen info besides than current song would require hacking that will be one more reason to prevent SDS from entering main jolla store.

One simple technical question: if you would have these extra views, would you prefer not to have SystemDataScope GUI running and start it only if you wish to examine the details? Or is this an additional output of GUI? ...

The reason I'm asking this is that I often have more than 9 GUI apps running simultaneously and would like to get of one screen. Thus I will not keep SDS GUI running permanently if any option from suggestions above will be implemented.

rinigus commented 7 years ago

I looked around a bit and it looks to me that adding graphs (or extra text for that matter) to lockscreen and events view are rather "hacky" approaches that are against SFOS design. However, sending notification should be in accordance with it and should actually be what would serve your case the best. In other words, you will be notified only if something is wrong and can enjoy your life without parsing extra data when everything is fine :) .

I will look into collectd notification handling. Probably some extra code needs to be written. As far as I remember, collectd notification part is still not developed/used much and we may hit some obstacles.

Just as a note: the notification should be done only if the device is not charging. Otherwise, we would get plenty of false positive cases.

I am rather swamped right now with my other project and would like to finish the things that I started before jumping into this one. However, I'll work on SDS/collectd in future, just it may take 1-2 months to get there.