[Freeciv-Dev] Re: Windows COM client

[Thue <thue@xxxxxxx>]

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
/client/gui-mui.

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

-Thue