GUI implementation critique requested

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

GUI implementation critique requested

Mark Wilden
I'm writing a spelling quiz application. There is no menubar. There are no
subwindows. There's just a ShellView, on which appear the widgets required
for the particular quiz.

When the game starts up, the window displays the widgets for selecting a
player, etc., as well as a Start Game button. When that's clicked, a new set
of widgets appear (effectively a new screen) and the quiz starts.

That's the desired appearance from the user perspective (and it's
nonnegotiable:). Here's how I'm presently doing it:

I created a Presenter for the ShellView (OK, the other way around) called
MainWindow, and Presenters for each of the screens (MenuScreen,
PracticeScreen, etc.). I created a ContainerView in VC to represent each
screen, each of which can have its own background color, toolbar, statusbar,
etc.

To start things off, I do
MainWindow>>createSchematicWiring
super createSchematicWiring.

menuScreen := self add: (MenuScreen createIn: self)

That lets the menu screen take over. One of its buttons sends #start to the
shell:

MainWindow>>start

self remove: menuScreen.

practiceScreen := self add: (PracticeScreen createIn: self)



This seems to be working well (except for keyboard accelerators, which don't
seem to make it down to the subpresenters), and it seems so simple that I
have a good feeling about it.

But, like everything else at this stage, it took me a _long_ time to figure
out. Will this work?


Reply | Threaded
Open this post in threaded view
|

Re: GUI implementation critique requested

Ian Bartholomew-18
Mark,

Was that a groan I heard  when you saw I'd replied? :-)

> But, like everything else at this stage, it took me a _long_ time to
> figure out. Will this work?

Probably.  It's the sort of technique used in a couple of Dolphin tools
(Debugger and Inspector).

Can I also suggest a couple of alternatives you might want to look at.

Create the Shell and add all the sub view/presenters to the shell in the
VC.  Use #show/#hide to set which one is visible.

Use a WizardCardContainer which is designed to sequentially display sub
view/presenters

--
Ian


Reply | Threaded
Open this post in threaded view
|

Re: GUI implementation critique requested

Mark Wilden
"Ian Bartholomew" <[hidden email]> wrote in message
news:Jlfha.2834$[hidden email]...
>
> Was that a groan I heard  when you saw I'd replied? :-)

Not at all, Ian--I was waiting up for it. :)

> Create the Shell and add all the sub view/presenters to the shell in the
> VC.  Use #show/#hide to set which one is visible.

I considered this. But there could conceivably be ten, twenty or a hundred
different screens--who knows? And would I have to instantiate the Presenters
all at once, too?

One nice thing about having the views separate is that I can work on them
separately in VC (or VCs).

"Classically," I think this sort of app would simply have multiple windows,
or maybe each kind of game could be considered a different kind of
"document" with its associated windows (assuming MVP is similar to MFC).

> Use a WizardCardContainer which is designed to sequentially display sub
> view/presenters

I will definitely look into this--thanks.


Reply | Threaded
Open this post in threaded view
|

Re: GUI implementation critique requested

Ian Bartholomew-18
Mark,

>> Create the Shell and add all the sub view/presenters to the shell in
>> the VC.  Use #show/#hide to set which one is visible.
>
> I considered this. But there could conceivably be ten, twenty or a
> hundred different screens--who knows? And would I have to instantiate
> the Presenters all at once, too?

That would be the easiest way.  If you have got a lot (say > 10)
different presenters then your #createIn: method is almost certainly the
best way to go.  I was thinking more along the lines of a limited number
of template presenters that are populated at run time.  Something like

User fills in current page and asks for next
Application selects next question.
Visible presenter is correct template for question?
if not
-- hide current presenter
-- show correct presenter
Fill in presenter fields with next question

This obviously won't work if each of your presenters is _completely_
different though.

> One nice thing about having the views separate is that I can work on
> them separately in VC (or VCs).

You could do the above using views created as separate subviews in the
shell or as ReferenceViews imported from other resources.

>> Use a WizardCardContainer which is designed to sequentially display
>> sub view/presenters
>
> I will definitely look into this--thanks.

This really needs a specified order of cards to work through so would
probably hit the same problems for a large number of presenters.

Just musing....

How may ways can you ask the questions in a computer based spelling quiz
anyway?.

I'll rule out the obvious "How do you spell Mississipi"  :-)

I could think of
    "Which is the correct spelling of a US river? ... Missisipi
Missississipi .........
    "Fill in the blanks with none, one or more letters ...  Mi_i_ip_i"
    "How many different ways to spell the word that sounds like rayne?
.... 2 3 4 ..."
    "Select the words that are spelt correctly... rayne reign rein
raine"
    ?

--
Ian


Reply | Threaded
Open this post in threaded view
|

Re: GUI implementation critique requested

Mark Wilden
"Ian Bartholomew" <[hidden email]> wrote in message
news:Ljhha.2895$[hidden email]...

> User fills in current page and asks for next
> Application selects next question.
> Visible presenter is correct template for question?
> if not
> -- hide current presenter
> -- show correct presenter
> Fill in presenter fields with next question
>
> This obviously won't work if each of your presenters is _completely_
> different though.

Each presenter is a different "screen" (think of an old DOS program). They
could be similar--they could be different. But they are independent.

> > One nice thing about having the views separate is that I can work on
> > them separately in VC (or VCs).
>
> You could do the above using views created as separate subviews in the
> shell or as ReferenceViews imported from other resources.

Yes, good point.

> How may ways can you ask the questions in a computer based spelling quiz
> anyway?.

Hey, I don't want to give away all of my domain secrets, do I? :)

> I'll rule out the obvious "How do you spell Mississipi"  :-)

Wye would you want to??

> I could think of
>     "Which is the correct spelling of a US river? ... Missisipi
> Missississipi .........

Actually, that's one. You show a bunch of right/wrong pairs on the screen,
and you click away the bad ones (or vice versa).

>     "Fill in the blanks with none, one or more letters ...  Mi_i_ip_i"

Something like that. There's a quiz mode: "How many s's does 'disappear'
have?"

>     "How many different ways to spell the word that sounds like rayne?
> .... 2 3 4 ..."

Hmm. Rain. Reign. Rane. Wreighn. I'll pick '2', Chris, and that's my final
answer.