MeMaker should support Drag and Drop of avatar preview

I like your idea. But it's not really a bug, rather, a feature. Could
you reimplement this as a blueprint rather than a bug? Thanks! We will
review this feature and accept or regect it for the 2.0 series when the
time comes. (Probably just before the Hardy release.)
None, the less, I totally agree. It's a great feature idea.
Jason Brower
On Mon, 2008-02-11 at 20:52 +0000, Dylan McCall wrote:
> Public bug reported:
>
> Memaker currently does not make changing avatars as easy as it could.
> One nice way this could be fixed is the inclusion of drag & drop
> support. Many programs which have avatars support dragging images on to
> their avatar image selectors. Two programs which do this are gnome-
> about-me and Pidgin.
>
> One program that supports dragging images to drop them in this way is
> The GIMP, with its image selector in the tool window. Notable in that
> one is how it seems to figure out where the image has been dropped and
> starts saving to there instead of the original source location. (Which
> is quite confusing in the case of that program, but could be a powerful
> feature for MeMaker!).
>
> MeMaker could implement this drag & drop functionality with the user
> dragging the avatar preview. If the capability of directly manipulating
> features on an avatar is implemented, the handle could be moved to the
> side of the preview (possibly on a Frame container) rather than being
> the entire preview widget. By supporting drag & drop, MeMaker can have a
> highly integrated feel that remains completely future proof.
>
> ** Affects: memaker
> Importance: Undecided
> Status: New
>

Here's a patch! :)

Current issues with this:

-Pidgin gets confused. It seems that once I have dropped a MeMaker avatar on to it once, I must restart the program for it to visibly update its avatars. Reason for this is because the dropped URI does not change. I blame Pidgin; it really should be copying the file to its own territory.

-Alas, no Pixmaps fun. I had implemented it, and it worked (PyGTK makes it dead easy!). I trimmed that out to streamline the code, since none of the systems I intend to target use Pixmaps. Furthermore, since this is an advanced SVG image, it would not make sense for a program to load the avatar as a pixmap! I decided that Dropping pixmaps added some extra stuff to maintain, which could easily lead to a regression down the line when fixes for drift out of scope.

-Added an import of gnomevfs at the top. Possibly overcome by hard-coding "file://", or via a command we already have available.

Other than that, it lives! (And the diff worked out nicely, to boot).
This is based on bzr trunk, hopefully the latest revision.

Darn, if I keep this up I'll get tagged as a spammer!

Here's another patch. Removed import of gnomevfs; using the path (/home/user/.MeMaker/avatar.svg) instead of a URI (file://thatpathagain). Does not seem to have injured anything, and I am sure we aren't the only ones to do it.

Tidied up comments a little, removed phantom modifications and unwanted extra files.

Oops. Lord, talk about misusing bug trackers...

Okay, last one. Turns out a few programs /do/ mind not being given URIs. A lot. Reverted to the old behaviour.

Merged into trunk