David A. Desrosiers - thanks for your comments!!!
Let me try to respond..
>> 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?
I don't know what "finished" means in an open source project :-) :-).
I mean "meets requirements, and is reliable".
Please note that it's May *2003*, not *2002*; my deadline is 15 months
away, and I mean the END of May 2003. It's an arbitrary "challenge"
deadline, just so that I don't have to pay someone who does this
50 years after I could have used the result. Beating the
deadline is quite acceptable :-).
And I know, $100 is not a lot. I wish I could offer more, I'm
stretching with the $100. However, if I just posted
"please make me an editor", most people would probably say
"sounds good, please submit the patch." And they'd be right.
So, here's something that's not as good as code, but maybe someone
can turn it into code.
>> * Edit Plucker files and Aportis DOC files (Palm).
>
> Will you provide Aportis DOC specifications? What about the other 17
>Palm DOC formats out there?
Feel free to support other formats, but I don't need them.
Aportis DOC's format is documented; I believe the CSpotRun or Weasel Reader
web sites will give you the information necessary.
>> 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).
I'd like to be able to edit HTML in two ways (a two-mode editor):
1. As raw ASCII text, when I'm doing lots of HTML tricks.
In that case, I want to enter the < and >.
2. As a simple font-aware word processor, in which case I want to see
bolded text (not <b>), italics, and headings with different fonts.
In this mode, if I select text and type control-B or press the
"bold" button, it becomes bold (and the underlying representation
adds <b>..</b>, so there it DOES do tag completion).
Here the connection with Plucker becomes obvious - to make this work,
I think the rendering system for Plucker would need to be reused.
When editing HTML, I'd like to be able to switch between the modes
while still on the Palm. If that's too hard, I can back that off
entirely. I just find that I often need to edit in two different ways,
sometimes fiddling with tags (e.g., complex HTML, XML, Docbook) and
sometimes NOT wanting to fiddle with tags (e.g., basic notes).
> 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.
Yes. That's what I meant when I said "round-trip".
That may mean a small change to the Plucker fomrmat may be needed,
enough to optionally insert data that's not used for HTML display but
is needed so that data isn't lost when it's sync'ed or beamed
to the outside world.
> Desktop conduit. Also GPL? Proprietary? Any preference of tools or
>portability for host-system builds? Must this run on Win32 for example?
GPL. I use both Win32 and Linux, so I'd want support for both.
I would expend that the conduit (the, er, "unparser" :-)) would be
easy to make portable. Requiring Python or Perl would be fine.
>> * Full-sized keyboard support (inc. arrow keys, scroll keys).
>
> Which keyboards do you want to support? Which drivers are you
>targeting? The PPK? Others?
At the least, the "Palm Portable Keyboard" (PPK) connecting to
a Palm m125... which by coincidence describes my setup :-).
Others optional, though I hope the code could be tailored to support 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.
Text entry fields, to my knowledge, can't do the multiple fonts,
and they're limited to 4K. Won't work.
>> * 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).
I can back off the filesize somewhat if necessary, but large files
are actually my biggest problem and the prime reason I starting
thinking about a bounty. I can edit NOW using Memopad and ZDOC,
but they're hostile to my large files.
I think you can work with only two copies ("original" and "being modified"),
and there's no need to leave everything always decompressed.
> 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?
I need help in defining this. Short answer: it needs to work
at least on mine, which is a Palm m125 (8M to start). I'm getting a 16M
expansion card for it.
>> 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.
That's fine. I just don't want to SEE the block boundaries - hide them!
DOC readers, for example, can seamlessly show files more than a megabyte,
although the individual records are obviously a little smaller.
>> * 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").
Don't need macro keys or tag linking.
The rules for switching back could be draconian if necessary.
If it's truly hard, that requirement could be dropped or weakened.
Fundamentally, I want a single editor that handles the different
kind of texts I write; some are on-the-fly documents where I'd like
the font stuff, and some are complex documents where I actually
want to see the 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.
That'd be great. My apologies, I don't know the Plucker "powers that be",
so I don't really know what it all entails. Hopefully I will become
enlightened :-).
>> 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?
Absolutely. I'm hoping to hear from this list who's actually
interested, and nail down the requirements through interaction with
him/her/them. If you could help me make these requirements more
precise, that would be great.
The deadline is just a challenge goal, and given 15 months,
hopefully it's not too hard (I'd really like it sooner!).
I can flex a good deal on the requirements, too. Basically, I want a
text editor/simple word processor, sortof like Wordpad, that will meet
my needs and be general enough that others will want it too.
Of course, if there's something already out there, let me know!!
