[CF-Devel] sdl client

[Mark Wedel]

Tim Rightnour wrote:

>
     
      That said, I'd rather not see the gtk client go away completely.  Perhaps we
     
     >
     
      mark it as being totally unmaintained, and not guaranteed to work, and stop
     
     >
     
      releasing it.  But if someone wants to hack on it, leave it in CVS and let them
     
     >
     
      do so.
     
     
 Thats the big gotcha. If it is maintained by anyone and kept reasonable up to
date, then it basically remains 'supported'.  I can see the circumstance where
otherwise, people are happily using the gtk client, server is updated and gtk
client breaks.  Those users will probably whine to the server admin that things
stopped working.

 This could be something other than gtk - with open source, anyone could
develope some new compatible client using the toolkit of the month that works
until protocol or other changes are made on the server.  There is no solution to
this client proliferation other than to say 'only this client is supported. 
Anything else may or may not work - use at your own risk'.  But this could end
being unpopular if the other client is more feature rich or better suited to a
users needs (some people don't want the xbm graphics to go away for example
because those images work better for the hardware they are using).

 I do agree 100% that the current situation with several different clients,
distributed in different cvs areas, is completely non sensical.

 But some various notes in no particular order:

I fired up the sdl client, but it didn't support flat view, and I really didn't
feel like fussing with the iso graphics at that point, so I really can't comment
much about it.  But I will say that there can be a very large difference between
it being 'functional' and 'as good as ...'.  I will say that in my current work
with the gtk client, I have better isolated the sdl stuff, so it should be
pretty easy to take the flat map generator.

One reason the gx11.c file is so huge is the large number of configurable
options, both via command line and menus.  That file could be greatly simplified
by removing that, but that may be unpopular.

Related to performance, performance of the sdl client on a wider variety of OS
is probably desired.  I know it has been optimized for linux and windows.  But
performance on solaris, irix, over remote display, etc, might be of importance. 
They way SDL deals with images (via direct pixel manipulation) is probably
really terrible if doing a remote display - probably much worse than using the
native x pixmaps (not necessarily xpm - just data converted to local images
stored on the server).  Once again, this may be an issue which you say 'too bad'
or 'use unsupported client'.  But the problem is that if this gets said too
much, then people may very well develope 'unsupported client' and not
develop/work on the sdl client.

There is the general problem with open source/volunteer development efforts. 
People work on what they work on.  It can be very easy to say that the sdl
client is the 'official' client, but if some people really rather work on the
gtk client because they like it better, what can you really do about it?  Given
that basis, I tend to work on the gtk client and not others because it is the
one I use and just from a very cursory look, looks much more feature rich than
the sdl client.  This even though I agree that one client is a good thing - like
most developers, I'm going to develop for the features that I want/find useful.

 I will say that there are probably several things that can be done to make
'support' of different clients better:
1) Split the current main (unix) client into sub directories based on each
module.  Make one of those common, which has the basic/common command related
stuff (I notice that the sdl client uses the same as the current client),
another called gnome, another gtk, another x11, another sdl, etc.  Unlike the
current layout where the main function is provided by one of the common files,
each subdir would be responsible for their own.
2) Individual portions of these can be listed as unsupported.
3) Merge the current sdl client into this layout.

 This of course does not solve the problem.  But IMO, there is no solution. as
it is likely some of the old clients will always be maintained/supported by
someone to some extent.  But at least if everything is in the same place, then
hopefully the more code can be shared.  For example, the sdl map generation for
both the sdl and gtk client could probably be shared.  Perhaps other areas as
well.