RE: User interfaces using XML

[Paul Hepworth <phepworth s-vision com>]

Your XML, trying to be abstract enough to work for all possible
interfaces, is not what I'd prefer.  In contrast, I envision a language
that allows the GUI to be specified more naturally and making no attempt
to scale to a speech-recognition system, for example (although text-only
gui is desirable).  For a speech system, you'd write a separate XML spec
for the interface, appropriate to the interface while maintianing the
same application code.  Rather than a single XML language trying to be
all things to all people, I favor a more gui-specific language for GUIs
and optionally other languages for radically different interfaces.
I think we differ in some of the goals of the XML definition of the
interface:
We both support separation of UI and application code, obviously.
OTOH, my vision of the XML-specified UI is that the *user* would tailor
the XML file to his exact tastes (dramatically changing the look and
feel of the program if he wants).  Because I want the user to make
changes to the exact presentation of the UI, the abstractness of your
XML is not desirable.  Rather, a what-you-describe-is-what-you-get
XML-specified UI is prefered.  The user could describe exactly what
buttons he wants, the format of the controls, (even whether he wants a
find dialog to automatically close after the first find or remain open,
for example), which items should be on toolbars and which on menus, etc.
etc.  Perhaps you meant to have this stuff specified by cascading style
sheets (of which I know almost nothing).  I'd prefer to have all this
type of stuff directly accessible in the markup language.

See my (adjacent) posting of my version of a notepad UI specified an XML
language.
Please comment.


Paul


> From: 	Robert Atkey[SMTP:roba@dcs.ed.ac.uk]
> <interface name="myNotePad" class="notepad">
>   <commandgroup name="main" class="man">
> 
> In a GUI this would be the menu bar. A Graphical Inetrface could
> decide to put 
> some of these on a toolbar, according to what class they are.
> 
>     <commandgroup name="file" class="file">
> 
> In a GUI this would be an item on the bar
> 
>       <semantic-commandgroup name="file1" class="weak">
>         <command name="open" class="open">
>           <connect signal="activate" message="command_open"/>
> 
> When this command is sctivated, the callback (corba method or
> whatever) 
> 'command_open' is called.
> 
>         </command>
>         <command name="save" class="save">
>           <connect signal="activate" message="command_save"/>
>         </command>
>         <command name="saveas" class="saveas">
>           <connect signal="activate" message="command_saveas"/>
>         </command>
>       </semnatic-commandgroup>
> 
> Here would be a spacer
> 
>       <semnatic-commandgroup name="file2" class="weak">
>         <command name="exit" class="exit">
>           <connect signal="activate" message="command_exit"/>
>         </command>
>       </semnatic-commandgroup>
>     </commandgroup>
> 
> Now for a standard edit menu. These could be activated by either
> clicking on 
> them in a gui, Or the line 'edit.cut' in a script or even saying
> "edit-cut" in 
> a speech interface.
> 
>     <commandgroup name="edit" class="edit">
>       <command name="cut" class="cut">
>         <connect signal="activate" message="command_cut"/>
>       </command>
>       <command name="copy" class="copy">
>         <connect signal="activate" message="command_copy"/>
>       </command>
>       <command name="paste" class="paste">
>         <connect signal="activate" message="command_paste"/>
>       </command>
>       <command name="find" class="find">
>         <connect signal="activate" message="command_find"/>
>       </command>
>     </commandgroup>
>   </commandgroup>
> 
> Now the actual data of the application
> 
>   <datagroup name="data" class="main">
>     <data interface="text/multiple" arguments="editable;selections" 
> name="text" class="notepad">
>        <connect signal="change" message="text_change"/>
> 
> Ask to be notified whenever the text changes. This signal would be
> defined as 
> part of a text/multiple interface.
> 
>     </data>
>   </datagroup>
> 
> The find dialogue box (or series of questions). In retrospect this
> could have 
> been included with the command 'find' above so that the command is
> more 
> connected with the data it needs to execute.
> 
>   <dialogue name="find" class="find">
>     <commandgroup name="commands" class="dialogue-commands">
>       <command name="find" class="activate">
> 
> A standard "OK" button.
> 
>         <connect signal="activate" message="find"/>
>       </command>
>       <command name="cancel" class="cancel">
>         <connect signal="activate" message="no_find"/>
>       </command>
>     </commandgroup>
>     <datagroup name="find_data" class="dialogue_data">
>       <data interface="text/single" arguments="editable" name="word" 
> class="word">
>       </data>
>       <data interface="option/boolean" name="case_sensitive" 
> class="case_sensitive">
>       </data>
>     </datagroup>
>   </dialogue>
> </interface>
> 
> The class names are there so that things like 'all activate commands
> are in 
> 24pt Times Roman and say "OK" except ones called "find" which say
> "Find"' in 
> some kind of stylesheet system.
> 
> This would be a little clearer with some real code to back it up.
> 
> Bob
> 
> 
> 
> -- 
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
>