Menu
▾
▴
filecaddy-developers
|
From: Matthew B. <mb...@ky...> - 2002-08-09 12:11:55
|
This time I'm asking before blundering ahead ;) Since FileCaddy no longer uses any Handspring-related APIs (there was no practical reason for me to inflict them upon my system in the first place, if you think about it ;) is there a way to avoid using the Plam-DefaultVars.make and Palm-CustomVars.make files? I.e. just have m68k-palmos-gcc IN THE PATH, instead of having a makefile that defines the location. After installing the new Prc-tools package, I encountered countless errors where I had to shift files around, or tweak them to get them working with FileCaddy again. Not to mention Sony SDK... That's another thing - Sony High-Resolution support. Seems easy enough to add (and has been requested for VFSBrowser in the past) so I've added it to the to-do list. -- Matthew (Darkstorm) Bevan mb...@ma... Margin Software, NECTI. http://www.marginsoftware.com Re-inventing the wheel, every time. - After your lover has gone you will still have PEANUT BUTTER! |
|
From: David J. K. <dke...@ko...> - 2002-08-09 14:43:09
|
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.
Keep the makefile using things like CC, PILRC, PALMRC, and OBJRES just as it
does now and then document at the top that the user has to define those
environment variables to match where he/she has the tools installed before
running the makefile. Move any non-tool env vars that Palm-DefaultVars and
Palm-CustomVars set up (and that we still need) into the top of the
makefile. Then it's trivial to set up a little "fc-dev.setup" script that
sets all the correct environment variables whenever you want to work on
FileCaddy (and if you want to "export CC=m68k-palmos-gcc" and then rely on
PATH to find it you can).
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.
--
- Dave Kessler
President - Kopsis, Inc.
http://kopsisengineering.com
On Fri, Aug 09, 2002 at 05:13:21AM -0700, Matthew Bevan wrote:
> This time I'm asking before blundering ahead ;)
>
> Since FileCaddy no longer uses any Handspring-related APIs (there was no
> practical reason for me to inflict them upon my system in the first
> place, if you think about it ;) is there a way to avoid using the
> Plam-DefaultVars.make and Palm-CustomVars.make files?
>
> I.e. just have m68k-palmos-gcc IN THE PATH, instead of having a makefile
> that defines the location. After installing the new Prc-tools package,
> I encountered countless errors where I had to shift files around, or
> tweak them to get them working with FileCaddy again. Not to mention
> Sony SDK...
>
> That's another thing - Sony High-Resolution support. Seems easy enough
> to add (and has been requested for VFSBrowser in the past) so I've added
> it to the to-do list.
>
> --
> Matthew (Darkstorm) Bevan mb...@ma...
> Margin Software, NECTI. http://www.marginsoftware.com
> Re-inventing the wheel, every time.
>
> - After your lover has gone you will still have PEANUT BUTTER!
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Filecaddy-developers mailing list
> Fil...@li...
> https://lists.sourceforge.net/lists/listinfo/filecaddy-developers
|
|
From: Matthew B. <mb...@ky...> - 2002-08-09 16:17:13
|
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.
|
|
From: David J. K. <dke...@ko...> - 2002-08-09 22:42:32
|
On Fri, Aug 09, 2002 at 09:18:43AM -0700, Matthew Bevan wrote:
> Well said! The API isn't that bad, as far as I can tell.
Take a look at Handera's SDK for the way that high-res on PalmOS *should* be
handled.
> 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...
Just remember that "cvs add" is non-recursive :) Have a great weekend!
--
Dave Kessler
President - Kopsis, Inc.
http://kopsisengineering.com
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X