I propose a programming method for a better native GUI.

Question

Basically the change is that in almost all cases the compiler/gui is in complete control over the layout of a window. This means that instead of an application declaring where every window element would be, it would have a file that would declare every element. Here's some examples using pictures from Apple's HI guideline. (sorry for the bad code example)
WindowNoResize (Settings, "Imagetype Changer Preference"); //declares a standard window with no resizing handles, dimensions are automatic. also declares the title of the window and the call function (Settings).
Include Help (manual.pdf); //declares that there is a help button included, which in this case launches the pdf manual
section 1 ("General Editing") //creates the first section and gives it a title. the following is it's contents
radio (ImageOption, 0="Select existing image", 1="Add a margin around image") //declares a radio button with two option, sets the result to ImageOption
InputBox Integer ( "Size:", ImageSize, "points") //declares an inputbox for numbers, surrounding text, and location where to store the result.
CheckBox (ReposChange, "Reposition windows after change") //declares a checkbox and sends the result (TRUE/FALSE) to ReposChange
CheckBox (Remember, "Remember recent items") //declares a checkbox and sends the result to Remember
end section 1; //finishes section
section 2 ("Clipboard settings") //declares section two
Radio (ClipOpt, 0="Copy selection from image only", 1="Erase section from Image") //declares radio, sends results to ClipOpt
CheckBox (Dither, "Dither content of clipboard") //declares checkbox, sends results to Dither
end section 2;
section 3 ("Color Optimization:") //declares section three
CheckBox (Calc, "Calculate best color table")
CheckBox (Ver, "Verify color table integrity")
CheckBox (NoteLoss, "Notify on loss of color information")
CheckBox (NoteBef, "Notify before CMYK to RGB conversion")
end section 3;
end window //declres the end of the window's code.then the compiler or the Operating System's GUI will use this information to render the following window:
Mostly this would be used for standard message boxes, so that an error box will look like a standard Mac or Windows error box depending on which OS is running the application. Ideally the GUI will also alter the text and everything so that the application will become indistinguishable from a native application.
the best part? Operationg systems designed for touch-screen input, such as The BlackBerry Storm or HP TouchSmart, can automatically render the windows in a format that is touch-screen fiendly.
Edited by: GrahamReneKennethFluet on Apr 12, 2010 3:18 PM

Answer 1

Well to be honest this was a copy and paste of a thread that was based off of another thread that was written when I had no idea what I was talking about... so let me start at the beginning.
A day or so ago I was reading on DaringFireball about how Apple is trying to remove all external api's such as Flash, because what happens is that it by default uses a GUI that clashes with the rest of the OS. I know that on my Blackberry Storm I have ZoomPass installed, a generic .jar that clashes significantly with the rest of the OS and I'd rather avoid if it wasn't for Zoompass's importance. This made me realize that Apple did this to prevent lazy coders from porting an app in the simplest and most butt-ugly way possible, because then when the user is running that app it ruins the overall "prettyness" of the OS. I then realized that all that was wrong with the app was it's gui, not the options or the performance. I then wondered if it was possible to have the OS control ALL aspects of the program's window, from the font to the button size and down to the layout of standard buttons such as cancel, allow, and help/info. I understand that compared to Swing AWT get's pretty close to native experience, but I feel it could be better.
So basically I'm asking for a way to set up a program in a way so that every window looks native, from the layout of the error and warning boxes to to position of the preferences/options menu item.