Application Configuration GUI.

Tue Apr 9 13:51:45 UTC 2013

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.

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 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
>
>
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel