Application Configuration GUI.
Joel Sherrill
joel.sherrill at OARcorp.com
Thu Apr 11 19:38:58 UTC 2013
On 4/11/2013 2:22 PM, Rempel, Cynthia wrote:
> 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).
Without a doubt, this has to be easy to install and start with. :)
And digging around, I was not surprised to find Python has a curses module
to wrap ncurses. So a bit of clever design could produce both GUI and TUI.
> 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).
Still important to have them on the list and identify who will do the
testing on them.
> 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.
http://www.pyinstaller.org/ appears to be one option.
> 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
>
>
--
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
More information about the devel
mailing list