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