[rfc] developer documentation on user interaction

[Alexander Belchenko]

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.

I don't remember I've talked about separating stderr and stdout,
so I'm not really sure what you talking about.

>     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" ?

Yes.

>     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.

This is wrong assumption.

> 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 ?

I care.

> And what bzr version does qbzr support ? And who use what ?

Usually bzr v.CURRENT-1 (or -2).

> 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.

The practice for QBzr is that: if you need to write simple GUI wrapper 
about straightforward bzr command, like say bzr check or bzr reconcile, 
you don't need to copy paste entire run method from bzrlib/builtins.py 
and then thinking about how to deal with exceptions and errors and 
status messages, but instead you can purely focusing on GUI part: which 
controls you need and how to layout them. Everything else will be done 
by qsubprocess.

For me -- this is huge win.

> So, I think "practicality beats purity" here, means, let's use
> bzrlib and stop pretending using bzr is the right way to go for
> wrong reasons ;)
> 
>        Vincent
> 
> [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 ;)

No comments.