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 |