[Pythondialog-users] pythondialog 2.14.0 released

[Florent R. <f.r...@fr...>]

Hello,

I am pleased to announce the release of pythondialog 2.14.0 (as you may
have noticed, from version 2.13.1 onwards, pythondialog version numbers
have three components, with a similar policy as for CPython, albeit on a
tremendously smaller scale).

After having sent a mail to "paulproteus" on August 17 (with no reply so
far) and filed a support request at PyPI, I have finally obtained
control over the pythondialog PyPI entry. This implies that you can
install the new pythondialog version with:

  pip install pythondialog

Unfortunately, PyPI refuses tarballs named python3-pythondialog-*,
therefore the files uploaded to PyPI don't have the explicit naming
scheme as on SourceForge, where the Python major version is apparent.

As usual, you can find the full list of changes in the Git history and in
the ChangeLog. The main changes in the latest releases are listed at:

  http://pythondialog.sourceforge.net/index.html#news

For your convenience, here is a text dump of the main changes in
version 2.14.0:

* Add support for the 'programbox', 'rangebox' and 'treeview' widgets.

* Add support for new dialog common options: --default-button and
  --no-tags.

* In dialog.py, use a context manager to factor out OSError and IOError
  handling throughout the module.

* dialog.py has a new version_info module-level attribute, similar to
  what the sys module provides. This avoids the need to parse
  __version__ when one wants to extract for instance the major and/or
  minor version number of pythondialog.

* Backend version caching and comparing

  Slight modification to a recent API: when the dialog-like backend does
  not return DIALOG_OK, Dialog.backend_version() raises
  UnableToRetrieveBackendVersion (new exception) instead of returning
  None. This way, the method either returns a string or raises an
  exception.

  dialog.py has a new DialogBackendVersion class (and BackendVersion
  abstract base class) for parsing the version string of the dialog
  backend, storing it in a structured format, and providing easy and
  reliable comparisons between versions using the standard comparison
  operators (<, <=, ==, !=, >=, >).

  Dialog.__init__ retrieves the backend version and stores the
  corresponding (Dialog)BackendVersion instance into a public
  cached_backend_version attribute. This should avoid having to run
  'backend --print-version' every time someone needs the version.

* Check for too old versions of the backend

  dialog.py has a new exception called InadequateBackendVersion that is
  raised when the user tries to use a programbox, rangebox or treeview
  widget with a dialog version that does not implement the widget in
  question (of course, similar checks will be added for future widgets).

  Similarly, for the latest widgets added to dialog, the demo checks the
  version of the backend if it's dialog and displays an explanation
  instead of the widget demo when it is too old.

* Add an 'is_widget' attribute to Dialog widget-producing methods

  dialog.widget is a new decorator to mark the Dialog methods that
  provide a widget. As explained in the docstring, this allows code to
  perform automatic operations on these specific methods. For instance,
  one can define a class that behaves similarly to Dialog, except that
  after every widget-producing call, it spawns a "confirm quit" dialog
  if the widget returned DIALOG_ESC, and loops in case the user doesn't
  actually want to quit.

* Improve structure and ESC handling in the demo

     * New MyApp class that implements the core of the demo. This class
       relies on a new MyDialog class that automatically wraps every
       widget-producing method of dialog.Dialog in order to display the
       "confirm quit" dialog if the user presses the Escape key or the
       Cancel button. This class also provides a few dialog-related
       methods used in the demo.
     * This new structure should completely fix handling of the Escape
       key, which was not satisfactory in previous versions since it
       required a while loop for every widget call that made the code
       redundant and harder to read. The new wrapping mechanism is
       completely transparent for most of the code in MyApp, which thus
       becomes shorter, more reliable and easier to read. The "magic" is
       contained within the MyDialog class.
* Add a sample program called simple_example.py that is really intended
  for newcomers: short, straightforward, with absolutely no magic.

* In demo.py, move a bunch of widget demos from
  MyApp.additional_widgets() to the main MyApp.demo() method to give
  them more visibility. The remaining widgets in
  MyApp.additional_widgets() either have little warts (like programbox
  which is waiting for a fix in the dialog backend), are cumbersome for
  the person running the demo (this is the case of
  progressbox_demo_with_filepath), or are almost identical to widgets
  already presented in the main part of the demo.


PS: the buildlist widget is only waiting for a fix in dialog (bug
    already reported), where --buildlist is not compatible with
    --separate-output.

-- 
Florent