Seperate UserItems are now created for each list, too, rather than a
single one being created per-user. This functionally works a lot nicer.
But onto more important things… now setting the user's own nick should
work quite well. Finally. =w=
This has given me a good bit of trouble over the past couple of days―
setting the user's nick *worked*, but it wouldn't propagate to its
corresponding UserItem nor its UserInfoDialog. It would, however, work
with the StatusView.
These are all registered Observers of the User itself, so if one works,
they *all* should, them all being registered to the same User.
Now, if a given User isn't found in the ProtocolLooper's user-list,
the Conversation class will take it upon itself to create a new
one and add it to both of their respective lists.
So the user's own contact would be set in the ProtocolLooper― but it
*wouldn't* be added to the user-list.
Hilarity ensues as two seperate objects for the user's own contact would
be created.
Since the StatusView is registered to the ProtocolLooper's "real" own contact
slot, it would receive all updates… but since Conversations' user-lists and
items would be registered to the Conversation-created "fake" user, they
would be borked.
Simple oversight, but wow it hecked with me. :P
Now the StatusView (bottom-left corner, right below the room list) can
be used to set the nickname and status not only for all accounts at
once, but for managing the status/nick of individual accounts.
AccountManager now can set details of a single account, too.
MainWindow is no longer an Observer (as it just passed the information
along to StatusView― now StatusView manages that itself).
NicknameTextControl was removed, not being in use.
Now all account menus will have the pretty protocol icons to go with
them. :)
The icons are scaled to text-size so that they might be displayed in a
corresponding MenuButton, or maybe BMenuField at some point, and put
into the ImageCache.
The menu items do not have ownership of the bitmaps.
StatusView now allows the selecting of accounts through a MenuButton
with BitmapMenuItems― the button for selecting an account is nice and
discrete, just showing the bitmap of a protocol (in leiu of a label).
No functional changes, other than this menu.
I tried making all AccountsMenus use BitmapMenuItems, but that gets
unweildy pretty quickly― for now they remain in this menu. Maybe
optional ownership of bitmaps in BitmapMenuItems and caching of protocol
items would help.
/me waves arms in the air like a maniac
/me knocks over a nearby cup of coffee
/me gasps when the coffee spills onto the adjacent laptop
/me cries out “Fore! Wait, four! Wait, fire!” when the laptop bursts
into flames
/me burns to a crisp
If a room doesn't have a set icon (and it isn't a one-on-one chat, for
which the icon'll come from the other user's avatar), the default icon
is now determined based on user count.
If there's X users, an icon with X people will be displayed, up to four.
After that, a "+" is overlayed on the icon.
Not really necessary… but I think it's cute. :-)
If the user has permission to change a room's subject or name, they can
now edit the text views displaying them (toward the top of the window).
When enter is pressed, the changes will be sent to the protocol.
To do this, a BTextView subclass was added to libinterface
(splitting somewhat from SendTextView)― EnterTextView sends a message
containing the text to the given target when the user hits enter sans
modifiers.
Windows using RosterView (like for the invitiation/new chat dialogues)
have a search-box for filtering between contacts. This allows the user
to type a user ID into this search-box that isn't a contact's ID, which
can then be selected as the user.
This makes common operations (inviting a user/adding a new contact)
a little easier.
For one-on-one chats without a custom icon, the other user's avatar will
be used as the chat's icon.
A default chat icon was also added
(haiku/data/artwork/icons/WebsiteComments).
Replaces libinterface's ToolButton, a custom button that can display
a pop-up menu on click (along with a custom image). It didn't scale well
with different themes and font-sizes compared to BButtons― which
ToolButton is supposed to look like to begin with.
A BButton-derived class is used instead, so these buttons look more
in-place among other buttons.
CreateAccountMenu() is used to populate a BMenu with items corresponding
to the map of accounts provided to it― but when an account is disabled
or enabled, it can't update automatically.
A dedicated class, fAccountsMenu, now replaces it― it'll automatically
repopulate the list whenever the active accounts update.
Currently, add-ons are disconnected when ChatProtocol::Shutdown() is
called, which the add-on can do by itself― but there is no standard way
for add-ons to notify the app about their Shutdown. Because of this,
they tend to not call Shutdown()― instead (as in the case of the Jabber
add-on), they display a BAlert (IM_ERROR) notifying the user of the
connection error, but the account is considered active by Cardie (and
its threads are still existant, including its ProtocolLooper).
Zombies are bad, so this is redesigned somewhat with this commit:
Protocols should no longer call ChatProtocol::Shutdown() themselves,
they must send an IM_MESSAGE of IM_PROTOCOL_DISABLE to the app.
This will delete its ProtocolLooper, which in turn will send a
notification to the user and delete the ChatProtocol, and so
calling ChatProtocol::Shutdown().
In the included protocols, an IM_ERROR is sent right before
IM_PROTOCOL_DISABLE is sent if due to a connection error. This is not
required, but it is courteous to inform your user about the "why." :)
Like the notification sent when accounts are ready (IM_PROTOCOL_READY),
one's been added for when accounds have disconnected/are disabled:
IM_PROTOCOL_DISABLED.
Also, error BAlerts (created with IM_ERROR messages) are now more
detailed, showing the associated accounts' name in the header.
Jaidyn Ann