Oleg Broytman writes: > > Back on the topic, I don't think a drop-down list of all modules is > > workable even in browsers that display them as combo boxes. How many > > modules do we have in std lib? About 100? Maybe more. What if the > > bug affects several modules? What if the patch modifies several > > modules? Do we want to allow selection of multiple modules for the > > given issue?
Roundup has a multilink type which allows selection of multiple items. The input interface is a list of checkboxes formatted as a two-column HTML table (checkbox and module name), not a combo box (which doesn't allow a list of selections). XEmacs uses such a multilink for its 147 Modules (in Python's tracker, that would be Components). For me, with my most frequently affected modules living at the top of the first page of the module list I have no problem with the multilink interface; it's when I need to find a library on the second or third page that things get frustrating. About 50 items with checkboxes should fit easily in a popup window in table form if there were multiple columns (say four or five); it just hasn't been coded yet. And there's no reason the table has to fit in the window. A scrolling table would be fine for this, as long as the total height wasn't more than about 3 times that of the window. I would guess that a table of checkboxes could easily handle a multilink with about 200 options, and would be usable both by newbies and triagers. Possibly active developers would find the one-line text- entry more efficient, but I think it would be a close race: > In this particular case I'd rather tend to agree - an editable > single-line box to enter space-*and*-comma-separated modules list > would be the best interface. For active developers, yes. But this is unhelpful for people who aren't hyper-familiar with the component list or who can't spell. The checkboxes are also faster when doing triage, at least if the relevant component is in the first screen. Maybe with enough Javascript to give autocompletion and validation, a space/comma-separated list would be OK, but I'm dubious. Also, some of our users are able to pick out which modules seem to be involved from backtraces in error messages, but not without a list. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
