[rfc] developer documentation on user interaction

[Alexander Belchenko]

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

s/I can/I can't/