Re: AW: AW: [PATCH] setup - help and local dir commandlineoptionswas"Re: Setup Command Line Options"

[Robert Collins <rbcollins at cygwin dot com>]

On Sun, 2003-11-02 at 07:11, Ralf Habacker wrote:
> I think there are some mißunderstandings. This code is *not* ready for
> reviewing. This is a step before, because while I'm working on this I have
> found some specification needs of the basic design. Let me explain what I
> mean:

Ok, whew. Thats good.

> 1. Definition of the term "engine". Actually I understand under the engine
> "all classes, functions and structures of the recently setup installer,
> which could be used are a common base to build gui or command line based
> installer." This definition may differs from your view, sow we have to
> adjust this.

That is close enough to my view - no problem there.

> >   I don't have a particular preference, but I've listed those in likely
> > order of difficulty (for migration from the current code base) - and we
> > should only use one approach. If we want to use windows messages, I
> > suspect we want to wrap the engine in an adapter - as the command line
> > tool won't have a message loop.
> > * never throws exceptions: all errors must be handled in the engine, and
> > propogated to the UI via the callback mechanism. (We need a callback for
> > engine termination.)
> >
> > The UI needs to be able to:
> > * query the engine for the available options
> > * hand user details into the engine
> > * retrieve structured data (ie. the list of sites)
> > * attempt to action a given stage of the engine.
> > * display progress of long running tasks.
> 
> 2. There are several ways to build the api of such a engine, smaller
> approachs (using mostly available code and classes) or bigger approach
> (complete rewrite), so at first I would prefer to use the current code base
> and to apply minimal changes (see below) to enable gui and command line
> applications. The above suggested design could then be implemented step by
> step (which means that the current windows message stuff will be used)

I think you'll find that that is a hard approach to take, as commandline
apps don't have an event loop unless you get into creating a hidden
window and so forth. The minimal engine API I proposed is a reuse
strategy, but various code will have to be converted as you go.

> 3. While some classes of the recent code base are gui independent, there are
> others which contains gui and non gui stuff intermixed, which should be
> cleaned up/separated before or while moving to a implementing.

Yes.

> Needed changes:
> 
> 1. defining a rule for class/file naming scheme. There some packages which

http://www.cygwin.com/ml/cygwin-apps/2003-03/msg00750.html or GUIDELINES
in the source code.

> 2. remove intermixing of GUI and non gui classes in one file

Yes - I addressed this in my roadmap.

> AntiVirus.cc for example contains a class AntiVirusPage, which provides the
> gui stuff and AntiVirus for the non gui stuff. If the functionality of this
> classes would be separated in such a manner, that the gui class(es)s contain
> only gui related stuff, the gui related stuff could be commented out by a C
> define. Unfortunally this isn't true in the most cases I found. Using this
> files in a command line tool need reorganisation of such files, which could
> be done in three flawors:
>   2.1. reassign the classes functionality and comment out gui stuff with
> #ifdef USE_GUI ... #endif and not defining USE_GUI for command line apps or
>   2.2. move the gui stuff in a new file named like the containing major
> class for example AntiVirusPage.cc for the AntiVirusPage class.
>   2.3. leave the gui file naming like it is and create a new similar named
> file for the engine containing the non gui stuff in a different dir (like I
> have done in the proof of design)

A different dir isn't needed for now. 2.1 isn't acceptable, as I don't
want to have to compile classes twice. 2.2/2.3 are essentially the same
and as long as a different dir isn't prematurely used are both fine.

> > Yes. I sketched out a fairly minimal development path to generate a
> > commandline setup that doesn't involve forking the engine code.
> > You haven't commented on the approach, rather you appear to have just
> > ignored it completely.
> >
> Why ? What is wrong with separating files into different dirs in a proof of
> design to get a better overview of the dependencies. May be you are very
> familiar with this code so you don't need something like this, but it helped
> me very much to get a clearer image about the dependencies. This is no
> forking. Also see 2. for the need of some separation.

CVS doesn't have the facilities for tracking movement of source files
properly. Until the engine is separate, and complete, we won't know for
sure what is in the engine, and whats in the UI. For instance, will we
use res.rc in the commandline, or switch to gettext? (I suspect res.rc
in the commandline). Does that mean we need to split res.rc? or do we
just ignore the overhead.

Cheers,
Rob

-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.

Attachment: signature.asc
Description: This is a digitally signed message part