Yes, I’ve just rewritten the cpufreq applet. There were some things that I wanted for the applet and I hadn’t done yet because it was necessary to change the current code design.
Some of them are:
- The applet should be independent of the data access method. The applet should behave as a simple viewer, and it shouldn’t know the data access details. My solution is a monitor that will do the data access work and will give these data to the applet
- The current applet is updated every second, even when there aren’t changes. I think it’s an error because most of the time, the cpu keeps the same frequency. With the new monitor it’s not the applet who is running every second, but the monitor. The monitor will get the data every second and will emit a signal when there are changes. The applet only has to listen for the signal for doing the update
I think that the advantages are evident . . .
I thought that the best way to do these things, it was an object oriented design. The monitor is an abstract class (CPUFreqMonitor) that has a child class for every possible monitor (CPUFreqMonitorProcs, CPUFreqMonitorSysfs, . . .). The applet only knows the CPUFreqMonitor class, so the methods for getting the data are virtual methods, polymorphic entities. In this way, we can add new monitors in the future (based on libcpufreq, HAL or whatever) by only writing a new class and without changing any line of code in the applet. We can even decide which monitor will be used at run time.
 |
| CPUFreq Applet new code design in UML |
We have now an applet more efficient and extensible.
While I rewrote the code I also migrated from gnome_about to gtk_about and I did some code cleanups.
I haven’t committed yet, because I want to test it a little more. I think I will commit with the new icons, since nobody has said anything bad of them.