[rfc] developer documentation on user interaction

[Gary van der Merwe]

This seems to be quite an emotional discussion.... (/me treads carefully)

On Fri, Sep 25, 2009 at 1:17 PM, Vincent Ladeuil <v.ladeuil+lp at free.fr> wrote:
>>>>>> "Stephen" == Stephen J Turnbull <stephen at xemacs.org> writes:
>    Stephen> The problem is, as Alexander says, that the CLI is
>    Stephen> *much* more stable than the API.  *In hindsight*, I
>    Stephen> am not at all surprised.
>
> That's precisely the assumption I'm challenging here.
>
> I don't have enough qbzr coding experience to speak, but based on
> my bzr-gtk and bzr/bzrlib experience, I didn't see that much
> changes in neither bzr nor bzrlib nor bzr-gtk that required
> *more* work because bzrlib was used instead of bzr (the notable
> exception being the new progress bars whose design was changed to
> better address GUI needs, by the way).

No - I don't think that api stability was the reason why we (luks)
chose the subprocess design. The reason why it was chosen was for
maintaining ui interaction.

I personally feel that a single process, 2 threads, one for ui, one
for bzrlib, and some way for them to talk (probably using qt event
signals) would be much better. This is a change I really want to make,
but I have not had the time yet. And I think that the uncertianty of
how much work it will be keeps me putting it off :-(

> But here, on of my arguments is that both qbzr and bzr-gtk try to
> maintain *one* source base to run against several versions of
> bzr, while it may be *less* effort to only support the last or
> the most recent bzr versions.
>
> Since bzr and the associated plugins are generally packaged
> together, what I'm asking here is: who cares that qbzr and
> bzr-gtk are maintaining compatibility with older bzr versions ?
>
> And speaking of bzr-gtk is the long list of supported versions
> really accurate ? Does it really support 1.6.0 ? Who tried last ?
>
> And what bzr version does qbzr support ? And who use what ?

Yes - Supporting older versions is a pain. qbzr has never a minimum
bzrlib version check. I plan to put one in soon. For a while, we will
support 2.0.x (which I believe has api version 1.17) and latest.