I’ve finally found some time to blog about this. The bonobo-less gnome-panel branch was merged into master, so since version 2.31.2 gnome-panel doesn’t depend on bonobo anymore. The API is mostly the same, but there are some minor changes since the old API exposed bonobo stuff. This of course means that applets need to be ported to the new API. There’s already a GNOME Goal with a porting guide, and I already ported most of the gnome-applets so there are a few examples too.
The frequency selector menu has been implemented for a long time now however, there are still people who don’t know such a feature exists. The problem is that it uses a helper program that has to be installed with the suid bit enabled and it seems that some distros don’t do that by default.
Now that PolicyKit has been proposed as an external GNOME dependency, I’ve decided to give it a try. Yesterday I committed a patch to gnome-applets to use PolicyKit (when it’s available) in the cpufreq applet, so that we don’t need to enable the suid bit in cpufreq-selector anymore. The selector menu will be always available by default now. An authentication dialog, provided by PolicyKit-gnome, will pop up when a non-admin user tries to use the selector menu.
|PolicyKit-gnome authentication dialog|
Don’t worry too much about the annoying popup dialog, since the authentication can be remembered forever, so that if you want, you will only see this popup dialog the first time.
After a course having to program in Java for several uni subjects, now I can happily remove java from my system :-))
$ sudo rm -r /opt/java
In my last post I talked about my cpufreq-applet plans for the current release cycle. Finally I’ve rewritten most of the applet and here are the results so far:
- Rewrite cpufreq selector popup: done (Fixed bugs #336449, #338557)
- Use libcpufreq from cpufrequtils: almost done. At the moment libcpufreq is used only in the monitor, but I’ll use it also in the selector soon.
GTK+ is using evince as a previewer in the new printing stuff. Great!. I’m working on a preview mode for evince available through the command line. I’ve added other command line options like –fullscreen and –presentation (fixes bug #317031) too.
There are still some problems. Right now, the printing dialog is closed when you click on preview and evince is launched. Matthias Clasen has proposed to add a print button in evince toolbar so that the user just click on it and the document is sent to the printer. IMO this approach has several problems: first of all, you can’t go back and change the print settings because the print dialog has disappeared. In addition, we have to provide a way to send the print settings from the dialog to evince which is not so easy to do. I think all of these problems could be solved if we don’t close the print dialog when clicking on preview and not allowing to print from evince when it’s in preview mode. What do you think?
GNOME System Tools
After some time without hacking because of the exams I’ve been working again on my project (DeTraS). I’m happy with the progress 🙂
GNOME Applets has been branched for 2.16. Here are my evil plans for CPUFreq Applet 2.16:
I’ve just committed the changes which add support to change the governor with the frequency selector. I didn’t know how to exactly add it, so finally I’ve chosen what I think it’s the less bad option.
|CPUFreq Applet Preferences dialog|
|Frequencies menu||Governors menu||Frequencies and governors menu|
Maybe the names of the governors are technical and difficult to understand for the users
GNOME 2.10 has been successfully released yet, so it’s time now to work on GNOME 2.12. I have some interesting bugs in CPUFreq Applet, lots of work in GNOME System Tools, and other features I’m really interested in.
- #168356: A patch for adding FreeBSD support. I have to review it carefully because it’s a long patch.
- #168550: I can’t reproduce this bug because I haven’t got a HT processor. I’ll try to fix it by using text files simulating two processors.
- #160031: It’s a zioma bug in fact. He is going to convert the icons to SVG format. I know he is working on a new application icon too :-))
- #170492: I disagree with this bug, anyway I would like to know other opinions
- #164581: I think it’s very important to be able to select governors. However I still don’t know how I’m going to do it. The cpufreq-selector drop down menu could become too big with the frequencies and governors.
GNOME System Tools
There are good news here, the GST backends have been accepted in FreeDesktop!.
There is lots of work to do, because they are going to be important changes in the GST architecture.
Garnacho has started coding, but he hasn’t published anything yet, because he is waiting for the migration of the GST backends from the GNOME CVS to the FreeDesktop CVS. Then, he’ll do a special branch for these changes and I’ll be able to start coding too.
Other interesting features
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
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 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.
The discussion about the inclusion of a CPUFreq applet in GNOME Applets is now open