[rfc] developer documentation on user interaction

[Alexander Belchenko]

Vincent Ladeuil пишет:
>>>>>> "martin" == Martin Pool <mbp at canonical.com> writes:
> 
>     >> I honestly feel that Gui's should be interacting with an
>     >> object model, and never interacting via a stdout
>     >> pipe. Though qbzr's policy of interacting via a subprocess
>     >> (to preserve interactivity in the main thread, IIRC) means
>     >> that this is difficult.
> 
> I think we *really* should discuss with Qbzr devs (hey guys, are
> you there ? :).

We are there. But I have no words to comment this. I don't know what you 
want to hear.

> There are two different problems entangled here.
> 
> Qbzr want to interact with a subprocess to keep the main thread
> responsive. Good.
> 
> Qbzr want to interact with bzr via pipes. Not good.

But and not too bad either.

<offtopic>
Just yesterday I've read wonderful new article from Joel:
http://www.joelonsoftware.com/items/2009/09/23.html
and http://www.jwz.org/doc/worse-is-better.html

And looking at the competition bzr vs hg I think I see why hg is so 
widely adopted and recommended. Because they don't try to find the ideal 
solution for every problem. It's my personal opinion, but there are 
still not implemented a lot of cool features in bzr, because in the past 
proposed solution was not ideal for core devs POV. I'd happy to feel 
wrong here, but I'm still feel sad sad sad.
</offtopic>

> There have been many occurrences where bugs were filed against
> bzr for not providing command line options for features provided
> by bzrlib that qbzr couldn't access...

Today this is only problem with per-file commit messages which used only 
by one big player and nobody else.

> I know Alexander said that, doing so, qbzr had better
> compatibility with several versions of bzr but the price for that
> seems higher than the benefits.

Price for whom?

> I really think qbzr should provide its own wrapper around bzrlib
> so that it can use 1) all the features available in bzrlib even
> when not accessible from the command-line 2) a more adequate
> UIFactory there.

It's a great idea and we discussed it this summer with Gary and Lukas.
The problem is: it requires many efforts to implement it

a) right
b) cover all our current needs.

I see QBzr team too small to promise anything so big. I.e. I can predict 
when I'll have enough free time to even start doing this, and we have 
enough high importance bug so far, and...

> 
> Can you guys comment on that idea[1] ?
> 
>     Vincent
> 
> [1]: And don't conclude too fast that I don't want to support
> qbzr, I'm searching for the best way to support it instead and
> want to discuss alternatives.
> 
>