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

[Chris D. <ch...@si...>]

Apologies Florent.  I'm really confused - you're not an admin on your own
project?  Oh well, don't worry.

I've deleted the github repository, to save any confusion.

All the best for the future of pythondialog.

Chris.

On 16 March 2010 16:04, Florent Rougon <fl...@vi...> wrote:

> 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
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Pythondialog-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythondialog-users
>



-- 

http://www.finalcog.com/