<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
<blockquote cite="mid:48CFCDEB.firstname.lastname@example.org" type="cite">
<pre wrap="">Kris Moore пишет:
<pre wrap="">A.Y. wrote:
<pre wrap="">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 :)
<pre wrap="">Here's a thought. What about having the GUI simply check if there is a
settings.sh script, and when the user clicks "settings", it launches
that script? That settings.sh script could in turn call a python-qt
script, which handles all the GUI elements, or even a binary settings
program, depending upon whatever the user wants. That would give us
flexibility, and allow developers to make simple or very complex
settings dialogs, depending upon their needs.
We can still try to implement our own UI scheme, but the trouble is
that we'll probably run into cases where it doesn't do "everything" a
developer may want to add, when they could simply use an existing
language for it.
<pre wrap=""><!---->Great idea, but I think that most cases for services our system could
(and should) cover.
Ten services, ten settings, same looking, same style = usability;
Ten services, ten settings and all looks very different (even if they
only switch places for "yes" "no" to "no" "yes" "apply", or even "help"
"yes" "cancel") = not cool;
But for some very rare and specific settings why not start
developer-defined script? I have now no idea what couldn't be covered by
our scheme, but I agree - in some cases developer-scripted-settings
would be normal.
Dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dev@lists.pcbsd.org">Dev@lists.pcbsd.org</a>
<a class="moz-txt-link-freetext" href="http://lists.pcbsd.org/mailman/listinfo/dev">http://lists.pcbsd.org/mailman/listinfo/dev</a>
Why not have the settings.sh method outlined by Kris and take care of
the the usability and aesthetics problem mentioned by publishing a
standard settings.sh template which a developer would use as a
guideline. Developers would start with this template and customize only
what needs to be changed for their service.<br>