Windows UI summer of code project

[Eoin Coffey]

On Tue, Apr 21, 2009 at 9:13 AM, John Bailey <rekkanoryo at rekkanoryo.org>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 pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>

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: <http://pidgin.im/pipermail/devel/attachments/20090421/daa86fe7/attachment.html>