Carlos Garcia Campos

In the last weeks I’ve been very busy doing some uni exercises that we have to do before doing the exams. I already have work to do, but today I’ve decided to take me the day as a free (in fact, I took me only the afternoon, because in the morning I was in class). What better way to spend a free day than hacking? Hehe, here is the result of my small free day

CPUFreq Applet

The new icons proposed by zioma have been accepted!!. I’ve uploaded them to CVS.

GST: The disks Tool

Because of the little time that I have, the disks tool development is going slowly. But I haven’t abandoned it. I’ve fixed an important bug in the scsi bus scanning. The scsi devices in which lun was greater than 0, were not detected.

I’m very happy to see Davyd talks about the disks tool in his GNOME 2.10 article.

I will continue with the uni exercises tomorrow. 🙂

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.