f.req: integrate participant list into mess.style

[telic.detour]

Right now, the list of participants in a group chat is shown in a pane to the right-hand side of the message window, and is completely unreachable by message styles. I would like to propose the following changes, in the interest of more flexible styling (and hopefully a better looking UI):

- When a chat window is first opened, isGroupChat(boolean) should be called, indicating whether this is a group chat (true), or a one-on-one IM (false).
- When a chat window is first opened (group chat or not), and every time a new participant joins a group-chat, addParticipant(name,screenname,icon,service) should be called.
- Whenever someone leaves a chat, removeParticipant(name,screenname,icon,service) should be called.

- Either remove the current implementation of the participant list completely, or provide it as a drawer instead of that ugly frame-like thing.

I realize some of what I am requesting is already sort of supported by status messages, but these are virtually useless on the javascript end of things, and aren't there at all when the message window is first opened. Adding these function calls would allow message styles that do not display sender names (such as my own, Clean) to be much more useable in group-chat situations. Message styles could use these functions to build their own participant lists if they so choose, and to easily provide different colours for messages from different people.

[zaudragon]

I don't like the drawers idea, but yeah, the group chat thing needs work!

This will take a while if it's approved…

[dchoby98]

Yes, we really need to change how message windows handle group chat. I'd actually like to add the ability to have a different message view for group chats. There is some sort of plan to have better status message support for group chats, after the Great Status System Rewrite (tm) happens... some day...

[The_Tick]

- Either remove the current implementation of the participant list completely, or provide it as a drawer instead of that ugly frame-like thing.

But the group list is required for group chat to be useful, so throwing it in a drawer is against the hig. We could throw it in another window, but that kills the adium design altogether. So split window it is. And it's really not so bad.

Maybe something cooler would be if the user list took on the colors/look of the contact list. Might be something interesting.

[dchoby98]

We actually already use the contact list code to draw the users' list -- but force it to have black-on-white. That could lead somewhere interesting though...

[BlueRevolution]

following the contact list wouldn't work, a lot of people have transparency in their list and it might not go very well with the message style. could there be a stylesheet setting in the message style for changing the list?

[evands]

It could be interesting to let message styles handle the group chat list by themselves... this would clearly have to be optional, since otherwise all existing message styles would have broken group chat functionality. Implementing something like suggested by telic.detour, with it enabled only if the message style Info.plist had something like:

Code: Select all

<key>ManagesGroupChatUserlist</key>
<true/>

would be reasonable if it were implemented...

telic.detour: You talk about using this for custom colors on a per-contact basis. Would it be feasible to implement a more traditional user list using these methods you've described?

[zaudragon]

Group Chat Participants will be displayed the same way as before right? With the buddy icon and alias?

Alias could be anything…

[The_Tick]

With most current message views though, you'd probably only see 2-4 participants in the list.

[evands]

With most current message views though, you'd probably only see 2-4 participants in the list.

How so?

[The_Tick]

With most current message views though, you'd probably only see 2-4 participants in the list.

How so?

Take smooth op for example. With a non-enlarged message window, the list would probably be 2-3 people. Mockie wouldn't be so bad, probably 5-8, etc.

The problem I'd have with using webkit here is we already have a list type thing that we can apply instead. Does that make any sense? (I'm not awake yet, lol)