<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">I will leave the GUI recommendations to
      those who know more.<br>
      As Karel points out, Eclipse has some nice facilities and is <br>
      effectively the standard IDE for RTOS vendors these days.<br>
      MOF is pretty cool. I have become a little familiar with it<br>
      through my involvement with the Open Group FACE standard:<br>
      <br>
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      <a href="http://www.opengroup.org/getinvolved/consortia/face">http://www.opengroup.org/getinvolved/consortia/face</a><br>
      <br>
      Whatever the implementation, it must work on Linux, Mac,<br>
      and Windows.<br>
      <br>
      A study of the implementations as part of your proposal <br>
      would be excellent. <br>
      <br>
      My main point is to echo something I think Gedare mentioned.<br>
      The configuration parameters and their documentation needs <br>
      improvement. There needs to be a structure like this:<br>
      <br>
      (1) Root definition in parseable format.<br>
      (2) Process the root definition for user's manual<br>
      (3) Process the root definition to generate GUI options. The GUI<br>
            should NOT be tied to a specific version of RTEMS. <br>
      <br>
      I am in the middle of rewriting the Configuring a System <br>
      chapter in the User's Guide. I am using the attached <br>
      template for each parameter: This is still in texinfo format<br>
      which matches (2) above. When I am done, the chapter<br>
      will heavily emphasize using confdefs.h and NOT mention<br>
      the underlying structures except to describe things<br>
      like defining your own device driver table or mount table.<br>
      <br>
      Each parameter has its name, type, range, default, description,<br>
      and notes. I want to make another sweep and add the direct<br>
      question you answer with it. Questions like:<br>
      <br>
      + Do you want to disable the filesystem support?<br>
      + How long should each clock tick be (in microseconds)?<br>
      + ...<br>
      <br>
      Some of the more complicated cases include examples.<br>
      There is discussion of side-effects and related parameters.<br>
      <br>
      Each parameter is in a X.y.n section with X.y being a related<br>
      category of options.<br>
      <br>
      My plan is to finish rewriting the chapter and then review <br>
      it for completeness versus confdefs.h (are any parameters <br>
      undocumented?)  I am currently about 60% of the way through<br>
      the chapter but am doing this at odd times.<br>
      <br>
      But the rewrite should help a GUI configuration project. It<br>
      is an important knowledge clean up step needed as input<br>
      to any GUI.<br>
      <br>
      <br>
      On 04/05/2013 02:51 PM, Shubham Somani wrote:<br>
    </div>
    <blockquote
cite="mid:CAB8Y--Aaz1yRECbhDaBQug+8jSSzff=EqOV4tRbv_cfNzMiypQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">@cynthia,gedare
        <div><br>
        </div>
        <div style="">Thanks for showing me more options. I will
          evaluate them and then discuss the ones which would meet the
          purpose. :).</div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">
          On Sat, Apr 6, 2013 at 1:11 AM, Gedare Bloom <span dir="ltr"><<a
              moz-do-not-send="true" href="mailto:gedare@rtems.org"
              target="_blank">gedare@rtems.org</a>></span> wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div class="im">On Fri, Apr 5, 2013 at 3:30 PM, Rempel,
              Cynthia<br>
              <<a moz-do-not-send="true"
                href="mailto:cynt6007@vandals.uidaho.edu">cynt6007@vandals.uidaho.edu</a>>
              wrote:<br>
              > Hi Shubham Somani,<br>
              ><br>
              > 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.<br>
              ><br>
            </div>
            Rather than getting Configuration options from the user
            manual, it<br>
            might be better to have a consolidated location and standard
            format<br>
            for specifying the Configuration options, including default
            values and<br>
            acceptable values/ranges (for options where ranges make
            sense). Right<br>
            now, confdefs.h is the only definitive location for
            Configuration<br>
            parameters and is the place to go to learn how a
            Configuration<br>
            parameter is actually used.<br>
            <div class="im"><br>
              > It will have to run on Fedora, Windows, and it would
              be amazing if it could run on Ubuntu (and possibly even a
              Mac).<br>
              ><br>
            </div>
            It should best work on any reasonable flavor of Linux, and
            on Windows and Mac.<br>
            <div class="im"><br>
              > 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.<br>
              ><br>
            </div>
            TkInter might be a good place to start, but the design of
            the<br>
            Configuration tool should not be bound so tightly to the GUI
            that<br>
            replacing the GUI would be hard. Thus, we can consider other
            GUI tools<br>
            and evaluate them at an early stage to determine which ones
            will<br>
            suffice. A nice list of possibilities is at:<br>
            <a moz-do-not-send="true"
              href="http://wiki.python.org/moin/GuiProgramming"
              target="_blank">http://wiki.python.org/moin/GuiProgramming</a><br>
            <div class="HOEnZb">
              <div class="h5"><br>
                > 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  +<br>
                ><br>
                > Thanks!<br>
                > Cynthia Rempel<br>
                > ________________________________________<br>
                > From: <a moz-do-not-send="true"
                  href="mailto:rtems-devel-bounces@rtems.org">rtems-devel-bounces@rtems.org</a>
                [<a moz-do-not-send="true"
                  href="mailto:rtems-devel-bounces@rtems.org">rtems-devel-bounces@rtems.org</a>]
                on behalf of Shubham Somani [<a moz-do-not-send="true"
                  href="mailto:shubhamsomani92@gmail.com">shubhamsomani92@gmail.com</a>]<br>
                > Sent: Friday, April 05, 2013 12:16 PM<br>
                > To: <a moz-do-not-send="true"
                  href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a><br>
                > Subject: Application Configuration GUI.<br>
                ><br>
                > Hi,<br>
                ><br>
                > I would wish to take up the project of making an
                Application Configuration GUI for RTEMS in this year's
                GSoC.<br>
                ><br>
                > I was studying the various approaches available and
                it eventually boiled down to this-<br>
                ><br>
                ><br>
                ><br>
                >     APPROACH<br>
                ><br>
                ><br>
                >         PROS<br>
                ><br>
                ><br>
                >          CONS<br>
                ><br>
                ><br>
                >  1)  To use the configuration<br>
                ><br>
                >     GUI from eCos and NutOS.<br>
                ><br>
                ><br>
                > -  Based on WX Widgets.<br>
                ><br>
                > -  Highly Portable<br>
                ><br>
                >  (runs on Windows and Linux)<br>
                ><br>
                ><br>
                ><br>
                ><br>
                > The code is heavily based on templates which are
                difficult to understand and port.<br>
                ><br>
                ><br>
                >  2) To use the config infrastructure used by the
                GNU/Linux kernel.<br>
                ><br>
                ><br>
                ><br>
                ><br>
                >           Works well on Linux.<br>
                ><br>
                ><br>
                >  Does not support MS Windows.<br>
                ><br>
                ><br>
                > To write a cross platform GUI in python. This also
                can be done in 2 ways-<br>
                ><br>
                > 3a)- To start with an existing open source project
                like Xpresser.<br>
                ><br>
                ><br>
                ><br>
                ><br>
                ><br>
                ><br>
                ><br>
                ><br>
                >                  Portable<br>
                ><br>
                ><br>
                ><br>
                ><br>
                >     Documentation is scarce.<br>
                ><br>
                ><br>
                > 3b) To code the application from scratch using
                python and GTK+. If any OS specific requirements are
                needed then they can be coded separately.<br>
                ><br>
                ><br>
                ><br>
                ><br>
                ><br>
                ><br>
                >     Highly portable & modifiable.<br>
                ><br>
                ><br>
                ><br>
                ><br>
                > Coding has to start from scratch.<br>
                ><br>
                ><br>
                ><br>
                ><br>
                > 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.<br>
                ><br>
                > Cheers,<br>
                > Shubham<br>
                ><br>
                ><br>
              </div>
            </div>
            <div class="HOEnZb">
              <div class="h5">>
                _______________________________________________<br>
                > rtems-devel mailing list<br>
                > <a moz-do-not-send="true"
                  href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a><br>
                > <a moz-do-not-send="true"
                  href="http://www.rtems.org/mailman/listinfo/rtems-devel"
                  target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Joel Sherrill, Ph.D.             Director of Research& Development
<a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a>        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35806
Support Available               (256) 722-9985</pre>
  </body>
</html>