From: Kevin A. <al...@se...> - 2005-04-04 22:45:30
|
On Apr 4, 2005, at 12:50 PM, bra...@om... wrote: > > I'm still in favor of a separate data structure for tab order. It's=20 > important to be able to take some > focusable components out of the tab order, just as you can in=20 > FileMaker. This is normally done > with rarely used-fields which still need to be focusable by = mouseClick. > > Here's a proposal for handling tab sequence: > > Every background rsrc gets a new property, which is a simple list of=20= > component widget names, > let's call it tabSeq. > > Rules for tabSeq: > > =A0 =A0 =A0 =A0 - If a widget isn't in tabSeq, it's not included in = the tab=20 > order. > =A0 =A0 =A0 =A0 - If a widget is deleted in Resource Editor, it must = be=20 > deleted from tabSeq > =A0 =A0 =A0 =A0 - If a widget is renamed in Resource Editor, it must = be=20 > renamed in tabSeq > =A0 =A0 =A0 =A0 - By default, at on_initialize, the focus would start = at the=20 > first widgets in tabSeq > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (this would reduce need setFocus = statements in=20 > on_initialize) > =A0 =A0 =A0 =A0 - Tab order in final background UI is determined by = tabSeq > > The Resource Editor UI to handle this would be a modal dialog box=20 > listing focusable widgets > of the current background, with checkboxes alongside each item. Any=20 > widget with a > checkbox is included in the tabSeq. Widgets could be reordered by=20 > using an > appropriate list reordering UI. > > Yes, this is yet another dialog box for Resource Editor, but I don't=20= > think it would > need to be implemented in Resource Editor right away. I for one would=20= > be happy > to set the values of tabSeq from a script, but hope for a future time=20= > in which Resource > Editor handles keeping the resource file in sync with tabSeq, and=20 > providing > a dialog UI for managing tabSeq. > There are a number of issues that this raises, but the short answer is=20= that I reject this idea. The main reason why is that a subset of the=20 focusable widgets seems like a border case at best and adds=20 complications to the resource file format, framework, and=20 resourceEditor as well as an additional thing that a user needs to=20 learn. That is contrary to the PythonCard 1.0 goals on pretty much=20 every level. At some point, people just have to use wxPython,=20 PythonCard will never duplicate all the functionality of wxPython, etc. For the cases where you want something like this it should be=20 relatively easy for you to implement yourself either as a subclass of=20 Background or just user code stuck into your main application. ka |