You are probably right in your suggestions. They just seem like more hassle
to me and do not meet my personal preferences. Imagine how hard it would be
to produce patch releases if I had so many different sub-directories to
worry about. Merging in changes from other developers? Managing my own
internal version control? Synchronizing changes between my notebook, work
computer and home computer?

One directory for sources does pile things up a bit but it sure simplifies
things where the rubber meets the road, development work.

IBO isn't your shrink-wrap variety product. I can't play by those rules and
keep up as aggressively as I do. I'm a hybrid between them and open source
type projects. I think my blend is friendly enough to pick up good numbers
of participants.

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Leonardo Quijano" <lquijano@...>
To: <IBObjects@yahoogroups.com>
Sent: Monday, February 05, 2001 3:47 PM
Subject: Re: [IBO] Installer for IBO


> On 5 Feb 2001, at 17:33, Geoff Worboys wrote:
>
> > Having worked with developing some aspects of IBO, I have to say that
> > I think the source files are organised very well. Now that I am
> > familiar with IBO I can go almost directly to any part of the code
> > that I want.
>
> That's it! I think i'm can do well with Delphi and installing
> components and programming. But I am not familiar with IBO.
>
> > Since most people will probably not get into the development of IBO,
> > perhaps what you are referring to is pulling the files of user
> > interest together somehow (the package projects, licence and
> > releasenotes.).
> >
> > A lot of packages have a "Source" subdirectory. The packages,
> > releasenotes etc could be in the base directory and refer to the
> > Source subdirectory. Is the sort of thing you mean?
> >
>
> Exactly. My point is that IBO would be worthless if nobody uses it
> to build applications, so we should have these people in mind,
> right?.
>
> I guess that before thinking of an installer program or somethink
> like that, we should think of getting the files organised (when I
> talked about "the code", I was talking about "the source files and
> packages and help files" :). sorry about that).
>
> Sorry if I get too picky about that, but for someone who isn't
> familiar with the components it a LOT easier to go through a
> directory with 20 files than one with 400.
>
> This is my idea of a IB_Objects organization (i'm kinda mirroring
> the Delphi organization):
>
> 1. Source Files: Here the files like 'IB_StoredProc.pas' go. Maybe
> it could be something like:
> \Source\Includes
> \Source\Implementations
>
> 2. Libraries: All DCUs (for the partial source or demo versions),
> RES files, etc.
>
> 3. Samples: WISQL, IPSamples, TDatasetSamples, Tutorials.
>
> 4. Apps: All add-on applications, third party software, etc.
>
> 5. Doc: Help files, maybe PDF manuals (very needed! free manuals
> please!), release notes, licenses.
>
> The dirs could have subdirs and everything. I'm sure it would help
> the development people too.
>
> Uhh, remember, these are only suggestions! This is what I think
> would make IBO a better product. If anyone wants to elaborate on
> this, it would be appreciated. Maybe I'll get on the installer thing
> later.
>
> Thanks,
> Leonardo Quijano
>
> >
> > > 3) A well done installer takes into consideration the
> > > people who wants to customize the installation. I really
> > > think that a program has to ask the user where he wants
> > > to put the files.
> >
> > All I want from an "installer" is the option for a pure extract of
> > files that I can install myself. Anything else I leave up to those
> > who care ;-)
> >
> >
> > > Another problem is that I can't choose if I want to step
> > > into the source code of the components when debugging.
> > > This makes debugging hard, because you have to navigate
> > > through all the internal methods of the components to
> > > reach your own code, after a Open or a Post or something.
> > > I think this should be an option.
> >
> > This certainly sounds like a worthwhile option for those simply
> > interested in using IBO but not getting involved in its development.
> >
> >
> > > Any suggestions?
> >
> > I think it remains to be seen what Jason has to say on this topic. I
> > suspect the most difficult aspect will be putting something together
> > that works smoothly with how Jason prepares his releases. The one
> > thing I dont want is to make it more difficult for Jason to maintain
> > the releases - I suspect he has quite enough to do already :-)
> >
> >
> > Geoff Worboys
> > Telesis Computing
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>