From: Brad A. <bra...@ma...> - 2004-09-14 04:37:06
|
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. 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. 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. >From an earlier message: >"It is probably time for a separate discussion thread on the issues >and possible solutions such as treating each page as a type of child >window where only the components of the child window resource are >used. I'm just brainstorming here. You would end up with a separate >source and resource file for each tab/page. I guess the references >to each tab layout would end up being something like >self.components.notebook[0].components.field1, etc. where each page >(window) of the notebook is referenced via a list." > >I sat down after the earlier posts about Notebook and did some >experiments. I created a Notebook component and made a simple sample >that uses the Notebook component and then manually adds a Panel with >a TextCtrl to the notebook. That worked fine and the resourceEditor >worked with the Notebook component too on the first try, though of >course there weren't any page attributes to complicate matters. Then >I started trying to add existing backgrounds as pages in the >on_initialize method. You can't add a wx.Frame as a notebook page >and PythonCard backgrounds subclass wx.Frame so that didn't work. > >I was able to get it to work by making a PageBackground class that >is almost identical to Background except that instead of a wx.Frame >it subclasses wx.Panel. Of course, many of the features of a >Background don't make any sense for a notebook page, so I commented >out the menubar, statusBar, and all of the events except idle. I had >to make some further tweaks to the event binding and dispatch to >correctly deal with the notebook pages without breaking events in >Background and CustomDialogs, but it all seems to be working now. I >made a sample that uses the minimal and widgets backgrounds without >any changes except that instead of model.Background, the Minimal and >WidgetsTest background subclass model.PageBackground. > >Since this was a fairly quick "hack" I hesitate to check it into cvs >without some discussion on the subject. > >If we went with a solution like this I would probably modify the >resourceEditor to support a new PageBackground template type. A >PageBackground is basically going to be like a Background, but there >won't be any menus, statusBar, etc., otherwise the .rsrc.py files >will be almost identical to keep things simple. You would edit each >page of the notebook separately just like you do different >backgrounds today. If and when the resourceEditor is changed to >allow editing of multiple windows at once that would be a little >less clunky. > >The notebook component wouldn't have an attribute list for all the >pages, instead you would add those manually by calling addPage, most >likely in your on_initialize method. I made a pageWindow function >that is almost identical to the childWindow function so that adding >a page looks something like this: > >page = model.pageWindow(self.components.notebook, minimal.Minimal) >self.components.notebook.AddPage(page, 'minimal', True) > >Since I didn't hide the wxPython methods behind a list interface, >accessing a elements of the child pages look like: > >print self.components.notebook.GetPage(0).components.field1.text > >So, will people be happy with this kind of solution? Any alternative >suggestions? If I check this into cvs does anyone have a app or >dialog they've been wanting to do that needs a wx.Notebook so we >would have a decent test case to flesh out other issues? > >ka > > > >------------------------------------------------------- >This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >Project Admins to receive an Apple iPod Mini FREE for your judgement on >who ports your project to Linux PPC the best. Sponsored by IBM. >Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php >_______________________________________________ >Pythoncard-users mailing list >Pyt...@li... >https://lists.sourceforge.net/lists/listinfo/pythoncard-users |