Pidgin

In HEAD we still have 2 members in the buddy structure that have been
there since before I started hacking on gaim, and have been obsoleted by
the status rewrite.  I'm of course talking about uc and present.

uc is on it's way out, but we still have protocols that are using it,
like novell.  I've tried to take a look at updating novell, but having
never even used the protocol, I have no idea what are considered valid
states and so on.

present on the other hand isn't directly related to the new status code.
For the most part it is used to determine if a buddy is online, recently
online, offline, or recently offline.  While this is somewhat used in
the core (to correctly calculate contact and group counts) I would argue
that is more of a UI concept.  But if we still want this behavior in the
core to keep the counts on groups and contacts than I suggest  that we
move it to a status type attribute of recent on both the online and
offline statuses.

Well I just wanted to get everyone's thoughts on this before I actually
started changing any of it.

--=20
Gary Kramlich <grim@...>

On Mon, May 16, 2005 at 06:00:28PM -0500, Ethan Blanton wrote:
> Luke Schierer spake unto us the following wisdom:
> > After today's flood of fake bounce messages, I have changed this list
> > such that you must be subscribed to post.  I realize this is somewhat
> > of a pain, as users who are cc'ed on help threads will not be able to
> > reply to the list in general, however, I think given the usage
> > patterns I have been seeing, where you all come through with just the
> > right answer and no reply is needed, I think we can survive this
> > change.
> > 
> > if someone thinks this is a bad idea and can support their position
> > logically and persuasively, I will revert the change.
> 
> I  think this is a bad idea, because I have no idea what address I might
> have used to sign up to this list.  I generally despise  subscriber-only
> lists,  for  a  number  of reasons, this being only one. A probably more
> important reason is, as you mentioned, non-list-subscribers who are Cc'd
> in order to bring in important outside opinions or information.
> 
> I  didn't  look  closely at the flood this morning, so perhaps they were
> just tricky spams, but it looked  to  me  like  they  were  bounces  ...
> there's  no  logical reason for the list to accept mail from mailer-dae-

they were fake bounces.  the email supposedly bouncing was not sent
from the list.

> mon@ anyway, so I would take the approach of simply  shutting  out  that
> address.   As  far  as  other spams ... I don't get those, because I use
> effective spam filtering.  I cannot condone impingement upon the utility
> of this list simply for the sake of those who do not have effective spam
> filters.

right, I do not get most spam but fake bounces are particularly hard
to filter out without missing real bounces.

I have however turned on posting from anywhere in responce to sf's
stepped up efforts to reduce spam.  apparently the flood that hit us
was SF-wide.

luke

> 
> Ethan
> (Who may or may not get bounced by the new policy)
> 
> -- 
> The laws that forbid the carrying of arms are laws [that have no remedy
> for evils].  They disarm only those who are neither inclined nor
> determined to commit crimes.
> 		-- Cesare Beccaria, "On Crimes and Punishments", 1764

I have updated my master copy of these ideas at
http://gaim.sf.net/luke/windowstuff
to reflect the ideas I have seen presented in this thread.  If no
further objections, clarifications, or enhancements are made by
tomorrow morning (EDT), I will pass this on to Warren as per his
request (which started this thread).

luke

On Mon, May 16, 2005 at 02:46:37PM -0400, Etan Reisner wrote:
> On Wed, 11 May 2005, Luke Schierer wrote:
> 
> > * window focus should only be transfered from one window to another by the direct action of the user.
> > 	* The WM does not know when a new window is user initiated or not.
> > 	* The application that requests the new window does know
> > 	* In the case of new application launch, this yields a useful result: you can start several things
> > 	  in the background (or on login) and not have your focus jerked around as they start.
> I agree. If, however, people feel that there should be a way for an
> application to request focus on mapping that's fine. Such a
> specification should be written such that it is an opt-in concept, not
> an opt-out one (or one that requires all applications to follow for it
> to work). For example, given our experience with metacity (and the focus
> stealing prevention spec) the fact that gaim does not do anything to
> accomodate the spec used to cause all of our windows to be on top and
> focused, and now causes all our windows to be popped up underneath other
> windows.
> This is really an unacceptable way to design a new specification,
> especially when dealing with something as old as X and which has legacy
> applications which one wants to continue to have act correctly. If the
> purpose of this spec is to only make windows that really want focus on
> map to get it than require that *those applications* set the property
> to some agreed upon value or set of values, and that anything which
> does not is going to be treated in a wm consistent and non-annoying
> fashion (i.e. not given focus on map, but also not hidden and therefore
> requiring further specification to function usefully).
> 
> > * new windows should be created at the top level unless specifically requested otherwise by the starting
> >   application.  Placement should reflect some overall policy of the WM, preferably a policy that the
> >   user understands and can predict.  Remembering previous placement is a reasonable, but not required,
> >   part of said policy.
> I mostly agree with this, however I can certainly imagine the case where
> a wm which supports absolute Z-levels would want to group windows by
> class, instance, or other criteria and as such I can certainly accept
> the idea that a wm would have a policy which doesn't put windows on the
> top level at all times. When the wm put a window in a non-obvious place
> it should then indicate this to the user somehow. (This by the way is
> where I think the _NET_WM_STATE_DEMANDS_ATTENTION stuff has merit, to be
> the property of a window that the wm sets when, according to policy, a
> window was not given the visibility it, or the user, might otherwise
> have been expecting.)
> 
> > * Applications which currently have focus should be able to determine if a window said application has
> >   created gets focus or not.  It should be able to do so without changing the level at which the window
> >   is created.
> I agree 100%. Since I do not know of any currently existing method to
> have an application indicate this to the wm there is certainly room for
> a specification to clarify how this should be done. I do not however
> think that _NET_WM_USER_TIME in it's current overloaded and (to my mind)
> poorly designed state is viable for this. I would suggest something
> along the lines of a _NET_WM_[GET_|TAKE_|REQUEST_]FOCUS property.
> 
> > * Applications which do not have focus should not be able to pull focus from another application in a
> >   way that the user cannot disable or modify.  Changes to individual applications at a source code
> >   level should not be necessary for this behavior.
> I likewise agree 100%. I think that this is again a place where the
> _NET_WM_STATE_DEMANDS_ATTENTION property has merit, it should be used to
> indicate that a window was created or requested focus and was not given
> it to comply with the window managers policies on focus and as such
> attention should be paid to it shortly. (As an example, my window
> manager has a small activity notification bar which appears at the top
> left of the screen when a window is created on a desktop other than the
> one you are currently viewing. It also uses this activity notification
> bar to indicate when a window has set the Urgency hint.
> 
> 	-Etan
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Gaim-devel mailing list
> Gaim-devel@...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel