Hi! On Sun, Nov 19, 2006 at 01:12:49PM +0100, Quentin Math? wrote: > True, but this is more a draft API than the final one. SystemConfig > methods/classes are placeholders that should allow people to submit > patch or commit code with a particular feature in mind. I think the > code will be easy to reorganize when the API evolves.
Okay. > >First, I would like to have an API for retrieving information about > >what > >the system supports. How shall the keyboard preferences dialog and > >screen resolution dialog offer options to choose from, if they don't > >know which keyboard types and screen properties are supported by the > >system? > > Good remark, I take note of this. Do you have a particular API in > mind for such features or do you think adding some methods can do the > deal? I think that adding methods would be enough. But it would be cool if they not just returned an array of strings but an array of objects describing the options. For example for different keyboard languages the method could return an array or set of instances of a ETKeyboardLanguageOption class (or a subclass of course) that also holds the short names of the languages that can be given to xkb then. But just specify the ETKeyboardLanguageOption class in a very simple way. For example specify that -description returns the name of the option and -icon may return a small icon of the size 22x22 (e.g. for small flag icons), and that the methods -enable and -disable can be used to enable and disable this language. When the ETKeyboard class is then told to switch the keyboard language to an option, it can call -disable on the former language option object and call -enable on the new one. The whole concept can be easily transferred to screen resolutions, the preferred language etc. > >Also very important IMHO would be to have a defined API on how > >SystemConfig gives back error information. Sometimes, hardware just > >fails, and SystemConfig should let you know if that happens, > >especially > >when changing a system preference fails. > > There is some preliminary support for this. SCConfigElement provides > a delegate that should be used in any subclass methods to report > error. See SCConfigElement.h. Error codes aren't yet defined though. Why don't we just have a boolean return value for the methods which can fail? > >I would also like to have SystemConfig objects send notifications when > >they changed. [...] > > This is planned. Fine. :-) > Yes, I think we should have OS-specific subclasses when necessary. I think it will be necessary everywhere. Keyboard, Monitor and Mouse all depend on X11. If - for some reason - somebody wants to run Etoile on a non-X11 backend one day, it will be good to have SystemConfig integrate with that directly. There's too much X11-dependent code anyway, we shouldn't make it even worse. ;-) SCSound will also obviously have different implementations for different OSs and sound daemons (esd and the like). -Guenther _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
