Re: [crossfire] gtkv2 client vs gtk client gap list.
And so says Mark Wedel on 05/02/06 11:24... > But what at the main features that are missing? IMO, there is a lot of > stuff > in gtkv1 client that I'm not sure people use. One being the keybinding > interface - do people use that very much, or do people just use command line. > It doesn't make sense to add features that no one needs. Sometimes I'll bind from the command line, specially if I'm in a hurry or I'm just pasting a binding (eg for a pickup mode or a spell I just learned). But usually I bind from the GUI, and I *always* unbind and edit bindings from the GUI. 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. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gtkv2 client vs gtk client gap list.
On 2/5/06, Mark Wedel <[EMAIL PROTECTED]> wrote: > > I'm not sure that is necessary, not so long ago there was a patch to > > gcfclient to make it compile against gtk2, I will assume that this > > gets accepted in the move towards 2.0, with the few bugs it isolates > > picked up on the way. > > I do wonder if at some point, gtk itself may drop support for the stuff from > gtk1 they obsoleted. For example, if gtk3 is released, they may very well say > 'gtk1 code is going away - we kept and entire released version, but we don't > want it anymore'. I'd imagine that may be years away (and gtkv2 may continue > to > be commonly available on distributions for a while even after gtk3 is > released), > but a random thought. Note that I have no indication that this is actually > going to happen, but I imagine at some point, the gtk1 stuff that they stopped > supporting will go away. But long before that time, gcfclient can have been compiled against gtk2, and it can use a lot of the code from gcfclient2 to replace deprecated stuff. > Maybe - I'm not 100% sure how big gtk-common would be. But this goes back > to > the original question, which is why keep the gtk-v1 client. If the gtkv2 > client > has all the same features, is there a reason to keep the gtk-v1 client (this > is > driven people using it, but then perhaps the question is why are people using > it > over gtkv2). > > If it is a matter of layout (I like the layout of gtk1 better), I wonder how > hard it would be to do a 'gtk API' type of thing - take a glade config file, > and > say 'these are the callbacks you use' - one could whip up a new layout pretty > darn quickly. That's pretty much the reasoning behind a gtk-common/ however, I'd rather have at least one client done manually, since glade is fairly complicated. > IIRC, I did the entire layout of the gtkv2 client in glade in a single > evening > - it was the back end portion that was harder, and in some cases, because of > the > difference in gtk 1 and 2. > IIRC, to be 100% gtk2, the text windows (messages) and the lists (inventory, > look) use new widgets. If you take those pieces out, what is then left as > common is the map (which does share code to a good extent right now), and the > stat/resistances windows (which are pretty trivial). If we assume that gcfclient is in future compiled against gtk2 by default then the inventory and text code could be taken directly from gcfclient2, given that they operate almost identically anyway. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gtkv2 client vs gtk client gap list.
On 2/5/06, Mark Wedel <[EMAIL PROTECTED]> wrote: > But what at the main features that are missing? IMO, there is a lot of > stuff > in gtkv1 client that I'm not sure people use. One being the keybinding > interface - do people use that very much, or do people just use command line. > It doesn't make sense to add features that no one needs. I use the keybinding interface on the occasions I run gcfclient. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gtkv2 client vs gtk client gap list.
Brendan Lally wrote: > On 2/4/06, Mark Wedel <[EMAIL PROTECTED]> wrote: >> To me, at some level, keeping the gtk(v1) client about may not make a lot >> of >> sense. Especially if we start going down the path of new character creation >> and >> other widgets - I don't look forward to trying to write those for the gtkv1 >> client. > > I'd note at this point that the recent spell interface updates I did > were for gcfclient not gcfclient2 - I find glade complex and > confusing, gtk code is comparatively straightforward to write, at > least for maintenance. And that is sort of the point - if/when more stuff is moved to the client, having to update multiple clients become more a burden. As long as we have peopel willing to keep updating all the clients, not as much a problem. Presuming of course those people stick around and are relatively responsive to making needed changes in a timely fashion. > >> I know a lot of people still use the gtkv1 client. So my basic question >> is, >> for those of you that do, what needs to be changed/added/fixed in the gtkv2 >> client so you would use it. > > I'm not sure that is necessary, not so long ago there was a patch to > gcfclient to make it compile against gtk2, I will assume that this > gets accepted in the move towards 2.0, with the few bugs it isolates > picked up on the way. I do wonder if at some point, gtk itself may drop support for the stuff from gtk1 they obsoleted. For example, if gtk3 is released, they may very well say 'gtk1 code is going away - we kept and entire released version, but we don't want it anymore'. I'd imagine that may be years away (and gtkv2 may continue to be commonly available on distributions for a while even after gtk3 is released), but a random thought. Note that I have no indication that this is actually going to happen, but I imagine at some point, the gtk1 stuff that they stopped supporting will go away. > > If cfclient is removed, (and the broken gnome client also), then there > would only be one toolkit in use. It would then be possible to > restructure the client directories to have common/ gtk_common/ gtk-v1/ > and gtk-v2/ mapping to: > protocol parsing and storage, toolkit specific code, and interface > respectively. Maybe - I'm not 100% sure how big gtk-common would be. But this goes back to the original question, which is why keep the gtk-v1 client. If the gtkv2 client has all the same features, is there a reason to keep the gtk-v1 client (this is driven people using it, but then perhaps the question is why are people using it over gtkv2). If it is a matter of layout (I like the layout of gtk1 better), I wonder how hard it would be to do a 'gtk API' type of thing - take a glade config file, and say 'these are the callbacks you use' - one could whip up a new layout pretty darn quickly. IIRC, I did the entire layout of the gtkv2 client in glade in a single evening - it was the back end portion that was harder, and in some cases, because of the difference in gtk 1 and 2. IIRC, to be 100% gtk2, the text windows (messages) and the lists (inventory, look) use new widgets. If you take those pieces out, what is then left as common is the map (which does share code to a good extent right now), and the stat/resistances windows (which are pretty trivial). But what that does mean is that any change to inventory handling (say new attribute to display) would be separate code for the clients. Likewise, any changes to message handling couldn't share code. The map portion could share code, and I'd bet to some extent, right now, could pretty easily do so (in both cases, it is just going directly to a drawable, and in the case of the opengl and SDL drawing modes, doesn't even use GTK - gtk just provides the window, nothing else). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gtkv2 client vs gtk client gap list.
Yann Chachkoff wrote: >> Briefly discussed on irc, but also related to other discussions, is perhaps >> what client(s) to use going forward. To me, at some level, keeping the >> gtk(v1) client about may not make a lot of sense. > > I'm not sure about that, at least not on the short term. The gtkv2 is far > from complete IMHO. On the longer term, it is probably correct that the gtkv1 > would get superceded at some point, though. But what at the main features that are missing? IMO, there is a lot of stuff in gtkv1 client that I'm not sure people use. One being the keybinding interface - do people use that very much, or do people just use command line. It doesn't make sense to add features that no one needs. > >> Especially if we start going down the path of new character creation and >> other widgets - I don't look forward to trying to write those for the gtkv1 >> client. > >> I know a lot of people still use the gtkv1 client. > > Well, I think it is actually more accurate to say that it is the most used > one :). Yes, numbers back you up - from metalforge: GTK Unix Client 6 GTK Unix Client 1.5.03 GTK Unix Client 1.7.01 GTK Unix Client 1.7.17 GTK Unix Client 1.8.0 22 GTK Win32 Client 1.7.0 1 GTK Win32 Client 1.7.1 2 GTK Win32 Client 1.8.0 7 GTK Win32 Client 1.8.0 snapshot 19 GTK2 Unix Client 1.8.0 6 Perl Bot 1 X11 Unix Client 4 X11 Unix Client 1.7.02 X11 Unix Client 1.8.0 11 These numbers are correlated with client and ip address - this likely isn't 100% accurate (there is a delay between the client connecting and player logging in, thus getting IP address), but probably gives an OK estimate. The number could also be skewed - people playing that connect via DHCP will be counted numerous times, compared to those on static IPs. > My most important complain is already well known: gtkv2 requires a 1280x1024 > screen resolution, which is not available (or comfortable) on many screens. > The resolution currently considered as standard is 1024x768 (a lot of laptops > are limited to it, while a lot of 17''CRT monitors can only display 1280x1024 > at rather low frequencies). Although I understand that people that got bigger > screens would want a client best suited for them, let's not forget all those > who cannot properly display such a big client: they'll have no other choice > but quit playing, or deal with ugly things like virtual scrolling. > > I think that the problem comes down to the impossibility to reconfigure the > client interface to suit your needs - not everybody needs/wants a 25x25 map > display, for example; others may want to get bigger tiles instead of getting > more. Before scrapping gtkv1, I think that the v2 must provide the same level > of display configuration. I'll look into this. Note it really comes down to the map display area - if the map area is made say ~550x550 pixels (instead of the 800x800 right now), that you could either get 17x17 display with full sized images, or 25x25 with images resized to be 22x22, or something in between. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gtkv2 client vs gtk client gap list.
On 2/4/06, Mark Wedel <[EMAIL PROTECTED]> wrote: > To me, at some level, keeping the gtk(v1) client about may not make a lot of > sense. Especially if we start going down the path of new character creation > and > other widgets - I don't look forward to trying to write those for the gtkv1 > client. I'd note at this point that the recent spell interface updates I did were for gcfclient not gcfclient2 - I find glade complex and confusing, gtk code is comparatively straightforward to write, at least for maintenance. > I know a lot of people still use the gtkv1 client. So my basic question is, > for those of you that do, what needs to be changed/added/fixed in the gtkv2 > client so you would use it. I'm not sure that is necessary, not so long ago there was a patch to gcfclient to make it compile against gtk2, I will assume that this gets accepted in the move towards 2.0, with the few bugs it isolates picked up on the way. If cfclient is removed, (and the broken gnome client also), then there would only be one toolkit in use. It would then be possible to restructure the client directories to have common/ gtk_common/ gtk-v1/ and gtk-v2/ mapping to: protocol parsing and storage, toolkit specific code, and interface respectively. These parts individually would not be so hard to maintain. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gtkv2 client vs gtk client gap list.
> Briefly discussed on irc, but also related to other discussions, is perhaps > what client(s) to use going forward. > To me, at some level, keeping the gtk(v1) client about may not make a lot of > sense. I'm not sure about that, at least not on the short term. The gtkv2 is far from complete IMHO. On the longer term, it is probably correct that the gtkv1 would get superceded at some point, though. > Especially if we start going down the path of new character creation and > other widgets - I don't look forward to trying to write those for the gtkv1 > client. > I know a lot of people still use the gtkv1 client. Well, I think it is actually more accurate to say that it is the most used one :). > So my basic question is, for those of you that do, what needs to be > changed/added/fixed in the gtkv2 client so you would use it. My most important complain is already well known: gtkv2 requires a 1280x1024 screen resolution, which is not available (or comfortable) on many screens. The resolution currently considered as standard is 1024x768 (a lot of laptops are limited to it, while a lot of 17''CRT monitors can only display 1280x1024 at rather low frequencies). Although I understand that people that got bigger screens would want a client best suited for them, let's not forget all those who cannot properly display such a big client: they'll have no other choice but quit playing, or deal with ugly things like virtual scrolling. I think that the problem comes down to the impossibility to reconfigure the client interface to suit your needs - not everybody needs/wants a 25x25 map display, for example; others may want to get bigger tiles instead of getting more. Before scrapping gtkv1, I think that the v2 must provide the same level of display configuration. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] gtkv2 client vs gtk client gap list.
Briefly discussed on irc, but also related to other discussions, is perhaps what client(s) to use going forward. To me, at some level, keeping the gtk(v1) client about may not make a lot of sense. Especially if we start going down the path of new character creation and other widgets - I don't look forward to trying to write those for the gtkv1 client. I know a lot of people still use the gtkv1 client. So my basic question is, for those of you that do, what needs to be changed/added/fixed in the gtkv2 client so you would use it. And anyone still using the old X11 client, same question. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] crossfire 2.0, smooth movement, thoughts.
In various 2.0 discussions, the idea of smooth movement has been brought up. Thinking about that, I wonder if it is better to aim for 3.0 for that. redoing it for smooth movement requires IMO a lot of code changes, and if we shoot for that in 2.0, I think 2.0 will be a long ways off. I think it also needs to be worked out a lot more. I have some thoughts on how to do it, but it needs to be worked out a lot more. For example, I was originally thinking that it could only pertain to players and perhaps monsters. But that doesn't work really wall - arrows should also move smoothly, and you should be able to roll boulders smoothly, or else it looks really weird. Underlying, I was thinking the idea of mapspace remains the same - at some level, you need some method to get to objects nearby. And splitting all the spaces into smaller spaces may not help - if you have to examine 200 spaces that the player is near for objects, that probably isn't an improvement. So my general though would be each object would have an offset within the space - presuming we want to match pixel offsets to position, it would be that each object would have an x and y offset for -15 to +15 - if the offset is more than that (say 16), it would move to the next space at a -15 offset. But what this does mean is that in many cases, you need to look at 4 spaces for objects/monsters (for example, if the player is at 15,15 offset, then objects on the neighboring space might be close enough to pick up). Likewise, movement for players get complicated. But the question also about how fine to reduce movement comes in. If we come into refining things to single pixel movement, we are talking about a 250 FPS redraw rate for the client, or about 4 ms to redraw the image. I don't think any of the clients on current hardware are capable at that rate (ignoring graphic performance, have to take into account the other things the client does). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gcfclient info window text trimming crash.
Brendan Lally wrote: > gcfclient can be made to crash reliably with the "Trims text in the > information window" option set when compiled against 1.2.10. > > This was reported on #crossfire, and I have been able to reproduce it > reliably (grab lots of items, and repeatedly pickup and drop them). > > Since this appears to be a GTK bug, which is presumably not present > under gtk2, I therefore suggest that the patch which is connected to > bug #1423605 - > https://sourceforge.net/tracker/index.php?func=detail&aid=1423605&group_id=13833&atid=113833 > as a work around. > > Basically I am adding > #if GTK_MAJOR_VERSION > 1 > ... > #endif > around the trimming code. (although there are also a couple of minor > cleanups too). > > The reason I am posting this here, is to ask if there is a better way > to do this (it works fine for me running gtk 1.2, but does it break > windows builds)? It is a little unclear what exactly the GTK_MAJOR_VERSION check is around. Does this mean that info trimming is completely disabled with version 1 of gtk? If so, I'd sort of say, what is the point - that is why there is a config option. Although, I suppose if that is the case, there isn't a big reason for a config option. > > Presumably 2.0 will compile gcfclient against gtk2, so there will be > no further issue with this; however since this doesn't seem likely to > be the case with 1.9 some way to stop it crashing seems to be in > order. Are you sure version 2.0+ of GTK fixes the problem? IIRC when doing the gtk2 client, there is a new widget for text stuff for gtk2, and the gtk2 docs specifically say don't use the old widget if at all possibly because it is severely broken. That said, it could be that that option get removed from the config page - if people want to muck with their config file, fair enough, but they are doing that at their own risk. IIRC, the config page specifically says it may cause crashes if you use that option. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
