If buddy is on neither Allow nor Block list, then add to Allow list.
At some point, we should figure out if the NetworkInfo really is used
for this sort of thing.
/*
* purple
*
* Purple is the legal property of its developers, whose names are too numerous
* to list here. Please refer to the COPYRIGHT file distributed with this
* source distribution.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02111-1301 USA
*/
#ifndef _PURPLE_STATUS_H_
#define _PURPLE_STATUS_H_
/**
* @file status.h Status API
* @ingroup core
*
* A brief explanation of the status API:
*
* PurpleStatusType's are created by each PRPL. They outline the
* available statuses of the protocol. AIM, for example, supports
* an available state with an optional available message, an away
* state with a mandatory message, and an invisible state (which is
* technically "independent" of the other two, but we'll get into
* that later). PurpleStatusTypes are very permanent. They are
* hardcoded in each PRPL and will not change often. And because
* they are hardcoded, they do not need to be saved to any XML file.
*
* A PurpleStatus can be thought of as an "instance" of a PurpleStatusType.
* If you're familiar with object-oriented programming languages
* then this should be immediately clear. Say, for example, that
* one of your AIM buddies has set himself as "away." You have a
* PurpleBuddy node for this person in your buddy list. Purple wants
* to mark this buddy as "away," so it creates a new PurpleStatus.
* The PurpleStatus has its PurpleStatusType set to the "away" state
* for the oscar PRPL. The PurpleStatus also contains the buddy's
* away message. PurpleStatuses are sometimes saved, depending on
* the context. The current PurpleStatuses associated with each of
* your accounts are saved so that the next time you start Purple,
* your accounts will be set to their last known statuses. There
* is also a list of saved statuses that are written to the
* status.xml file. Also, each PurpleStatus has a "saveable" boolean.
* If "saveable" is set to FALSE then the status is NEVER saved.
* All PurpleStatuses should be inside a PurplePresence.
*
*
* A PurpleStatus is either "independent" or "exclusive."
* Independent statuses can be active or inactive and they don't
* affect anything else. However, you can only have one exclusive
* status per PurplePresence. If you activate one exclusive status,
* then the previous exclusive status is automatically deactivated.
*
* A PurplePresence is like a collection of PurpleStatuses (plus some
* other random info). For any buddy, or for any one of your accounts,
* or for any person with which you're chatting, you may know various
* amounts of information. This information is all contained in
* one PurplePresence. If one of your buddies is away and idle,
* then the presence contains the PurpleStatus for their awayness,
* and it contains their current idle time. PurplePresences are
* never saved to disk. The information they contain is only relevant
* for the current PurpleSession.
*/
/**
* PurpleStatusType's are created by each PRPL. They outline the
* available statuses of the protocol. AIM, for example, supports
* an available state with an optional available message, an away
* state with a mandatory message, and an invisible state (which is
* technically "independent" of the other two, but we'll get into
* that later). PurpleStatusTypes are very permanent. They are
* hardcoded in each PRPL and will not change often. And because
* they are hardcoded, they do not need to be saved to any XML file.
*/
typedefstruct_PurpleStatusTypePurpleStatusType;
typedefstruct_PurpleStatusAttrPurpleStatusAttr;
typedefstruct_PurplePresencePurplePresence;
typedefstruct_PurpleStatusPurpleStatus;
typedefstruct_PurpleMood{
constchar*mood;
constchar*description;
gpointer*padding;
}PurpleMood;
/**
* A context for a presence.
*
* The context indicates to what the presence applies.
*/
typedefenum
{
PURPLE_PRESENCE_CONTEXT_UNSET=0,
PURPLE_PRESENCE_CONTEXT_ACCOUNT,
PURPLE_PRESENCE_CONTEXT_CONV,
PURPLE_PRESENCE_CONTEXT_BUDDY
}PurplePresenceContext;
/**
* A primitive defining the basic structure of a status type.
*/
/*
* If you add a value to this enum, make sure you update
* the status_primitive_map and primitive_scores arrays in status.c.