Le 22 janv. 06 à 03:30, Yen-Ju Chen a écrit :
On 1/21/06, Quentin Mathé <[EMAIL PROTECTED]> wrote:
Known bugs :
- Matrix view presentation is still really buggy
What kind of bug did you meet ?
Maybe I should take a look at it. :)
When a pane view is loaded, it is partially covered by the matrix
presentation view. It is related to the fact PreferencesKit doesn't
support to have the current pane view embedded as subview in
presentation view. I'm going to fix this issue in the way I told you
when we discussed it. Moreover it is necessary to support tab view as
a possible presentation view.
Well, it may involve some matrix presention changes you could
eventually take care of.
There is another issue in my mind while I am planning to use it.
The communication between application and preference panes are
difficult.
For example, I have an AppController to control the main window,
Did you mean the preferences window or the main application window ?
and PreferencesController for PreferencePane.
In many cases, I want the change in preferences shows up in real-time.
So if I change the setting of window color in PreferencePane, how does
it notify AppController to change the window color ?
And since PreferencePane is a bundle, it cannot access classes in
AppController,
unless they share the same library.
Well with GNUstep/Cocoa, notifications is the correct or advised way
to reflect preference changes.
In the other hand, if AppController want to know the settings in
PreferencePane,
it have to go throught PreferencesController and know the internal of
a specific pane.
It shouldn't in any cases.
The only way I can think about is that PreferencePane write settings
into user defaults
and throw out a notification so that AppController can read the user
defaults again.
That's precisely how it should be done :-)
This notification also tell AppController which default has been
changed.
You could do this, but there is another solution often used which is
to provide the preference new value with the notification. If you are
interested by a code example, let me know.
Then PreferencesKit need to define some notifications for this kind of
communication.
Not when you put the new value with the notification, because such
notification is then specific to each preference/default.
Well, it could better to have this handled with only one
notification, it could be named
'PreferenceDidUpdateNotification' (that's not the usual way to do it
though). This notification would have two fields in userInfo :
namePath (would contain the Defaults lookup key) and newValue… this
last field would be optional if you decide to rely on namePath to
retrieve on each update the new preference value stored in Defaults
database.
A nice feature too would be to automatically send such notification
in a distributed manner on each Defaults database update (à la GConf).
Take note that you have a nice explanation on how to put together
Defaults and Notifications in Cocoa Programming for Mac OS X (by
Aaron Hillegass).
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
