Google SoC Introduction

[Timothy Waterhouse]

Mark,
GDI will be critical in making the "big list" which is the main problem I
foresee.  I love the big list and equate it to a critical element of the
pidgin interface.  I'm in the process of writing up an official proposal
right now and I'll include a list of parts to be mimicked closely and parts
to fall to the operating system defaults.

Thanks for the input, I hope to be working with you guys this summer.

Tim Waterhouse

On Mon, Mar 30, 2009 at 2:39 AM, Mark Doliner <mark at kingant.net> wrote:

> 2009/3/28 Timothy Waterhouse <Tim at timwaterhouse.com>:
> > Hi Everyone,
> > Just wanted to introduce myself because I plan on applying for a SoC
> > position with writing a better Windows front end.  My name's Tim
> Waterhouse
> > and I've been using pidgin/gaim since back when it was highly recommended
> > people use the nightly builds (I think back around version .4).  At one
> > point I wrote a few plugins to do miscellaneous tasks for me but I never
> > maintained them when the protocol functions changed.  Below I've put a
> run
> > down of my background, but I'm first going to put a rough idea of the
> > Windows front-end.
> > Windows Front-End Goals:
> > 1) Use native Windows UI elements
> > 2) Make interfacing with the libpurple library as easy as possible
> > 3) Make it so building both libpurple and the front-end at the same time
> is
> > easy
> > I'm leaning toward using unmanaged C++ to write the front end using MFC
> > classes because that will get rid of a lot of the dll issues.  For ease
> > of maintenance, however, managed code would be easier as long as wrappers
> > are written for the unmanaged libpurple.  I've done this before so I know
> it
> > is possible, it really depends on the comfort level you, as pidgin
> > developers, have for managed vs. unmanaged Windows code.  I do plan to
> > maintain this project long after the summer ends so I suppose it really
> > wouldn't be much of an issue.
> >
> > My background is fairly simple.  I've got a dual degree from undergrad in
> > Electrical Engineering and Computer Science.  I interned for General
> > Electric for two summers designing and writing programs and I worked for
> > Microsoft as an intern this past summer.  I'm highly fluent in C, C++ and
> > C#.  In undergrad I took a course where I made several Windows UI
> programs
> > using just assembly so I have a very good grasp of the scope of this
> > problem, particularly using GDI to do the drawing.  My goal would be to
> > match the look of the Linux native client but using Windows UI elements.
> > I look forward to hearing back from those involved in this project,
> please
> > let me know if I'm looking at this project from the wrong angle.  Also,
> feel
> > free to contact me on aim at caffineehacker.
> > Hope to be working with you guys this summer,
> > Tim Waterhouse
> > P.S. My final proposal will be more flushed out, I just want to throw
> some
> > ideas around before I write it up.
>
> Hi Timothy.  It sounds like you're looking at this at the right angle.
>  One thing I thought I'd mention... I'm not sure what you have in mind
> with respect to using GDI to do the drawing to match the look of the
> Linux native client.  I think we're less concerned about the windows
> UI looking exactly like Pidgin, and more concerned with the Windows UI
> fitting in with other native Windows applications and respecting
> Microsoft's design guidelines.  I can't speak for everyone, but I
> think we generally feel like applications should mesh with the
> operating system on which they run, and that means meeting users
> expectations for the way things look and behave.
>
> But at the same time, Pidgin has undergone years of evolutionary
> design and UI experimentation and careful thought and planning, and
> there are a lot of basic decisions that should probably remain the
> same:
>
> * Similar looking buddy list.  The "big list" version for sure,
> possibly the "small list" version as an option (see Tools->Show->Buddy
> Details if you have no idea what I'm talking about).  Buddy icons to
> the right of the buddy name.
> * Status selector at the bottom of the buddy list.
> * Show aliases/friendly names everywhere.
> * Allow for multiple accounts on all our supported protocols, with
> some sort of account management window.
> * A similar set of preferences.
>
> -Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20090330/a883d59e/attachment.html>