From lalo.martins at gmail.com Sat Apr 4 12:52:18 2009 From: lalo.martins at gmail.com (Lalo Martins) Date: Sat, 4 Apr 2009 17:52:18 +0000 (UTC) Subject: [crossfire] clients Message-ID: Well, gtk-v2 is now successfully built and packaged for Windows. This brings the usual question :-) any objections if we nuke x11 and gtk from the tree for trunk (and 1.13)? Actually, I don't really care about objections. Let's put this a different way. Any volunteers to maintain those? ;-) They haven't been touched in a looong time, so unless someone steps up, I'll be nuking them right after the release nightmare is over. (Last time we talked about it, there were two objections; v1 was better on smaller screens, and easier to build on windows. Kevin solved the former with glade; v2 is now actually better on small screens. And I worked out building it with msys. So I don't really see a benefit to keeping that unmaintained codebase around.) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From kbulgrien at att.net Sat Apr 4 17:18:21 2009 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Sat, 4 Apr 2009 17:18:21 -0500 Subject: [crossfire] clients In-Reply-To: References: Message-ID: <200904041718.21419.kbulgrien@att.net> > Well, gtk-v2 is now successfully built and packaged for Windows. Woohoo... Kudos! Double Points that it was done with MinGW/MSYS! > This brings the usual question :-) any objections if we nuke x11 and gtk > from the tree for trunk (and 1.13)? It's time... the main holdout was due to the lack of another Windows solution (at least until jxclient is considered complete/stable). > Actually, I don't really care about objections. Let's put this a > different way. Any volunteers to maintain those? ;-) They haven't been > touched in a looong time, so unless someone steps up, I'll be nuking them > right after the release nightmare is over. > > (Last time we talked about it, there were two objections; v1 was better > on smaller screens, and easier to build on windows. Kevin solved the > former with glade; v2 is now actually better on small screens. And I > worked out building it with msys. So I don't really see a benefit to > keeping that unmaintained codebase around.) This reminds me... I need to check in sixforty.glade. Someone challenged me to create a 640x480 layout quite a while ago. I completed it, but never added and committed it. Kevin From kbulgrien at att.net Sat Apr 4 22:03:22 2009 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Sat, 4 Apr 2009 22:03:22 -0500 Subject: [crossfire] clients In-Reply-To: <200904041718.21419.kbulgrien@att.net> References: <200904041718.21419.kbulgrien@att.net> Message-ID: <200904042203.22265.kbulgrien@att.net> > > This brings the usual question :-) any objections if we nuke x11 and gtk > > from the tree for trunk (and 1.13)? > > It's time... the main holdout was due to the lack of another Windows > solution (at least until jxclient is considered complete/stable). One of the arguments I had for GTK-V1 back in the day was the font size... It was nice and small compared to GTK-V2. I think that is still an issue for small screens. It would be nice to be able to do something about that in GTK-V2 without making someone change the font for GTK2 system-wide. Not changing the reply here, just making note of one thing GTK-V1 still has over GTK-V2 despite the layout capability in GTK-V2. Kevin From lalo.martins at gmail.com Sat Apr 4 22:32:41 2009 From: lalo.martins at gmail.com (Lalo Martins) Date: Sun, 5 Apr 2009 03:32:41 +0000 (UTC) Subject: [crossfire] clients References: <200904041718.21419.kbulgrien@att.net> <200904042203.22265.kbulgrien@att.net> Message-ID: quoth Kevin R. Bulgrien as of Sat, 04 Apr 2009 22:03:22 -0500: >> > This brings the usual question :-) any objections if we nuke x11 and >> > gtk from the tree for trunk (and 1.13)? >> >> It's time... the main holdout was due to the lack of another Windows >> solution (at least until jxclient is considered complete/stable). > > One of the arguments I had for GTK-V1 back in the day was the font > size... It was nice and small compared to GTK-V2. I think that is still > an issue for small screens. It would be nice to be able to do something > about that in GTK-V2 without making someone change the font for GTK2 > system-wide. Not changing the reply here, just making note of one thing > GTK-V1 still has over GTK-V2 despite the layout capability in GTK-V2. I kinda-almost-know-at-the-edge-of-my-head how to do that in gtk... I'll take a look after the release, if nobody beats me to it :-) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Sat Apr 4 23:55:43 2009 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 04 Apr 2009 21:55:43 -0700 Subject: [crossfire] clients In-Reply-To: <200904042203.22265.kbulgrien@att.net> References: <200904041718.21419.kbulgrien@att.net> <200904042203.22265.kbulgrien@att.net> Message-ID: <49D839CF.6080507@sonic.net> Kevin R. Bulgrien wrote: >>> This brings the usual question :-) any objections if we nuke x11 and gtk >>> from the tree for trunk (and 1.13)? >> It's time... the main holdout was due to the lack of another Windows >> solution (at least until jxclient is considered complete/stable). > > One of the arguments I had for GTK-V1 back in the day was the font size... > It was nice and small compared to GTK-V2. I think that is still an issue for > small screens. It would be nice to be able to do something about that in > GTK-V2 without making someone change the font for GTK2 system-wide. > Not changing the reply here, just making note of one thing GTK-V1 still has > over GTK-V2 despite the layout capability in GTK-V2 I believe (but could be wrong) that both the gtk and gtk-v2 client basically use the standard system font - they are not going through extra hoops to mess with font size. That said, the default system font may very well not be usable on a low resolution screen. Note that a while back, I added theme support to the gtk-v2 client. So using a different font may just be as simple as making a new theme with different font settings. From lalo.martins at gmail.com Sun Apr 5 05:37:56 2009 From: lalo.martins at gmail.com (Lalo Martins) Date: Sun, 5 Apr 2009 10:37:56 +0000 (UTC) Subject: [crossfire] clients References: <200904041718.21419.kbulgrien@att.net> <200904042203.22265.kbulgrien@att.net> <49D839CF.6080507@sonic.net> Message-ID: quoth Mark Wedel as of Sat, 04 Apr 2009 21:55:43 -0700: > Kevin R. Bulgrien wrote: >> >> One of the arguments I had for GTK-V1 back in the day was the font >> size... It was nice and small compared to GTK-V2. I think that is >> still an issue for small screens. It would be nice to be able to do >> something about that in GTK-V2 without making someone change the font >> for GTK2 system-wide. Not changing the reply here, just making note of >> one thing GTK-V1 still has over GTK-V2 despite the layout capability in >> GTK-V2 > > I believe (but could be wrong) that both the gtk and gtk-v2 client > basically > use the standard system font - they are not going through extra hoops to > mess with font size. > > That said, the default system font may very well not be usable on a > low > resolution screen. > > Note that a while back, I added theme support to the gtk-v2 client. > So using > a different font may just be as simple as making a new theme with > different font settings. Ah, that would be correct :-) The themes (not to be confused with layouts) are just gtkrc files. As such, you can set a font. I'll play around with that later and tell you if/how it works. (Or you can.) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From elsbernd at dfki.uni-kl.de Sun Apr 5 06:50:22 2009 From: elsbernd at dfki.uni-kl.de (Klaus Elsbernd) Date: Sun, 05 Apr 2009 13:50:22 +0200 Subject: [crossfire] clients In-Reply-To: Your message of "Sat, 04 Apr 2009 17:52:18 -0000." Message-ID: <200904051151.n35BpCLC016973@dfki.uni-kl.de> Well, one cent from an old user: lalo.martins at gmail.com said: > This brings the usual question :-) any objections if we nuke x11 and gtk > from the tree for trunk (and 1.13)? I would like to remark, that there are more than windows systems out there. For example simple traditional old-style unix-systems, like my plain Solaris system for example. And I would prefer, if running plain X11 would be possible. X11 is by far the fastest interface. (If you nuke gtk, go ahead, there is now gtk-v2) Klaus -- "Sure, vi is user friendly. It's just particular about who it makes friends with." Unknown ;-) _________________________________________________________ Deutsches Forschungszentrum f?r K?nstliche Intelligenz GmbH (DFKI GmbH) Klaus Elsbernd; System Administrator | Klaus.Elsbernd at dfki.de Trippstadter Stra?e 122 | elsbernd at dfki.uni-kl.de 67657 Kaiserslautern; Germany | Fernruf: 0631/20575-586 Fernbild: -582 Gesch?ftsf?hrung: Prof. Dr. Wolfgang Wahlster (Vorsitzender), Dr. Walter Olthoff Vorsitzender des AR: Prof. Hans A. Aukes| Amtsgericht Kaiserslautern, HRB 2313 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 516 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20090405/cead5bcb/attachment.pgp From mwedel at sonic.net Sun Apr 5 23:20:51 2009 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 05 Apr 2009 21:20:51 -0700 Subject: [crossfire] clients In-Reply-To: <200904051151.n35BpCLC016973@dfki.uni-kl.de> References: <200904051151.n35BpCLC016973@dfki.uni-kl.de> Message-ID: <49D98323.4050101@sonic.net> Klaus Elsbernd wrote: > Well, one cent from an old user: > lalo.martins at gmail.com said: >> This brings the usual question :-) any objections if we nuke x11 and gtk >> from the tree for trunk (and 1.13)? > I would like to remark, that there are more than windows systems out > there. For example simple traditional old-style unix-systems, > like my plain Solaris system for example. > And I would prefer, if running plain X11 would be possible. X11 is by far the > fastest interface. > (If you nuke gtk, go ahead, there is now gtk-v2) Note that the X11 (and perhaps even gtk v1 client) are largely unmaintained and not getting updated. For the most part, this doesn't create much problem, because the protocol handing is done in the common area. But if/when a feature is added that really requires smart client support, X11 client is probably out of luck at that point Doing any type of interface work for the X11 client is difficult - this is why the gtk client has a spell window, etc - so while the X11 client may be fastest, it is probably also the most minimal of the bunch. From mwedel at sonic.net Mon Apr 6 00:29:06 2009 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 05 Apr 2009 22:29:06 -0700 Subject: [crossfire] clients In-Reply-To: <49D98323.4050101@sonic.net> References: <200904051151.n35BpCLC016973@dfki.uni-kl.de> <49D98323.4050101@sonic.net> Message-ID: <49D99322.8060103@sonic.net> Just another notes on clients: For the gtk-v2 client, having 3 different draw modes (pixmap, opengl, sdl) seems like overkill and is extra maintenance work. pixmap is no frills, but is always sure to be there, so should be kept. I don't think we need both opengl and sdl support. I'd suggest SDL support gets removed at some point, and for best graphic support, go with opengl. I mostly say that because opengl is a much more powerful library. While we may never use most of the features it has, even if we use just a few, having them there would be quite nice (main one that comes to mind to me immediately might be lighting support, but also things like real time rescaling, etc are nice). SDL would be a better choice if all the media aspects (sound, mouse, threads, etc) were written to use it. But the only part that does is graphics, so a lot of what SDL might give us isn't really there. From a performance standpoint, if you're video driver has a opengl interface, it blows the doors off of SDL. If it doesn't (and thus work is being done in software), performance is probably about the same. But if there are lots of folks out there using SDL and can't use opengl, or there are other good uses to keep SDL around, would be interested in hearing about it. From lalo.martins at gmail.com Mon Apr 6 00:38:22 2009 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 6 Apr 2009 05:38:22 +0000 (UTC) Subject: [crossfire] [ANNOUNCE] Client 1.12 released Message-ID: The 1.12 clients are released. Source tarball and Windows binaries are at https://sourceforge.net/project/showfiles.php?group_id=13833 as usual. Deb packages for Ubuntu can be found at our new PPA at https://launchpad.net/~crossfire/+archive/ppa (I'm not sure whether or not they'd work on Debian, let me know if you try). RPMs weren't made, but if someone makes them I'll upload them :-) Although I'm making the release, I'd like to take a moment to say that this release is largely the work of Kevin R. Bulgrien, who refuses to be called the client maintainer but is the de facto person who does the work. Kevin is responsible for the level of stability the v2 client reached in this release, as well as the Glade layout support, and a number of other cool new features. A number of other people who made significant contributions also get our thanks (Mark Wedel, as usual, showed up to add some cool stuff, like themes and on-the-fly map resizing.) Keep tuned to this channel for the content and server 1.12 releases. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From lalo.martins at gmail.com Mon Apr 6 17:13:21 2009 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 6 Apr 2009 22:13:21 +0000 (UTC) Subject: [crossfire] clients References: Message-ID: Ok. Feedback gotten and digested. So here's my semi-official decree as not-really-project-leader: We'll remove old gtk from trunk. I'd like opinions on whether v2 should be renamed to gtk, or even renamed to just crossfire-client. The SDL rendering is scheduled for removal, but removing it is not a priority. If someone feels like doing it, go ahead. The x11 client will be left in the tree, and on each release from here on, I (or the release manager) will test if it builds and runs. But there are no promises that it will actually be updated, unless someone steps up and volunteers to maintain it. As long as x11 doesn't have a maintainer, it will be considered unsupported, and disabled by default in configure (you'll have to pass an explicit --enable argument to build it). Binaries will not be included in releases. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From juhaj at iki.fi Tue Apr 7 10:33:09 2009 From: juhaj at iki.fi (Juha =?iso-8859-1?q?J=E4ykk=E4?=) Date: Tue, 07 Apr 2009 18:33:09 +0300 Subject: [crossfire] clients In-Reply-To: References: Message-ID: <200904071833.13181.juhaj@iki.fi> > As long as x11 doesn't have a maintainer, it will be considered > unsupported, and disabled by default in configure (you'll have to pass an > explicit --enable argument to build it). Binaries will not be included > in releases. Just my quick thought: this seems like a very nice solution. Good work. -Juha P.S. Didn't try the new version - yet. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20090407/8c8ec25d/attachment.pgp From kbulgrien at att.net Tue Apr 21 02:59:45 2009 From: kbulgrien at att.net (Kevin Bulgrien) Date: Tue, 21 Apr 2009 02:59:45 -0500 Subject: [crossfire] Continuing client messages UI work proposed/underway Message-ID: <20090421025945.1e1b5d21@a850srvr.kbulgrien.att.net> Following up on a thread started in December, I finally applied a patch to the GTK-V2 client to experiment with improving message routing in the client. This code begins to sort messages between message pane 0 (Messages) and pane 1 (so- called Critical Messages) based on MSG_TYPE classification. What drove the change was a desire to put player communication and other kinds of important messages) in a panel that was not spammed with "You miss/hit..." messages, etc. The idea being that the player does not want to have to scroll-back and hunt for talks/chats and messages like all your armor is melting away from that acid and your xp drained by that Nazgul or what have you - those messages need to stay visible for longer periods of time. In that vein, after some play testing, I found that there was a weird split with character says appearing in pane 1 vs. NPC and Magic Mouth replies showing up in pane 0, so a later patch added MSG_TYPE_DIALOG to the pane 1 routing. As a side note, it may be noted that this change seems to drive certain of the Glade client layouts to the top of the list of preferred ones since it means that there is a lot of value to having pane 1 visible by default. In any event, for those who can play 2.x GTK-V2, please feel free to comment on changes. The change was simple, but with its advent, it becomes much more tantalizing to continue the improvement effort. mwedel has suggested a number of possible ideas in this regard, and I better see the potential now. Two of the items under consideration are to add a panel specifically to support player communication, and, to allow a player to select the message routing between the various message panels via in-client configuration settings. (Another idea is a lot more technically challenging, that therefore will not get first attention, considers giving the player even more fine control of the UI layout than is possible with the glade layout files that need a client restart.) Anyway, on to the topic of new work... and in particular, planning how to prepare for player configured message routing, a client quirk has popped up on the radar. Messages are only classified according to MSG_TYPEs if they originate on the server. The client uses a simple, color-based routing method... namely that all client-sourced messages are placed on pane 0, and any that are color are ALSO put on pane 1. The routing concept starts to make this behavior look kind of weird. "Why do those messages show up in all panels? They really aren't all that important!". Essentially, this behavior comes down to the fact that the clients all use a draw_info() function that have no awareness of message type. The GTK-V2 client was the first client to support processing messages by type. The solution is very simple and I have a patch made that instantiates a new MSG_TYPE_CLIENT. Subtypes for client messages haven't been focused on yet, but should be quite basic. GTK-V2's custom messages are few, and have already been changed (in my sandbox only) over to use MSG_TYPE_CLIENT, but this makes the client-messages sourced in the common code start to stick out like a sore thumb. To start converting these messages to be routable, it becomes necessary to add a draw_ext_info() function to all clients (X11/GTK-V1/GTK-V2). In X11 and GTK-V1, this is a stub function that discards type and sub-type by passing the text and color data to draw_info(). In GTK-V2, draw_ext_info() calls message_callback() which is the entry point for type-aware message handling. Basically this proves to me that now all client-sourced messages are easily converted to the type-based routing method, which seems to be the best when considering making the client-side routing configurable. So, if you followed all that... and have an interest (for or against) the message routing, feel free to comment on what you think about adding a new MSG_TYPE_CLIENT and one or more related sub-types. Pros: This expands upon the GTK-V2 theme support in that now all message types can be tweaked by a theme whereas in the present SVN client, the theme has no control over client-sourced messages. If additional message panes are implemented, this change assures us that client-side messages need not be sprayed over all of them - the routing can be more intelligent. Client messages can now follow a single code path instead of two (code comments in the client even ask the question of whether the draw_info() code makes sense when there is (an implied) better method). This seems to make is simpler to read the GTK-V2 code that relates to client messages. There are requests for client layouts 640x480 and smaller and smart message handling in such tiny client screens is critical to playability. This change seems to enhance the ability to effectively support smaller screen layouts. Cons: I cannot think of any, can you? I plan to continue this effort and eventually commit the changes, but I'll be glad to entertain additional input. I believe enough in the end-result that the balance is already strongly tipped in favor of the change, but figure it is only fair to open the topic up for discussion in case there is more to consider than has crossed my mind. One particular area that is a bit fuzzy is whether the new MSG_TYPE_CLIENT is that necessary. MSG_TYPE_ADMIN might be re-used instead of adding the new type. It has sub-types that could be construed to be a bit relevant, although I ended up going with the new type simply because most MSG_TYPE_ADMIN sub-types were obviously server-oriented, and it seemed a bit cleaner not to mix server and client messages at the type level when some sub-types would make no sense at all for client-sourced messages. Opinions on this point are particularly welcome. Kevin From kbulgrien at att.net Wed Apr 22 06:45:35 2009 From: kbulgrien at att.net (Kevin Bulgrien) Date: Wed, 22 Apr 2009 06:45:35 -0500 Subject: [crossfire] Continuing client messages UI work proposed/underway In-Reply-To: <20090421025945.1e1b5d21@a850srvr.kbulgrien.att.net> References: <20090421025945.1e1b5d21@a850srvr.kbulgrien.att.net> Message-ID: <20090422064535.20615902@a850srvr.kbulgrien.att.net> > The GTK-V2 client was the first client to support processing messages by type. Correction: While working the draw_info() calls, it seems GTK-V1 did also. I forgot about the pop-up code.