Fw: Re: New UI

[Luke Schierer]

On Fri, Aug 03, 2007 at 02:25:29PM -0400, Allan Clark wrote:
> On 8/3/07, Josh Williams <yurimxpxman at gmail.com> wrote:
> > On 8/3/07, Mark Doliner <mark at kingant.net> wrote:
> > > I think Jeff probably meant to send this to everyone.
> > >
> > > ---------- Forwarded Message -----------
> > > From: "Jeff Sadowski" <jeff.sadowski at gmail.com>
> > > To: "Mark Doliner" <mark at kingant.net>
> > > Sent: Fri, 3 Aug 2007 10:25:49 -0600
> > > Subject: Re: New UI
> > >
> > > Now that libpurple exists how hard is it to write a UI for it?
> > > I might be able to wipp something up. :-)
> > > I can't help thinking of a skin-able chat client.
> > > Allowing you to have it look and act as a user desires. :-P
> >
> > That's what I've been thinking. I'm considering writing a QT UI. I'm
> > not sure I like the idea of a skin-able client, though.. that seems
> > like an awful lot of memory devoted to such a utilitarian application.
> >
> > Kopete already exists, but I'm not a big fan of it. Perhaps a QT
> > implementation of Pidgin could replace it in future versions of KDE.
> 
> The problem with forking a UI or any separation is that newer changes
> are slow to propagate (often) and (often) changes may result in
> unforseen downsream issues.  This would mean that forked UI might
> adopt changes more slowly, and it might be more difficult (ie Adium)
> to implement various features (IRC) already supported by Pidgin.

A QT UI would in no sense be a forked UI.  QT is too different from GTK+
to allow for much code reuse outside of libpurple itself.

> 
> Allowing these things to exist in a similar code trunk as Pidgin might
> allow developers to see th impact of changing a specific API for
> example.  It could also make it harder to maintain since every change
> impact a number of random other things.  I wanted to throw this out
> there:

We already have 3 clients using libpurple.  But in a larger sense, your
argument applies to *any* library, including GTK+ or glibc.  One would
think, if the difficulty were insurmountable, that everyone would be
re-implementing everything from scratch.  In the real world, paying
attention to version numbers and having rules about how we increment the
version number to reflect different changes (and getting the soname to
match) should alleviate most if not all of these difficulties.

We as a project just need to get over the fear of having minor numbered
releases in proximity.  But that is an entirely other discussion.

> 
> It might be possible to fork the UI within the Pidgin tree to offer
> support to both camps, who can then pursue the icons and fonts and
> sizes and windows they prefer.

We are using a distributed version control system, and one with a good
concept of branches, and propagation between them.  This means that it
is trivial for you to pull the database, go back to any revision you
like (say, 2.0.2), branch off of it, and propagate the changes you like.

If the 10 or so of us currently developing pidgin were to try to do this
for every contested change, we would be bogged down simply managing that
many trees.  If you want another tree, you need to find (or be) a
maintainer for it.  Just like what happens with the kernel, which has
tons of git repositories.

> 
> (and maybe one will offer IRC to Mac :) )
> 
> Allan

I'm told IRC is available in the adium subversion repository.

luke