Settings browser

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Settings browser

HilaireFernandes
Hello,

From the settings browser, I want a drop list populated with morph of my
choice; for example coloured rectangle morphs: I want the user to select
a colour from such a predefined set and not from a text list.

I did not find it is possible. Did I miss something ?



                (aBuilder pickOne: #pointColor)
                        label: 'Colour' translated;
                        description: 'The default point colour.';
                        default: #red;
                        domainValues: {#red->Color red asMorph .
#black-> Color black asMorph}].

Thanks

--
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu



Reply | Threaded
Open this post in threaded view
|

Re: Settings browser

Peter Uhnak
Hi,

take a look at WidgetExamples class>>exampleBasicControls
one of the inputs is a morph drop list.

Peter

On Tue, Mar 24, 2015 at 6:02 PM, Hilaire <[hidden email]> wrote:
Hello,

From the settings browser, I want a drop list populated with morph of my
choice; for example coloured rectangle morphs: I want the user to select
a colour from such a predefined set and not from a text list.

I did not find it is possible. Did I miss something ?



                (aBuilder pickOne: #pointColor)
                        label: 'Colour' translated;
                        description: 'The default point colour.';
                        default: #red;
                        domainValues: {#red->Color red asMorph .
#black-> Color black asMorph}].

Thanks

--
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu




Reply | Threaded
Open this post in threaded view
|

Re: Settings browser

HilaireFernandes
Le 24/03/2015 18:30, Peter Uhnák a écrit :
> take a look at WidgetExamples class>>exampleBasicControls
> one of the inputs is a morph drop list.
>

Hi Peter, I know but my question is about using such morph drop list
from the Settings browser.

Hilaire

--
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu



Reply | Threaded
Open this post in threaded view
|

Re: Settings browser

Pharo Smalltalk Users mailing list
Hello Hilaire,

you do it but not with a pickOne list.
Yes I know it would be very cool to be able to do with a pickOne.
Have a look at the setting chapter (The Setting Framework) 
At the end of the chapter I explained how to extend the setting browser.
You will see how to implement this preference setting:



Cheers
Alain


Le 24 mars 2015 à 20:39, Hilaire <[hidden email]> a écrit :


Le 24/03/2015 18:30, Peter Uhnák a écrit :
take a look at WidgetExamples class>>exampleBasicControls
one of the inputs is a morph drop list.


Hi Peter, I know but my question is about using such morph drop list
from the Settings browser.

Hilaire

--
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu




Reply | Threaded
Open this post in threaded view
|

Re: Settings browser

HilaireFernandes
Le 24/03/2015 21:22, Alain Plantec via Pharo-users a écrit :
> Have a look at the setting chapter (The Setting Framework)


Hi Alain,

Thanks Alain.
I was already studying the chapter yesterday, but it appears there is an
unexpected complication,
In a singleton DrGeoStylePreference class I define the methods as follow:

drgeoStylesOn: aBuilder
    <drgeosettings>
    (aBuilder group: #drgeoStyle)
        label: 'Style';
        with: [
            (aBuilder group: #point)
                label: 'Point' translated;
                with: [
                    (aBuilder setting: #pointColor)
                        label: 'Colour' translated].
../..

then

pointColor
  ^ current "respond the singleton, widget build up set later"

settingInputWidgetForNode: aSettingDeclaration
    ^ (aSettingDeclaration name, 'Widget') asSymbol value: self.

pointColorWidget
    ^ (UITheme builder
            newMorphDropListFor: self
            list: #colorMorphCollection
            getSelected: #pointColorIndex
            setSelected: #pointColorIndex:
            help: 'Set the colour.' translated) minWidth: DrGIcons
menuExtent x + 35
../..

and so on.

The complication comes from the SettingDeclaration>>inputWidget where
the widget model is set to the SettingDeclaration, and it breaks:

inputWidget
    "return the default widget for the input a the setting"
../..
    inputWidget
        ifNotNil: [(inputWidget respondsTo: #model:)
            ifTrue: [inputWidget model: self]].
../..

If I remove the #model: call, it is ok.

Did I miss something?

Thanks

Hilaire

--
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu



Reply | Threaded
Open this post in threaded view
|

Re: Settings browser

Pharo Smalltalk Users mailing list

Le 25 mars 2015 à 12:19, Hilaire <[hidden email]> a écrit :

settingInputWidgetForNode: aSettingDeclaration
   ^ (aSettingDeclaration name, 'Widget') asSymbol value: self.


strange that you send the #value: message to a Symbol here.
Alain
Reply | Threaded
Open this post in threaded view
|

Re: Settings browser

HilaireFernandes
Le 25/03/2015 12:39, Alain Plantec via Pharo-users a écrit :
>>
>> settingInputWidgetForNode: aSettingDeclaration
>>    ^ (aSettingDeclaration name, 'Widget') asSymbol value: self.
>>
>
> strange that you send the #value: message to a Symbol here.
> Alain

It is tricky indeed, but it is the only way I found to by-pass the
limitation for customized widget:
as I understood it, settings browser expects one class (a type) per
dedicated widget. I can latter create a dedicated class for each drop
list morph I need in the settings browser, then remove this strange
by-pass, I am still exploring.
Nevertheless, it does not seem related to the model problem I exposed
previously.

Thanks

Hilaire

--
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu



Reply | Threaded
Open this post in threaded view
|

Re: Settings browser

HilaireFernandes
Le 25/03/2015 15:04, Hilaire a écrit :

> Le 25/03/2015 12:39, Alain Plantec via Pharo-users a écrit :
>>> settingInputWidgetForNode: aSettingDeclaration
>>>    ^ (aSettingDeclaration name, 'Widget') asSymbol value: self.
>>>
>> strange that you send the #value: message to a Symbol here.
>> Alain
> It is tricky indeed, but it is the only way I found to by-pass the
> limitation for customized widget:
> as I understood it, settings browser expects one class (a type) per
> dedicated widget. I can latter create a dedicated class for each drop
> list morph I need in the settings browser, then remove this strange
> by-pass, I am still exploring.
> Nevertheless, it does not seem related to the model problem I exposed
> previously.
>
> Thanks
>
> Hilaire
>
As I wrote previously, the Settings browser let me complete almost
successfully what I need. See attached screenshot. I am only stuck with
widget model explicitly set to the SettingDeclaration.

Thanks

--
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu


Capture.png (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Settings browser

Pharo Smalltalk Users mailing list
Hello Hilaire,
I will have a look, I don’t remember why.
btw, I have to check because the #respondsTo: is not very sexy.
Cheers
Alain


As I wrote previously, the Settings browser let me complete almost
successfully what I need. See attached screenshot. I am only stuck with
widget model explicitly set to the SettingDeclaration.

Thanks

-- 
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu

<Capture.png>

Reply | Threaded
Open this post in threaded view
|

Re: Settings browser

HilaireFernandes
Hi Alain,

Modifying inputWidget method as follow will be fine for me:

inputWidget
    "return the default widget for the input a the setting"
../..
    inputWidget
        ifNotNil: [(inputWidget respondsTo: #model:)
            ifTrue: [inputWidget model ifNil: [inputWidget model: self]]].
../..


However I don't know the consequences at the larger Settings browser use
cases.

Thanks

Hilaire

--
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu



Reply | Threaded
Open this post in threaded view
|

Re: Settings browser

Pharo Smalltalk Users mailing list
I’ve opened an issue.
15242
Cheers
Alain

Le 28 mars 2015 à 12:43, Hilaire <[hidden email]> a écrit :

Hi Alain,

Modifying inputWidget method as follow will be fine for me:

inputWidget
   "return the default widget for the input a the setting"
../..
   inputWidget
       ifNotNil: [(inputWidget respondsTo: #model:)
           ifTrue: [inputWidget model ifNil: [inputWidget model: self]]].
../..


However I don't know the consequences at the larger Settings browser use
cases.

Thanks

Hilaire

--
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu




Reply | Threaded
Open this post in threaded view
|

Re: Settings browser

HilaireFernandes
Le 28/03/2015 15:11, Alain Plantec via Pharo-users a écrit :
> I’ve opened an issue.
> 15242 <https://pharo.fogbugz.com/default.asp?15242>
> Cheers
> Alain
>
Thanks Alain,

I tested this change on the Pharo settings, and I did not notice any pop
up debugger. But of course a deeper testing may be needed.

I have finished building DrGeo style preferences based on the Settings
Browser and it works like a charm (attached screenshot).

Hilaire

--
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu


Settings browser.png (74K) Download Attachment