From: Alex T. <al...@tw...> - 2004-09-14 12:38:52
|
At 23:36 13/09/2004 -0500, Brad Allen wrote: >I'd don't really understand all of what you are describing here, and I'm >too sleepy to dig into it tonight. But both you and Alex both seem to be >talking about introducing a major architectural change to support tabbed >browsing. Actually, I think Kevin's PageBackground is a way to avoid doing too major changes. (And my discussion about sizers was also not about any major change - I wouldn't want to see Pythoncard changing the resourceEditor GUI to explicitly use sizers. I'm hoping that we can (adequately, but perfectly) reconcile the effectiveness and power of sizers with the ease of use of "direct layout". >This may be the right way to do it, and may provide other benefits, but >before I retire for the evening I just want to mention how the tabbed >interface widget is used in Revolution. It may not be the best way, but >it's worth mentioning. > >In Revolution, a tabbed interface is implemented as a dead-simple button. >The tabs don't "contain" other widgets. They don't act as a Panel or >implement a container model. Clicking on a tab just generates an event >similar to picking an item from a Combo button or a popup menu. It sends a >mouseUp event along with the parameter of what tab the user clicked. >Hiding and showing interface widgets as a response is left up to the scripter. Yeah, it's a neat trick. I was a bit surprised to see Rev use it, because they already have the inheritance/container infrastructure for groups, so it might have been easy to just re-use that for tabs. But I agree it does give 90% of the benefit for relatively little effort within the tool; I've user it for help/docs and for preference setting, and found it very easy to use. >Of course, you can leverage Revolution's existing container model of >cards, backgrounds, and stacks if you want. I usually put a tabbed button >at the background level so that it shows up on all the cards in a given >stack. Then, I set up a correlation of one card per tab, so that if the >user clicks on the tab, the tab button takes the user to the appropriate >card. But that isn't the only way of doing it. I could just as easily have >hidden and shown the appropriate widgets all on one card. I tried the "hide / reveal widgets" and found it pretty cumbersome and error-prone - the "card per tab" may add a number of cards, but it is much cleaner. The other issue with hide/reveal for Pythoncard will be when you use sizers - the current set of sizers don't have a way to properly handle multiple, non-interacting sets of widgets. I think if PythonCard had the multiple-cards-per-stack model, then it would be a good idea to look at using a similar trick, but without it, we're better off with PageBackground or similar approach. -- Alex. |