Re: [pilot-db-list] editing on a PC

[Nathan K. <na...@ve...>]

> > Yes, certainly a tool that did not throw away all the information it
> > did not understand would be a useful improvement.  I must confess I
> > haven't actually tried using palm-db-tools in the last couple years. :(
> 
> And you don't need to? Do you use a Palm regularly and is it good enuogh?

No, that's the sad part.  I don't actually use a Palm now.  I've got a
Palm III deep in my closet somewhere, but I'm doing everything
Simulators and Emulators.  I used DB on a Palm about 4 years ago, when
Tom Dyas was just developing it, and then came back to it recently
with an idea for how it could be made useful to me if it would support
better linking, automatic sorting, and multi-line record displays.

But as I started poking around, I realized the project was well on its
way to dying: there was no one left on the list who even had write
access to the SF code.  I managed to get CVS access from Tom Dyas, the
original but no longer involved author.  I started fixing things, and
only later realized that the CVS was junk and that 1.1.0 was the last
code that was ever compiled.

But I don't use it currently, since without the true link support, I
have no current use for it.  My goal is just to keep it breathing
until a stranger from the holy land appears to save it.  But who knows
when that will happen. :) (hope the hereticism doesn't offend)

> I even thought about patching pilot-db to give each record in the
> listview more than one screen line, to see longer fields without
> entering the recordview. Does this sound good? Do you have any idea
> if it's easy to do?

Great idea, hard to do because of the way records are layed out.  My
last plan (haven't thought about it for a bit) was basically to allow
"newlines" to be added to record views, such that items after the
newline would appear on a second line on a per view basis.  But this
wouldn't allow for one record to be on multiple lines.  The other way,
but probably harder to implement, would be to just wrap at the pixel
width if a "wrap" flag is set.  Likely one would also need word wrap.

> > > But when writing for a PC, we can use some higher level language. Either
> > > a general-purpose scripting language (such as perl or python),
> > 
> > Yes, definitely.  I think the best way to achieve this might be to
> > have a C language library that allows access to PDB files (ideally one
> > that actually shares most of its code with the Palm version), and then
> 
> Ideally. But is it practical? From looking at both sources, it seems it
> will require mostly rewriting at least one of them.

My assumption (perhaps unjustified) was that rewriting a PDB interface
from scratch, adding a Perl XS layer, and then writing the utility in
Perl would be easier than modifying the current db-tools code.  

Writing the entire thing in Perl (I'm more comfortable there than
Python) would probably be easier yet, but would be less generally
useful.  C is usually so much easier as an interface langauage (to
Python, to Java, etc).  

> Is the palm-db-tools project alive?  Should I correspond with them,
> or here?

As far as I know, it has no life other than here.  Neither
administrator listed is still involved, and there don't appear to have
been any changes to CVS in recent years.

> BTW, do you want to be in the "To:" line? I manually send to the list
> only, guessing it's annoying for you to get everything twice. Is it?

No, I'm happy with list only.  I added you to the first few messages
only because I wasn't sure if you had subscribed to the list yet.

--nate