Google Summer of Code
igregord at googlemail.com
Sat Mar 7 17:08:27 EST 2009
John Bailey wrote:
> Not that it matters much, but I thought MFC applications were possible to build
> with MinGW as long as you had the headers? That said, it doesn't matter too
> much for the purpose of the Win32 UI SoC project whether MinGW or Visual Studio
> is the preferred toolchain--if the project is successful, I want to split it
> away from Pidgin and have it be a separate project in the vein of Adium. I
> already have a trac environment set up at vulture.rekkanoryo.org, as the
> preferred applicant last year agreed to the name Vulture (to keep with the bird
> theme for UI names).
Thanks for the quick response. My understanding was that compiling in
the way you describe would result in binaries that weren't
ABI-compatible with Microsoft's libraries due to the differing binary
layouts of C++ objects between the compilers. In any case, I'm not
sufficiently well-acquainted with the MFC to propose to use it for this
project, but this might be of interest to other potential applicants.
Having had a quick look at the Vulture repository I see that there are
MSVC projects for libpurple there already, and so I'll probably propose
to work with those. A MinGW build environment could always be crafted
later so as not to discommode people who, for example, want to
cross-compile, but aiming to support two compilers during SoC sounds
like an unnecessary headache.
>> As far as I'm aware there hasn't been any concrete discussion regarding
>> particular requirements for a Win32 front-end, for instance in which
>> respects, if any, it should attempt to be self-consciously Pidgin-ish.
>> If there's any established opinion on such matters, I'd be grateful if
>> someone could please point it out so that I can work it into my proposal
>> and prototype when the period for applications begins.
> I was hoping that the design would be overall similar to Pidgin, but with
> behavior that makes sense for the Windows users. For example, the buddy list
> design works well, but the mini dialogs that we have may not make sense in a
> Windows application (I've never seen such a thing on Windows). The Pidgin
> preferences window design may not make as much sense as something that's more in
> line with other applications on Windows. There are other examples, but I can't
> think of them at the moment.
The mini dialogues (I take it these are "Join a Chat" and so on) could
probably be made to feel more natural on Windows simply by expanding
them a bit and maybe adding some group-box static controls, without
interfering too much with the function of each dialogue as in Pidgin.
One thing that I'll put some thought into for my proposal is what to do
with the modeless on-top dialogues (e.g. "Manage Accounts"), which will
need to be handled carefully if their functionality is to be preserved.
Thanks for making those points; I'll take them into account when I apply.
More information about the Devel