Application Configuration GUI.

Tue Apr 9 01:49:24 UTC 2013

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 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>        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35806
Support Available               (256) 722-9985