Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2000:
[Freeciv-Dev] Re: Windows COM client

[Freeciv-Dev] Re: Windows COM client

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Arlo Belshee <arlo.belshee@xxxxxxxxxxxxxx>
Cc: Freeciv dev <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: Windows COM client
From: Thue <thue@xxxxxxx>
Date: Tue, 21 Nov 2000 22:10:28 +0100

On Tue, 21 Nov 2000 20:57:40 Arlo Belshee wrote:
> >  > So now I would like to program the Windows client. For this, I'd
> like
> to use
> >  > a simple multi-threaded component architecture, using Visual Basic
> for
> the
> >  > GUI, C++ to write certain GUI components (like the map and backside
> >  > drawing), and C++ for most of the back-end. However, this is a great
> >  > division from the direction dictated by the current codebase. My
> intention
> >  > would be to program something entirely new that integrates with
> existin
> >  > systems but is more flexible and extensible. I don't know this
> audience: are
> >  > you receptive to such a change in direction? This definately goes
> against
> >  > the way that things have been done, so what are the reasons that you
> used to
> >  > choose to do it this way? I can construct several arguments for an
> alternate
> >  > approach, and would be happy to if asked (some interesting new
> directions
> >  > for the project); I want to make sure that we choose to do this
> correctly.
> >
> > Freeciv would certainly lost its portability because VB is
> > windows specific.
> > There are much things in the client which are done in a general way.
> > After I had ported update_map_canvas I was surprised that the map was
> > shown correctly. Units were drawn. And also special terrains. I see no
> > sense in doing such a big change.
> That is a good point, and gets to what I want to do with a component
> architecture. The architecture that I stated above was for the Windows
> client. Overall, there would be a set of components that do things in a
> general way (basically wrap portions of the existing code-base in
> individual
> components that link together at run-time). Over time, we can then
> replace
> individual pieces with components that exhibit a more specific behavior
> on
> platforms that support it. Thus, we have one GUI component for the client
> that does things using gtk. We add another one that does things using
> win32
> GDI, and potentially another one that uses DirectX. The two Win specific
> components exhibit the Windows look and feel, while the gtk one has a
> more
> generic or a more linux look. The Win components would likely be written
> in
> VB (because that's easier for the target platform), and would not be
> intended to be portable to all platforms. Then, when we want to port to a
> new platform, we just use the general components (without changes) for
> most
> things, and rewrite those that are platform specific. For example, going
> to
> Mac would just require a re-write of the drawing component, and use the
> rest
> of the components unchanged.

That is really how it allready is - The common code is in /client, the gtk
specific code is in /client/gui-gtk, the amiga specific code is in

> The main purpose is to be able to take advantage of platform specific
> functionality, as detected at runtime, while still having generic
> functionality that will work everywhere (for example, use the Pentium
> instruction set optimizations only on machines that have Pentiums, and
> un-optimized code elsewhere, or write one set optimised for Intel and
> another for AMD, or ...). The primary goal is to have run-time selection
> of
> capabilities, and to have smaller code chunks to work with. I'd much
> rather
> write a networking unit than write the networking in a monolithic
> application. I'd also rather seperate the openGL version from the GDI
> version entirely, rather than trying to write one that can do both,
> depending on what is available.
> Arlo

Fx the networking code really is very seperated already...


[Prev in Thread] Current Thread [Next in Thread]