Adium

Opened 13 years ago

Closed 12 years ago

#8435 closed enhancement (fixed)

Allow a secondary message style for MUC

Reported by: zacw Owned by: Catfish_Man
Milestone: Adium 1.3 Component: Adium UI
Version: Severity: normal
Keywords: Cc: mathuaerknedam
Patch Status:

Description

Allow the user to specify a secondary message style to be used in multi-user chats.

Change History (9)

comment:1 Changed 13 years ago by Andreas Monitzer

I agree. My current message style doesn't include the sender's name (it's unnecessary for one-on-one-chats), so that's kinda unusable for chats where multiple persons are involved.

comment:2 Changed 13 years ago by David Smith

Owner: changed from nobody to David Smith
Status: newassigned

Thirded. This has been on my mental list for a while.

comment:3 Changed 13 years ago by Evan Schoenberg

Milestone: Adium X 1.2.1Adium X 1.3

David, what are your plans with this?

comment:4 Changed 13 years ago by David Smith

Patch compiling at the moment. Do we want to support groupchat-specific variants*? At the moment I've got it just importing a single extra css file (groupchat.css) that can be used to override rules in main.css.

*not unique variants, but rather the ability to have two files for one variant, one of which is groupchat specific.

comment:5 Changed 13 years ago by David Smith

(In [22290]) Import a new css file called groupchat.css if we're starting a group chat. I have not yet decided whether we need to do something similar for variants, so I will leave the ticket open. Refs #8435

comment:6 Changed 12 years ago by mathuaerknedam

Cc: mathuaerknedam added

comment:7 Changed 12 years ago by David Smith

So, I'm not convinced I did this right. It doesn't address the particular use-case I wanted to solve (turning on name coloring in groupchats and not in others), and it doesn't play well with the concept discussed on the mailing list of transforming chats to/from groupchats.

The latter case could be handled by simply adding/removing a groupchat class from the chat element, allowing styles like {{{ #chat.groupchat .message { ... } }}}

but I'm unsure on how to handle the former case without CSS variable support (which won't happen until Safari 3.2 at the *earliest*, it's not even in webkit svn yet).

comment:8 in reply to:  description Changed 12 years ago by hawkman

If we abandon the idea that the colours should be name-derived (admittedly sub-optimal), how about using %messageClasses% to assign an identifier (eg. participant1, participant2, etc) to each person? With the #chat.groupchat approach it would allow customising colours in group chats and non-group chats alike, although it would not be consistent across chats and would require that keyword to be used, breaking backwards-compatibility.

On the other hand, requiring a "nongroupchat.css" could make things work the other way round - using !important to turn off colours specified in inline css through %senderColor%?

I guess the 'lame' %groupchatSenderColor% might be the easiest way, in the end.

comment:9 Changed 12 years ago by David Smith

Resolution: fixed
Status: assignedclosed

(In [23290]) Remove the concept of groupchat.css and replace it by simply adding a class 'groupchat' to the #Chat element. This allows styles like (taken from my custom SO2): #Chat:not(.groupchat) .incoming .sender { color: #001298 ! important; }, which turns off nick coloring for non-groupchats. This also is more future proof if we decide to allow transforming 1:1 chats into MUCs and vice versa, and should allow better variant support for groupchat-specific styling. Fixes #8435

Note: See TracTickets for help on using tickets.