[crossfire] channels

Sat Apr 30 05:11:00 CDT 2005

Le Samedi 30 Avril 2005 08:38, Mark Wedel a écrit :
>

      tchize at myrealbox.com

       wrote:

     >>

      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)

     >

     >

       This has to be done at load time then - if we have to examine every

     >

      message we send to a client to see if it has tags and then strip out those

     >

      tags, I'd see this quickly become a very costly operation.

     >

agree

>>>

       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 think I was looking at the pango parser:

     >

      http://www.gtk.org/api/2.6/pango/PangoMarkupFormat.html

     >

     >

       This is a bit more complicated in its format, but then integrates very

     >

      simply into the client.

lib pango is gtk2, not gtk1. And the format is indeed more complicated. This 
sure simplifies to writing of gtk2 client, but it's a problem with other 
clients (gtk1, opengl client, sdl client).
Also there is a problem for fonts, i want 5 fonts to be availabe, 
corresponding to  normal text, hand written text, magical text, 
undecipherable text and fixed width text and the <span> attribute does not . 
I can't really see how the pango markup will be of help on that. Not to 
mention it has no support for including pictures in text.

Also, am not sure it's a good idea to have client/common have a permanent 
dependency on libPango

>

     >

       It just strikes me as stupid to write our own parser when there are

     >

      perfectly good ones out there.  Aside from the initial effort, you are then

     >

      likely to get into the case of features people perhaps want in the future,

     >

      so what is right now a simple parser may in the end become pretty

     >

      complicated.

     >

     >>>

       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

     >

     >

       There is nothing in the protocol file right now about your drawinfo_ext

     >

     command.  Updating that file the same time you commit the rest of the

     >

      changes is not considered advanced notice and is not acceptable practice.

     >

     >>>

     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.

     >

     >

       The problem with that is I can certainly see new msgtypes added with a

     >

      format that is very simple and every client would understand.  Yet if the

     >

      client has to explicity understand all the msgtypes, it means it has to get

     >

      the information in the old format (while the client may not know the

     >

      msgtype, and thus not have any real idea of what tab to put it into, it is

     >

      perfectly capable in knowing how to display it).

     >

     >

       So to me, it makes sense to seperate those two pieces - have a formattype

     >

      that says how to display this, and a msgtype that says what type of message

     >

      it is so the client knows what tab to display it in (or other special

     >

      operations).

     >

     >

     _______________________________________________

     >

     crossfire mailing list

     >

      crossfire at metalforge.org

     >

      http://mailman.metalforge.org/mailman/listinfo/crossfire

-- 
--
Tchize (David Delbecq)

     tchize at myrealbox.com

Public PGP KEY FINGERPRINT:
    F4BC EF69 54CC F2B5 4621  8DAF 1C71 8E6B 5436 C17C
Public PGP KEY location:

     http://wwwkeys.pgp.net/pgpnet/wwwkeys.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : 

     http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050430/be0d2817/attachment-0001.pgp