Messagebox

[UnFleshed One]

I'm about to do that. The question is: what should it be able to do?

 

-- Show text and a couple of buttons (Ok, Cancel or with custom text).

-- Return what button was clicked.

-- Show an edit box, to accept simple data.

-- Be totally modal, pausing the game when shown.

-- Be single, meaning only one is allowed on the screen at any given time.

If another one is called it is get put in a queue and gets called after first one is closed. (probably a checkbox "dissmiss all" is good idea as well).

 

What else?

[red knight]

It is fine, just make sure that you can delegate the rendering of the actual content so we can use it as a sort of template (unless it get too complex or messy).

 

Greetings

Red Knight

[UnFleshed One]

I'm going to make a couple of standart layouts to choose from (simple text with ok button, choice with ok/cancel, choice with yes/no, maybe something else). And a way to load custom layout as long as it has standart windows names. To make it really custom it is better to derive from it and overload what needs customizing.

 

BTW, is it ok to load layouts everytime from disk, or better to cache them?

 

PS

I think we overusing singletons .

 

Edit:

Do we need syncronous show()? One which will wait until user pressed the button?

Edited October 3, 2005 by UnFleshed One

[red knight]

That depends, I think that both synch and asynch are useful... one for things that requires the game to pause (somehow) and asynch for things that let you continue doing stuff. In that I think about Errors for example.

 

About the layout, do not cache them for now.

 

Greetings

Red Knight

[UnFleshed One]

And condition "one at a time" is ok? (It is just that design will heavily depend on this one, and redoing it will be painfull ).

 

Rationale for it is that it won't flood screen with windows (thus putting the machine on it's knees). And it is easier to program.

 

But if somebody can't live without a possibility of putting a dozen or two messageboxes simultaneously, I can do that too.

[UnFleshed One]

I guess I have a problem with syncronized boxes...

 

Let's say user pressed a button. That invoked CEGUI event, and it called the event handler for that button. Let's say there was a call to sync function, which creates a message box and blocks current thread to wait until the box is closed.

 

See the problem?

 

Right. The problem is that blocked thread is the thread which handles CEGUI events and supposed to draw the box.

 

So, by waiting for something to happen we prevent it from happening.

 

Isn't it a Zen observation?..

 

Unless I am mistaken, or somebody have different solution, we'll have to do with async messageboxes...

 

Edit: Too bad, I rather liked that part of the code...

Edited October 4, 2005 by UnFleshed One

[red knight]

Maybe the word isnt synchronized... I would say modal to all with Simulation stop capability.

 

Greetings

Red Knight

[blob]

I don't think that we should limit it to one at a time. And I think that we shouldn't make it multi threaded as it would be real pain in the a** to program it that way and I don't think there's anything we would gain from there.

 

Ps. Many people think that singletons are bad and those should be used only if there's good reason.

Edited October 4, 2005 by blob

[red knight]

I am among those mainly because:

 

- Singletons do not allow you to test independently from anything.

- Once you used a singleton everything looks like a singleton.

- They can introduce subtle multithreading issues.

 

So they must be avoided as much as posible.

 

Greetings

Red Knight

[UnFleshed One]

Yeah, and what we are using as singletons are essentially just global variables .

 

What I called asyncronous (maybe wrongly) is that you call show() in one function, and receive whatever messagebox returns in a callback, in another function. It is a natural way considering CEGUI desing. (I had to use threads to make it sync).

 

It is not possible to receive a responce in the same function show() was called from (see my post above), if it was called in the CEGUI thread (and that is where most of messageboxes will be called from).

 

One at a time is how user perseives it. From programming point of view nothing changes, you call up a messagebox whenever you feel like it, and your callback is called when your messagebox was closed.

Do users need to see a messagebox he can't dissmiss because another one is blocking it?

Edit: Ah, yes, I can also use priority queue, so next messagebox will be determined by it's priority, but it will be shown after current one was dissmissed anyway.

 

Modality is achived as in all existing modal dialogs (OptionsDialog and ActionMapDialog are good examples). So it is modal to everything exept to console.

 

Stop simulation I can (when I find out how ).

 

PS:

I'll commit what I have today or tomorrow, so you'll see what I mean.

Edited October 4, 2005 by UnFleshed One

[red knight]

We will have to devise such a mechanism

 

Greetings

Red Knight

[UnFleshed One]

What I said about CEGUI is correct, unless I can run another CEGUI dispatching loop in a new thread. I don't know if it is designed for that, though...

[red knight]

As a matter of fact try to avoid multithreading as much as posible

 

Greetings

Red Knight

[UnFleshed One]

Asyncronous it is, then .

[Guest Azrael]

*loves seeing programming progressing*

[UnFleshed One]

Besides stopping the simulation there must be a way to put switching of states on hold.

 

Edit:

Commited whatever there is (removed all syncronization). Click Options/Load or Options/Abandon to see.

 

We definitely need second FrameWindow, without reserved space for vertical scrollbar. SupSuper, can you draw right side like left side? The window should be used where there guaranteed won't be any scrollbars.

Edited October 5, 2005 by UnFleshed One

[SupSuper]

Besides stopping the simulation there must be a way to put switching of states on hold.

 

Edit:

Commited whatever there is (removed all syncronization). Click Options/Load or Options/Abandon to see.

 

We definitely need second FrameWindow, without reserved  space for vertical scrollbar. SupSuper, can you draw right side like left side? The window should be used where there guaranteed won't be any scrollbars.

Just use , messageboxes don't look that bad without the frame.

Well, if they do, I can fix that. Though you gotta be sure we'll never need windows without the frame

 

Btw, couldn't you merge all the default layouts into one? For example, choiceok and choiceyes are exactly the same, just with different text on the buttons. And you could just hide / move buttons around according to how many there are.

[UnFleshed One]

I will merge 'em eventually, yes. When I have close to complete set of variations.

 

Edit:

Those frameless frames look good for me.

 

Edit2:

But I want XenoLook/Button/LeftRightHard

Edited October 6, 2005 by UnFleshed One

[SupSuper]

I will merge 'em eventually, yes. When I have close to complete set of variations.

 

Edit:

Those frameless frames look good for me.

 

Edit2:

But I want XenoLook/Button/LeftRightHard

What's wrong with rounded corners?

 

Fine, I'll add it, but I think we're reaching a pointless amount of button variations when half of them are hardly used and weren't even on the original design. For instance, you could use XenoLook/Button/Left and XenoLook/Button/Right when you have two buttons.

[UnFleshed One]

Later, when we finish most of UI, you'll have go through and clean and unify all design .