I just prototyped this and it appears to work fine, though I do find it a bit awkward. I think I'd prefer Tab continue to transfer focus and Ctrl-Tab to insert the tab spaces. However, I don't feel all that strongly about it and could go either way - what do others think?
On Nov 16, 2010, at 6:24 PM, Greg Brown wrote: > 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 >>>>> >>>>> >>> >> >
