Application Configuration GUI.
Rempel, Cynthia
cynt6007 at vandals.uidaho.edu
Thu Apr 11 19:22:33 UTC 2013
Hi,
It sounds like you have a good design idea there! I wasn't able to open the files, but hope the parser works.
WxPython may be okay to use for the application configuration GUI, it would have to be packaged in such a way as to "just install" ( a "stand-alone" package).
So, basically the wx module would have to be packaged with the application configuration gui, and the package would have to install on a host machine that doesn't have wx already installed.
At the end of the project the "acceptance test" would be to try to launch the configuration gui from a freshly installed Debian, PC-BSD, and Windows (although I suspect someone else will check Fedora and MacOS).
I would be looking for if it installed, and ran, or prompted me to add wx. (Incidently, I would also look at the outputted .h file, but that's not wx related)
Most likely there is FOSS python packaging software out there, packaging the wx with the application configuration GUI would be part of the project.
The community would also want to coordinate enough to incorporate an additional Eclipse interface as well into the design.
Thanks,
Cynthia Rempel
________________________________________
From: rtems-devel-bounces at rtems.org [rtems-devel-bounces at rtems.org] on behalf of Shubham Somani [shubhamsomani92 at gmail.com]
Sent: Thursday, April 11, 2013 7:58 AM
To: Joel Sherrill
Cc: rtems-devel at rtems.org
Subject: Re: Application Configuration GUI.
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<mailto: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<mailto: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 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<mailto: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<mailto: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<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<tel:%28256%29%20722-9985>
_______________________________________________
rtems-devel mailing list
rtems-devel at rtems.org<mailto:rtems-devel at rtems.org>
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<tel:%28256%29%20722-9985>
_______________________________________________
rtems-devel mailing list
rtems-devel at rtems.org<mailto:rtems-devel at rtems.org>
http://www.rtems.org/mailman/listinfo/rtems-devel
More information about the devel
mailing list