This is the mail archive of the
mailing list for the Cygwin project.
AW: AW: [PATCH] setup - help and local dir command lineoptionswas"Re: Setup Command Line Options"
- From: "Ralf Habacker" <Ralf dot Habacker at freenet dot de>
- To: "Robert Collins" <rbcollins at cygwin dot com>
- Cc: "Cygwin-Apps" <cygwin-apps at cygwin dot com>
- Date: Sat, 1 Nov 2003 21:11:14 +0100
- Subject: AW: AW: [PATCH] setup - help and local dir command lineoptionswas"Re: Setup Command Line Options"
> On Sat, 2003-11-01 at 12:16, Ralf Habacker wrote:
> > Rob
> > > I need more time to think about what you have written and how to
> > > start with which class,
> > >
> > I have take some time to inspect how it could be go and have build a
> > testcase to see what kind of api is needed. Please note that I am
> > concentrated only to get a command line version initial running, so I've
> > removed the not needed gui stuff. Currently I can't send in a patch for
> > this, because I have splitted the relating engine files into subdir and
> > build a static library to allow file including checks, although
> the binariy
> > and sources could be downloaded here:
> > binary http://kde-cygwin.sf.net/snapshots/enginetest-0.0.1.exe.
> > source http://kde-cygwin.sf.net/snapshots/setup_new-0.0.1.tar.bz2
> Sounds like you've gone too far too fast. I don't have the time to
> review a non-delta set of changes.
>Particularly ones that throw away a lot of code (the gui) that -must- be
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
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
> 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)
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.
1. defining a rule for class/file naming scheme. There some packages which
are written lowercase (1) and some mixed (2). What's the prefered one ?
some examples (this is mainly for me to learn what the current strategy
type class file
1 packagemeta package_meta(.h|.cc)
1 packagedb package_db(.h|.cc)
2 UserSetting UserSetting(.h|.cc)
2 AntiVirus AntiVirus(.h|.cc) (see topic 2)
AntiVirusPage AntiVirus(.h|.cc)(see topic 2)
2. remove intermixing of GUI and non gui classes in one file
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)
Here a general decision of the maintainer is required.
There may be more issues, but I think for now is is enough and I'm waiting
for your comments.
> 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.