Re: [Pythondialog-users] pythondialog is not dead!

[Florent R. <fl...@vi...>]

Hi,

Chris Dew <ch...@si...> wrote:

> Hi, Peter.

Florent. I'm Florent.

> Firstly, thanks for writing pythondialog.
>
> I forked pythondialog to github after having several emails ignored by the
> both of the maintainers on sourceforge for many months.

As written earlier, I am aware of this. As I am not admin of the SF
project, I did not receive any of these emails. As far as SF stuff is
concerned, I only read this mailing-list.

> I'm happy to remove the git repo, in order to remove confusion.  Does the
> new release support password fields (and the other patches submitted to
> sourceforge)?

Yes, it supports every dialog widget except --tailboxbg (for the dialog
version in Debian unstable, i.e. 1.1-20100119 as of now).

I reviewed the patches at
http://github.com/chrisdew/pythondialog/commits/master

  -> patch for labels of Yes or No buttons: added in version 2.10
  -> "Fix for dialog hang on guage close": as said, it is a workaround,
     and the problem is likely not to be reproducible with versions 2.09
     and later. If it is, I am much interested in a way to reproduce it.
     Thus, patch not applied.
  -> patch to add --form and --passwordform support: I had already
     implemented something equivalent in 2.09, except for --insecure
     (global dialog option). Version 2.10 has support for --insecure.

That is all I can see on your branch. As for the people who are still
using Xdialog, I incorporated Peter's "use_stdout" keyword argument to
Dialog.__init__ and _strip_xdialog_newline() method in pythondialog
2.10, so they should be happy too.

[ The only thing that might cause a change in Peter's private code, if
  any (based on my inspection of version 2.7), is that I chose the
  terminology "(child_output_rfd, child_output_wfd)" instead of
  "(child_rfd, child_wfd)", because the latter was confusing IMHO. When
  seeing "child_rfd", you could think it is the pipe read end used by
  the father process to obtain dialog's output (which was the case in
  version 2.7), but you could also think it is the pipe read end used by
  the child process to read input from the father process (as when
  dialog reads input for --gauge). Same thing with write ends.

  We have 2 sets of read/write fds in dialog.py:

    - one for dialog's output, which I called child_output_[rw]fd in
      version 2.10 and corresponds to dialog's stderr (normal case) or
      stdout (workaround for Xdialog's incompatibility);

    - one for dialog's input, which is used in gauge_start (called
      "child_stdin_[rw]fd") and in progressbox (no pipe created here, fd
      directly passed to Dailog._perform() with the new
      "redir_child_stdin_from_fd" keyword argument. ]

-- 
Florent