pythoncard-users

RE: [Pythoncard-users] clearing up tab order in resourceEditor

[Schollnick, B. <Ben...@xe...>]

> I'm not particularly thrilled with the idea of making
> a separate dialog specifically for the tab order of
> controls, since it will just be a duplicate of the=20
> functionality already provided.

Then how about adding a DRAG reordering ability to the
current dialog?

It's quite annoying to have to keep clicking "UP", etc....
Actually the most annoying "issue" with the TAB order is that
you need to reference the properties panel, while manipulating=20
it in the options menu....

Why not get rid of the TAB order options from the options menu,
and move those controls to the properties floater?  That makes
more sense from a workflow perspective.

		- Benjamin

Re: [Pythoncard-users] clearing up tab order in resourceEditor

[Alex T. <al...@tw...>]

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 30/03/2005

Re: [Pythoncard-users] clearing up tab order in resourceEditor

[<bra...@om...>]

I'm still in favor of a separate data structure for tab order. It's 
important to be able to take some 
focusable components out of the tab order, just as you can in 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 
component widget names,
let's call it tabSeq. 

Rules for tabSeq:

        - If a widget isn't in tabSeq, it's not included in the tab order.
        - If a widget is deleted in Resource Editor, it must be deleted 
from tabSeq
        - If a widget is renamed in Resource Editor, it must be renamed in 
tabSeq
        - By default, at on_initialize, the focus would start at the first 
widgets in tabSeq
                (this would reduce need setFocus statements in 
on_initialize)
        - Tab order in final background UI is determined by tabSeq

The Resource Editor UI to handle this would be a modal dialog box listing 
focusable widgets
of the current background, with checkboxes alongside each item. Any widget 
with a 
checkbox is included in the tabSeq. Widgets could be reordered by using an
appropriate list reordering UI.

Yes, this is yet another dialog box for Resource Editor, but I don't think 
it would
need to be implemented in Resource Editor right away. I for one would be 
happy
to set the values of tabSeq from a script, but hope for a future time in 
which Resource 
Editor handles keeping the resource file in sync with tabSeq, and 
providing
a dialog UI for managing tabSeq.


 

Re: [Pythoncard-users] clearing up tab order in resourceEditor

[Alex T. <al...@tw...>]

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 30/03/2005

Re: [Pythoncard-users] clearing up tab order in resourceEditor

[<bra...@om...>]

Alex Tweedly wrote on 04/04/2005 03:42:32 PM:

> I think it's important to NEVER have focusable components that can't
> be reached by TAB order. The idea of a field that needs to be 
> reachable but can be reached ONLY by mouse movement strikes me as 
> being wrong. 

Well, I suppose that's a reasonable position, assuming your application is 
attempting to reach the widest possible audience. But what if your 
application is for a very small set of users, or even one end user, such 
as the owner of a small business?

My experience doing custom FileMaker solutions tells me that some 
customers want only specific fields in the tab order, so as to streamline 
data entry, and FileMaker does support omitting fields from the tab order. 
The most egregious example in my experience was a loan application form 
with dozens of obscure fields that were usually not used. The loan officer 
wanted the option of editing those other fields, but didn't want to have 
to tab through them constantly. I suppose I could have made him switch to 
a different layout, but he wouldn't have been happy with that.

Sometimes having a toolset enforce a user-interface convention/ideology 
makes sense, but I'm not sure it makes sense in the case of tab order. 

Re: [Pythoncard-users] clearing up tab order in resourceEditor

[Alex T. <al...@tw...>]

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 30/03/2005

Re: [Pythoncard-users] clearing up tab order in resourceEditor

[<bra...@om...>]

> I certainly wouldn't argue for wxPython to enforce this, though I 
> might try to argue for Pythoncard doing it.
> But my main point is that it's a design "feature" I try to avoid, 
> and wanted to plead the case for others to avoid it too.

The point is well-taken. In future, if a customer insists on this,
I can always work around the default PythonCard behavior, but
can also suggest some of the ideas you mentioned for having
cake and eating too.

Re: [Pythoncard-users] clearing up tab order in resourceEditor

[Murray A. <m.a...@op...>]

Alex Tweedly wrote:
> bra...@om... wrote:
> 
> 
>>I'm still in favor of a separate data structure for tab order. It's 
>>important to be able to take some
>>focusable components out of the tab order, just as you can in 
>>FileMaker. This is normally done
>>with rarely used-fields which still need to be focusable by mouseClick.
> 
> I completely disagree. (Climbs on hobby-horse ......)
> 
> I think it's important to NEVER have focusable components that can't be 
> reached by TAB order. The idea of a field that needs to be reachable but 
> can be reached ONLY by mouse movement strikes me as being wrong.
> 
> In my own case, it's because I can type much better than I can use the 
> mouse; I like keeping my hands over the keyboard and just typing to get 
> what I want - but I'll admit that's personal preference.
> 
> But there are others who are disabled in various ways, for whom 
> requirements to use a mouse can be close to a show-stopper problem.  I 
> think it behooves us as developers to make our applications as 
> accessible to as wide range of people as possible - there should always 
> be an alternate, non-mouse mechanism, and it should be reasonably easy 
> if that is at all possible. (I accept that for some aspects of say a 
> drawing program there may be no alternative to a mouse other than 
> cursor-arrow-keys - but for reaching fields on an input form, that's not 
> necessary).
> 
> Try it some day - disconnect your mouse. You might be surprised by how 
> possible it is to do 95% of what you need, and how hard the other 5% 
> becomes. And how annoying it is that 4% out of those 5%  could have been 
> easy if someone had just thought about it a bit longer or more 
> sympathetically.
> 
> (Dismounts from hobby horse .....)

I don't think one has to climb on a hobby horse to suggest that
accessibility be a requirement for any project, nor do we need to
appeal to anyone's sense of fairness or ethics. If you're doing
business in the US or the EU, chances are you often have legal
requirements to provide accessible solutions. This applies to
whether you're doing business with government, industry, education,
etc., just as one finds requirements for entry ramps into both
public and private buildings.

Those who work with computers should always realize that they're
just one step away from needing accessibility features. Yes, it
can happen to YOU (if you're reading this, I mean YOU). It doesn't
even take some kind of accident. I know several people who simply
blew their hands out by too much typing or mousing, and are now
forced to use voice software in order to use a computer at all.
Yeah, it's a pain in the ass. They don't have any other option if
they want to use a computer. Any one of the people on this list
could be in this situation -- nobody is immune. [I also know a
fantastic acoustic bass player who retired this year after a long
battle with hand problems. In the end, it was just too painful
to continue. And he is a big guy, over six feet tall and strong
like an ox.]

As part of designing any software, Alex's suggestion is a very
good one: disconnect your mouse and see if you can still use
your software. If not, think about how those limited to keyboard
or voice will feel about your product. What if they happen to be
say, your client's purchasing agent, CTO or CEO?

It's good business practice to make one's software applications
accessible.

Murray

......................................................................
Murray Altheim                    http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

        Ils ont l'orteil de Bouc, & d'un Chevreil l'oreille,
        La corne d'un Chamois, & la face vermeille
        Comme un rouge Croissant: & dancent toute nuict
        Dedans un carrefour, ou pres d'une eau qui bruict.

Re: [Pythoncard-users] clearing up tab order in resourceEditor

[Kevin A. <al...@se...>]

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