|
From: Florent R. <f.r...@fr...> - 2014-08-06 22:16:45
|
Hello,
When most of the pythondialog widget bindings were written, the dialog
backend did not work well when using width=0 and height=0 for widgets.
This is why most widgets, with the notable exception of those whose
bindings were recently written, have a non-zero default value in
pythondialog for the width, height and
list_height/menu_height/form_height/etc. parameters. These default
values have been chosen to look fine on a 80×25 terminal, but obviously
can't be adequate for any kind of widget contents.
The situation has changed, however, and current versions of dialog seem
to perform a decent automatic size computation when using 0 for such
parameters. As a consequence, 0 seems to be a better candidate for the
default width/height/etc. than any fixed value. This is why I have used
0 in this context for "recently"-added widgets such as buildlist.
Of course, it would be easy to change all these defaults to 0, but that
would break applications relying on the default values. In order to
allow new applications to use automatic sizing without having to
explicitely write width=0, height=0, and so on in every widget call, I
propose to implement a mechanism similar to Python's __future__
statement. From a user code perspective, that would look like this:
import dialog
dialog.enable_feature(dialog.Feature.autowidgetsize)
d = dialog.Dialog()
# Would behave as if 'width=0' and 'height=0' had been passed
d.msgbox("Some text")
# Same as 'width=45' and 'height=0'
d.msgbox("Some other text", width=45)
I have written a proof of concept which can be found in the attached
patch. It is based on the enum module for the dialog.Feature object.
enum is only part of the standard library in Python 3.4 and (presumably)
later, but the relevant code is safely ignored when enum is not
available. As a consequence, people using old installations should not
encounter any significant regression due to this change. The patch only
adds the new behavior for the following widgets: msgbox, checklist,
infobox, menu and inputbox. However, it is trivial to extend to all
widgets.
The only downside I can see with this approach is that the actual
default values (for the width/height/list_height/etc. parameters of a
given widget) are not part of the function signature anymore since they
depend on whether dialog.Feature.autowidgetsize has been enabled or not.
Therefore, unless duplicated in the docstring, they can't be found using
help() in the interactive Python interpreter. However, with the idea
that the feature may be enabled by default in a future major release,
the default values in currently-released pythondialog versions would
become obsolete and thus not worth to worry about.
Another point that is worth thinking about is the following: in the
proof of concept being discussed here, the _features object used to
record which members of the dialog.Feature enum have been enabled is
defined at module level. I have done so because the general feature
mechanism might be needed at module level for future changes, however
for the particular 'autowidgetsize' feature, it could as well be
implemented at the Dialog class level. The latter might be useful for
applications using several instances of the Dialog class in the same
process... and needing a specific set of features for every such
instance. I believe this case to be too hypothetical to warrant the
sacrifice of losing the ability to use the feature mechanism at module
level, or to justify the complexity of implementing both module-level
and instance-level features.
Finally, 'autowidgetsize' is the best name I could find, but I am open
to suggestions if someone has a better idea.
If you have something to say before this change reaches the Git
repository, please speak now or forever hold your peace. :-)
--
Florent
|