[PC-BSD Dev] Questions
A.Y.
yerenkow at uct.ua
Tue Sep 16 07:30:06 PDT 2008
Gerard van Essen:
> that's only a mockup for "KDE4 brainstorm" so there's no actual code
Oh well, I'm lame :)
Actually I downloaded some plasmoids from there with real source, I was
mistaken that this is real too :)
Will write our :)
>
> On 9/16/08, *A.Y.* <yerenkow at uct.ua <mailto:yerenkow at uct.ua>> wrote:
>
> A.Y. пишет:
> > A. Yerenkow пишет:
> >
> >> On Monday 15 September 2008 21:54:06 Fabrizio Parrella wrote:
> >>
> >>
> >>> On Mon, September 15, 2008 1:56 pm, Kris Moore wrote:
> >>> [...]
> >>>
> >>>
> >>>
> >>>> 2. Services.
> >>>>
> >>>>
> >>>>
> >>>>> PC-BSD 7 introduce very good feature - concept "Service". it
> have
> >>>>> controls
> >>>>> "Start, Stop, Restart, Enable, Disable"
> >>>>> But his have no "settings". I think this should be
> discussed. I wrote
> >>>>> ACPI-support for notebooks as Service, but had a problem: I
> have no ways
> >>>>> to user
> >>>>> specify their vendor; The workaround was made, but I thinks
> Services
> >>>>> should
> >>>>> anyway have "Settings", and scripts which callbacked after
> settings are
> >>>>> set
> >>>>> (I'll explain why restart isn't sufficient).
> >>>>> for example, they could have optional file "preferences.cfg"
> and some UI
> >>>>> to
> >>>>> configure it, via simple conventions in structure file:
> >>>>> Each parameter in UI have "select" for controlling, and have
> three vars
> >>>>> in
> >>>>> config, for example:
> >>>>>
> >>>>> vendor_label="Specify your notebook vendor"
> >>>>> vendor_selected="asus"
> >>>>> vendor_values="None:
> >>>>> Asus:asus
> >>>>> Toshiba:toshiba
> >>>>> Sony:sony"
> >>>>>
> >>>>> I think that could be useful for future, services not always
> generics,
> >>>>> and may
> >>>>> have some configurable options too;
> >>>>> Another use: we could add option "Root allowed" in SSH
> service. here we
> >>>>> need
> >>>>> callback - script, which is started when we change settings
> (it simple
> >>>>> repopulate settings to /etc/ssh/sshd.conf if I'm not mistaken)
> >>>>>
> >>>>>
> >>>> I think this is an excellent idea as well. We should discuss the
> >>>> preferences.cfg UI specification, and then figure out how to
> create the
> >>>> UI on the fly. Maybe like this?
> >>>>
> >>>> preferences.cfg:
> >>>>
> >>>> [settings]
> >>>> title: SSHD Settings
> >>>> element1: radio
> >>>> element1.text: Enable root login via SSH
> >>>> element1.options: enabled, disabled
> >>>>
> >>>> element2: combobox
> >>>> element2.text: Enable root login via SSHD?
> >>>> element2.options: combo1, combo2, combo3
> >>>>
> >>>> element3: checkbox
> >>>> element3.text: Allow root login?
> >>>> element3.options: checked
> >>>>
> >>>> We'll have to put some thought into it, but I think something
> along
> >>>> those lines may work and allow us to create nice settings
> dialogs.
> >>>>
> >>>>
> >>> I have been facing this problem other time, and this is how I
> did when I
> >>> was building a website where the user was able to add custom
> fields to
> >>> show on the website to the customers:
> >>>
> >>> each line can start with "element", I did it with a table, and
> each row
> >>> was an entry:
> >>> - text: whatever description for the field
> >>> - type: select/radio/checkbox/input/text
> >>> - default: default value
> >>> - help: text to show in a different place as HELP when that
> element is
> >>> selected
> >>> - values: number of values that will be showed in case of
> select, radio,
> >>> or checkbox (this can be skipped if you can traverse the
> following)
> >>> - value#: value for the select, radio, and checkbox
> >>> - show#: text to show referred to value1
> >>>
> >>> merging with Kris file, will be something like:
> >>>
> >>> [state]
> >>> text = please select a state
> >>> type = select
> >>> default =
> >>> help = "This is the state that we will use to ship your package"
> >>> values = 51
> >>> value0 =
> >>> show0 = Please Select...
> >>> value1 = ca
> >>> show1 = California
> >>> value2 = nc
> >>> show2 = North Carolina
> >>> value3 = va
> >>> show3 = Virginia
> >>>
> >>> [zip]
> >>> text = enter the zip code
> >>> type = text
> >>> default =
> >>> help = "This is the zip code that we will use to ship your
> package"
> >>> values = 0
> >>>
> >>> etc .....
> >>>
> >>> another way, I did it with a text file and using a PHP array
> (you can
> >>> easily translate)
> >>>
> >>> name=name of the field
> >>> text=text to display
> >>> type=select/radio/check/int/boolean/text/char/email/url/...
> >>> values=templates
> >>> default=
> >>> help=this is to help you
> >>>
> >>> and values was build in this way:
> >>> - selects/radio/check
> >>> - values:value|show,value2|show2,value3|show3
> >>> - other keyword that will show, for example, all the ports
> installed,
> >>> files in a specific folder with a specific extension (I.E.:
> >>> files:folder1|*.jpg,folder2|*.gif)
> >>> - boolean (display as single checkbox, or dropdown with YES/NO)
> >>> - values is listed as "TRUE,FALSE", so, if you want TRUE to
> have value
> >>> 1, and false to have value 0, you can set "1,0".
> >>> - text (display as textarea)
> >>> - value is not used
> >>> - other (apply different error checking depending on the
> type, display as
> >>> inputbox)
> >>> - value is not used
> >>>
> >>>
> >>> hope that this help.
> >>>
> >>> lately, for pbidir.com <http://pbidir.com>, I have created a
> more complex way to do this as I
> >>> needed more in depth references between the modules, so if
> necessary I can
> >>> give you more info about that as well.
> >>>
> >>>
> >>>
> >> Thanks!
> >> But I think that preferences for services will be not so
> complicated;
> >> all info user could enter in two ways: select with options and
> textfield for
> >> free text;
> >> radio buttons = same as selects;
> >> checkbox = select with only two options;
> >> Question is how complex would be write such dynamic ui for
> service preferences
> >> editing;
> >> Also, I'd like to add: all available options for this must be
> in different
> >> file from selected-entered values; This prevent low percentage
> of loss
> >> preferences structure due to some issue with parsing-saving;
> >>
> >> Now I'm going to boot usb and upgrade my system, so I think
> you'll read me
> >> tomorrow :)
> >>
> >>
> >>
> > So, what structure of service settings did you chose?
> > And what are our dev-plans?
> > Currently I'm looking into plasmoids, want to make post-your-bug
> one :)
> >
>
> http://www.kde-look.org/content/show.php/report+the+bug+to+the+developer?content=35657
>
> can this be integrated and used?
>
>
> >
> >
> >
> >>> Fabry
> >>>
> >>>
> >>>
> >>>> [...]
> >>>>
> >>>>
> >> _______________________________________________
> >> Dev mailing list
> >> Dev at lists.pcbsd.org <mailto:Dev at lists.pcbsd.org>
> >> http://lists.pcbsd.org/mailman/listinfo/dev
> >>
> >>
> >
> > _______________________________________________
> > Dev mailing list
> > Dev at lists.pcbsd.org <mailto:Dev at lists.pcbsd.org>
> > http://lists.pcbsd.org/mailman/listinfo/dev
> >
>
> _______________________________________________
> Dev mailing list
> Dev at lists.pcbsd.org <mailto:Dev at lists.pcbsd.org>
> http://lists.pcbsd.org/mailman/listinfo/dev
>
>
More information about the Dev
mailing list