This is the mail archive of the
mailing list for the Cygwin project.
AW: AW: [PATCH] setup - help and local dir commandlineoptionswas"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: Sun, 2 Nov 2003 14:47:14 +0100
- Subject: AW: AW: [PATCH] setup - help and local dir commandlineoptionswas"Re: Setup Command Line Options"
> > 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.
agreed, I assumed that the event loop has to be in the gui stuff,
> > 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.
> > 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
> 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
> 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
1. This may a reason for not separating, but there are several solutions
a. you can add a move hint like "class AntiVirusPage moved to/from
AntiVirusPage.cc" in the related files log message
a. we are already forced yet to move classes to other files like the class
AntiVirusPage and other.
> 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.
The only usable parts from res.rc are the stringtables, but this isn't very
much, so this duplicating may not be a major problem.
Regardless of the used way I think we should define a generic function to
retrieve language strings, so that we can implement whatever we want.
Additional there is the question, should the engine code reports clear text
messages or only return values, so that the message text in only located in
the frontends. Providing engine related error messages in the engine may
reduce duplication. What about let returning the engine error codes and
providing an additional engine function to retrieve the error messages ?
gettext versus res.rc - I have to think a little more about this.
2. In general this are reason to separate very early because it enforces the
developer to think about the context where the code belongs. At first this
requires a little more efforts to get thins running, but I think this is
worth while. (This is exactly the reason why I have moved the files a
different dir in the provided sources, I have already moved about 80% of the
So do what you like to say ? Should we separate now or not ?
Note: If the separation comes is suggest to use at first a directory for the
engine with a static library and/or a dll, one for the command line tool and
one for the gui. The gui dir could be added later and would contain all
source files which are left in the current setup dir after separation.
Note2: While I'm writing this, a thought comes into my mind that another
possible engine name may be "backend" - while the gui and command line tools
are the frontends. What do you think ?