Re: UI enhancements
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 <roessler@xxxxxxxxxxxxxxxxxx>