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
>
>
>
>
>
>