Application Configuration GUI.
Rempel, Cynthia
cynt6007 at vandals.uidaho.edu
Fri Apr 5 19:30:24 UTC 2013
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.
It will have to run on Fedora, Windows, and it would be amazing if it could run on Ubuntu (and possibly even a 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.
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 [rtems-devel-bounces at rtems.org] on behalf of Shubham Somani [shubhamsomani92 at gmail.com]
Sent: Friday, April 05, 2013 12:16 PM
To: 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
More information about the devel
mailing list