Application Configuration GUI.

Rempel, Cynthia cynt6007 at vandals.uidaho.edu
Fri Apr 5 23:40:11 UTC 2013


Hi,

I know Eclipse seems to work on Ubuntu, if we went that route, we would probably want to ensure the plug-in would work with Eclipse CDT version 3.5.2 (that's the version on Debian; a quite popular but stability oriented distribution) through the current CDT version of Eclipse.  We would want the plug-in to work with the RTEMS Eclipse Plug-in.

Paying attention to the versions of Eclipse, and compatibility with CDT and the existing RTEMS plug-in would probably meet the compatibility requirements...

If we went that route it will be an interesting adventure to see how to populate information for the plug-in from the confdefs.h or the user's guide.

________________________________________
From: rtems-devel-bounces at rtems.org [rtems-devel-bounces at rtems.org] on behalf of Joel Sherrill [joel.sherrill at OARcorp.com]
Sent: Friday, April 05, 2013 1:17 AM
To: Shubham Somani
Cc: rtems-devel at rtems.org
Subject: Re: Application Configuration GUI.

I will leave the GUI recommendations to those who know more.
As Karel points out, Eclipse has some nice facilities and is
effectively the standard IDE for RTOS vendors these days.
MOF is pretty cool. I have become a little familiar with it
through my involvement with the Open Group FACE standard:

http://www.opengroup.org/getinvolved/consortia/face

Whatever the implementation, it must work on Linux, Mac,
and Windows.

A study of the implementations as part of your proposal
would be excellent.

My main point is to echo something I think Gedare mentioned.
The configuration parameters and their documentation needs
improvement. There needs to be a structure like this:

(1) Root definition in parseable format.
(2) Process the root definition for user's manual
(3) Process the root definition to generate GUI options. The GUI
      should NOT be tied to a specific version of RTEMS.

I am in the middle of rewriting the Configuring a System
chapter in the User's Guide. I am using the attached
template for each parameter: This is still in texinfo format
which matches (2) above. When I am done, the chapter
will heavily emphasize using confdefs.h and NOT mention
the underlying structures except to describe things
like defining your own device driver table or mount table.

Each parameter has its name, type, range, default, description,
and notes. I want to make another sweep and add the direct
question you answer with it. Questions like:

+ Do you want to disable the filesystem support?
+ How long should each clock tick be (in microseconds)?
+ ...

Some of the more complicated cases include examples.
There is discussion of side-effects and related parameters.

Each parameter is in a X.y.n section with X.y being a related
category of options.

My plan is to finish rewriting the chapter and then review
it for completeness versus confdefs.h (are any parameters
undocumented?)  I am currently about 60% of the way through
the chapter but am doing this at odd times.

But the rewrite should help a GUI configuration project. It
is an important knowledge clean up step needed as input
to any GUI.


On 04/05/2013 02:51 PM, Shubham Somani wrote:
@cynthia,gedare

Thanks for showing me more options. I will evaluate them and then discuss the ones which would meet the purpose. :).


On Sat, Apr 6, 2013 at 1:11 AM, Gedare Bloom <gedare at rtems.org<mailto:gedare at rtems.org>> wrote:
On Fri, Apr 5, 2013 at 3:30 PM, Rempel, Cynthia
<cynt6007 at vandals.uidaho.edu<mailto:cynt6007 at vandals.uidaho.edu>> wrote:
> Hi Shubham Somani,
>
> Depending on what the other developers say, you can go with 3b, but it would be awesome to add that the code parses a certain chapter in the user manual to get the configuration information, so after 5 years it's not bit-rotten away.
>
Rather than getting Configuration options from the user manual, it
might be better to have a consolidated location and standard format
for specifying the Configuration options, including default values and
acceptable values/ranges (for options where ranges make sense). Right
now, confdefs.h is the only definitive location for Configuration
parameters and is the place to go to learn how a Configuration
parameter is actually used.

> It will have to run on Fedora, Windows, and it would be amazing if it could run on Ubuntu (and possibly even a Mac).
>
It should best work on any reasonable flavor of Linux, and on Windows and Mac.

> Would you be willing to change the GUI library from GTK+ to tkinder?  Although tkinder is very dated, from my research on the topic, it ships with Python, thus ensuring cross-platform compatibility, while GTK+ only ships with certain platforms.
>
TkInter might be a good place to start, but the design of the
Configuration tool should not be bound so tightly to the GUI that
replacing the GUI would be hard. Thus, we can consider other GUI tools
and evaluate them at an early stage to determine which ones will
suffice. A nice list of possibilities is at:
http://wiki.python.org/moin/GuiProgramming

> My big problem with the NutOS GUI is that it doesn't run on Ubuntu -- the dependencies for the NutOS GUI require versions higher than what is packaged for Ubuntu, so avoiding this option is a  +
>
> Thanks!
> Cynthia Rempel
> ________________________________________
> From: rtems-devel-bounces at rtems.org<mailto:rtems-devel-bounces at rtems.org> [rtems-devel-bounces at rtems.org<mailto:rtems-devel-bounces at rtems.org>] on behalf of Shubham Somani [shubhamsomani92 at gmail.com<mailto:shubhamsomani92 at gmail.com>]
> Sent: Friday, April 05, 2013 12:16 PM
> To: rtems-devel at rtems.org<mailto:rtems-devel at rtems.org>
> Subject: Application Configuration GUI.
>
> Hi,
>
> I would wish to take up the project of making an Application Configuration GUI for RTEMS in this year's GSoC.
>
> I was studying the various approaches available and it eventually boiled down to this-
>
>
>
>     APPROACH
>
>
>         PROS
>
>
>          CONS
>
>
>  1)  To use the configuration
>
>     GUI from eCos and NutOS.
>
>
> -  Based on WX Widgets.
>
> -  Highly Portable
>
>  (runs on Windows and Linux)
>
>
>
>
> The code is heavily based on templates which are difficult to understand and port.
>
>
>  2) To use the config infrastructure used by the GNU/Linux kernel.
>
>
>
>
>           Works well on Linux.
>
>
>  Does not support MS Windows.
>
>
> To write a cross platform GUI in python. This also can be done in 2 ways-
>
> 3a)- To start with an existing open source project like Xpresser.
>
>
>
>
>
>
>
>
>                  Portable
>
>
>
>
>     Documentation is scarce.
>
>
> 3b) To code the application from scratch using python and GTK+. If any OS specific requirements are needed then they can be coded separately.
>
>
>
>
>
>
>     Highly portable & modifiable.
>
>
>
>
> Coding has to start from scratch.
>
>
>
>
> This made me think that approach 3b would be the best for a baseline. These are just my Initial ideas. A lot of other work apart from this (XML parsing,rewriting conf.t etc) also needs to be done. I would discuss them once the baseline becomes clear. Please help me analyse any deficiencies in my understanding.
>
> Cheers,
> Shubham
>
>
> _______________________________________________
> 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<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






More information about the devel mailing list