Scott Barnes wrote: > > Yes, GTK is the toolkit used by Gnome, but that's not why I did it, sure, > the GTK client looks good in Gnome but it doesn't take advantage of Gnome's > features. As for examples, here goes: Ok. Some of it was just curiousity of what specifically had to be done to make it work under gnome properly > * Use of gdk_imlib for image proccessing, thus allowing the images to be > reused and resized more efficiently (for instance, the Inv and Look lists > now use smaller images than the actual map so that they don't eat up so > much screen space) As a note - imlib was originally used for the client for png support. But it was so buggy/slow I gave it up. Basically, it would not render some PNG files correctly (some of them important, like the cobblestones). Maybe they've finally fixed that up. > > There is one downside though, the map drawing is slightly slower than the > GTK client's because of the fact that the GTK client just used a quick blit > to a GtkDrawable while the Gnome one uses separate drawables for each tile > to better allow scaling. However, the difference isn't all that noticable > unless you're on a slower machine (like about a 75Mhz) some people are already complaining that the performance of the gtk client is poor. But I guess if you have the hardware to run it, up to each user to choose client that works best for them. > Also, about the "put it in the current client" idea, that may not work, > since the sound code and a few lines in client.c, player.c, and commands.c > had to be modified/rewritten in order to allow for some of the > enhancements. However, the protocol code is essentially the same so maybe > with some work it could be integrated into the current client. However, > for now I'm going to submit it to SourceForge and just keep all the > duplicate code up to date with the CVS version of the regular client. But > I would like to see it added to the current client one day. Ok. I guess its your call to do the extra work to keep it in sync.