Windows UI summer of code project

Mark Doliner mark at kingant.net
Tue Apr 21 04:22:34 EDT 2009


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.

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... it might be
possible to talk to the developers of that program and see if they
would welcome a collaborator.  I'm also not very familiar with XUL...
one question I have is whether it's capable enough to create a UI that
does what we want.  I would hate for this project to be restricted by
the use of XUL.  I feel like if we're going to create a new UI with
the goal of meshing with the Windows OS then we should make sure the
graphics toolkit we pick supports that goal.  I really should stress
that I'm not very familiar with XUL, but I'm worried that it isn't
native enough.

I'm not very familiar with Windows programming either.  It sounds like
the win32 API is a C API and is about as low-level as it gets (aside
from assembly)?  And MFC is a set of nice C++ wrapper classes around
the lower-level win32 api?  And .NET is built on top of the
win32API/MFC, but has substantially different API.  Code is written in
any language that supports .NET (like C#, VB.NET, managed C++), and is
compiled to a language-neutral assembly file.

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.

In terms of low-level to high-level we have:
win32 API <--> MFC <--> .NET <--> XUL

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.

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).

-Mark

[1] http://instantbird.com/




More information about the Devel mailing list