[tetrinext] Re: TINT UI and Theme Standard draft -- part 1:interface

[Jared Johnson <solomon@xxxxxxxxxxxxx>]

On Fri, 24 Mar 2000, tetrinext-bounce@xxxxxxxxxxxx  Fri Mar 24 01:11:12 2000
wrote:
> Date: Fri, 24 Mar 2000 18:10:55 +1100 (EST)
> To: tetrinext@xxxxxxxxxxxx
> From: Ka-shu Wong <zillidot@xxxxxxxxxxxx>
> Reply-To: tetrinext@xxxxxxxxxxxx
> Subject: [tetrinext] Re: TINT UI and Theme Standard draft -- part 1:interface
> 
> 
> [snip]
> > -Menu System.
> > The menu system will give users access to every function available.  It
will
> 
> I would prefer to not have a menu system... it should certainly be able to
> function without it.  But I think it'd be a useful feature.
> 
> It's going to be based on Quake-style console commands - ie, it's possible
> to do everything via the console.  The menu would only exist as a shortcut
> to typing out the commands.
> 

that's pretty much what i had in mind.  only i was thinking, define everything
in the menus and give users a console command for every menu item, whereas you
were thinking, define everyting in the console, and give users a menu item for
every console command.  hrm, no different really ;)

> > -Dialogues.
> > Dialogues will be included primarily for connecting to a server, setting up
a
> > serer, and editing client, server, and interface preferences.  Note that
which
> > options will be available for change within the preference dialogues will
be
> > determined by further discussion.  Input dialogues for simple arguments
within
> > functions like setting nick name, changing teams, etc. will also be
included with
> > functions that require it.
> 
> I wouldn't call them dialogues, they seem to give me the impression of a
> free floating window, which I don't think is appropriate.
> Maybe you can call them 'pages', like, the connection page, the
> preferences page, etc...
> In any case, I think a 'dialog description language' would be useful.  I'm
> sure you can imagine what that is.

sounds like that works for alot of stuff -- it can just be stuck into a pane. 
but what about the single text arguments like team and nick changes?

> 
> > -Task Bar
> > Another common element of an interface that will be included in TINT will
be
> > the task bar.  This bar will be optional -- it can be hidden through an
option in
> > the Vew menu as well as by whatever other means are decided.  Every
function
> > included in the task bar will be one that is available via the menu system.
 It
> > will include a text description and an icon -- whether to display the text,
icons,
> > or both will be left up to the theme author and/or user.  A possible
additional
> > feature for this task bar would be to allow input of a text argument to be
added
> > as a flag to the function that is being used, via a text input box directly
on
> > the task bar.  This would be useful for connecting to a server, joining a
> > channel, joining a team, or changing a nick.  Everything included in the
task bar
> > should be modifyable by the theme author and perhaps through the preference
> > dialogue.
> 
> The buttons on the task bar, like the menu, simply issue a command as if
> the user had typed it at the console.
> I'm not sure how task bars (actually, shouldn't they be 'tool' bars?)

oh yeah, hehe, wrong word.  s/task/tool.
  
> would fit into the design of the interface ... I was planning to make it
> so that theme authors can place buttons arbitrarily on the screen, but
> this makes it difficult for the user to edit, since it wouldn't be a tool
> 'bar'...
> Maybe the theme author should be able to specify a region of the screen as
> a tool bar area, and allow the user to add/modify/remove buttons from it.

i was thinking more like a bar at the top, sort of like nutscrape navigator,
mozilla, etc.  putting it wherever the theme author wants wouldn't be so
bad...but, would it be worth the effort to allow theme authors to decide where 
this
element needs to go?  Are there all that many places that would be good for 
such a
toolbar besides across the top?

same question for the menu bar.

> 
> > -Console
> [snip]
> > type "/team teamsters" in the console.  Note that the menu, taskbar, and
console
> > name for a function can theoretically be different, provided that there is
a
> > means by which such differences can be documented for the sake of theme
authors and
> 
> What do you mean by 'different'?  The menu and toolbar thingies are just
> bindings for the console command - ie, selecting the menu item or clicking
> on the button simply sends the command to the console.

all that i really mean by that is, if the console command is /team, the menu
item can be "change team" and the toolbar item can be "change team to:" with a
text box

> 
> > users.  Aliases for various functions can also be set for use in the
console. 
> 
> Hehe, maybe I should make the console like some kind of mini-scripting
> language...

well, it would be nice to support ; | > ...but not all that easy.  well, ;
wouldn't be hard and that would be very nice =)

other than that, wtf are you talking about =)

> 
> > The console will be at the bottom of the user's screen; The size of the
console
> > during the game and between games will of course be different (and can be
set by
> > theme author and/or user).  Users will also be able to manually grow,
shrink, or
> > hide the console.  This console is remeniscent of the console used in games
> > like Quake.
> 
> Yup.  But it doesn't have to be at the bottom of the user's screen.
> 
> > -Panes
> > Panes will be used for various information that users would like to see
> > displayed throughout gameplay.  Gameplay will be enveloped within a pane. 
Other
> > possible elements that can be displayed within panes include lists of users
within the
> > channel or on the server, queries with individual players (remeniscent of
/msg
> > in irc), and winlists.  Interested parties looking to have fun could even
create
> > SDL hacks displayed in a pain that do various fun things like, for
instance,
> > graphically reflecting the height of a player's field.  Users and theme
authors
> > will be able to show and hide panes, resize panes that can allow resizing,
and
> > perhaps set various dialogues to be displayed in a pane (an example of good
use of
> > this would be to place the connection dialogue into a pane)
> 
> Wow, I haven't thought of this before.  Nice :)
> 
> Ok, so panes are like 'windows'.  Everything are panes - including the
> menu bar, the tool bar, the console, the game play fields, 'dialogues',
> and any special panes added by mods and things.
> 
> There needs to be a 'layout manager' for the panes, to work out where they
> would go.  But how would that work?
> 
> It would be nice to have panes that slide in and out from the side of the
> screen.  How would that fit in?

the console would be a good example of this.  in designing the default theme,
we could also set a pane on the right with the connection dialogue that also
slides out, and perhaps a user list pane that does the same.  even the gameplay 
pane
could do this.

the problem is making it fairly simple...we probably don't want to code a
window manager for this.  most panes can just have two sizes:  their default 
size,
and their hidden size (like, 3 pixels wide).  the console pane would want three
sizes -- hidden, in game, and out of game.  perhaps it could be designed to fill
the size of the gameplay pane when the game isn't going on, and shring down
during a "count down" period before the game starts.

anyway, i'm going to bed, i'll post my rant on themes tomorrow.  i'm pretty
sure it will be grossly deficient, but at least it will be something =)

-- 
Jared Johnson
solomon@xxxxxxxxxxxxx

A mother takes twenty years to make a man of her boy, and another woman
makes a fool of him in twenty minutes.
                -- Frost

-----BEGIN GEEK CODE BLOCK-----
Version:  3.12
GCS/C d+(-)>-- s:+ a18 C++++$ UL++++>$ P+>++++ L+++ E--- W+ N+ o? K- w--- !O
M-- V-- !PS !PE Y PGP- t+ 5-- X R-- tv- b+ DI>+ !D G e>++(>+++) h-- r* y-(>+++)
------END GEEK CODE BLOCK------