On the Mac (at least, in Mail.app), Tab appears to insert a tab and Ctrl-Tab transfers focus to the next component. So it is probably safe to use this convention - we can always make it configurable later, if necessary.
On Nov 16, 2010, at 5:29 PM, Roger L. Whitcomb wrote: > Okay, here are *some* of the conventions, which seem to differ not just > by OS, but by application: > - Windows, Outlook 2007: Tab always moves between major areas of the > screen, as does Ctrl-Tab UNTIL you get into the message area, then > Ctrl-Tab moves among the parts of the message circularly (i.e., it gets > you into a loop). This is in reading mode. While editing a message, > Tab or Ctrl-Tab always inserts a tab character (and moves to the next > tabstop). This seems weird to me.... I can't find any option to change > it > - Windows, Ultraedit: Tab moves to next tabstop while editing, Ctrl-Tab > shifts among open files. Tab in a dialog moves among fields, and > Ctrl-Tab still shifts between open files (even with a modal dialog > open!) > - Windows, Firefox: Ctrl-Tab moves among the open tabs, Tab navigates > around the current HTML page fields. The only option I can see is under > "Accessibility" where you can choose to "Always use the cursor keys to > navigate within pages". Within dialogs, Tab moves among fields, > Ctrl-Tab shifts among tab pages in the dialog. > - Windows, Visual Studio 2008: Tab in dialogs moves among fields, > Ctrl-Tab moves among functional areas of the dialog (tab pages). While > editing a source file, Tab always inserts a tab, Ctrl-Tab moves among > the open documents (tab pages). I don't see any option to change this. > > I haven't been able to find (yet) any dialogs that have multi-line text > areas where Tab would be useful for editing. Still looking... > > So, one (fairly) reasonable approach, that would be workable, I think, > would be to have a single property on TextArea that says essentially: > "Tab does insert instead of move off field". Then Ctrl-Tab always moves > out of TextArea to next field and Tab could do either that or insert > depending on this property. And maybe the Ctrl-Tab could be something > else (automatically) on OSX (not sure what). > > > Roger Whitcomb | Architect, Engineering | [email protected] | > Ingres | 500 Arguello Street | Suite 200 | Redwood City | CA | 94063 | > USA +1 650-587-5596 | fax: +1 650-587-5550 > > -----Original Message----- > From: Greg Brown [mailto:[email protected]] > Sent: Tuesday, November 16, 2010 1:31 PM > To: [email protected] > Subject: Re: Displaying tabs in TextArea > > Anyone know how this is typically handled by the various OSes? In other > words, what does Windows/OS X/Linux do in this case? We can certainly > make it configurable, but if there is already a standard convention we > can apply, that would be easier. > G > > On Nov 16, 2010, at 4:26 PM, Roger L. Whitcomb wrote: > >> Personally, I use tabs a lot, and am frustrated in the few places that > I >> can't use it when writing text to (for instance) indent the first line >> of a paragraph. This would come into play with Pivot if TextArea were >> used (as an example) to compose an email message, to write comments in >> an online customer database, etc. >> >> I have seen other apps that have a configurable setting that allows >> Ctrl-Tab (or equivalent) to either do the insert / tabstop operation > and >> Tab move between fields or the reverse: to have Tab do the insert and >> Ctrl-Tab do the field move. I'm not sure how to do this kind of >> configuration thing with Pivot, other than to have a property or style >> specify it. >> >> Roger Whitcomb | Architect, Engineering | [email protected] | >> Ingres | 500 Arguello Street | Suite 200 | Redwood City | CA | 94063 | >> USA +1 650-587-5596 | fax: +1 650-587-5550 >> >> -----Original Message----- >> From: Greg Brown [mailto:[email protected]] >> Sent: Tuesday, November 16, 2010 1:17 PM >> To: [email protected] >> Subject: Re: Displaying tabs in TextArea >> >> After thinking about this a bit more, I wonder if maybe the existing >> behavior might be preferable. In all other components, pressing Tab >> transfers focus to the next component. If we convert Tab key presses > to >> spaces, we'll have to come up with some other way to transfer focus > out >> of a TextArea. >> >> How important is Tab key support? I personally never use tabs myself >> unless I'm editing code, but TextArea isn't really designed for that >> purpose. What do others think? >> >> >> On Nov 8, 2010, at 5:13 PM, Jeremy Heiler wrote: >> >>> Thanks Greg. >>> >>> If you get around to it, could you send me the diff? I would really >>> like to see where the change was made. >>> >>> On Sun, Nov 7, 2010 at 7:42 AM, Greg Brown <[email protected]> wrote: >>>> Good question. TextArea doesn't currently support tab stops. It's >> kind of a pain and didn't seem worth the effort. >>>> >>>> However, as you noted, the Tab key is currently ignored, which may > be >> confusing to users. It would be fairly easy to insert some number of >> spaces when the Tab key is pressed (I almost always configure my text >> editor to do this). I'll prototype it and see how it turns out. >>>> >>>> G >>>> >>>> On Nov 6, 2010, at 11:32 PM, Jeremy Heiler wrote: >>>> >>>>> Hi everyone, my name is Jeremy, and I am developing a text editor >> with >>>>> Pivot. I have set up a basic application that loads a file into a >>>>> TextArea, and so far working with Pivot has been very nice. >>>>> >>>>> My first question is, how can I display tabs in a TextArea? it > seems >>>>> like they're either ignored or are simply not visual. I am also >>>>> looking how to insert tabs, but I assume that has to do with > messing >>>>> with the listener for focusing. I haven't looked too much into that >>>>> yet, but any hints would be appreciated! >>>>> >>>>> Thanks, >>>>> //Jeremy >>>> >>>> >> >
