Why port your cmdline apps to gui if you can write a script that draws a gui on top?

I'm not a linux person. I don't even have linux installed on my PC . I once tried linux but there are too many scripts involved that were non gui everything happens through the shell. using MS-XAML the other day I had an idea how this can be fixed. I decided to set out to create a GUI script language that would take A command line of program or scripts output and draw appropriate combo boxes and text boxes I made a quick sketch of what a gui produced by it might look like (for a drive formatting script).

-------------------------------------------------------------------
=
=
= FOMATTER
=
= By someone
--------------------------------------------------------------------
= hdb1
= hda2
= Sellect drive ^ hda1
=
=
= next
---------------------------------------------------------------------
=
=
=
= are you shure you want to format hda1?
=
= [yes] [no]
=
=
----------------------------------------------------------------------
=
=
=
=
= formatting [========------------------------]100%
=
= done
=
----------------------------------------------------------------------------

this would all be in a gui interface of course

and the acuall script would look somthing like this.

import drives; //some library somewere

START

FRAME
contents.Centered = true;

Label
Text = "FOMATTER\n\n"
end Label

Label
Text = "By someone"
end Label

ON_NEXT = TIMER(1)

END ON_NEXT

END FRAME

FRAME
contents.Centered = true;

Label
Text = "Sellect drive"
end Label

Combo
name = "c1";
fill = drives.getdrives;
end Combo

ON_NEXT = BUTTON

consol.writeLine("mnt\" + c1.text); // or whatever the path is.

END ON_NEXT

END FRAME

FRAME
contents.centered = true;

Label
Text = "are you shure you want to format " + c1.text + "?";
end Label

button
text = "yes"
click
consol.writeline("y");
frame.end();
end click
END button

button
text = "no"
click
end click
consol.writeline("n");
frame.end();
END button

END FRAME

FRAME

Label
name="l"
END LABEl

while(s=consol.readline())
{
l.text=s;
}

ON_NEXT = TIMER(1)

END FRAME

EXIT

that just ives you an idea how much easyer a sript would be if such a laguage exsisted.


QUESTIONS

1.does such a project exsist?

2. what is a good linux distro to program in (i tryed gentoo and gave up)

3. what ide should i use(i demand code compleation)?

4. will anyone join me writing script specifacations/ interpreter if this does turn into a project?

o and
5. is there a library for programatically comunicating with the command line?

If I understand you correctly, yes
There are at least two: Tk toolkit and wxPython.

Tk can work with Perl, Tcl, and Python
wxPython only works with Python

There may be a generic toolkits that hook into bash or other native shell scripting, but I'm not familiar with them.



To answer your original question though:
It's a question of performance. No matter how much you poke, twist, or tweak a script, it will never perform as efficiently as a compiled program. If the application that needs a GUI is relatively complex (lots of options/switches), then just slapping a script-based GUI on top might be sluggish. It just depends. A lot of people will use scripting to create a prototype GUI. They do it to experiment with component placement, organization, etc. When they're happy, they could use that as a guide for building a compiled app. They could also sit there and say the script-based GUI is "good enough."

Personally, I prefer compiled GUI interfaces. Simply because controlling a GUI can get ridiculously complicated: This button is enabled when this other combination of components are selected, but that can only happen if some other options are filled out, and another component is active, etc. All that stuff needs to be checked each time the window is updated. That means you take the performance hit of an interpreted script language for every refresh.

since there are lots of really simple cmd apps like our buddy format I think it would still be easyer to do guiing through a script language. they arnt complex. but things like combo boxes make a big diference.

I don't think you quite got my point eather this script would just sitt ontop of the program waiting for output and providing input through the user.

That's the whole purpose of any GUI

All a GUI does is collect information from the user. It gives buttons to press, options to select, and fields to fill out. It doesn't do anything until the user hits "Ok" or whatever. When that happes, the script behind the GUI just spits out the command the user would have typed with all the options selected. Then it would wait for a result from the command it submitted (to tell the user "It worked" or not). So, I'm on the same page, I promise!

There may be a lot of people that prefer to have buttons to press instead of reading about how a command works. If you see that as a place for improvement, by all means, follow through with it. All I was saying is that there are toolkits available that do what you were talking about, and discussed why some people prefer not to do script-based GUIs.