Alargando las pestañas

Estoy usando el tkabber pack para win, y me parece que he logrado configurar el tkabber para que aparezcan los mensajes "mensajes" en pestañas (me parece por que creo que venía así por defecto), pero tengo una duda que no se si sería más una "feature request" o qué. Ahí va:

Los mensajes de los contactos normales aparecen como pestañas de chat. Puede parecer trivial, pero un mensaje tiene un "subject" y un "body" y así sólo se ve el "body". Supongo que para cambiar esto habría que tocar algo de dentro (de ahí lo de la "feature request", aunque habría que definirlo algo más, digamos que me guio por el estilo del exodus de manejar esto).

En cambio parece que los mensajes del bot jabrss aparecen en una ventana nueva, ¿cómo me aseguro de que salga en pestañas por narices?

Saludos

PD: además me acabo de dar cuenta que al bot no se le guarda el historial de mensajes, pero a los usuarios normales sí ( o_0)? la noche me confunde, me voy a dormir.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

He probado, y recibo los mens

He probado, y recibo los mensajes como mensajes (en ventana aparte) y las charlas como charlas (en una pestaña). Prueba a enviarte mensajes a ti mismo (Servicios->Enviar mensaje->pon tu JID). También recibo mensajes de otra gente, y los veo como mensajes, con su asunto, su contenido, y su apartado para escribir la respuesta. En Tkabber->Personalizar->Chat->::chat::options(default_message_type) tengo puesto 'Charla'.

Los mensajes de noticias los recibo en pestañas, con forma de árbol y tal. Comprueba la configuración del bot JabRSS: le abres una charla, y dile 'configuration'. Yo lo tengo en modo 'message type "headline"'.

Tkabber puede tratar de dos formas distintas las noticias RSS: normal (te la muestra, y cuando cierres la pestaña se pierde) o cacheada (te la presenta siempre, hasta que le digas que ya la has leido). Esto se configura en Tkabber->Personalizar->Messages.

Sí, tienes razón.

Justo he probado a enviarme un mensaje a mi mismo desde tkabber, y lo recibo como mensaje en una ventana aparte, pero si me lo mando desde otra cuenta que tengo abierta en otro cliente (exodus 0.8.6.0), los recibo como un chat, por lo visto este cliente no manda el parámetro "type" en el tag "message" cuando envia mensajes normales, así que el comportamiento del tkabber parece correcto (tampoco se va a inventar lo que no hay).

Y por otro lado, mientras hacía probaturas he descubierto que me había faltado trastear un poco más, no había visto el registro de mensajes. Y en un principio me había parecido que esto es lo que estaba buscando,... hasta que le he dicho al jabrss que me mande los mensajes como titulares set headlines, dios mio, esto es estupendo, hasta ahora lo tenía en "plain text" por que el exodus los manejaba mejor que los otros tipos, pero tkabber lo borda con el modo headlines.

Muchisimas gracias

He estado probando lo que com

He estado probando lo que comentas más en detalle. Te recuerdo que los principales clientes Jabber tienen una ventana para ver el XML que mandan y reciben. En Tkabber: Servicios->Administración->Abrir ventana de XML crudo. Así puedes comprobar qué envia el Exodus, el Psi, el Tkabber y encontrar el problema más fácilmente.

Pues bien, este es el XML que envia Tkabber para un mensaje (no un chat):

<message 
        to='badlop@***********'
	type='normal'
	xml:lang='es'>
  <subject>eee</subject>
  <body>aaaaaaaaaaaaaa</body>
</message>

Exodus envia para un mensaje:

<message 
       id="" 
       to="badlop@****">
  <subject>eee</subject>
  <body>aaaaaaaaaaaaa</body>
</message>

Psi envia para un mensaje:

<message 
       to="badlop@*******" >
  <subject>eeee</subject>
  <body>aaaaaaaaaaaaaaaaaaa</body>
</message>

Así que la cosa está clara, los tres clientes envían Subject y Body, pero solo el Tkabber especifica claramente que el envio es un mensaje (type='normal'), y no un chat (type='chat'). La duda es saber quién está actuando incorrectamente. Para ello nos vamos a la documentación del protocolo (XMPP-IM), y vemos que pone:

2.1.1 Types of Message

The 'type' attribute of a message stanza is RECOMMENDED; if included, it specifies the conversational context of the message, thus providing a hint regarding presentation (e.g., in a GUI). If included, the 'type' attribute MUST have one of the following values:

  • chat -- The message is sent in the context of a one-to-one chat conversation. A compliant client SHOULD present the message in an interface enabling one-to-one chat between the two parties, including an appropriate conversation history.
  • error -- An error has occurred related to a previous message sent by the sender (for details regarding stanza error syntax, refer to [XMPP-CORE]). A compliant client SHOULD present an appropriate interface informing the sender of the nature of the error.
  • groupchat -- The message is sent in the context of a multi-user chat environment (similar to that of [IRC]). A compliant client SHOULD present the message in an interface enabling many-to-many chat between the parties, including a roster of parties in the chatroom and an appropriate conversation history. Full definition of XMPP-based groupchat protocols is out of scope for this memo.
  • headline -- The message is probably generated by an automated service that delivers or broadcasts content (news, sports, market information, RSS feeds, etc.). No reply to the message is expected, and a compliant client SHOULD present the message in an interface that appropriately differentiates the message from standalone messages, chat sessions, or groupchat sessions (e.g., by not providing the recipient with the ability to reply).
  • normal -- The message is a single message that is sent outside the context of a one-to-one conversation or groupchat, and to which it is expected that the recipient will reply. A compliant client SHOULD present the message in an interface enabling the recipient to reply, but without a conversation history.

An IM application SHOULD support all of the foregoing message types; if an application receives a message with no 'type' attribute or the application does not understand the value of the 'type' attribute provided, it MUST consider the message to be of type "normal" (i.e., "normal" is the default). The "error" type MUST be generated only in response to an error related to a message received from another entity.

Although the 'type' attribute is OPTIONAL, it is considered polite to mirror the type in any replies to a message; furthermore, some specialized applications (e.g., a multi-user chat service) MAY at their discretion enforce the use of a particular message type (e.g., type='groupchat').

Por tanto:

  • Exodus y Psi harían bien en proporcionar Type cuando son mensajes, aunque no es obligatorio.
  • Tkabber cumple un requisito no obligatorio, que es enviar el Type en mensajes.
  • Cuando no se especifica Type, Tkabber DEBE entender que es un mensaje, no un chat. Aquí está el problema. Lo añado a la lista de cuestiones por resolver del Tkabber, gracias por comentarlo :)

Vaya, un último dato

Me acabo de dar cuenta de la opción que hay en preferencias, en la sección de "Chat", donde se puede especificar la llegada de mensajes normales en ventana o en chat.

En español reza así:

"Tipo de mensajer por defecto(si no se especifica explícitamente)."

y cambiandolo se consigue que los mensajes que no tienen el tag "type" especificado, aparezcan de un modo u otro.

Quizás lo único que haya que hacer es dejarla en "modo mensaje" por defecto (como rezan las specs.) y moverla de la zona de chat a la zona de mensajes en la configuración, ya que afecta a la manera de mostrar los mensajes.

Aha, pues menos mal que lo ha

Aha, pues menos mal que lo has dicho, porque no habia caido en la cuenta. Esa opción supongo que la añadirían hace meses, cuando aún no se habia añadido la obligatoriedad. Yo también la tenia cambiada a 'chat', jeje.

Pues para que el Tkabber respete XMPP esa opción ni deberia estar disponible. Lo único que va a provocar es problemas, así que lo añadiré a la lista de cuestiones pendientes.

Actualización: esa opción modifica dos cosas:

  • El tipo de mensaje cuando pulsas dos veces sobre un contacto en el roster para hablar con él
  • El tipo de mensaje con que se muestran los mensajes recibidos en los que no se especifica tipo del mensaje

Como ya hemos visto, según XMPP la segunda parte no tiene sentido, ya que es obligatorio presuponer que es de tipo 'normal'. Por tanto no se trata de quitar la opción, sino de que no modifique la segunda parte (bueno, yo me entiendo, jeje).

Sí, es cierto

Del "doble efecto" no me di cuenta.

En fin, ahora que ya parece que todo esté en su sitio, muchas gracias.

Syndicate content