Application Configuration GUI.
Joel Sherrill
joel.sherrill at OARcorp.com
Fri Apr 5 08:17:43 UTC 2013
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 On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35806
Support Available (256) 722-9985
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130405/a751fc41/attachment.html>
-------------- next part --------------
@c
@c === XXX ===
@c
@subsection
@findex
@cindex
@table @b
@item CONSTANT:
@item DATA TYPE:
@item RANGE:
@item DEFAULT VALUE:
@end table
@subheading DESCRIPTION:
@subheading NOTES:
More information about the devel
mailing list