[rfc] developer documentation on user interaction

[Vincent Ladeuil]

>>>>> "Gary" == Gary van der Merwe <garyvdm at gmail.com> writes:

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

Sometimes things have to be said :-D

<snip/>

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

Nothing wrong with that, the problem is not trivial anyway.

    Gary> I personally feel that a single process, 2 threads, one
    Gary> for ui, one for bzrlib, and some way for them to talk
    Gary> (probably using qt event signals) would be much
    Gary> better.

I'm pretty sure GTK provides ways for processes to exchange
events, I'd be surprised if qbzr couldn't do the same.

Otherwise, you'll have to serialize/deserialize them in the
pipes, since you're dealing with the same code on both sides, you
shouldn't encounter nasty problems there.

    Gary> This is a change I really want to make, but I have not
    Gary> had the time yet. And I think that the uncertianty of
    Gary> how much work it will be keeps me putting it off :-(

I fully respect that.

<snip/>

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

Yes, see other thread. 2.0 uses 1.17.0, we switched to 2.1.0 for
bzr.dev but that's really minor and you shouldn't even think
about it since the change is about bzrlib.user_encoding instead
bzrlib.get_user_encoding() and I'm pretty sure you didn't do the
former for quite same time.

What would be very valuable for everybody involved is that you:
- list every private API you're currently using,
- file bugs when you encounter API changes that break qbzr.

        Vincent