> However, I have a problem: what I'd also like to have is a simple editor
> (word processor), sufficient to take notes at a meeting or edit some
> file I'm working on.
Yet another one of my suggestions from 1999 or thereabouts that was
a couple of years ahead of it's time; being able to add notes to a
particular selection or Plucker database itself. =)
> So, I have a proposal: I'm offering a $100 bounty for someone who will
> create a simple GPL'ed basic text editor for PalmOS by May 2003 that can
> do the following:
Is that all? $100.00 by May? Finished version? Or first cut?
> * Edit Plucker files and Aportis DOC files (Palm).
Will you provide Aportis DOC specifications? What about the other 17
Palm DOC formats out there? No doubt someone will want to have it support
their format of choice, so that means modular, which means separate dlopen()
segments, or "plugins", like we do with SysZLib (and another one of my very
very very early suggestions for Plucker).
> This should have the effect of editing at least
> HTML and ASCII text files (as stored on the host system).
Will you input the manual < and > characters yourself?
Or do you want buttons to do that for you? What about
bracket/element completion?
Will this only do HTML? Or also XML? (i.e. tag validation).
Will you be importing files into this, ready-for editing, and then
exporting back out to the desktop? Now you'll need a desktop conduit
to pull the data back off.
> I don't need Microsoft Word compatibility, but I bet some
> people would like room so it could be expanded to that later.
Modular, and now we're talking compression also, to save space. Text
compresses really well.
> * Be able to round-trip documents (i.e., it must be possible to
> take existing HTML and ASCII documents on a host system,
> transfer them to the Palm, edit them, and bring them back,
> with no loss and the only changes made are those that are
> made by the user on the Palm.
Desktop conduit. Also GPL? Proprietary? Any preference of tools or
portability for host-system builds? Must this run on Win32 for example?
> * Full-sized keyboard support (inc. arrow keys, scroll keys).
Which keyboards do you want to support? Which drivers are you
targeting? The PPK? Others?
> * "Normal" editing: cut, copy, paste, stylus to move cursor and select
> text, page up/page down, delete key, typing puts text there.
This is a built-in for text entry fields.
> * A find command, at least one that searches the current "page".
You can probably use the built-in Find function for this, but as you
know, Plucker cannot use that, so if you're talking about using Find on
Plucker documents also, now we have to use the Plucker facilities.
> * Transparent support for single files up to 1.2 Meg in size.
Do you know of any editor at all in existance that can do this?
You'll need 3.6 megs to open, edit, make changes, and save that file, if it
is 1.2 megs to start (1.2 on ROM/Flash/VFS, 1.2 for temp file, 1.2 for new
file, deleting original and temp upon compare and save).
Based on this, you'll no doubt need VFS support. Now we need to know
who's vfs implementation you want to support? What are the target storage
mediums and PDA handhelds you want to target? Sony? Palm? Handera?
Handspring? Are you talking Springboard and MemoryStick also?
> Even Plucker's current 32K blocking would be problematic for
> files of that size. It can use blocks internally.. they just need
> to be invisible to users.
32k in Plucker expanded into memory is... ~60k, which is a Palm
limitation, not a Plucker limitation.
> * Be able to edit HTML directly (i.e., without an "HTML view"),
> if I want to work in the HTML for a while and then switch back.
An, now you're talking macro keys, tag linking, validation of tags
(i.e. "You have 10 unclosed tags").
> This thing doesn't have to be in Plucker itself, but I'd like them to
> work together.
Actually, to meet your deadlines, it probably *SHOULD* use Plucker,
out of the box, and use an external link to this "plugin" for editing. Not
hard to implement, but would require changes to Plucker itself (i.e. dynamic
menus and forms so that "detection" of the PluckerEditor.prc plugin can be
detected, and relevant entries loaded in the menus of Plucker.
> I realize $100 isn't much, but I don't have a lot of money, and I hope
> that others will add to the bounty. And if someone was thinking of doing
> this anyway, here's incentive.
Well, let's get the FRS (Functional Requirements Specification)
nailed down, and "virtually" signed off, and task people with hacking on it.
Is this deadline to meet your own internal goal? Or just a "challenge" goal?
As you can see, I've done this many, many, many times before. Making
sure we have all of your requirements up front, and that goals are clearly
defined, elimiates "scope creep".
> Anyone willing to add to the bounty? Or even better, willing to do it?
I can help, slightly, but won't be able to do the bulk of the work.
I have some pretty pressing deadlines to find a job, and get this latest
pilot-link release out, before I can look away and dig into other projects.
/d
