On 2007-09-03 01:15:32 -0400, Derek Martin wrote: >> It's not about noticing, but about causing minimal confusion. > > It's hardly confusing. The typical user is highly accustomed to > interacting with GUI applications, virtually 100% of which have > dialog boxes pop up either in the middle of the main window, or > (more commonly) in the center of the screen.
You're arguing why mutt should have a completely different UI paradigm, which -- surprise! -- might even make sense if it was started from scratch today. However, the question at hand is how to make a specific interaction fit the rest of the interactions that people have with mutt. And for that, it's more critical to be consistent *inside* the program than to be consistent with curses applications around it. (To give just one example, emacs -- which shares some UI paradigms with mutt -- has an occasionally-extending status bar.) In any event, as I said before elsewhere, I'd like to see the two options (center of screen and bottom of screen) in place for a while, so we can actually see what makes more sense. > A great many curses-based terminal-oriented programs behave this > same way. This is now decades old, well-established, > cross-platform behavior. Saying it is more confusing is like > saying the Metric System (SI units) of measurements is more > confusing than the English System... it just isn't. Using the metric system in the middle of a conversation that's otherwise using miles and feet is, indeed, confusing... >>> FWIW, I've also always wanted Mutt to have a multi-paned >>> interface, not unlike most GUI mailers: one pane for the >>> folder list, one for the message index, and one to display >>> messages. >> Incidentally, I wouldn't want to have that particular kind of >> UI for myself. > But lots of people would, hence the popularity of the sidebar > patch, which is standard on Debian's build of mutt. And the > point is it would be configurable, like everything else in Mutt, > so you don't need to use it if you don't want to, and you can > even enable/disable it on the fly, if you want to use it some of > the time... much like you can do with GUI mailers, by dragging > the pane frames around to hide or unhide the various frames. I think you constructed an objection to including that patch from a simple remark about my personal preferences. De gustibus non est disputandum. ;) >>> Mutt could do some (extremely) basic HTML formatting, like >>> handling <b>, <i>, and <tt> tags, and displaying inline >>> images. Yeah yeah bloat blah, but it's just a lot more >>> convenient if I don't have to launch external applications to >>> view these extremely common forms of e-mail. >> Use "lynx -dump -with_backspaces" as your default html handler. >> :) > > This doesn't display italics on my terminal, nor does it display > bold as bold text. It should actually take care of bold. > That kind of eliminates the usefulness of using formatted text to > highlight and emphasize selected text over the rest... I could > probably futz with my terminal configuration to make it display > that way, but I don't *want* to. By contrast, the GUI mailers > just work as expected, in that regard. True. They also work as unexpected, if you look at the various side effects that HTML can have at times. >> From a design perspective, that handler should actually be an >> external filter. > That makes sense for the Mutt of today (or rather 10 years ago), > but makes very little sense for (say) a GNOME-ized version of > Mutt which is (optionally) already linked against all the happy > libraries that handle HTML formatting and JPEG display, etc. The > point of Mutt's design (and the Unix philosophy, in general) is > modularization -- making small, easy-to-test bits of code that do > one job, and do it well... But modularization can just as > effectively be handled by using good software engineering > principles to write modular code, and using any of a plethora of > well-tested libraries to accomplish tasks that Mutt currently > accomplishes using child processes. As much as I'd love to get more into that discussion... Let's leave it on the sidetrack that it's on right now. ;) > The current "design perspective" of Mutt was born in computing's > Stone Age, and is sorely in need of updating. That mutt is starting to show its age is doubtlessly true. That its heavy reliance on a single text terminal is quite limiting is true as well. At the same time, there are use cases where that limitation is actually a plus, and I'd hate to see mutt become unsuitable for these. > It causes a variety of limitations that are not currently > suffered by users of other, more modern (GUI) mailers. Mutt is > still the most powerful and flexible mailer around, AFAIK; but it > is far from the easiest to use... Mutt could continue to be the > most powerful and most flexible mailer, and at the same time > realize a great many improvements in ease of use and > configuration management by letting go of its ancient design > philosophy. It need not lose its terminal orientation in order > to do so, either. You could keep a terminal mode around, but I would be surprised if all (or even most) of the benefits of an updated architecture were to manifest themselves in such a mode. > the current code base desperately needs to be abandoned, and a > fresh rewrite started with modularity and modernization in mind. > But that's a project -- and an argument -- for a different, > brighter day. :) Good luck. :) -- Thomas Roessler <[EMAIL PROTECTED]>
