[rfc] developer documentation on user interaction

[Vincent Ladeuil]

>>>>> "bialix" == Alexander Belchenko <bialix at ukr.net> writes:

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

Same here Alexander, I'm not an English speaker either, you know
me, so try to remember that I respect you and value your point of
view.

That shouldn't forbid discussions.

<snip/>

    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.

    bialix> What wrapper? I don't understand.

Roughly, qsubprocess spawn bzr and then do a lot of things around
that process barrier.

What I'm suggesting is that you can still spawn a subprocess,
replacing the bzr script (or bzr.exe) with a qbzr script that
knows it is talking to qbzr.

In that script, you can use bzrlib from python (just like bzr
itself does) instead of hacking to deal with bzr through pipes.

Controlling the sending side of the pipes should address many of
your concerns (that's my assumption) without needing a lot of
effort (and I may be wrong here that's why I said I was
expressing opinions because I don't expect to find the time to
write the code).

    bialix> Currently bzr emits to stderr
    bialix> tooooooooooooooooooooooooooooo much different
    bialix> information.

Still vague, Martin is working on that, care to give him more
examples so that we can address them ?

    bialix> I've tried to point to the fact that writing things
    bialix> via ui factory currently does not solve the problem
    bialix> with trace.py module.

Which has been modified recently too...

    bialix> They seems to live in different planes. Am I wrong?

Again, I understand that Martin is working in both areas, tell
him where bzrlib doesn't work for you, I'm sure he will love to
hear about that.

    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 ?

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

New features changes things which is different from "don't change
anything" which means "change nothing".

You said above: "bzr emits to stderr
tooooooooooooooooooooooooooooo much different information",
either you want that to change or you don't.

If you want it to change, you won't have stability.
If you don't want it to change, then why are you whining about it ?

    bialix> Don't push on me, please.

Ha come on, the point is not to push on you, you know that. But
you said I was wrong and then right a couple of lines below...

    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 ?

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

    bialix> So what's wrong with that?

Replay:

vila: it may be *less* effort to only support the last or the most recent bzr versions.

bialix: This is wrong assumption.
...

vila: who cares that qbzr and bzr-gtk are maintaining compatibility with older bzr versions ?
bialix: I care
bialix: Usually bzr v.CURRENT-1 (or -2).

So, if you care only about the last or the most recent bzr
version, you don't really care about being compatible with bzr
from last year.

So the changes in bzrlib API shouldn't have such an impact on you
knowing that the last changes were:

- 2009-08-28 api_minimum_version = (2, 1, 0) when
  get_user_encoding() was deprecated (after someone took care of
  updating bzrlib of its last bad uses of user_encoding, wait,
  wasn't that you ? :-p)

- 2009-06-17 api_minimum_version = (1, 17, 0) which was... yeah, the
  progress bar rework.

- 2009-05-04 api_minimum_version = (1, 15, 0) because of the
  removal of InstallFailed.

- 2009-02-25 api_minimum_version = (1, 13, 0) add a
  repository_policy to banch.clone()

- 2008-12-05 api_minimum_version = (1, 11, 0) inventory deltas.

- 2008-11-28 api_minimum_version = (1, 7, 0) inventory deltas.

And before that it was 1.7.0 which I think is well too old for
your concerns, so don't tell me the bzrlib API is changing under
your feet every minute.

Now, may be qbzr is using *private* bzrlib APIs and in that case,
please file bugs and nag us to provide public APIs since that's
what we are supporting via the deprecation dance.

Certainly the list above doesn't reflect your remarks so
obviously there is a gap. That gap shouldn't exist.

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

    bialix> I don't understand your proposal.

Then ask questions but don't say the proposal is flawed.

    bialix> What's will be different?  The principle will stay
    bialix> the same: qbzr will run commands as subprocesses and
    bialix> communicates with them via pipes.

You'll get the control of what travel in the pipes instead of
yelling at one side of them that you don't get what you want !

    bialix> You and John said this is wrong approach. If you
    bialix> change the horse this will not make you closer to
    bialix> your target if you ride in wrong direction.

That's fun but that doesn't apply here :-D

The idea is to come closer to bzrlib to get better control,
putting pipes and the bzr CLI API between you and the horse
doesn't help you chose the best direction.

<snip/>

    >> 
    >> You're mixing two different things that I'm trying to separate,
    >> you can have your cake and eat it.

    bialix> This phrase means something not really good about me

Your phrase says that you see bad things were they aren't.

My phrase said: 

1) You mixed different things (you said you don't
   understand,that's the same)

2) There is a saying in english: "You can't have your cake and
   eat it" which roughly mean either you have a cake (or a drink)
   XOR you eat it (drink it). You can't have (or do) both at the
   same time.  

   The pun here is that I'm saying: "You can keep a separate
   subprocess for the good reasons you care about" (have your
   cake) AND "You can write a *python* wrapper to take control
   closer to bzrlib on the *other* side of the pipe you're
   staying right now" (and eat it!).

    bialix> but I don't understand. Sorry I'm dumb.

Your main mistake is putting bad thoughts in my mails where you
should know better.

       Vincent