[rfc] developer documentation on user interaction

[Alexander Belchenko]

I should apologize for my bad English skill. It's hard to discuss such 
things when somebody lack of right words.

Vincent Ladeuil пишет:
>>>>>> "bialix" == Alexander Belchenko <bialix at ukr.net> writes:
> 
>     bialix> Vincent Ladeuil пишет:
>     >>>>>>> "Stephen" == Stephen J Turnbull <stephen at xemacs.org> writes:
>     >> 
>     >> Alexander mentioned having troubles separating stderr from stdout
>     >> when using subprocess (I don't see why but without looking at the
>     >> code I trust him), using a dedicated wrapper that can control
>     >> sys.stdout and sys.stderr and all other facets of the UIFactory
>     >> and from there calling bzrlib leave little place for such
>     >> troubles.
> 
>     bialix> I don't remember I've talked about separating stderr and stdout,
>     bialix> so I'm not really sure what you talking about.
> 
> ,----
> | For QBzr needs I'd like to have in UI explicit methods to write
> | error messages. Currently we detect error messages by 'bzr:
> | ERROR:' prefix of the line. And some error messages are
> | multi-line. Heh?
> `----
> 
> You shouldn't have to even think about that with a proper wrapper.

What wrapper? I don't understand.

Currently bzr emits to stderr tooooooooooooooooooooooooooooo much 
different information. I've tried to point to the fact that writing 
things via ui factory currently does not solve the problem with trace.py 
module. They seems to live in different planes. Am I wrong?

>     Stephen> 2.  The audience for the CLI demands stability;
>     >> 
>     >> As in: "I don't want to test which version I'm using so don't
>     >> change anything there or I'm doomed" ?
> 
>     bialix> Yes.
> 
> Hello ? You can't ask for stability AND more features. You
> realized that's what you are doing right ?

My 3 wishes for new features have nothing in common for instability.

Don't push on me, please.

>     Stephen> the audience for the API demands features.
>     >> 
>     Stephen> I think "Although practicality beats purity"
>     Stephen> applies.
>     >> 
>     >> 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.
> 
>     bialix> This is wrong assumption.
> 
> So why do you confirm it just below ?

I don't know what you mean.

>     >> 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 ?
> 
>     bialix> I care.
> 
>     >> And what bzr version does qbzr support ? And who use what ?
> 
>     bialix> Usually bzr v.CURRENT-1 (or -2).
> 
> See ? You care only about "the last or the most recent bzr versions".

So what's wrong with that?

>     >> Don't get me wrong either, I do care a lot about compatibility, I
>     >> just want to understand if we are talking about theory or
>     >> practice here.
> 
>     bialix> The practice for QBzr is that: if you need to write simple GUI
>     bialix> wrapper about straightforward bzr command, like say bzr check or
>     bialix> bzr reconcile, you don't need to copy paste entire run method
>     bialix> from bzrlib/builtins.py 
> 
> Please re-read my proposal, I said write a dedicated wrapper to
> replace bzr *the* script.

I don't understand your proposal. What's will be different?
The principle will stay the same: qbzr will run commands as subprocesses 
and communicates with them via pipes. You and John said this is wrong 
approach. If you change the horse this will not make you closer to your 
target if you ride in wrong direction.

> Do you see a copy of command run methods in the bzr script ?

I don't understand your point.

>     bialix> and then thinking about how to deal with exceptions
>     bialix> and errors and status messages, but instead you can
>     bialix> purely focusing on GUI part: which controls you need
>     bialix> and how to layout them.  Everything else will be done
>     bialix> by qsubprocess.
> 
>     bialix> For me -- this is huge win.
> 
> You're mixing two different things that I'm trying to separate,
> you can have your cake and eat it.

This phrase means something not really good about me but I don't 
understand. Sorry I'm dumb.

> <snip/>
> 
>     >> [1]: Disclaimer: I'm expressing opinions here not telling people
>     >> how they should write their code in their free time. Feel
>     >> free to ignore me ;)
> 
>     bialix> No comments.
> 
> Can you elaborate on that ? 

No, sorry.

> If you really had no comment you could have just cut that part
> like you did for other parts of the mail (including the part that
> refers to that footnote which put it out of context). If you have
> some comments, please speak.

I don't want to continue this discussion because I'm clearly don't 
understand what we talking about.