Application Configuration GUI.

Thu Apr 11 14:58:11 UTC 2013

Hi,

1) I've created a very basic script which parses conf.t and gives
section-wise parameters as output.
    The format for output is-
                                 <Name of the subsection>
                                 <parameter 1,parameter 2,parameter
3......parameter n>
                                 < "end of subsection" >

The script can be accessed here- http://pastebin.com/wSJ0YTPk
The output can be accessed here- http://pastebin.com/mxkyZK9p

2) The flow of control of the GUI-
https://docs.google.com/file/d/0B41ApxXt-m4jTjdscTRxMjIyVU0/edit?usp=sharing

3) I now wanted to create a GUI which could import the input from the
parser.
    So, I wished to ask if it was fine to use wxPython for making the GUI?
    Also, as some people wish for an additional TUI implementation , I
researched about it and found that
    ncurses would work fine on linux but wont on Windows, so would have to
do it on  PDCurses.

Any suggestions on these ideas are welcome. :)

Cheers,
Shubham

On Tue, Apr 9, 2013 at 7:32 PM, Joel Sherrill <joel.sherrill at oarcorp.com>wrote:

> On 4/9/2013 8:51 AM, Gedare Bloom wrote:
>
>> I think it best not to tie the creation of the GUI to any particular
>> design tool, although certainly it is fine to use a design tool to
>> create the GUI and document how that design tool can be used to
>> maintain the GUI, still it should be possible to modify the source
>> code directly to maintain the GUI. Design tools that embed lots of
>> extra stuff in the source code of the GUI often lead to extra work
>> when the GUI needs to be updated--especially if the tool becomes
>> obsolete.
>>
> I am wanting to make sure one requirement I have comes through loud
> and clear.
>
> The dialogs used to enter information and menus should be programmatically
> constructed based on descriptions of the parameters which ultimately
> originate in the documentation or a higher level document from which the
> docs and code derive.
>
> There has to be a generic dialog for boolean feature parameter, integer
> parameter,
> etc. But the specific dialog for parameters like CONFIGURE_MAXIMUM_TASKS
> and
> CONFIGURE_MAXIMUM_POSIX_**THREADS must derived from upstream
> parameter descriptions.
>
> I am not dictating a mechanism for"programmatically constructed".
> The tool could read the "master description" and generate tables used
> by the UI or the UI itself could read the master description.  That is
> an implementation decision and for future discussion.
>
> But the following use cases had better not have someone editing the UI
> source code:
>
> + adding a configuration parameter of any existing type
>    (e.g. a new "maximum" or "disable/enable" parameter)
> + changing the description of an existing parameter
> + deleting a configuration parameter
>
> This is critical so the maintenance is low and multiple UIs can exist.
>
> --joel
>
>
>  On Mon, Apr 8, 2013 at 9:49 PM, Rempel, Cynthia
>> <cynt6007 at vandals.uidaho.edu> wrote:
>>
>>> Hi Joel,
>>>
>>> As you're one of the mentors of this project, you should definitely make
>>> executive decisions (python will remain a requirement).  I completely agree
>>> with every point listed in the email below, and will be filling out
>>> http://www.rtems.org/wiki/**index.php/**ApplicationConfigurationGUI<http://www.rtems.org/wiki/index.php/ApplicationConfigurationGUI>next weekend to reflect these requirements.
>>>
>>> If it's desirable, I am still willing to proffer the wxFormbuilder
>>> project to assist with the GUI design...
>>>
>>> Thanks,
>>> Cynthia Rempel
>>>
>>> ______________________________**__________
>>> From: Joel Sherrill [joel.sherrill at oarcorp.com]
>>> Sent: Sunday, April 07, 2013 5:22 PM
>>> To: Chris Johns
>>> Cc: Shubham Somani; Rempel, Cynthia; rtems-devel at rtems.org
>>> Subject: Re: Application Configuration GUI.
>>>
>>> Hi
>>>
>>> I wanted to make sure you step back a bit and take a very broad
>>> view of this project. It is fun to jump in and code but this project
>>> really requires more than that. We have had this idea for years
>>> but not pushed it because of this. With my recent work on the
>>> configuration chapter, a lot of heavy lifting that we couldn't
>>> expect a student to do has been done. Without deep knowledge
>>> of RTEMS, no one could present the configuration parameters
>>> in a more uniform manner. [1]
>>>
>>> Here is what this project needs as basic requirements:
>>>
>>> (1) describing the parameters
>>> (2) saving user selections
>>> (3) generating appconfig.c (arbitrary name)
>>> (4) UI implementation(s)
>>>
>>> (1) needs to be shareable in a computer manner between
>>> the users guide and the Configuration Tool.
>>>
>>> All user dialogs need to be generated based on descriptions
>>> of the parameters. There can be no hard-coding of menu
>>> options. If we add or delete a parameter, this should just
>>> fall out naturally from the descriptions.
>>>
>>> There needs to be a file format to save user selections.
>>> This file format needs to be the same independent of UI.
>>> The user should be able to generate a configuration,
>>> come back later, load it, edit it, and regenerate C code.
>>>
>>> The UI must be portable between all major platforms including
>>> Linux, *BSD, MacOS, and Windows.
>>>
>>> (1)-(3) could be completely using text editors and defined file
>>> formats and transformations. Any tools could be command line.
>>>
>>> And any transformation between Users Guide and UI configuration
>>> parameter must likely be command line.
>>>
>>> The UI (4) could be a command line tools to transform (2)
>>> which is in ASCII into a C file to be compiled. But the UI
>>> could also be a TUI (Text User Interface) using ncurses
>>> or true GUI using Python.
>>>
>>> Ultimately the definition of (1)-(3) make it possible to
>>> implement multiple UIs. But we need a simple portable
>>> one first that assumes little. I assume that means a TUI
>>> and next a GUI.
>>>
>>> If you are clever, you can do all of this with some transformation
>>> and magic of reading files and generating various dialogs in TUI
>>> and GUI form.
>>>
>>> Chris is the resident Python wizard and offered to help
>>> define classes to do the transformations. Python is a very
>>> portable language and toolkit which should be easy to
>>> dynamically generate UIs in -- both TUI and GUI. Using one
>>> implementation language would allow you to share the
>>> "controller" portion of the program but implement
>>> different "views". [2]
>>>
>>>
>>> I hope this helps you get a broader view of this project.
>>> And I hope this has given you requirements.
>>>
>>> --joel
>>>
>>> [1] I don't mean this to brag or denigrate. I invested a significant
>>> amount of personal time in rewriting this chapter. And I have
>>> sections that I need help to improve still. I did this both to
>>> improve the documentation and make a big step to providing the
>>> definition of the configuration parameters in a computer
>>> parseable form from which dialogs could be generated. I hope
>>> I succeeded.
>>>
>>> [2] I guess I am making an executive decision. Implement this
>>> in Python. Focus on (1)-(3) first with the focus on being able to
>>> read this and generate the bulk of the UI based on the various
>>> types of configuration parameters.
>>>
>>> On 04/07/2013 06:09 PM, Chris Johns wrote:
>>>
>>> Shubham Somani wrote:
>>>
>>>
>>>
>>> Crosstool-ng would indeed work very well with linux systems.
>>>
>>>
>>>
>>> I do not use Linux so where does that leave me. Unless you intend to
>>> support native Windows, MacOS, FreeBSD, ie what is not Linux as well,
>>> then this tool will be of little value to me or those who do not use
>>> Linux as a development environment.
>>>
>>>
>>>
>>> But I did some research and found out some drawbacks of running
>>> crosstool-ng on cygwin and mac as given on their site
>>> http://pastebin.com/NiLxUqdz
>>>
>>>
>>>
>>> This is what I was talking about. You are not picking up an easy to use
>>> package, you are fixing a part of another project. Unless you work in
>>> that project to first fix it there you could potentially create a fork.
>>>
>>> Chris
>>>
>>>
>>>
>>>
>>> --
>>> Joel Sherrill, Ph.D.             Director of Research& Development
>>> joel.sherrill at OARcorp.com<**mailto:joel.sherrill at OARcorp.**com<joel.sherrill at OARcorp.com>>
>>>        On-Line Applications Research
>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35806
>>> Support Available               (256) 722-9985
>>>
>>>
>>>
>>> ______________________________**_________________
>>> rtems-devel mailing list
>>> rtems-devel at rtems.org
>>> http://www.rtems.org/mailman/**listinfo/rtems-devel<http://www.rtems.org/mailman/listinfo/rtems-devel>
>>>
>>
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>
> Support Available                (256) 722-9985
>
> ______________________________**_________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/**listinfo/rtems-devel<http://www.rtems.org/mailman/listinfo/rtems-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130411/b95549c4/attachment-0001.html>