pilot-db-list

[pilot-db-list] Re: Another dumb question

[<to...@ki...>]

> Ok, this is a dumb question, but I can find out how to adjust the column
> width.
>
> Anyone?

Not sure if this is what you mean, but...
You should have a little down-pointing arrow at the top right of your
screen, presumably saying "All Fields", but it might have almost any name.
 Click it; your bottom option is "Edit List Views."

Now select the view you'd been using and hit "Edit".  The numbers are the
column widths (in pixels and not hi-res aware.)  So if you set your first
field to 80, it will take half the screen. 16 holds two characters
comfortably normally.  Select that view to see those widths in the future.

Don't forget to set the database to read-write if you need to save those
changes.

   -TMcN-

[pilot-db-list] Another dumb question

[Chris T. <ct...@ST...>]

Ok, this is a dumb question, but I can find out how to adjust the column
width.

Anyone?

-----Chris

RE: [pilot-db-list] Font size problem?

[Chris T. <ct...@ST...>]

Thanks!  Fonts4OS5 is absolutely amazing.  and a lot more stable than using
the hackmaster to adjust them.

Dunno why my previous version of Pilot-DB would do the tiny fonts and this
one won't but this solves the problem.

Thanks for all your advice.

-----Chris

-----Original Message-----
From: to...@ki... [mailto:to...@ki...]
Sent: Friday, March 12, 2004 11:03 AM
To: Chris Turner
Cc: 'chessla' ; pil...@li...
Subject: RE: [pilot-db-list] Font size problem?


> Hmmm, sounds like it might be more my end then.  Am I missing a setting
> somewhere?  Also, the version I had before asked me if I wanted small
> fonts
> or large fonts.  Is there something there?
>
> Perhaps if I was able to choose other fonts, this would be solved. Where
> can
> I get this FontsOS5?  I did a search at a few places, but can't seem to
> find
> it.

I got the name slightly wrong, sorry.  It's fonts4os5, not just fonts0s5.

http://www.palmgear.com/index.cfm?fuseaction=software.showsoftware&prodID=52
925

Where is the program asking you?  I can choose off of Options - Global
Display - Select, but that just gives me four choices (which I can set via
Fonts4OS5, so it isn't very constraining.)

RE: [pilot-db-list] Font size problem?

[<to...@ki...>]

> Hmmm, sounds like it might be more my end then.  Am I missing a setting
> somewhere?  Also, the version I had before asked me if I wanted small
> fonts
> or large fonts.  Is there something there?
>
> Perhaps if I was able to choose other fonts, this would be solved. Where
> can
> I get this FontsOS5?  I did a search at a few places, but can't seem to
> find
> it.

I got the name slightly wrong, sorry.  It's fonts4os5, not just fonts0s5.

http://www.palmgear.com/index.cfm?fuseaction=software.showsoftware&prodID=52925

Where is the program asking you?  I can choose off of Options - Global
Display - Select, but that just gives me four choices (which I can set via
Fonts4OS5, so it isn't very constraining.)

RE: [pilot-db-list] Font size problem?

[Chris T. <ct...@ST...>]

Hmmm, sounds like it might be more my end then.  Am I missing a setting
somewhere?  Also, the version I had before asked me if I wanted small fonts
or large fonts.  Is there something there?
 
Perhaps if I was able to choose other fonts, this would be solved. Where can
I get this FontsOS5?  I did a search at a few places, but can't seem to find
it.

-----Original Message-----
From: chessla [mailto:ch...@co...]
Sent: Friday, March 12, 2004 10:13 AM
To: Chris Turner; pil...@li...
Subject: Re: [pilot-db-list] Font size problem?


 
 
You must have pretty good eyesight, Chris, because I have the same version
of Pilot-DB loaded onto a Sony Clie PEG-SJ20 (with the same type of hi-res'
screen) and the smallest font available at this point is pretty darn tiny
(and, no, I don't wear glasses).
 

----- Original Message ----- 
From: Chris  <mailto:ct...@ST...> Turner 
To: 'pil...@li...'
<mailto:'pil...@li...'>  
Sent: Friday, March 12, 2004 8:11 AM
Subject: [pilot-db-list] Font size problem?


Hey there,

New to the mailing list, even though I've used Pilot-DB for a while now.
But I recently upgraded my Pilot-DB program from 1.0.1 to 1.1, and some icky
things happened.  First off, the fonts got huge, and I only have three fonts
to choose from it seems.  Big, Bigger, and Biggest.  I used to have a nice
tiny fint so that fields could actually fit in the window.  I tried
downgrading back again at one point, but the fields were all acting wierd.

In addition, it's a large DB I was loading up, and it kept telling me about
experimental DB size or something?  I'm not sure what the whole message was,
because half of it was behind the graffiti pad.

I'm using a Soy Clie PEG-NX60/U, and the Pilot-DB I loaded off of the
website running this mailing list.

Any suggestions?  I want to keep using it, because it HAD been the best DB
program I'd seen for the Palm!

-----Chris Turner


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Pilot-db-list mailing list
Pil...@li...
<mailto:Pil...@li...> 
https://lists.sourceforge.net/lists/listinfo/pilot-db-list
<https://lists.sourceforge.net/lists/listinfo/pilot-db-list> 

Re: [pilot-db-list] Font size problem?

[<to...@ki...>]

Grrr... previous reply was off-list

> New to the mailing list, even though I've used Pilot-DB for a while now.
> But I recently upgraded my Pilot-DB program from 1.0.1 to 1.1, and some
> icky
> things happened.  First off, the fonts got huge, and I only have three
> fonts
> to choose from it seems.  Big, Bigger, and Biggest.  I used to have a nice
> tiny fint so that fields could actually fit in the window.  I tried
> downgrading back again at one point, but the fields were all acting wierd.
>
> In addition, it's a large DB I was loading up, and it kept telling me
> about
> experimental DB size or something?  I'm not sure what the whole message
> was,
> because half of it was behind the graffiti pad.
>
> I'm using a Soy Clie PEG-NX60/U, and the Pilot-DB I loaded off of the
> website running this mailing list.


Dunno about the fonts; on my system (UX50 with FontsOS5 on it) the font is
whatever I set the system font to.  So I can have a tiny font, huge font
or anything in-between.  And FontsOS5 lets me select a different font set
for each application, so I currently have a thinner smaller font for DB
than for everything else, so as to get more data on-screen.  (One of these
months I will get Landscape support for the UX50 in there. <g>)

On the warnings, I built a new prc without the large database warning and
mailed it to a few people.  One of them may mail it to you today or I'll
do it this evening.  A newer build without that problem is probably
available from CVS but has other significantly-modified code too.

Re: [pilot-db-list] Font size problem?

[chessla <ch...@co...>]

You must have pretty good eyesight, Chris, because I have the same =
version of Pilot-DB loaded onto a Sony Clie PEG-SJ20 (with the same type =
of hi-res' screen) and the smallest font available at this point is =
pretty darn tiny (and, no, I don't wear glasses).

  ----- Original Message -----=20
  From: Chris Turner=20
  To: 'pil...@li...'=20
  Sent: Friday, March 12, 2004 8:11 AM
  Subject: [pilot-db-list] Font size problem?



  Hey there,

  New to the mailing list, even though I've used Pilot-DB for a while =
now.
  But I recently upgraded my Pilot-DB program from 1.0.1 to 1.1, and =
some icky
  things happened.  First off, the fonts got huge, and I only have three =
fonts
  to choose from it seems.  Big, Bigger, and Biggest.  I used to have a =
nice
  tiny fint so that fields could actually fit in the window.  I tried
  downgrading back again at one point, but the fields were all acting =
wierd.

  In addition, it's a large DB I was loading up, and it kept telling me =
about
  experimental DB size or something?  I'm not sure what the whole =
message was,
  because half of it was behind the graffiti pad.

  I'm using a Soy Clie PEG-NX60/U, and the Pilot-DB I loaded off of the
  website running this mailing list.

  Any suggestions?  I want to keep using it, because it HAD been the =
best DB
  program I'd seen for the Palm!

  -----Chris Turner


  -------------------------------------------------------
  This SF.Net email is sponsored by: IBM Linux Tutorials
  Free Linux tutorial presented by Daniel Robbins, President and CEO of
  GenToo technologies. Learn everything from fundamentals to system
  =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
  _______________________________________________
  Pilot-db-list mailing list
  Pil...@li...
  https://lists.sourceforge.net/lists/listinfo/pilot-db-list

[pilot-db-list] Font size problem?

[Chris T. <ct...@ST...>]

Hey there,

New to the mailing list, even though I've used Pilot-DB for a while now.
But I recently upgraded my Pilot-DB program from 1.0.1 to 1.1, and some icky
things happened.  First off, the fonts got huge, and I only have three fonts
to choose from it seems.  Big, Bigger, and Biggest.  I used to have a nice
tiny fint so that fields could actually fit in the window.  I tried
downgrading back again at one point, but the fields were all acting wierd.

In addition, it's a large DB I was loading up, and it kept telling me about
experimental DB size or something?  I'm not sure what the whole message was,
because half of it was behind the graffiti pad.

I'm using a Soy Clie PEG-NX60/U, and the Pilot-DB I loaded off of the
website running this mailing list.

Any suggestions?  I want to keep using it, because it HAD been the best DB
program I'd seen for the Palm!

-----Chris Turner

Re: [pilot-db-list] Very large Database Error!

[<Cyb...@ao...>]

Oh hey I have a large database and I have a compiled version  which I believe 
tony made for me... Could be wrong but this does get rid of the  large 
database debug window. I will sent it to you in a email directly to you. 
John

Re: [pilot-db-list] Very large Database Error!

[Tony M. <to...@ki...>]

 On Tue, Mar 09, 2004 at 11:31:01AM -0500, Kyle davis wrote:
 >> If you're still here I'm getting the Very Large Database error on
 >> the department's TC.  Which version should I download off of the site to
 >> rectify this?
 >
 > I am still here.  Unfortunately, there is not yet a binary version you
 > can download that will get rid of that message.  The current CVS
 > version should work for you though, if you can compile it yourself.

Kyle, didn't I send you a build a few weeks ago with that fixed?  Perhaps
I have you confused with someone else.  Anyhow, if you need, I can resend
it.  Just the PRC file; all you need to do is install it over the current
one.

 > Thanks to Tom Dyas, just yesterday I got the SourceForge privileges
 > put a new release up on the site.  I was hoping I could get at least
 > _one_ other person to report a successful compile before releasing
 > something (hint hint) but maybe it's more realistic to just quietly
 > put up a binary release since more people are able to test that.

Nathan, I can try it this afternoon if you'd like; where's the build you
want compiled and tested?

   -TMcN-

Re: [pilot-db-list] Very large Database Error!

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

On Tue, Mar 09, 2004 at 11:31:01AM -0500, Kyle davis wrote:
> If you're still here I'm getting the Very Large Database error on
> the department's TC.  Which version should I download off of the site to
> rectify this?

I am still here.  Unfortunately, there is not yet a binary version you
can download that will get rid of that message.  The current CVS
version should work for you though, if you can compile it yourself.

Thanks to Tom Dyas, just yesterday I got the SourceForge privileges
put a new release up on the site.  I was hoping I could get at least
_one_ other person to report a successful compile before releasing
something (hint hint) but maybe it's more realistic to just quietly
put up a binary release since more people are able to test that.

I'm busy right now with another project, but should be able to spend
some time on pilot-db this weekend.  I'll plan on quietly putting a
CVS-based alpha binary release up on the site next Monday (March 15).

--nate

[pilot-db-list] Very large Database Error!

[Kyle d. <dav...@ya...>]

Nate,

	If you're still here I'm getting the Very Large Database error on
the department's TC.  Which version should I download off of the site to
rectify this?

Kyle

Re: [pilot-db-list] Re: pilot-db current CVS version

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

On Mon, Feb 23, 2004 at 10:59:34PM +0000, Mark Walker  wrote:
> The reset problems are only with CVS, the stable recompiled problems
> are explicitly noted as "(also stable recompile)". To summarise,
> these are plug-in button not working, colorselect returning a debug
> msg instead of working, and no Sony Hi Res.

I looked at the default configuration choices, and think that all the
problem you are seeing are due to the way I configured this test
build.  I think that all the things you mentioned are not supported in
the default build.  Obviously, (at least I hope obviously) the default
build should not have crashing bugs.  But on the bright side, the
problems you are seeing are probably not due to code changes in CVS.

I'm midway through making some other changes, so I can't build you a
different version right now.  But probably in the next couple days.
But I can help you build your own, if you run into problems :).

I also just went through and looked at all the CVS changes that Scott
checked in on his last batch before his disappearance.  There aren't
that many, and other than the partial Microtime support they seem
likely to solve more bugs than they cause.  But the problems you are
reporting would seem to give more reason to reduce the number of
config options that lead to never tested code paths.

--nate

[pilot-db-list] Re: pilot-db current CVS version

[Mark W. <mar...@op...>]

The reset problems are only with CVS, the stable recompiled problems are explicitly noted as "(also stable recompile)". To summarise, these are plug-in button not working, colorselect returning a debug msg instead of working, and no Sony Hi Res.  

NB, there are no such problems with the official release, I can use Hi Res and view five columns per screen as opposed to two columns without it.  This was a major reason for switching from SmartList, along with the database jumping in read only view (great for movie databases) and the more intelligent link fields (sorting a SmartList linked field on a 800 record database can take 40 mins, as opposed to a few mins on DB).

Best wishes.

----- Original Message -----
From: Nathan Kurz 
Date: Mon, 23 Feb 2004 10:44:16 -0700
To: Mark Walker 
Subject: Re: pilot-db current CVS version


> > The plug-in button on the database view does not work, although
> > plug-in support is compiled in (also stable recompile).  Plug-ins
> > appear to work via the menu, but causes a reset (Memo-Export, Report
> > and Information).  Interestingly, when I tried Report on a
> > non-reportable database (i.e., no integers or floating point fields)
> > it worked, but when I switched to a Reportable db it required a soft
> > reset (button still worked, so no freeze).
> >
> > The plug-in menu item on the db list view does not appear to work.
> > The only one that you should see a result from is colorselect, and
> > instead of offering colours, it gives a debug msg; giving
> > gridColorID and win Depth (also stable recompile).
> >
> > Any attempt to access Global Preferences from either view causes a
> > non-frozen reset screen or on occasions a freeze requiring a pin
> > reset.
> 
> Those sound major.  Are these with both versions, or only CVS?
> 
> > The above research was carried out on a Sony Clie SJ-33.  Maybe I
> > will give prc-tools another try and see if I can get the code to
> > compile.
> 
> I just started again with prc-tools a month ago, and found it to be a
> lot better packaged than it was a couple years ago.  If you happen to
> need Slackware packages, I've converted a number of the RPMs.
> 
> > PS, just remembered one possible answer to some problems, the file
> > sizes are approx CVS:160k and stable recompile:150k, yet the offical
> > realease is 170k, has color, hi-res etc really been compiled in or
> > is it just being reported as such?
> 
> Unknown.  I went with the default configure options, but I haven't
> tracked down what actually happened.  As a discouraging note, I've
> been finding obviously non-compilable typos in some of the less used
> code paths, so my faith in what "compiled in" means is scant.
> 
> > Best wishes.
> > 
> > Mark
> > ----- Original Message -----
> > From: Nathan Kurz <na...@ve...>
> > Date: Sat, 21 Feb 2004 13:22:40 -0700
> > To: mar...@op...
> > Subject: pilot-db current CVS version
> > 
> > > > While we are waiting for the new release if anyone wants to send the
> > > > debug msg recompiled version to me it would be much appreciated.  At
> > > > markwalkeratoperamail.com
> > > 
> > > Here's a copy of the CVS version, which is probably going to have more
> > > bugs than the current stable version---although it doens't appear to
> > > have the problem with the debug message about large databases.
> > > 
> > > Likely we'll try to make two small releases in the short future:  one
> > > a small bug fix version of the current stable version, and one alpha
> > > release based on this new version.
> > > 
> > > So trying out this version so we can catch the obvious bugs before a
> > > more general release would be a fine service.
> > > 
> > > --nate
> > > 
> > << db-en.prc >>
> > 
> > 
> > 
> > Mark Walker



Mark Walker


-- 
_____________________________________________________________
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.

Powered by Outblaze

[pilot-db-list] Memo Export!

[Kyle d. <dav...@ya...>]

Yippee!

Memo Export plugin is working for me!

However, it trucates some of the record.

Do any of our interprid developers out there have an inkling as to what
might be going on here?

Also, a big thanks goes to Nate Kurz.  He truly has put in a lot of work
recently to the pilot-db project.

Nate, you don't happen to be related to a Hank Kurz, do you?

Kyle

[pilot-db-list] Re: Any info/ideas would be awesome

[Michael A. L. <mic...@ma...>]

Monday, February 23, 2004, 17:09

Dear pil...@li...,

Regarding your message dated 22/02/04 01:59,
subject "Pilot-db-list digest, Vol 1 #859 - 4 msgs",

   I have an idea but no knowledge to develop this.

   You  see,  there  is  a  great  program  for  controlling  Internet
   bookmarks,  named  Powermarks,  by  Kaylon (www.kaylon.com). Really
   good and fast program.

   But,  of  course,  I can't sync it with the Palm, even with all the
   import/export tools it has.

   My  idea  is  to develop something similar, but that can synch with
   Pilot-DB.  So if I add a new bookmark in my DB on my Palm, or add a
   new  bm  on my desktop, both files will synch with each other and I
   can carry all those updated bookmarks.

   Just an idea.

Sincerely,

Michael A. Lees
mic...@ma...

RE: [pilot-db-list] merge tools and you

[Mike <pa...@mi...>]

You are correct as far as I know with the released version, it does a
complete replace.  Including any filters you had that the other didn't.  =

=20
I would be like a merge feature added to the existing system, not tied
directly to any app.  Unfortunately I've been out of the programming =
realm
for several years, and never made into the C worlds very far.

Yeah I am thinking of making it truely customizable so people who dont =
need
a loan section dont need it or if they need new sections that are not in =
the
default that they would be easy to add in and use. In my opinion this =
will
bring it eventually up and beyond just a movie database and could have =
many
other practical applications.=20
I am thinking the IR sync part though is going to need to be done using =
yet
another program or a modification to pilot-db to get it done as I think =
the
exchange right now is not a sync but more like a download and replace =
type.
Anyone who has exact details please feel welcome to provide any =
information.

=20

[pilot-db-list] Re: pilot-db current CVS version

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

On Mon, Feb 23, 2004 at 11:51:28AM +0000, Mark Walker  wrote:
> Thanks for sending the CVS file.  Where do you want bug reports to
> go, to you, to the bug list, or to the discussion list?  

I haven't thought about it yet.  My guess is that it's probably best
to send bug reports to the list if they are some large problem we need
to work on real soon, and to the bug tracker if they are something
that we want to remember to get back to later.  Both wouldn't hurt.
I'm posting this reply to the list so we can follow up there.

> The compile claims to have Sony Hi-Res, but it does not work.  I was
> also sent a copy of the stable version recompiled (by you?) to
> simply remove the large db msg.  It also does not work as hi-res.

For right now, it's going to be important to differentiate between the
bugs in the stable version and the bugs in the CVS version.  Sad as it
seems, the CVS version is currently an entirely unknown quantity: it
might fix some bugs, or it might introduce a lot of new ones.
Depending on which is the case, we'll either ditch the CVS version and
rollback, or start fixing the bugs in the CVS version.

> The plug-in button on the database view does not work, although
> plug-in support is compiled in (also stable recompile).  Plug-ins
> appear to work via the menu, but causes a reset (Memo-Export, Report
> and Information).  Interestingly, when I tried Report on a
> non-reportable database (i.e., no integers or floating point fields)
> it worked, but when I switched to a Reportable db it required a soft
> reset (button still worked, so no freeze).
>
> The plug-in menu item on the db list view does not appear to work.
> The only one that you should see a result from is colorselect, and
> instead of offering colours, it gives a debug msg; giving
> gridColorID and win Depth (also stable recompile).
>
> Any attempt to access Global Preferences from either view causes a
> non-frozen reset screen or on occasions a freeze requiring a pin
> reset.

Those sound major.  Are these with both versions, or only CVS?

> The above research was carried out on a Sony Clie SJ-33.  Maybe I
> will give prc-tools another try and see if I can get the code to
> compile.

I just started again with prc-tools a month ago, and found it to be a
lot better packaged than it was a couple years ago.  If you happen to
need Slackware packages, I've converted a number of the RPMs.

> PS, just remembered one possible answer to some problems, the file
> sizes are approx CVS:160k and stable recompile:150k, yet the offical
> realease is 170k, has color, hi-res etc really been compiled in or
> is it just being reported as such?

Unknown.  I went with the default configure options, but I haven't
tracked down what actually happened.  As a discouraging note, I've
been finding obviously non-compilable typos in some of the less used
code paths, so my faith in what "compiled in" means is scant.

> Best wishes.
> 
> Mark
> ----- Original Message -----
> From: Nathan Kurz <na...@ve...>
> Date: Sat, 21 Feb 2004 13:22:40 -0700
> To: mar...@op...
> Subject: pilot-db current CVS version
> 
> > > While we are waiting for the new release if anyone wants to send the
> > > debug msg recompiled version to me it would be much appreciated.  At
> > > markwalkeratoperamail.com
> > 
> > Here's a copy of the CVS version, which is probably going to have more
> > bugs than the current stable version---although it doens't appear to
> > have the problem with the debug message about large databases.
> > 
> > Likely we'll try to make two small releases in the short future:  one
> > a small bug fix version of the current stable version, and one alpha
> > release based on this new version.
> > 
> > So trying out this version so we can catch the obvious bugs before a
> > more general release would be a fine service.
> > 
> > --nate
> > 
> << db-en.prc >>
> 
> 
> 
> Mark Walker

Re: [pilot-db-list] CVS indentation strategy

[Mariusz S. <MSt...@zn...>]

	As a new (and very impressed) user of Pilot-DB, I have just subscribed
to this list, so hello all.
	The subject of coding style, as much as a choice of an programmer's
editor has been a flash point for many a flame war, yet the idea of coding
standardization is a compelling one, but a choice (any choice!) of even
among the four major (not counting variants) coding styles will leave the
proponents of the other three less happy.
	There is a solution, though, that bypasses the whole issue; namely,
source code reformatters.  One particular implementation of this idea has
served me well over the years in the Windows environment (*nix has a
similar one (part of GNU utilities) which name escapes me now).  Christophe
Beaudet' s GC (for Great Code) can be found at
http://perso.club-internet.fr/cbeaudet is NOT an open source utility, but
is free to use.  It is a very versatile command line utility that does a
near perfect (you know, like that 99% accuracy OCR) job.  No, really; It
has very few quirks, and it excels at straight C code... good enough to do
a wholesale batch convert between styles.

/Mariusz

P.S. Is there a way to get past posting to this list... Mailman comes up
short on this.

On Sat, 21 Feb 2004 20:33:11 -0800, Tony McNamara wrote:

>We'd never get a standardized indentation style working.  I personally 
>have used four spaces (no tabs) for decades, along with the old 
>structured-C style braces (braces on their own lines), and find the BSD 
>style function header line of type\nname(args){\n utterly 
>incomprehensible even though I do a lot of commercial work on BSD. 
>
>The open-source world is full of opinions, but there's no way to enforce 
>a standard when all the work is charity.  So I would say do whatever you 
>feel necessary for legibility and always use the -w parameter with cvs 
>diff.  (That ignores all whitespace differences.)

Re: [pilot-db-list] merge tools and you

[<Cyb...@ao...>]

In a message dated 2/23/2004 7:26:50 AM US Mountain Standard Time, 
pa...@mi... writes:
> My hopes is to eventually have a method where for example a 
> movie can be added to the website using imdb information and 
> then plug in a pilot and have it sync with the database on 
> the pilot as well as other pilots between themselves. Also to 
> have it where if a movie is added to a pilot all the pilots 
> update as well as the website. 
> Some of you already know that I have an extremely large movie 
> collection somewhere around 600+ and this type of system is 
> what is needed to keep me from going crazy when I go to a 
> movie store as well as when friends as me what movies I have 
> and want me to loan them one. 
> I am hoping to also have this system be able to be used by 
> both windows and linux people without much hassle. 
> Any info/ideas would be awesome. 

I think it's a great idea.  Even just the merge portion w/o the web is a
great idea.  I've been wanting the ability to merge, especially though the
IR port.  My wife and I both have palms and keep the same db's of our books
and movies, it would be great to be able to update them seperately and then
merge them together.  I include a 'own/want/loaned' column so we also list
ones that we don't have but want, if you don't already have that in the
plan, it would be a good addition.

-Mike



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Pilot-db-list mailing list
Pil...@li...
https://lists.sourceforge.net/lists/listinfo/pilot-db-list
Yeah I am thinking of making it truely customizable so people who dont need a 
loan section dont need it or if they need new sections that are not in the 
default that they would be easy to add in and use. In my opinion this will bring 
it eventually up and beyond just a movie database and could have many other 
practical applications. 
I am thinking the IR sync part though is going to need to be done using yet 
another program or a modification to pilot-db to get it done as I think the 
exchange right now is not a sync but more like a download and replace type. 
Anyone who has exact details please feel welcome to provide any information. 

RE: [pilot-db-list] merge tools and you

[Mike <pa...@mi...>]

> My hopes is to eventually have a method where for example a 
> movie can be added to the website using imdb information and 
> then plug in a pilot and have it sync with the database on 
> the pilot as well as other pilots between themselves. Also to 
> have it where if a movie is added to a pilot all the pilots 
> update as well as the website. 
> Some of you already know that I have an extremely large movie 
> collection somewhere around 600+ and this type of system is 
> what is needed to keep me from going crazy when I go to a 
> movie store as well as when friends as me what movies I have 
> and want me to loan them one. 
> I am hoping to also have this system be able to be used by 
> both windows and linux people without much hassle. 
> Any info/ideas would be awesome. 

I think it's a great idea.  Even just the merge portion w/o the web is a
great idea.  I've been wanting the ability to merge, especially though the
IR port.  My wife and I both have palms and keep the same db's of our books
and movies, it would be great to be able to update them seperately and then
merge them together.  I include a 'own/want/loaned' column so we also list
ones that we don't have but want, if you don't already have that in the
plan, it would be a good addition.

-Mike

Re: [pilot-db-list] CVS indentation strategy

[Emmanuel S. <se...@wa...>]

On Sat, Feb 21, 2004 at 08:51:22PM -0700, Nathan Kurz wrote:
>
> As I start to do things with the CVS repository, it's apparent that
> Scott and Tom had different opinions on how indent C code.  The
> obvious difference is that Scott preferred 8 space indents, while the
> rest of the code (presumably mostly Tom's) has 4 space indents.

I'm more of a K&R style (8 space indents, braces on the end of the line)
fan myself but hey...

> The current code is often hard to read, because the indentation might
> change several times withing a given function.  Personally, I prefer
> GNU style with 2 space indents, but changing over to this would be
> silly.  So what is to be done?  My impulse is to restandardize to
> Tom's original 4 space indentation.

Probably best to change to whatever is more present in the code at the
moment. Makes for less work.

> Thoughts appreciated, although practical suggestions would be
> appreciated more than blind zealotry.  Left to my own devices, I'll
> probably just start re-indenting files before I start working on them,
> checking them in, and then checking my changes in on top of that.

This is absolutely vital, IMHO.
Submit a indentation fix to CVS, noting in the logs that there has been
no code change then make a second commit with your changes.

Emmanuel

Re: [pilot-db-list] CVS indentation strategy

[<Cyb...@ao...>]

Tony has some really good insight especially on the -w parameter. 
I would say handle it like one of my jobs in an opensource company deals with 
it. 
What they do is make what is known as clean sweep and merge days every month. 
They had to deal with several open source CVS communities and also cross 
merging of thier commercial source into the open source models. 
This way people could contrib without having much war on "syntax" or format. 

However as I am just a user right now and not a contrib I press this only as 
an suggestion based on past experience. 

Re: [pilot-db-list] CVS indentation strategy

[Tony M. <to...@ki...>]

We'd never get a standardized indentation style working.  I personally 
have used four spaces (no tabs) for decades, along with the old 
structured-C style braces (braces on their own lines), and find the BSD 
style function header line of type\nname(args){\n utterly 
incomprehensible even though I do a lot of commercial work on BSD. 

The open-source world is full of opinions, but there's no way to enforce 
a standard when all the work is charity.  So I would say do whatever you 
feel necessary for legibility and always use the -w parameter with cvs 
diff.  (That ignores all whitespace differences.)

Nathan Kurz wrote:

>As I start to do things with the CVS repository, it's apparent that
>Scott and Tom had different opinions on how indent C code.  The
>obvious difference is that Scott preferred 8 space indents, while the
>rest of the code (presumably mostly Tom's) has 4 space indents.
>
>The current code is often hard to read, because the indentation might
>change several times withing a given function.  Personally, I prefer
>GNU style with 2 space indents, but changing over to this would be
>silly.  So what is to be done?  My impulse is to restandardize to
>Tom's original 4 space indentation.
>
>The arguments against standardizing it now is that the CVS changes for
>the indentation will mask the CVS changes that might give good clues
>when one is searching for the cause of a recent bug.  The argument for
>standardizing now is that we are at a point we almost all the code in
>there is suspect, so when would be better than the present.
>
>Thoughts appreciated, although practical suggestions would be
>appreciated more than blind zealotry.  Left to my own devices, I'll
>probably just start re-indenting files before I start working on them,
>checking them in, and then checking my changes in on top of that.
>
>--nate
>  
>

[pilot-db-list] CVS indentation strategy

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

As I start to do things with the CVS repository, it's apparent that
Scott and Tom had different opinions on how indent C code.  The
obvious difference is that Scott preferred 8 space indents, while the
rest of the code (presumably mostly Tom's) has 4 space indents.

The current code is often hard to read, because the indentation might
change several times withing a given function.  Personally, I prefer
GNU style with 2 space indents, but changing over to this would be
silly.  So what is to be done?  My impulse is to restandardize to
Tom's original 4 space indentation.

The arguments against standardizing it now is that the CVS changes for
the indentation will mask the CVS changes that might give good clues
when one is searching for the cause of a recent bug.  The argument for
standardizing now is that we are at a point we almost all the code in
there is suspect, so when would be better than the present.

Thoughts appreciated, although practical suggestions would be
appreciated more than blind zealotry.  Left to my own devices, I'll
probably just start re-indenting files before I start working on them,
checking them in, and then checking my changes in on top of that.

--nate