architectural proposals for our "barn"
Posted by: Bowerbird <Bowerbird@...>
i would apologize for the length of this post,
but thanksgiving is a time for excess, is it not? ;+)
happy thanksgiving everybody!
-bowerbird
***
people suggested that we make our joint program
a _tool_,
and i think that's an _excellent_ idea.
heck, we might even wanna _name_ it that -- "tool".
(or "barn" -- since i called this a "barn-raising".)
let's see, i'll call it "tool" for the rest of this post...
***
tedd said:
> I would rather see 50 programs that do just one thing
> than one program that does 50 things.
tedd then explained that he had this preference because
50 programs would get more exposure than one would.
but i guess i'm facing in the exact opposite direction --
i've been thinking of a single program that does 50 things.
i know i'd love to have one application that did 50 things,
so i could get rid of the 50 separate programs i'm using now.
sort of like the "swiss army knife" approach. (thanks, ross!)
a slogan:
"it seems like whatever i want to do, 'tool' is the program i use!"
***
what i thought is that someone will create a skeleton project,
one which will contain all of the p.g. filters.
then, each of us can assume all the filters and global variables,
and write an include file that would perform 1 of our 50 tasks.
i do know that having all those filters does a lot of the work,
so each of us can just focus on the specific guts of our sub-task,
without all the hard work of creating a whole application around it.
and i think this p.g. approach is what most of you also had in mind,
but i don't actually use p.g., so if i mess up factually, correct me.
anyway, somebody would fold all the includes into the .main master,
which of course would then be responsible for coordinating them all.
(i suggest david for that, because he's close to the horses' mouths,
if you know what i mean, since we've been using this "barn" analogy.)
for simplicity, we might want to encourage local-mode functions.
but i almost never use them, so i'm not the one to suggest it.
and, of course, each contributor gets a copy of all the includes.
(making it easy for us to significantly improve our own apps!)
***
as for distributing this source code to non-owners of futurebasic,
i can see costs and benefits of doing it, and of not doing it.
i'm certainly not afraid of someone porting it to c++ or whatever.
on the contrary, i would _relish_ that.
first of all, that translation task is going to be a good bit of work.
in fact, it might even be easier to just write it from scratch.
second, the futurebasic version of the program would be better!
it would run faster.
it would use less memory.
it would have a smaller footprint.
it would run on older versions of hardware and software.
third, people could view the source for both versions,
and ask themselves which one _they_ would rather maintain.
on the whole, everything about that comparison favors our favorite.
but still, if our futurebasic version of "tool" is the only one out there,
it will obviously better serve our purpose of promoting futurebasic.
besides, if we distribute the source code only to futurebasic owners,
then that becomes an additional incentive for people to _buy_ f.b.
generating overall awareness is one of our goals, sure, but our priority is
stimulating a purchase that puts money into stazsoftware pockets, not?
(heck, programmers might buy f.b. just so they get the source for "tool"!)
so i think we should bundle the source only to f.b. buyers and upgraders.
or, to be even more conservative (and to collect even more functions),
we could limit it to only those people who contribute a function.
(after all, it's really a very inexpensive price to pay, isn't it?
and it's an acknowledgement that we are part of a community.)
***
and this point brings us to another important matter:
namely, the question of our primary objectives with "tool".
to sum it up in a sentence, i think:
we want to put "tool" on every mac in the universe.
why?
1. so we become famous, of course. ;+)
2. and, oh yeah, so people get exposed to futurebasic, so
3. stazsoftware will sell more copies.
in this respect, i think we should make "tool" freeware.
this will help insure that it gets put on every mac out there.
(another route would be to get apple to decide to bundle it.
if they paid stazsoftware $.02/copy -- just two cents per copy --
that would be $100,000 for the first 5 million copies they'd need.
i assume that would be a nice chunk of change for stazsoftware.)
anyway, then we pack "tool" with as much power as possible,
to make sure that it becomes an _often-used_ program.
there are some programs that i put on _any_ machine i use,
because my work-flow is so enhanced by their presence that
they've become necessary. that's how we want "tool" to be.
if "tool" is an _often-used_ program on _every_ mac,
people will become familiarized with futurebasic,
and that will eventually lead to more sales of the product.
i'm imagining a fancy splash that says something like:
"tool"
freeware created by
the joint futurebasic programmers group
to help promote
*** futurebasic ***
the awesome basic compiler for the mac
that brings basic into the 21st century.
we've got graphic-talented guys on the list who'll make it look nice.
oh, and tedd... photoshop was programmed in macapp, by
thomas knoll, john knoll, mark hamburg, steve guttman, and russell brown.
and the precise reason that i actually _know_ those facts is because
it says so right on the photoshop splash, at least on my old v2.0.1.
:+)
we'll go even further, making futurebasic the focal point of our splash,
so people know that futurebasic is the compiler used to make "tool".
then, the functionality of "tool" will be what helps sell futurebasic.
***
also, of course, "tool" should contain a multi-media presentation
that showcases all the great things about futurebasic.
this presentation should be one of the 50 "sub-tools" in "tool".
(or should that be "50 tools in the barn"?)
(or we could call the program "toolshed", and the sub-parts "tools".)
(or the "garage"? -- hey, i like that one -- "tools in the garage".)
so, possible component: multi-media ad for futurebasic.
(the text on the "100-reasons" web-page is a good start for this.)
even if a presentation about f.b. isn't that useful as a "tool",
we can _make_ it useful by making it a screensaver, for instance.
so, possible component: screensaver.
besides, if it's eye-catching, people will view it for entertainment.
another embedded presentation could tell people who _we_ are,
what applications we've created with futurebasic, our u.r.l.'s,
and, for instance, our rates for custom programming in futurebasic.
so, possible component: multi-media ad for us,
including those graphic-talented guys who make it look nice.
oh, when i say multi-media, i really only mean text and some graphics.
one of futurebasic's best aspects is that it creates small programs.
in order to highlight that, our app should be as small as possible,
so that precludes big graphics, sounds, etc., that bloat the size.
***
there was also discussion of whether we should build
a tool for programmers or for the general public.
i think our objective should be _both_!
we should include enough general tools to make the program
valuable and necessary to everyone in the mac universe,
_plus_ programmer tools that make it a must-have for them.
for example, "tool" might do various types of sorts for general users.
then, for programmers, it might also spit out various sort functions.
(i know i couldn't find my quicksort function when i looked recently.)
***
i personally _love_ the idea of (some of you!) doing some cdef's... :+)
i can give you the exact specifications i'd like to have followed!
in fact, what about a cdef-generator, where i punch up what i want
and it spits out the futurebasic source code to create that cdef?
in my opinion, that would be a really neat include-file for "tool"...
so, possible component: cdef-generator
***
as for other tools, i was looking for a "str#" editor just today,
and couldn't find a decent one. (and, yeah, i seem to remember that
there's a good one right in p.g., but i've lost my f.b. installer disk #1,
so i can't re-install p.g. on my system to use it, or even take a look.
i ordered another from staz, but the snail won't arrive until monday.)
so, possible component: str# editor
(the idea of a general resedit replacement seems ambitious to me,
but a str# editor is easily realizable, as are other specific editors.)
***
other possible components suggested by various people:
launcher, draw program, type & creator (and everything else) changer,
quicktime editor, scheduler/planner/calendar, graphic converter
heck, if we just have the functionality from all the sample functions
that come included with f.b., we'd have a super-duper app just like that.
also, if someone doubts their ability to write a suitable contribution,
well... adapting some of this existing code would certainly qualify!
for instance, one could easily build in the code from the file-viewer app,
as well as the text-editor app and the draw program that comes bundled.
plus! add in the genius tweakings of staz and andy to finetune the code,
and our beast would undoubtedly be an elegant screamer speedwise. wow!
***
tedd's reason for preferring 50 programs instead of just one was that
we need to keep a constant presence in cyberspace, and he is right on.
so we should regularly release new versions, with new capabilities.
we could start slow, with a few good capabilities, and build on it,
so new versions appear often on the "new" list on shareware.com, etc.
dabbs seemed to take this approach on a.o.l. perhaps he can brief us on it.
speaking of dabbs, i think he's released the source code for an icon editor.
so, possible component: icon editor
and if dabbs wanted to donate some calendar functionality as well,
that'd be cool. he wouldn't want to cannibilize his own commercial app,
of course, but he'll be the one donating the code, so he can make the call.
one trick would be to put some basic useful functionality into "tool",
and then use that to stimulate curiosity about your more-advanced app.
(and remember, this "demo" part will be on every mac in the universe!)
another example would be mel putting some internet-config smarts in.
and finally, another good example of "start-small-and-build-up"
could very well be the database component. as bill said:
> On the other hand, even a _simple_ (but reliable & extensible) db would
> probably satisfy 80% of the demand, and would be pretty easily done!
> You could even just "grow" SimpleBase a bit, if Frank concurred...
of course, an advantage of starting simple is that we can get it out fast,
perhaps fast enough to prime some interest for the upcoming version #3.
***
in general, i wasn't thinking of each of us writing something from scratch.
rather, my thought was that each of us could donate a function or two
(that has already been written) to create each of the sub-tools in "tool".
so, who's got what?
let's get this ball rolling... ;+)
-bowerbird
bowerbird@aol.com
p.s. i give thanks for the futurebasic mailing list -- my _favorite_ e-mail!