Windows UI summer of code project

Tue Apr 21 12:00:26 EDT 2009

As Gregor said, many thanks to the whole pidgin team for accepting our
summer of code applications -- I'm excited to be part of a project
that I use every day, doing something I love, and getting experience
in the open source community.

On Tue, Apr 21, 2009 at 9:13 AM, John Bailey <rekkanoryo at rekkanoryo.org>
...
> 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).

I haven't done any straight native win32 API work, but I've done quite
a bit of extensive programming in straight C in the past couple of
years -- so, if necessary, it's just a matter of learning the API to
help work/contribute/colab on any native win32 code.  I've done some
toy applications in MFC, so I have some experience there -- though
it's far less than Windows.Forms/.NET or XUL.  Looking into Eoin's
suggestion of WPF, it looks to be an XUL-like approach to native
Windows GUIs and could be worthwhile to evaluate what kind of
performance hit it takes over .NET as it's an abstraction above
WinForms.
...to throw out some more ideas, Adobe AIR is also gaining popularity.
Probably not a platform we want to use due to it's proprietary nature,
but we could do a toy implementation to look at performance there as
well v. XUL v. WinForms v. WFC v. native-win32 if we're concerned
about that.

On Tue, Apr 21, 2009 at 10:01 AM, Gregor Dick <igregord at googlemail.com> wrote:
...
> As regards the MFC, I'm not sure that it's really appropriate for the
> task. It's a bit more than just a wrapper for the Win32 API, and a lot
> of its functionality is geared towards 'productivity'-type apps, with
> its Document/View model. Also, I have scarcely worked with it myself;
> Wade, do you have a clearer idea of how using the MFC might work out?

There are some elements of a MVC involved in MFC, but I don't know if
an MFC-approach isn't a desired approach.  Any GUI for pidgin is going
to be a very reactive GUI (eg: only a user interaction or an external
message triggers a state change of the GUI for the most part), which
seems to almost beg for a MVC design.  However, I haven't looked
deeply into this, so there may be some major downsides that you're
aware of that I'm not in the usage of MFC.

- wade

On Tue, Apr 21, 2009 at 10:21 AM, Eoin Coffey <ecoffey at gmail.com> wrote:
> 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.
>