"Jason Doucette" <[EMAIL PROTECTED]> writes: > Ok, great. Are UI issues are considered bugs? I believe so, as > Franz Steinhäusler mentioned that Shift+Tab does not dedent as > expected. I have found many similar bugs -- some of them I believe > to be more important than broken functionality bugs, since they are > that disruptive to usability / productivity.
That would be a Request for Enhancement (RFE). If an existing feature isn't working, that's a bug. Adding or enhancing a feature is an RFE, even if it's 'expected'. There is already an RFE open for this request: http://sourceforge.net/tracker/index.php?func=detail&aid=694339&group_id=5470&atid=355470 The OP noted that a keybinding could be added to the user's config which would handle the request. Raymond wants to make it the default. I made a comment that maybe it would be nice if IDLE worked like python mode (smart tab indent and backspace dedent. Note that there is a fairly serious bug (1179168) involving Shift-Tab keybindings which needs to be fixed first! (I just raised the priority.) The discussion ended there, but I'd be happy to pick it up again. >> This list is appropriate for general discussion of issues related to >> IDLE development. >> >> The order of IDLE development priority is: >> >> 0. critical bugs >> 1. patches for bugs >> 2. important bugs submitted w/o patches. >> 3. patches for new functionality >> >> Then requests for enhancement (RFE, use Sourceforge), 'normal' bugs >> without patches, and the developer's personal interests are worked on >> in some random fashion. >> >> Please review the archives to get a feel for IDLE's design goals: >> >> * Stability is more important than features. >> >> * Keep the surprise factor low. >> >> * Simple interface: usable by children as well as professionals. >> >> * (But satisfy 98% of professional needs for writing pure Python code) > > The above two points would 'OK' the request to submit broken UI > functionality. My guess is that the interface should be simple and > intuitive, and be robust enough for professionals to not be > frustrated with any quirks. Correct? Yes. More esoteric facilities could be available, but should not be obtrusive. (We don't want to scare the kiddies.) The experts will find the features! (And assign hot keys). Maybe we should have a "long menus" option someday which could be turned on in the Configure IDLE dialog. It would also be nice to have an extension config dialog. > Do I submit the bugs directly to the bug tracking database, or should I > discuss them here first? Maybe we should discuss yours briefly here so we can come to agreement on what's a bug, what's an enhancement, and what's likely to be implemented (or not). Give us a quick list! In general, putting specific requests on the Trackers is better so they don't get lost and can be tracked ;-) Sometimes a quick question here can save time in the case of enhancements, but if it's a reproducible bug it belongs on the tracker. Please look over the IDLE bugs, patches, and RFE so you don't duplicate them. You can limit the tracker to IDLE by using the Category selector. General discussions of developmental direction and problems which are still vaguely defined are good topics for this list. -- KBK _______________________________________________ IDLE-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/idle-dev
