Windows UI summer of code project

Eoin Coffey ecoffey at
Tue Apr 21 11:21:40 EDT 2009

On Tue, Apr 21, 2009 at 9:13 AM, John Bailey <rekkanoryo at>wrote:

> Mark Doliner wrote:
> > This year we accepted TWO students to work on a better/native Windows
> > user interface for libpurple.  It's not decided what these projects
> > entail exactly, nor if/how these two students should interact.  I know
> > I'm opening a can of worms here, but I think it's probably a good idea
> > for us to talk about what we'd like to see from these projects.  The
> > language and drawing toolkit are the biggest decisions.  Wade proposed
> > using either .NET or XULRunner with the possibility of also comparing
> > against MFC, and Gregor proposed using straight up win32 api.
> For the record, I'm fine with one project being .NET and one being W32API.
> > In our comments on Wade's proposal we expressed some concern about
> > using XULRunner, since there already exists a project called
> > Instantbird [1] which is an IM program which uses libpurple and XUL
> > for the UI.  I'm not very familiar with Instantbird...
> <snip>
> > I really should stress
> > that I'm not very familiar with XUL, but I'm worried that it isn't
> > native enough.
> These are concenrs I share.  I would hate to restrict a Windows UI project,
> but
> at the same time I'd hate to duplicate or detract from the work Florian and
> his
> contributors have done to date on Instantbird.
> <snip>
> > My experience with .NET 1.x and 2.x UIs from years ago left me with a
> > feeling that it was good, but not as good as programs written using
> > the win32 api or mfc.  I remember minor flickering and slowness to
> > draw the UI when launching an application initially.  But I've heard
> > .NET UIs have improved in recent versions.
> I too have had less than optimal experiences with .NET applications on
> Windows.
>  the new 250MB (on x86, it's even bigger on "x64") .NET Runtime 3.5 has
> helped
> things quite a bit, but there's still the initial lag due to loading the
> crapton
> of new libraries.
> > I feel like the lower-level solution would allow for a more perfect
> > product.  But a higher-level language would be more accessible to
> > developers, and that's very important since we want this project to
> > survive and prosper on its own.
> Both projects could survive on their own after the SoC.  It's also possible
> that
> each project could make different choices to best serve a particular set of
> Windows users, thus achieving my primary goal with a Windows UI--provide
> something that serves our Windows users better than GTK+ does.  If two UI's
> make
> us better able to fit Windows users' needs, then it's definitely time and
> effort
> well spent.
> > It sounds like Wade and Gregor might not have very overlapping
> > experience with Windows UI toolkits.  Gregor, are you very familiar
> > with MFC or .NET?  Wade, are you very familiar with win32 or MFC?  If
> > not then it seems like it makes the most sense for the two students to
> > work independently, with Gregor using win32 and Wade using .NET (or
> > maybe XUL or MFC).
> The two students have to work independently anyway to comply with the terms
> of
> participation in SoC.  Of course, there's no reason they can't share ideas,
> but
> they can't commit to each others' branches.
> John
> _______________________________________________
> Devel mailing list
> Devel at

If comfortable working in .Net, and we have a reasonable C# wrapper (*looks
at aluink*), I would recommend implementing the UI in WPF.  Its
the successor to WinForms, and something Microsoft itself is dog fooding in
the next visual studio release.  I've play with it a little, and it seems
like a pretty slick way to put together a UI.  I have some links and other
info to share with anyone offline if they're interested.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Devel mailing list