I'm sorry it took so long, but I was flooded in work. I'll integrate your changes sometime today. Thanks.
-- Saso On 5/19/06, Quentin Mathé <[EMAIL PROTECTED]> wrote:
Le 16 mai 06 à 08:47, Sašo Kiselkov a écrit : > Alright, I've integrated David's changes, Nice. The code is better now, thanks David. > but I'm not sure I did it > right for platforms other than Linux and unsupported platforms. Could > somebody please check it? It works but not that well on Linux ppc. I was expecting it :-) I attached a patch to add Linux ppc support. I was surprised and it's somewhat a shame, but it seems /proc/cpuinfo isn't standardized, it varies with the architecture you are running the system on. 'cpu MHz' is 'clock' and 'model name' is 'cpu' on my Mac mini. In this pach, I updated also ETMachineInfo to have the correct spacing between value and unit in the About window. 1.4 GHz and not 1.4GHz Here are links to screenshots 'before' and 'after'. It seems the code isn't failing correctly in the first case, I think ETMachineInfo should always check the return of the concrete category implementation, in order to have for example 'CPU: Unknown', not 'CPU: ' when the system is installed on an unsupported architecture. 'CPU' in About window should probably renamed 'Processor' and 'CPU MHz' just 'Speed'. This would be more user-friendly. Before: <http://etoile-project.org/etoile/experimental/screenshots/ menu/AboutEtoileEntryLinuxppcBuggy.png> After: <http://etoile-project.org/etoile/experimental/screenshots/ menu/AboutEtoileLinuxppcFixed.png> I hope the issue addressed by the patch doesn't arise with BSD, well just supposing the related system call doesn't return idiosyncratic results like /proc/cpuinfo on Linux. For 'Machine: ', we could either display 'PowerPC' or I could add code to parse the model name. On my test system, /proc/cpuinfo provides a field 'detected as: 237 (Mac mini)'. I could extract 'Mac mini' portion, but I'm not sure it's worth the pain if there is no equivalent support for branded PC machines. However that would mean, overriding +[ETMachineInfo machineType] in ETMachineInfo_Linux without the possibility to call the default code since we use an category. Well, perhaps it's time to add some official code in Étoilé to call methods overriden by category. Another option, probably better would be to switch to a simple class cluster. > Things I changed on David's code: > > - reformatted it to GNU style. It's not like Etoile has a particular > bias towards it, but I do, and since the rest of EtoileMenuServer is > in it, I'd like to keep things consistent. I have no problem with EtoileMenuServer sticking to GNU style (at least until we have time to spend on updating indenting style). But any new modules should avoid it. Well, it's true the coding guidelines aren't yet official, but they will soon. > - changed the makefile definitions to compile all source files (since > all of the EtoileMenuServer project is managed by ProjectManager and > that doesn't allow to conditionally change the source file list > depending on the platform), but instead protected the code by using > ifdef's (i.e. FreeBSD code doesn't get compiled unless you are running > FreeBSD). Looks like a step backward but a minor one. Hopes ProjectManager will catch up on this one. > - made memory sizes of up to MB rounded to integer values (so it > doesn't spit out (511.65MB, but instead 512MB). Nice. > As for the FreeBSD < 5 yes or no discussion I'm for no - FreeBSD 4 is > really old. Neither am I.  Thanks, Quentin. -- Quentin Mathé [EMAIL PROTECTED]
_______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
