Function codes (was: Color support in CVS)
On Tue, Nov 06, 2001, Bill Janssen wrote: > Another thought I had was to use function code 0x1B instead of 0x53, That would not be according to the spec. which says that the function code's least significant 3 bits represent the remaining function code length; the most significant 5 bits represent the function code. /Mike
wxPerl! YEAH!
Alright, you say po-tay-to, I say wxPerl! http://www.perl.com/pub/a/2001/09/12/wxtutorial1.html I'll see if I can get Robert's gui or parts of it working in this, just something to tinker with. You all know how I feel about Python. /d
Re: gluing the parts of a long page together
> How should the viewer render the segments? Should it show the text as > "one" document (i.e. merge the current and next/previous segment)? Yes, that was my thinking. > That would require two simultaneously opened records and also *MAJOR* > changes to several parts of the viewer (like the scrolling, session > handling, etc.) Hmmm. Not good. Would that be the code in session.c? Are you thinking of the History and HistoryData data structures? > Possible solution: include the total number of paragraphs in every > segment. Yes, I was thinking last night that at the top of each non-first chunk, we'd need the previous chunk ID, the total # of paragraphs in the page, and the # of paragraphs in the chunks preceding this chunk. OK, today's proposal: We use three function codes. Function code 1, START-OF-MULTICHUNK-DOC, provides two 16-bit parameters: the total # of paragraphs, and the record ID of the last chunk (for jump-to-end). Function code 2, CHUNK-BEGINNING, provides 3 16-bit parameters: the total # of paragraphs, the # of paragraphs preceding this chunk, and the record ID of the previous chunk. Function code 3, CHUNK-NEXT, provides a single 16-bit parameter, the record ID of the next chunk in the series. The first chunk of the page contains at the start START-OF-MULTICHUNK-DOC and CHUNK-NEXT, and at the end another CHUNK-NEXT. The start of each of the other chunks of the page has CHUNK-BEGINNING and CHUNK-NEXT, and CHUNK-NEXT again at the bottom to mark the end, except for the last chunk, which has no ending CHUNK-NEXT. > A scrollbar/jump location relative to the number of paragraphs could > be a problem. In a document that is one huge paragraph the scrollbar > would not be of any help to the user. Neither will the scrollbar/jump > location be updated while you scroll *within* a paragraph. Could be > confusing. We currently have a max-paragraph-size of 1000 characters for plain text, and 3000 for HTML. Anything larger gets broken up into multiple paragraphs. So for example the AFS FAQ that I use as a plain-text document has 73K of text, but gets broken up into 273 paragraphs. That page gets split into 3 chunks. The first has 125 paragraphs, the second 104, the third 44. I was also thinking, I suppose, that we could have a sort of hybrid approach to the scrollbar. The paragraph count would be the rough guide, with actual lines on screen providing some fine detail within that. Bill
Re: Color support in CVS
> Please feel free to modify/improve as you see fit, as I am > not much of a python wizard. If you pass everything around as a 3-ple, you > can chop out the itoa function from PluckerDocs.py. Another thought I had was to use function code 0x1B instead of 0x53, which saves a tiny bit in the function code space (other related codes 0x11 and 0x1A are already assigned). Probably unnecessary optimization, though. Bill
RE: Color support in CVS
Hi Bill, > > If someone could test it out and see what things need > correcting, especially > > that the charset work by Bill still is working as expected. > > I looked it over a bit, and didn't see anything that would raise a > flag. It looks like all the parser diffs were to PluckerDocs.py and > TextParser.py, right? Yes. Just these two files. > I changed the string.atoi() calls to int() calls and updated the > docs/DBFormat.html doc. No problem. > I'd probably have used a mapping of standard > colornames to rgb values, instead of an if-elif tree. The color value > could perhaps be carried as a 3-ple (R, G, B) instead of a string? Very reasonable. Please feel free to modify/improve as you see fit, as I am not much of a python wizard. If you pass everything around as a 3-ple, you can chop out the itoa function from PluckerDocs.py. When you are satisfied with the strategy, can recycle the derived strategy for backcolor support as some later point, if needed/requested. Best wishes, Robert
Re: I cannot delete one article
On Tue, Nov 06, 2001, MJ Ray wrote: > Why shouldn't there be something to do that sequence for me and leave > me in the library screen? Try the viewer I have put at http://www.sslug.dk/~micke/plucker/viewer.zip I have changed "Details..." to /I and reserved /D for "Delete document" (/D is also used for "Delete all" in the Document Library, and I guess it is a good idea to use the same shortcut for both delete options.) I have run some tests on it and everything seems to be OK, but you should still backup any important data on your device before you try it out... /Mike
Re: gluing the parts of a long page together
On Mon, Nov 05, 2001, Bill Janssen wrote: > How about the viewer? Does this provide enough information to > actually implement the necessary viewer changes? How should the viewer render the segments? Should it show the text as "one" document (i.e. merge the current and next/previous segment)? That would require two simultaneously opened records and also *MAJOR* changes to several parts of the viewer (like the scrolling, session handling, etc.) How do you jump to another segment? E.g. if you are in the first segment and select "Jump to bottom" the viewer would have to parse *all* segments between the first and the last to know what segment it should jump to. That would be slow... Possible solution: include info about the next/previous record at the top of each record segment. That way the viewer can find the record reference without parsing the whole record. A scrollbar/jump location relative to the number of paragraphs could be a problem. In a document that is one huge paragraph the scrollbar would not be of any help to the user. Neither will the scrollbar/jump location be updated while you scroll *within* a paragraph. Could be confusing. When a named anchor points to a different segment than the first one you would have to traverse back to the first segment to know the total amount of paragraphs or you can't set the scrollbar/jump location. Possible solution: include the total number of paragraphs in every segment. That would leave us with a function code that requires twice as much data (6 bytes). Anyway, I doubt 6 extra bytes per segment will be a problem... /Mike
Re: I cannot delete one article
On Mon, Nov 05, 2001, aardvarko wrote: > It seems as though it wouldn't be terribly difficult to implement - just > close the current document, save its name to a global variable or somesuch, > and set a flag 'DeleteLastDocument'. Then let the user open another document > and add a bit to the Open function checking the aforementioned flag, and, if > necessary, deleting the last document. Not removing the document until the user opens a different document could be quite complex and definitely confusing to the user. Instead I would jump to the Document Library when the user has deleted the current document -- makes sense since the user probably wants to open a new document anyway (or exit the application). I have made a quick hack, but for some reason it sometimes fails to update the document list, i.e. the document is removed from the device, but still shows up in the document library. Have to figure out why before I can create a viewer for you to try out. /Mike
Re: I cannot delete one article
Gary: > I use sitescooper to create about a dozen plucker files each day. I usually > want to delete a file after reading it. > I understand your logic though. I don't. I sync quite a few pages most times (when my Palm isn't ill like it seems to be at the moment -- that's the last time I use hacks on it!), but I usually go L and then delete the doc I just had open. Why shouldn't there be something to do that sequence for me and leave me in the library screen? -- MJR
