12:16 p.m.
Ben Wing <ben(a)666.com> writes:
i have seen no other application that intrusively resizes the main
window in order to display a progress gauge. both vc++ and ie,
which are modern, fully gui apps, use a much smaller progress gauge
that fits in the status bar [the echo area equivalent].
why can't we do the same?
I strongly agree here -- in fact I've asked the same question myself.
IMO a progress gauge should be located in the echo area, replacing the
traditional echo area messages. Or, the messages can remain on the
right-hand side of the gauge. Something like:
| |
| |
+----modeline---------------------+
|<------%------> Fontifying... |
+---------------------------------+
My `small' progress gauge was modeled after that, but it still
displayed in a gutter rather than in the echo area where it should be.
3:21 a.m.
New subject: Progress gauge review
the echo area is just a buffer. the progress-gauge widget is just a glyph. it
should [at least theoretically] be possible to just put the small progress-gauge
widget in there as an extent-begin-glyph, and things should just work. has
anyone tried this? hrvoje?
btw does anyone object to my messages wrapping at 80 columns? hrvoje, did you
reformat my message?
Hrvoje Niksic wrote:
Ben Wing <ben(a)666.com> writes:
> i have seen no other application that intrusively resizes the main
> window in order to display a progress gauge. both vc++ and ie,
> which are modern, fully gui apps, use a much smaller progress gauge
> that fits in the status bar [the echo area equivalent].
>
> why can't we do the same?
I strongly agree here -- in fact I've asked the same question myself.
IMO a progress gauge should be located in the echo area, replacing the
traditional echo area messages. Or, the messages can remain on the
right-hand side of the gauge. Something like:
| |
| |
+----modeline---------------------+
|<------%------> Fontifying... |
+---------------------------------+
My `small' progress gauge was modeled after that, but it still
displayed in a gutter rather than in the echo area where it should be.
--
Ben
In order to save my hands, I am cutting back on my mail. I also write
as succinctly as possible -- please don't be offended. If you send me
mail, you _will_ get a response, but please be patient, especially for
XEmacs-related mail. If you need an immediate response and it is not
apparent in your message, please say so. Thanks for your understanding.
See also http://www.666.com/ben/chronic-pain/
7:19 a.m.
New subject: Progress gauge review
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)iskon.hr> writes:
Hrvoje> My `small' progress gauge was modeled after that, but it
Hrvoje> still displayed in a gutter rather than in the echo area
Hrvoje> where it should be.
Huh?
I mean, this is what gutters are _for_. The modeline is a specialized
per-window gutter object, the echo area/minibuffer is a somewhat less
specialized per-frame gutter. Historically they don't happen to be
implemented that way, of course, but they _could_.
To my mind, the real question is not "why isn't the progress gauge in
echo area?", it's "why isn't the echo area in the gutter?", not to
mention "When should gutters be `visual unions' (eg minibuffer + echo
area) and when `structs' (menubar + toolbar)?" and "Should gutters be
so volatile?" and "Are gutters frame components or window components?"
So let's not limit the rethink to "progress bars".
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
9:01 a.m.
New subject: Progress gauge review
At 03:19 PM 6/4/00 +0900, Stephen J. Turnbull wrote:
So let's not limit the rethink to "progress bars".
I like this thinking :)
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
4:01 a.m.
New subject: Progress gauge review
stephen, if you want to go this far, then we should go the next step and
eliminate the concept of "gutter" and simply allow the xemacs frame to be a
widget, so you could have arbitrary layout. andy likes this, and it's in fact
something i proposed long, long ago [in architecting xemacs].
"Stephen J. Turnbull" wrote:
>>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)iskon.hr> writes:
Hrvoje> My `small' progress gauge was modeled after that, but it
Hrvoje> still displayed in a gutter rather than in the echo area
Hrvoje> where it should be.
Huh?
I mean, this is what gutters are _for_. The modeline is a specialized
per-window gutter object, the echo area/minibuffer is a somewhat less
specialized per-frame gutter. Historically they don't happen to be
implemented that way, of course, but they _could_.
To my mind, the real question is not "why isn't the progress gauge in
echo area?", it's "why isn't the echo area in the gutter?", not
to
mention "When should gutters be `visual unions' (eg minibuffer + echo
area) and when `structs' (menubar + toolbar)?" and "Should gutters be
so volatile?" and "Are gutters frame components or window components?"
So let's not limit the rethink to "progress bars".
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
--
Ben
In order to save my hands, I am cutting back on my mail. I also write
as succinctly as possible -- please don't be offended. If you send me
mail, you _will_ get a response, but please be patient, especially for
XEmacs-related mail. If you need an immediate response and it is not
apparent in your message, please say so. Thanks for your understanding.
See also http://www.666.com/ben/chronic-pain/
6:09 a.m.
New subject: Progress gauge review
>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
Ben> stephen, if you want to go this far, then we should go the
Ben> next step and eliminate the concept of "gutter" and simply
Ben> allow the xemacs frame to be a widget, so you could have
Ben> arbitrary layout. andy likes this, and it's in fact
Ben> something i proposed long, long ago [in architecting xemacs].
I don't disagree with eliminating gutters as an implementation.
I do think that XEmacs should have a sensible default policy as to
where things go (I think we can all agree that progress bars should
not pop up in the center of the window by default), and I think that
the concept of "gutter" as a place inside the frame, normally on its
edge, where menubars, toolbar, gauges, tab controls, etc, normally go
is useful in that sense.
I don't know how to do it. But what I'm suggesting is that certain
kinds of widgets should gravitate to certain places.
Ie, let's make sure that (1) "in principle policy-free" doesn't mean
that in practice implementors regularly institute defaults that suck.
And (2) we take the opportunity that the flexibility allows to get
either change defaults that currently suck or make them easier to
customize.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
8935
days inactive
8938
days old
5 comments
4 participants
participants (4)
-
Andy Piper -
Ben Wing -
Hrvoje Niksic -
Stephen J. Turnbull