Showing posts with label pidgin. Show all posts
Showing posts with label pidgin. Show all posts

11 August 2008

Reddit power




Apparently I should get reddited more:





Sadly, that now makes the handful of visits I had before look like 0 on the graph, but oh well. I actually posted that entry on a comment to another post, but apparently somebody reposted it as a story. A surprising number of people agreed with me considering I think it's a minority opinion, but there were plenty that disagreed too. And my anti-Windows thing at the end got interpreted backwards, which lead to confusion: I was saying that Pidgin, as an open source project, should be avoiding the very things that tend to drive people away from Windows. The main reason I love Linux is I can customize whatever I want, effortlessly; Windows is far less flexible. Trillian is an example of an unusually flexible Windows program, which is the very reason I used it, but with Linux it's no longer the exception to find a program that lets me configure it the way I want

EDIT: Apparently I should've waited before taking that screenshot:

08 June 2008

Arguing with users over what they want

I wrote a whole bunch of this a long time ago when I stumbled across the debate that resulted in the FunPidgin (apparently now Carrier) fork of Pidgin. As their website puts it, "Unlike the Pidgin developers, we believe the user should have the final say in what goes into the program."

If you've missed this whole debate (likely even if you use Pidgin), it started with this bug report for Pidgin. The problem was stunningly simple: in the new version of Pidgin, the input text area automatically resizes itself. This is fancy and neat, but it also can't be sized larger than about 4 lines of text, which makes a lot of people sad, and some people find the auto-resizing jarring and unpleasant. This massive support ticket is basically a huge argument between the users and the developers about whether users want this feature or not. Seriously, a whole group of users telling the developers they want something, and the developers telling them they're in some way addled and don't really want it at all.

If your users want a feature, unless it's too difficult or time-consuming to write, you should add it. Your users shouldn't have to defend or justify why they need something, that's ridiculous; if they say they need it, they need it, and developers saying "no, you really don't want that" is absurd. Users have better things to do than sit on your bug tracker begging for you to implement something you've already written; obviously they want this feature.

I've always been of the opinion that if users want two competing ways of doing something it should be an option, which I know isn't a universally accepted view -- I might go so far as to say it's the minority view. I like the ability to customize how my programs work, since usually I don't like the defaults. Trillian was spectacular at this, and it's still my favorite IM client of all the ones I've tried; every single time I disliked something there was a preference to change exactly that. The pidgin developers do not believe this; they state repeatedly that they want a "better" (they frequently put the quotes around it too, like they're mocking themselves) solution than adding a preference. That's great and all, but either find one or give us the choice back. There might be a better solution than adding a preference, but adding a preference is still a better solution than telling a section of your userbase to go fuck themselves. The developers even mock the users in some of the posts, asking why they're not clever enough to write a plugin to do this. Is this supposed to be some sort of battle between developers and users, where developers change something and then taunt the users to try and change it back? I know lots of users don't like preferences; personally, I don't know why they can't just ignore them them, but apparently the mere fact that options exist bothers them in some way. Nonetheless, the users saying that they want an option and the developers telling the users that the users don't want an option is so obviously ridiculous that I can't believe this is still going on.

This quote was particularly amusing; it makes me think maybe the developers are missing the point completely: "it proved to be impossible to get both manual sizing and automatic resizing to work at the same time". Really? That's like saying "well, we tried to let the user set the size manually, but that damn automatic sizing kept automatically sizing". Obviously they can't work together, it has to be one or the other. Almost like it should be the user's choice. Like some sort of "preference" or something. They should have a dialog for those. I loved this solution: "What if manual sizing is disabled when automatic sizing is enabled?" Maybe it's just that this seems way more obvious to me than it apparently is to other people if this was actually considered ground-breaking enough to post, so I'll lay out my fairly brilliant solution to this problem in hopes of merging: Have an "automatic input resizing" checkbox. When it's checked, the input box auto-resizes. Manual resizing does not work. When it's unchecked, the box can be manually resized. Auto-resizing does not work. If anyone needs further clarification, I will send them a truth table

I dislike the notion that developers need to protect the silly users from themselves and not give them an option that deep down the developers are confident users really don't want. This is very much a Windows point of view.

27 February 2008

Water ripple as demands_attention indicator

I came across an interesting effect for Pidgin (or anything else, really). It requires Compiz; specifically, it requires the Water Effect plugin. I'm also pretty sure it requires GNOME. It turns out compiz has a fantastic dbus interface, you can pretty much get, set or trigger anything using it (more info). You can use any language with dbus bindings, but I prefer shell scripting when I can, so I use the included dbus-send program. To trigger the water effect, the command is:

dbus-send --type=method_call --dest=org.freedesktop.compiz /org/freedesktop/compiz/water/allscreens/point org.freedesktop.compiz.activate string:'root' int32:`xwininfo -root | grep id: | awk '{ print $4 }'`


The backtick expression pulls the root window's ID, which all the compiz activation commands require. That command shows a water ripple in the middle of the screen. My goal was to make the Pidgin icon ripple when I got a new message, which I'd noticed in a youtube video once and liked. I found code that uses xwininfo to figure out the location of a gnome panel icon, and combined it with the dbus call to make the ripple effect around a panel icon:

#!/bin/bash
#WINFO=`xwininfo -root -tree | egrep ' (1[2-9]|2[0-4])x(1[2-9]|2[0-4])\+0\+0' | grep "$1" | cut -d ')' -f 2-`
#This WINFO is faster to calculate, but depends on the icon being in the top panel
WINFO=`xwininfo -root -tree -name "Top Expanded Edge Panel"| grep "$1" | cut -d ')' -f 2-`
WIW=`echo $WINFO | cut -d 'x' -f 1`
WIH=`echo $WINFO | cut -d 'x' -f 2 | cut -d '+' -f 1`
WIX=`echo $WINFO | cut -d '+' -f 4`
WIY=`echo $WINFO | cut -d '+' -f 5`
let WAX=WIX+WIW/2
let WAY=WIY+WIH/2

dbus-send --type=method_call --dest=org.freedesktop.compiz /org/freedesktop/compiz/water/allscreens/point org.freedesktop.compiz.activate string:'root' int32:`xwininfo -root | grep id: | awk '{ print $4 }'` string:'amplitude' double:.1 string:'x' int32:$WAX string:'y' int32:$WAY


All that's left is to call the script when a message comes in. The accepted way I found was to change Pidgin's sound settings, but I'd prefer to leave them the way they are. Instead, I wrote a Pidgin plugin (in Perl, because C makes me sad) that waits for the received-im-msg signal and calls the shell script:

use Purple;

%PLUGIN_INFO = (
perl_api_version => 2,
name => "Icon Ripple",
version => "2.0.0",
summary => "Shows water ripples around the Pidgin icon",
description => "Shows water ripples (powered by the Compiz Water Effect plugin) around the Pidgin icon when a message is received",
author => "Michael Mrozek <sysop073\@gmail.com>",
url => "http://pidgin.im",
load => "plugin_load"
);

sub plugin_init {return %PLUGIN_INFO;}

sub plugin_load {
my $plugin = shift;
Purple::Signal::connect(Purple::Conversations::get_handle(), "received-im-msg", $plugin, \&signal_msgin, "");
}

sub signal_msgin { #(account, sender, message, conv, flags)
system("/home/mrozekma/scripts/waterping","Pidgin");
}


This has a side-effect that some may not like of showing the ripple on every received message, not just ones when the window is demanding attention. There's probably a way to change this in the plugin, but I prefer it that way so I haven't explored it.

EDIT: I forgot that I took a screenshot of the ripple effect before I wrote this article, and never included it. It's not very good, but you can see the effect at least: