From: Erik V. <eri...@hc...> - 2006-02-04 21:47:34
|
> I think maybe I'm talking about one thing and meaning another. I > tossed off that reply rather quickly from work yesterday, so it > probably didn't get as much thought as I should have put into it. > > I realize that we need to track the state of the UI somehow. I'm more > looking at the organization of the ORWindow. > > Right now things are a bit of a mess between HexMap, UpgradePanel, and > ORWindow. We have HexMap manipulating things in the UpgradePanel, and > UpgradePanel calling a processDone method in HexMap. > > It's all a bit too... incestuous. Yes, absolutely. > I think that HexMap shouldn't need to know about UpgradePanel, and > UpgradePanel shouldn't need to know about HexMap. The ORWindow should > be taking care of governing that when actions are taken, the proper > information is propagated downward to each Panel that needs affecting. ORWindow is a newcomer, so it's not surprising that its role is limited so far. I agree that these things can best be controlled form one place, and I had in fact in mind to choose HexMap for that place, because that is where the action is as it comes to tile and token laying. Besides, HexMap is guaranteed to survive whatever UI reorganisation we may do in the future. ORPanel is another option, as it has the closes ties to the real state machine in the background: OperatingRound. And ORPanel is also the place where some of the action buttons are (and I think we should move the UpgradesPanel buttons there too, opening UpgradePanel only if there are tiles to show). But I have no real objection against using ORWindow. Erik. |