Re: [Arianne-general] GUI specification

[masahiro m. <el...@aa...>]

hi, sorry for my late reply --

At 10:52 PM +0200 01.9.27, MIGUEL ANGEL BLANCH LARDIN wrote:
>   First, we need to know what we requiere to accomplish our task.
>   Following the GUI look design guide, we can find the next set of active
>elements:
>     - Button
>     - TextBox
>     - InputBox
>     - Menus
>     - RadioButton
>   There are also passive objects that don't generate events(*) and that
>shouldn't accept events(*).
>
>   (*) Event means Game events and not GUI events like mouse move or so.

I guess CheckBox is also necessary.
<CHECK>name, status</CHECK>

>   Each of these active elements should have an identificator that for easier
>understanding can be name. Also they will have different information about 
>their
>state.
>
>   The state is comunicated to the game logic on each change, unless the events
>procedding from that type of element would have been disabled.
>   So we have an asynchronous system.
>
>   As our target client is threadless we requeire to do a poll in each loop for
>test for GUI events.

I think this is all right because we need to process events internally
turn ( Arianne time ) based. Right ?

>
>   Let's detail each element for a simpler specification.
>
>   - Button -
>   The button is an element that when PRESSED will generate the button event.
>   The event could be like:
>
>     <BUTTON>name</BUTTON>
>
>   As it has no more events interesting for the game logic, with that info 
>we can
>manage it.
>
>
>   - TextBox -
>   This is a box of 1 or more lines of text that is READ-ONLY.

i.e., in your term, GAME_2_GUI
>
>   - InputBox -
>   This a box of 1 or more lines of text that is WRITEABLE.
>   It will generate events for the game and the game will generate events 
>for it.
>   The events can be like this.
>
>     <INPUTBOX>name,Text</INPUTBOX>
>
>   It doesn't matter in what way the communication is done. In the GUI_2_Game
>way, it will tell the game about something the player has written. In the 
>other
>way it will behave just like a TextBox.
>
>
>   - Menus -
>   It must be a menu don't matter if static or pop-up ( that is GUI specific )
>but it MUST allow to have submenus.
>   It will only generate event's on the GUI_2_Game way. The events could look
>like this:
>
>     <MENU>name, option </MENU>
>     where option can be also <MENU>name, option </MENU> so that is the 
>option at
>choose at last no matter how deep in the submenu it is.

hmmm.. I think if only each MENUs have own identifiers, we don't have to 
care about
the depth of menu --- do we ?
>
>   Once we have seen the main elements, we need to reach an agree about how to
>manage the user input with the mouse to control the character.
>   Managing it with mouse instead of with keyboard looks a lot of better, 
>because
>the keyboard will generate tons of events to make the same that two clicks 
>with
>the mouse.

Agreed.

>
>   In my opinion the key is to think that the mouse generate Game actions with
>mouse clicks ( We have had a ML discussion about this ), so on each event that
>is the click of the mouse or whatever of the above events, we can send 
>also the
>mouse position in the global reference system.
>   We can send mouse position as <MOUSE>x,y</MOUSE>. We can't ignore the 
>state of
>the buttons here so we give it this treatment. <MOUSE>x,y,left,right</MOUSE>

why not left = 1, right = 2, center = 3... like that
This way we can handle modifier keys like Shift + Right click = 5.


>
>   Now we will talk about how all this info is managed.
>   We need an event gatherer and when all this info is collected and based 
>on the
>rules for controlling the GUI it should change the game state.
>   The only state dependend event is the mouse. So we need to define events 
>that
>requiere TWO events to be complete: one from wherever you want, and 
>another from
>the mouse. Most of them will be Menu related.

I don't get the idea -- could you give me some example ?
Do we need to care about mouse state when we choose menus ?
But choosing a menu item requires mouse action, so we don't have to care 
about mouse
when a user ( client ) sends menu event...
I guess we rather need to consider how to handle keyboard events AND mouse 
events,
for we will need some or more keyboard combinations to play a game like 
Arianne.
Am I missing the point here ?

>
>Questions
>---------
>
>   While writting this short explanation several questions has arrise for me.
>
>   - Should Game be able to configure the GUI sending events to it? ( Would be
>really interesting )

Do you mean customization of the GUI / events ?

>   - How we can link mouse and menus?

I don't get the meaning. Could you explain in details ?

>   - We need to filter mouse events that are not supposed to be known by the
>game.

Reading the doc, I thought that we should use the word EVENT for a pure GUI 
events,
and call messages sent to the Game / Server COMMANDs, so that we will not 
be confused.
So, all the <BUTTON>....</BUTTON> messages should be called COMMANDs, and 
not EVENTs.

How about it ?

Also, reading your new GUI code ( PressButton.h / .cpp ), I guess you 
misunderstood something.
We need to send raw ( Renderer, in our case at the moment, SDL ) events to 
some GUI Commander
class, and then determine which part of GUIs the event should be handled ( 
is the mouse on a button
or on a radio button ???), and THEN produce COMMANDs.

Your code;
....
bool PressButton::execCommand(GenericCommand* com)
<snip>
   switch( com->type )
     {
	case ARIANNE_COM_BUTTON_PRESSED:
       {
 
m_renderer->internalEvents.push(std::string("<BUTTON>")+m_name+std::string("=press</BUTTON>"));
       m_pressed=true;
       done=true;
       }
<snip>
   }
....

Must be something like this;
bool PressButton::execCommand(GenericCommand* com)
   {
<snip>
   switch( com->type )
     {
	case ARIANNE_COM_MOUSE_DOWN:
       {
       if IsInRect( com->mouseX, com->mouseY) then
         {
 
m_renderer->internalEvents.push(std::string("<BUTTON>")+m_name+std::string("=press</BUTTON>"));
           m_pressed=true;
           done=true;
         }
<snip>
   }

Otherwise, we can't know if a mouse click is on some GUI control before we 
sent the message to the GUI control
and determine if it's inside the control ---- may be we can if we control 
where on the screen each GUI control
is in event handling part, but if we do this way, it's really difficult to 
customize the whole GUI because we need to
tell the event handling part that 'Now the ATTACK BUTTON is at X, Y, with 
WIDTH, HEIGHT' ----

So the problem is how to wrap system / library dependant events to produce 
GenericCommand ( I guess we had
a small discussion about this months ago..;))

And according to my proposal about EVENTs and COMMANDs, GenericCommand 
class here should be defined as
GenericEvent class, and ARIANNE_COM_MOUSE_DOWN should be 
ARIANNE_EVENT_MOUSE_DOWN.....


Am I missing something here ?

Please correct me if I'm wrong.

Regards,
-- 
masahiro minami <el...@aa...>

PowerBook G4/400
PowerMac G3/233
MacOS 9.1--MacOS X---LinuxPPC
(Eudora 4.3.2J)
exception handling : www2.age.ne.jp/~except

( happy hacking & love & peace & noise )