Le Jeudi 28 Avril 2005 09:10, Mark Wedel a écrit : <snip> > This is a little more than I was thinking, but was along the idea I was > thinking with the NDI_.. redo. So flavors like spell listing, shop > listing, level gains, etc could also be added as flavors then? > Any flavor you like :) <snip> > I'm a little concerned about this - my fear is that the nicebuf things > won't get updated in any timely fashion, or people will be updating only > one, and the two will be completely out of sync (support for this alternate > msgbuf obviously would need to be put into the editors that people use). > nope, peoples only have one field to update it's the book->msg field. The server just present data differently depending on the command used to send data (draw_info or draw_info_ext) in fact server does this: strncpy(buf,sizeof(buf),"You open the %s and star reading... \n%s",ob->name,ob->msg); Something similar is done for nicebuf. The server will also have to strip out media tags before sending using the draw_info command (for old clients) > However, it also seems like you are doing 2 things here: > > 1) telling client types of messages so it could draw pretty frames, etc > 2) extending the text field to include tags for color, bold, etc. > > I hope on #2 you are using the formatting features the GTK already has > built in. If so, then it makes life much easier (it'd be really stupid to > have to write our own parser for that when GTK provides one for us) working with gtk1, all i saw was samething called gtk-html, which is an extension not include with the main gtk code, and i doubt it will work for windows version :/ i choos to use something easy to handle (no closing tag, a tag just set a value, there is no such thing as [normal]blabla[hand]foo-bar[/hand]other blabla[/normal] Parsing is quite straight forward anddoesn't involve complicated things. > > I'd personally like to see full documentation for the 'drawinfo_ext' > command - the docs that will make it into the protocol file. Coding > practices for crossfire are that the protocol changes are to have been > properly documented and sent to the mailing list for discussion with plenty > of advance notice before such changes are made to CVS. > sure, there are descriptions in protocol file > That said, in my ideal scenario, it would look something like: > > drawinfo2 <formattype><msgtype><msgsubtype><color><message> > > where formattype descirbes the format of the message (text, binary data, > text formatted in 3 rows, text formatted for ...) > > msgtype helps identify the type of message for sorting and preference > purposes. msgsubtype is finer control. > color is color of message - probably obsolete because that will be a client > preference based on previous fields. > > The advantage of having formattype as the key value is that there > probably isn't a need to have too many different format types. And > regardless of the remaining fields, the client could display the data if it > understands the format type (if it doesn't, it probably shouldn't try). > msgtype, because it regroups things presenting the same way, does inherently have a format. Client must request deliberatly a setup for each msgtype it support to be send by server, so no suprises in format. > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- David Delbecq Royal Meteorological Institute of Belgium