Re: [Filecaddy-developers] Large Makefile changes...

[Matthew B. <mb...@ky...>]

On Fri, 2002-08-09 at 07:43, David J. Kessler wrote:
> I'm totally ok with ditching Palm-DefaultVars.make and Palm-CustomVars.make
> but I'm not ok with hard coding "m68k-palmos-gcc" (or any other specific
> executable names) in the makefile and relying on the PATH. Using the PATH
> environment variable (instead of specifying the full path to the executable
> in the command) significantly slows down builds on some systems.

Understandable, especially under Windows ^_^;  I was tired as of that
writing (and still am... 12 hours and going weakly)  Of course, the
variables can be overwritten by global variables or a defaults.make file
in the build directory.

> As for the brain fart that Sony calls the Hi-res API (and here I thought
> they couldn't do worse than they did with VFS), make sure anything you add
> for that (including #includes) is totally conditional. No one should be
> forced to have the Clie SDK in order to build FileCaddy. We should probably
> also consider two releases once that's in place so that non-Sony users don't
> have to deal with the bloat that the hi-res API causes.

Well said!  The API isn't that bad, as far as I can tell.  Preliminary
support is now there - it sets the graphics mode and plays nice.  Check
out the feature request for the complete to-do list :D

The only reason I was able to get started at all was because I needed to
fix a client's Clie T615C, and had it overnight.  I'll try continuing
with the Sony Palm Emulator.

High resolution functions are all wrapped in #ifdef's and if (
HiResSupport ) statements.  There are several new global variables (some
nessicary, marked by *'s, some not.)

*Boolean        HiResEnabled = false;
*UInt16         HRLibRef;
 UInt32         ScreenWidth = 160,
                ScreenHeight = 160;
*UInt32         PalmOSVersion;

And some #defines of PalmOS version codes in Globals.h.  The
PalmOSVersion stuff is to place wrappers around 3.5+/4.0 explicit code
(i.e. WinScreenLock).  I've sloved the flickering problem, the easay
way.

A better way would to capture how many lines to scroll (using jog-wheel,
or scrollbar) and move the bitmap up that many lines, then only redraw
the -new- items.  That would speed up the refresh immensely.

I've also created a few new images - a home icon and some
higher-resolution application icons.  None of which have been included
in the application, but they're there.  Now to add them to CVS...

-- 
Matthew (Darkstorm) Bevan       mb...@ma...
Margin Software, NECTI.		http://www.marginsoftware.com
	Re-inventing the wheel, every time.

 - You will always find something in the last place you look.