On Tue, Jul 09, 2002 at 03:34:22PM -0700, Chuck Groom wrote: > > Nifty. How far along is the code? > > I'm about a week from done with the first version. The hard part was actually > designing good data structures and making them play nicely; wrapping works, > it's fast, but there's lots of stuff yet to be done. When it's in decent > shape, I'll import a branch.
I'd like to have it in CVS even if it doesn't work yet, but if you'd rather not that's fine too. > > You cannot embed other widgets, flow text around graphics, use tables. > It will support fonts/colors and drawing when there's a background > behind the text in later revs. It's useful for reading text files and > simple word processing. <IMHO>PicoGUI needs this first, and a separate > read-only-text-with-embedded-objects widget later. I think they're very > different problems.</IMHO> Maybe the way to handle this is to keep both of our textbox widgets in different branches, then compare their performance for simple text editing. If there's a big difference that can't be fixed, we keep two separate widgets. Otherwise we merge the two designs somehow? I dunno.. > > I'm excited to hear about your design goals! What you describe sounds > very cool, and I'm impressed by the anticipated flexibility. I'll certainly > take a look at the pgstring object. Well, there's not much there yet. I've been doing background processing on the design, and most of the coding so far has been reworking existing code to be compatible with pgstring. > > I have a few quick questions: how does the pgstring manage its gap? What > kind of metadata will the paragraph keep around to avoid the nasty > "editing in the middle of a 1Mb single paragraph" problem? Finally, how > heavy is the paragraph object -- will it waste memory if the user > loads a lot of newlines? I'm still thinking about this part of the design, but I'm anticipating that the pgstring object will insert a (relatively) large gap near the part of the string that's being edited, use this for fast insertion, then clean up the gap after that part of the string has been inactive for some time. The gap and all formatting will be done inline with the text. I'll probably use null characters for the gap, and some unused unicode sequence (I'll have to see what I can do according to the standard) to signify a pointer to formatting data. I know that I'll need a way to quickly skip these gaps when rendering text. I might do this by always aligning the end of the gap to some boundary. The paragraph object will keep a list of locations where text is wrapped (or possibly a list of line lengths in bytes, so things can be inserted/deleted easier). It will probably use 4 bytes per newline.. so there will be some overhead for large numbers of newlines, but not that much. > > While your design at first sounds different, it's actually pretty similiar > to what I was working with. Gapped paragraphs n'stuff. Fun! yep :) > > I'm going to push hard to get something that works out as soon as possible, > then step back and discuss how to fit it into the bigger picture. Does > that sound good? That should be fine. I have had this big vision of the ultimate textbox almost since the beginning of picogui, but you can see how well that's got us a working product! The other factor to consider is that Smartdata is funding my current work on the Textbox. So I suppose they should have some say in this decision. > > Cheers, > > Chuck -- Only you can prevent creeping featurism! ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf _______________________________________________ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
