[rfc] developer documentation on user interaction

[Vincent Ladeuil]

>>>>> "martin" == Martin Pool <mbp at canonical.com> writes:

<snip/>

    >> Well, we currently also have the "Command.outf" functionality. Which is
    >> still always bound to stdout but sometimes has unicode encoding/decoding
    >> enabled.

    martin> I would question whether the Command object is really
    martin> the right place for it vs the UI, and I think if it
    martin> has to be explicitly passed from the command down to
    martin> whatever code actually writes, people are likely to
    martin> cheat and use stdout.

I've seen that happen and I'm pretty sure there are still
existing cases of stdout usage instead of .outf.

    martin> It's not very consistently used and that to me
    martin> indicates it's probably not the right interface.

Hmm, to be honest, I think it's caused by the feature not being
implemented properly.

I seem to recall that you could very easily end up with command
objects where outf is not set for example.

    >> 
    >> If we went to put something like this onto ui_factory, I'd like to see
    >> an object that was smarter than .write(bytes).
    >> 
    >> Possibly a minimal api would be something like:
    >>  .write(bytes)
    >>  .write_unicode(Unicode)

-0.5 or make it private ?

    >>  (arguably you could go so far as .write_path(), .write_url()...)

+1

    >> I think internally we know when we are writing something like a Log
    >> message, that should be in Unicode locally, and translated for the
    >> screen. Versus writing the diff output ('log -p').

Exactly.

<snip/>

    >> 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 ? :).

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.

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

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.

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.

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.