[Freeciv-Dev] Re: Windows COM client

["Arlo Belshee" <arlo.belshee@xxxxxxxxxxxxxx>]

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

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