Plucker Desktop initial tour
The Plucker Desktop can now be taken for an initial tour. Can download the zip and run it. This is a Windows32 binary compile. Linux and Mac haven't been compiled yet, but should only need minor if any improvements to the codebase. http://www.rob.md/projects/plucker/2001_11_05/plucker_desktop.zip This is a debug build (zip is 1.1MB), having all the wxWindows debugging stuff in it, plus some more debug messages of my own (hook in a message listener to watch the normal execution messages go by as the program runs). Some things are currently wired up, including: -the XML resources. -loading up and moving around the dialogs. -main dialog: loading up details into main forms listcontrol. -HTML editor dialog: can add a plucker hyperlink using the wizard button. -main dialog: if select one of the rows in listcontrol, then press configure (or double click the list control's row), will load up that config file (currently just the name at the top of the dialog) for editing, and can save change to name with 'OK'. ToDo: a refresh of the row in listcontrol when finished. -channel dialog: loading/saving a test html file in HTML editor dialog and flipping to the preview tab to see the result. -channel dialog: gallery button will call up a gallery. A sample custom parser parses a regular SGML text file and loads up the example channels into the list control ready to click and enter. -main dialog: config load/saves of most main form control entries to an ini file. MJ's idea to have a box for a command to execute after plucking has been included (also a box for command before plucking). Also takes up David's idea and is structured as 2 parts: a plucker-desktop and a plucker-daemon. Comments (good or bad) are welcomed. Best wishes, Robert
Re: gluing the parts of a long page together
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. Here's what I'm thinking. Not sure whether the Palm scrollbar widget, in the way that we use it, can support this, though. We keep the current scrollbar action, but we use the paragraph count to add a scaling factor. So imagine chunk #2 of a multi-chunk page. Let's say the page contains 100 paragraphs, and chunk #2 contains paragraphs 26-50 of those 100. Currently, when we view chunk #2, the scrollbar, which goes from 0-100%, represents just the chunk, not the page. Can we scale the scrollbar, so that in this case the range of motion of the scrollbar's elevator would only be from 26% to 50% of the full scrollbar? This would then be scaled to the full range of the chunk by the appropriate arithmetic, whenever a scrollbar event was received. Where's the viewer code that interfaces with the scrolling? Bill
Re: wxPerl! YEAH!
David wrote: 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. ...and you all know how most of us feel about *spit* Perl ;-) -- MJR
Re: --update-cache option on plucker-build: what's it good for?
On Mon, Nov 05, 2001, Bill Janssen wrote: Does anyone know what good building a cache directory is? Once upon a time we didn't have a parser that could create a Palm database. What we had were some awk scripts that downloaded the html pages and converted them into their individual records (placed in the cache directory). Using a conduit written in C we created the Plucker document on the device by sending each record to it. The C version of the conduit was later on replaced by a Perl program written by Alexander Wagner. It can be found in the conduit dir in CVS. /Mike
Re: Function codes (was: Color support in CVS)
On Wed, Nov 07, 2001, Bill Janssen wrote: Yes, you're right. However, we can change that. The viewer already checks all 8 bits. Anyway, until we run out of function codes I prefer to keep it as it is. /Mike
Re: gluing the parts of a long page together
On Tue, Nov 06, 2001, Bill Janssen wrote: Are you thinking of the History and HistoryData data structures? I'm thinking about every part of the viewer that work on a one-record-at-a-time basis... Finding the next/previous segment is the easy part. Adding some kind of wrapper function that can glue together the records and present them as one to the rest of the viewer's functions is the difficult part. Show me that and you have a winner ;-) We currently have a max-paragraph-size of 1000 characters for plain text, and 3000 for HTML. *Our* parser makes sure that the paragraphs are of an acceptable size, but that is not required by the Plucker format... The paragraph count would be the rough guide, with actual lines on screen providing some fine detail within that. When you have rendered all segments you know the exact size of the page. /Mike
Re: gluing the parts of a long page together
Hi. I guess the multi-part thing is the result of the size limit on database records. So, how about using file streams? It does allow arbtrary sizes. The record only makes sense when you have records..if it is only chunks of HTML pages why bother? Max --- Michael Nordström [EMAIL PROTECTED] wrote: On Tue, Nov 06, 2001, Bill Janssen wrote: Are you thinking of the History and HistoryData data structures? I'm thinking about every part of the viewer that work on a one-record-at-a-time basis... Finding the next/previous segment is the easy part. Adding some kind of wrapper function that can glue together the records and present them as one to the rest of the viewer's functions is the difficult part. Show me that and you have a winner ;-) We currently have a max-paragraph-size of 1000 characters for plain text, and 3000 for HTML. *Our* parser makes sure that the paragraphs are of an acceptable size, but that is not required by the Plucker format... The paragraph count would be the rough guide, with actual lines on screen providing some fine detail within that. When you have rendered all segments you know the exact size of the page. /Mike __ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com
Handheld directories
Is there any dmoz.org similar organizations for organizing/maintaining a reviewed directory of handheld-friendly sites? Does anyone chat with the dmoz project or other projects, to know if they have something in the pipe? Seems like something that will become more useful in time, and the dmoz approach pretty-well rose to the top of the directories (and the openess allowed the google rankings which made it even nicer). Looking for something where they dump a structured SGML/XML file for anyone to use, as dmoz does. Something like http://www.mymobilestuff.com/palm/ , only open. Best wishes, Robert
