Google SoC Introduction
Tim at TimWaterhouse.com
Mon Mar 30 09:24:42 EDT 2009
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.
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
> > 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
> > 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
> > 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
> > 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
> > 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,
> > let me know if I'm looking at this project from the wrong angle. Also,
> > 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
> > 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
> * 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel