[rfc] developer documentation on user interaction
v.ladeuil+lp at free.fr
Fri Sep 25 13:22:36 BST 2009
>>>>> "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
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.
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" ?
Hello ? You can't ask for stability AND more features. You
realized that's what you are doing right ?
Stephen> the audience for the API demands features.
Stephen> I think "Although practicality beats purity"
>> 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 ?
>> 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".
>> 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.
Do you see a copy of command run methods in the bzr script ?
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.
>> : 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 ?
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.
More information about the bazaar