Le 13 nov. 06 à 12:07, Guenther Noack a écrit :
Hi!
On Sat, Nov 11, 2006 at 12:13:57AM +0100, Quentin Math? wrote:
I just committed a basic SystemConfig prototype to ?toil? repository.
It's mainly an API until it gets updated with real code.
I recently took a quick look at the API. I'm not sure if this
simple API
will be sufficient for system configuration.
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.
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?
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.
I would also like to have SystemConfig objects send notifications when
they changed. That would integrate nicely with MVC. We don't have any
implementation yet, but the notification name should still be defined
and the same for all OS-specific implementations.
This is planned.
Another thing (but this is just a wish), is that I'd like to have the
plain SystemConfig classes call [self subclassResponsibility:
_cmd], as
i assume the OS-specific implementations are going to be done in
subclasses, whose instances are returned by some factory class.
Putting
every OS-specific implementation in one file would end up in a mess of
#defines.
Yes, I think we should have OS-specific subclasses when necessary.
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
