Lukas Renggli a écrit :
>> SystemSettingBrowser browse: 'seaside|systemsetting' "for seaside and
>> systemsetting settings"
>>
>
> I thought that there is a tree that already provides a kind of
> grouping of settings.
yes there is.
> Why do you need another concept here?
no new concept. It only makes use of a regexp instead of a string.
I only didn't want a "hardcoded" keyword (setting) and be able to change
it because I suspected that "setting" would not be ok for every one.
There is a default which is now "setting", which will be "systemsetting"
if we want and
"SystemSettingBrowser open" allows you to browse the default settings.
But imagine that someone do not want it's application setting to be
browsed together
with system settings. (debug, Free type, halo setting). It is simply
possible because the keywords
a setting browser is using can be passed as parameter.
> I assume
> that one could just display all settings from the root
yes
> , or starting at
> an arbitrary node in the tree.
>
not for now but I can add it easily
> I don't want an extra package just with the settings for every package
> I write.
so, do as you want. If you want your settings to be declared together
with the rest of the code you simply can.
But it is interesting because this is mainly what I asked and I have an
answer.
> Also I don't want to have unreferenced classes in any of my
> packages.
>
>
>> Then, SettingManager is only referenced by packages which are dedicated
>> to settings management.
>> It makes them very easily removable.
>> see also my answer for you 'after refactoring' example.
>>
>
> Still that introduces a lot of dependencies between packages. In your
> example CodeHolder still depends on the preferences, because it
> depends on the CodeHolder-Preferences that in turn depend on the
> Preferences.
No, this is exactly what we want to avoid.
CodeHolder have its own class variable and do not depend on any other
package regarding the setting management.
But there are some case where you can have to define some class variable
for the setting browsing only
(so only useful when the setting browser is available). I can give you
an example
if you want. Then, I think it is better to declare this class variable
in another package for better separation of concerns.
> Loading and unloading in the right order will be a
> nightmare (without having the transcript full of undeclared warnings).
>
no, you can load the Tool-Base package without having to load the
Tool-Base-Settings package.
Tool-Base-Settings is only loaded if you want the setting browser.
Imagine an image used headless. It does not need Tool-Base-Settings.
> My suggestion completely decouples the setting declaration from the
> setting framework. Metacello is following that pattern for its project
> definitions with great success.
>
I like the builder solution. I find it very clean myself.
The problem is that I think we don't need it if we keep the setting
declaration as it is now.
Regarding your suggestion concerning the way settings are declared, then
yes a builder is a good solution.
>> the default is optional.
>> Do you think it is really a problem to keep it ?
>>
>
> Actually that was more of a question. Maybe specifying a default is
> also useful to reset the settings to the default value?
>
yes and also to know the kind of value if we have nil in the class
variable representing the setting.
But it is optional because one can also indicate the type explicitely in
a declaration.
>
>>
>
> Who defines that tree?Who defines the labels of this tree? Who
> defines the icons of that tree?
>
for a setting, all is given in a single setting declaration
(except the icon but good idea, I will add this possibility)
>> no, this is not like that because a setting declaration is never stored
>> (I mean in a global tree somewhere)
>> the tree is always dynamically built (no change management is to be
>> implemented).
>>
>
> I imagine that the builder has some kind of a Seaside like API that
> allows the methods to add and configure the settings, and probably
> also group them into tree nodes. In the following example there is no
> need to use the pragma for the groups (which is ugly indeed):
>
> CodeHolder class>>settingsOn: aBuilder
> <settings>
>
> aBuilder group
> label: 'Code Browser';
> with: [
> aBuilder setting
> label: 'Annotation Pane';
> selector: #annotationPane.
> aBuilder setting
> label: 'Auto Format';
> selector: #autoFormat.
> aBuilder group
> label: 'Highlighting';
> with: [ self settingsHighlightOn: aBuilder ].
> aBuilder group
> label: 'Formatting';
> with: [ self settingsFormatOn: aBuilder ] ]
>
> I think that would also make the whole thing much easier to understand.
>
>
At a first time, I liked that solution very much but now I don't.
If I understand well, if we use this pattern, then settings are not
discovered
on the fly anymore (and with it, I don't see the utility of the pragma
using except for root declarations).
the tree is hard coded is such #settingOn: methods and then you
introduce dependencies between settings.
>> - one method = one setting
>>
>
> The configurable formatter of the refactoring browser has 23 settings.
> Shout, the syntax highlighter, has 108 style definitions. It simply
> does not scale to be forced to have to write a separate method for
> each setting.
you only do that one time thought.
but ok, I think I can easily allow several declarations in one method.
something like:
CodeHolderSetting class>>browserSettings
<setting>
^ SettingManager newLevel parent: #userInterfaceSettings withAll: {
SettingManager newSetting: 'Annotation Pane'; selector: #annotationPane.
SettingManager newSetting: 'Auto format'; selector: #autoFormat.
.... }
which is ok if you declare your settings in a specific package
or
CodeHolderSetting class>>browserSettingsOn: aManager
<setting>
^ aManager newLevel parent: #userInterfaceSettings
withAll: {
aManager newSetting: 'Annotation Pane'; selector:
#annotationPane.
aManager newSetting: 'Auto format'; selector: #autoFormat.
.... }
which is better if you do not want any setting specific package.
is it ok like that ?
if yes, the only point would be the #parent symbol.
> I did not suggest to store the settings anywhere. The builder object
> would be passed into all <settings> methods to build the tree
> dynamically whenever needed.
>
ok, thank you very much for this design tips.
but as far as I understand it is not so useful here.
again, thank you for this discussion.
Cheers
Alain
> Cheers,
> Lukas
>
>
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
