Noel, Couple of quick questions for you:
a) How can I extract out the current line and column number? I would like to bind a couple of labels in my display to those stats and have it automatically updated. I searched through the Document class hierarchy but not see any methods for this. I did see the method for the total number of lines though. b) Do you expose the "new paragraph" character as a static field in a class somewhere? I am reading text from a file then placing the text into the text area. To do so, I need to be mindful of the proper encoding of new paragraph markers. The standard java IO classes ensure that I can logically work with lines of text properly, but when I create a string buffer to place into the text area using setText, I need the official new paragraph character to be logically consistent. I saw a lot of '\n' but I was hoping for a static field to ensure I always use the right marker. c) How can I obtain the total height of each line? I'm not sure of the right language here, but if I am keeping a ruler in sync that displays line numbers, and assuming one font for all of the text for the moment, I need to know your line height to draw correctly and be robust. I saw a ParagraphView but am not sure if that helps. d) Are you planning on a logical mapping for keystrokes to "actions" and from "actions" to behavior? -----Original Message----- From: Noel Grandin [mailto:noelgran...@gmail.com] Sent: Friday, June 18, 2010 8:52 AM To: dev@pivot.apache.org Cc: aappddeevv; 'Greg Brown' Subject: Re: [RFC] adding components to TextArea TextArea exposes the document model, along with formatting and styling information, via the org.apache.pivot.wtk.text.* classes. I'm busy building a demo application (basically a wordpad-clone) that shows off how it works. -- Noel Grandin aappddeevv wrote: > How generically is the RichTextArea being built? I noticed the swing classes > abstract out the document aspect and I think provides some abstraction on > the formatting--maybe at the nitty gritty level it like TeX and blocks > within blocks with glue. > > I am asking because I think any styled text widget is great, but I also was > thinking about html decorated styling. Just wondering out loud. > > > -----Original Message----- > From: Noel Grandin [mailto:noelgran...@gmail.com] > Sent: Monday, June 07, 2010 4:45 AM > To: dev@pivot.apache.org > Cc: Greg Brown > Subject: Re: [RFC] adding components to TextArea > > Hi > > The new child components are laid out using the existing *NodeView inner > classes in TextAreaSkin. > Currently, I set the size of the child components during the layout() > operation, and I set their position during the paint() operation. > I have to do it this way because TextAreaSkin only calculates position > information during paint(). > > The tricky part is that because the child components are part of the > normal Component hierarchy, their position is defined with reference to > the TextArea object, not with reference to the surrounding NodeView objects. > So I have to pass extra information down the paint() call chain in order > to set their position correctly. > > I see that we're releasing a 1.5.1, so I'll hold off on checking > anything in until we've released 1.5.1 > > Regards, Noel. > > Greg Brown wrote: > >> I have not looked at the code in any detail, but I had assumed that the >> > sub-components would be arranged in TextAreaSkin#layout(), as is done with > other containers. Is that feasible? > >> On Jun 4, 2010, at 10:54 AM, Noel Grandin wrote: >> >> >> >>> Hi >>> >>> This is my first attempt at the part of PIVOT-31 related to inserting >>> > Component's into TextArea (soon to be RichTextArea). > >>> It seems to be mostly working - I can add components, they follow the >>> > layout properly, and the components can receive mouse events. > >>> I'm asking for comments because there are 2 design decisions I'm not sure >>> > about > >>> (1) in TextAreaSkin I'm passing x and y parameters down the paint() >>> > method chain, because a Component inside a TextArea lives outside the way > other nodes are painted. > >>> (2) I've changed the listeners quite a lot in the wtk.text package to >>> > better reflect the difference between events fired for text mutation, and > events fired for node mutation. > >>> Regards, Noel Grandin >>> <patch1.txt> >>> >>> >> >> >
