From: Brett L. <wak...@gm...> - 2007-08-02 20:30:34
|
On Thu, 2007-08-02 at 21:15 +0200, Erik Vos wrote: > > > > 1. A new section (JPanel) is added to the existing > > Options dialog, and > > > > shows any available variants, and is not visible if no > > variants are > > > > found. > > > > > > This is about what happens, except that (1) the original > > contents of that > > > window have been removed > > > (the alternative being to disable everything before adding > > the new stuff) > > > and (2) it is moved 200x200 pixels to make it somewhat > > better accessible. > > > And, yes, it is briefly out of sight. > > > It should be easy to tweak it your way - go ahead, I would say. > > > > > > > You're misunderstanding my meaning. This isn't at all what happens. > > > > By new JPanel, I'm meaning a new JPanel within Options(), > > this does not > > mean a modal popup dialog. > > This is what happens (have a look at the code), although it does not seem > so.... > But I understand that you want the rest of the Options window > remain visible, well, that is easy enough to do: > remove setVisible(false), and remove getContentPane().removeAll(). > Well, it may be a bit more work because I have also used a different layout > manager, > so it may not be that easy... > Now you're just playing funny semantics games. Technically, you call getContentPane().removeAll() on the Options dialog, which removes the current Options UI, and replace it with the new elements. This is effectively the same exact thing as creating a whole new dialog. The old UI goes away, and the user is presented with a new UI. I don't care about the technical details of how it works. It's the user's experience that matters. It's the user experience that is exactly what I don't want. New Game needs to start a new game. No additional questions. No additional options. New Game must start the game. > > > > 2. A new button on the Options dialog that then pops up > > the variant > > > > selector dialog. > > > > > > That button already exists: it is the New Game button. > > > > > > > Wrong answer. New Game needs to start a new game *immediately*. > > > > If we're going the button route, then it needs to be a *different* > > button that shows the variant options. This button needs to > > only toggle > > the variant values, and not be in between the user and starting a new > > game. > > OK, I had missed that point: you want a user allow to skip the game options > part. > Fair enough. > Yes. They're called "options" because they're optional. Otherwise they'd be called "requirements" or "dependencies". ;-) > > This requires two separate UI paths: > > > > First: Options() presented -> User hits New Game button -> New game is > > started, code just assumes no optional 6 train (i.e. the default value > > is used). > > > > Second: Options() presented -> User clicks Variants button -> Variants > > dialog is presented -> User selects variant options and hits an OK > > button -> User is returned to Options() -> User clicks New Game button > > -> New Game starts. > > OK, although the last to items can be skipped IMO: why not let OK start the > game? We don't start the game with OK because the user may not be finished setting up their game. If I want to select my game options, then enter in the players names, that needs to be just as valid as entering player names then selecting game options. This is why I'd prefer to keep these things all in the same window. Changing the dialog (or having an extra dialog) isn't at all necessary and causes more problems with the UI than it solves. ---Brett. Two is not equal to three, even for large values of two. |