3:21 p.m.
Some time ago I started using lesstif on my Linux machine. I noticed
that the progress bar looks like a slider. Is that intentional? On
the cool side, the flicker is much less noticable than with Athena,
which flickers horribly.
Also, the `Stop' button does not seem to do anything. I don't know if
that's lesstif-specific.
Thirdly, it causes weird stuff in empty files. It might as well be a
font-lock bug, but slider/progress-gauge makes it very noticable. Try
opening a new .c file:
C-x C-f ~/a.c RET
Now start typing characters into it. What I notice is the bottom of
the screen flashing like mad because a gutter forms to create a
progress bar, and immediately disappears. The problem goes away once
you insert a newline character.
Either font-lock should be fixed so that it doesn't attempt to display
the spurious progress, or the progress bar should be adapted to handle
the case more gracefully.
4:12 p.m.
Hrvoje Niksic wrote:
Either font-lock should be fixed so that it doesn't attempt to
display
the spurious progress, or the progress bar should be adapted to handle
the case more gracefully.
I don't know if this is even remotely possible, but it would be nice
if the progress bar could be suppressed for operations taking less
than, say, 1 second or so. The progress bar might be kind of nifty
for long operations, but I find it quite distracting to pop up a
progress bar for very quick operations.
5:06 p.m.
At 10:12 AM 6/2/00 -0500, Charles G Waldman wrote:
Hrvoje Niksic wrote:
> Either font-lock should be fixed so that it doesn't attempt to display
> the spurious progress, or the progress bar should be adapted to handle
> the case more gracefully.
I don't know if this is even remotely possible, but it would be nice
if the progress bar could be suppressed for operations taking less
than, say, 1 second or so. The progress bar might be kind of nifty
for long operations, but I find it quite distracting to pop up a
progress bar for very quick operations.
Is this under font-lock? If so I guess we could have a
font-lock-minimum-size just as we have font-lock-maximum-size currently.
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
6:17 p.m.
Andy Piper writes:
Is this under font-lock? If so I guess we could have a
font-lock-minimum-size just as we have font-lock-maximum-size currently.
If you just deferred showing the progress gauge for a half-second or
so, we wouldn't need to add new variables to all the code which uses
progress gauges, the gauge code itself could decide if it's
appropriate to be popping up a progress gauge.
5:16 p.m.
On Fri, 02 Jun 2000 10:12:44 CDT, Charles G Waldman said:
I don't know if this is even remotely possible, but it would be
nice
if the progress bar could be suppressed for operations taking less
than, say, 1 second or so. The progress bar might be kind of nifty
for long operations, but I find it quite distracting to pop up a
progress bar for very quick operations.
Amen.
There's nothing like doing ALL the effort of putting up a progress bar
for a font-lock for a 23 line file....
The funniest part is if I'm connecting via gnuclient, it will open a new
frame, show the *scratch* buffer, do the progressbar while font-locking,
then switch to the buffer I just created....
/Valdis
8:39 a.m.
andy, i really think it's time to rethink the progress gauge.
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?
Charles G Waldman wrote:
Hrvoje Niksic wrote:
> Either font-lock should be fixed so that it doesn't attempt to display
> the spurious progress, or the progress bar should be adapted to handle
> the case more gracefully.
I don't know if this is even remotely possible, but it would be nice
if the progress bar could be suppressed for operations taking less
than, say, 1 second or so. The progress bar might be kind of nifty
for long operations, but I find it quite distracting to pop up a
progress bar for very quick operations.
--
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/
8:58 a.m.
At 12:39 AM 6/3/00 -0700, Ben Wing wrote:
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 don't feel possessive over the current progress gauge - if anyone wants
to play around with it be my guest. It is progress though :)
Ideally we would use the status bar widget that comes with windows but
unfortuneately there is no X equivalent. I guess an alternative would be to
allow the lower gutter to be permanently placed below the echo area - but
that's not going to look quite the same. You could also (as you point out)
put a progress gauge in the echo area - or even the modeline (see
glyph-tests.el for an example). The problem I found with this was that you
couldn't actually make progress gauges under X small enough to fit - they
seemed to have a minimum size below which meant they would just not display.
With all of this stuff its easy to do something that looks good under
windows, much harder to do it under X. Still harder under Athena :). I
would like to see all of the displayable portions of XEmacs be widgets in
their own right so that you could arbitrarily put together the look and
feel. I don't see how we can do this easily without dropping tty support
however. The whole modeline / echo-area / minibuffer thing looks very
archaic to me, it would be nice to put all of the modeline info in a bottom
status bar and put the minibuffer under the toolbar with a little
combo-box like a browser, the echo area could live in the status bar. This
is all a lot of work needless to say, but there's an argument that say's we
are going to have to do it at some point if XEmacs is to survive at all.
Maybe we should fork a new branch and ditch tty (and Athena since Motif is
now free) .....
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
2:18 p.m.
>>>> "Andy" == Andy Piper
<andy(a)xemacs.org> writes:
Andy> Maybe we should fork a new branch and ditch tty (and Athena
Andy> since Motif is now free) .....
I don't think either of these is acceptable. Much of the world is
likely to still prefer TTY for remote work (and especially gnuclient
usage) for quite a while (for sure I don't want to pay the freight for
a high speed connection yet, even a local connection costs about 3 yen
per minute).
Motif is not free in a practical sense yet, since none of the free
OSes is distributing it. Nor can we be sure that it will stabilize
quickly, or get a lot of support from the community, now that a lot of
developers have a lot invested in Gtk and Qt.
--
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."
4:07 a.m.
Andy Piper wrote:
At 12:39 AM 6/3/00 -0700, Ben Wing wrote:
>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 don't feel possessive over the current progress gauge - if anyone wants
to play around with it be my guest. It is progress though :)
Ideally we would use the status bar widget that comes with windows but
unfortuneately there is no X equivalent. I guess an alternative would be to
allow the lower gutter to be permanently placed below the echo area - but
that's not going to look quite the same. You could also (as you point out)
put a progress gauge in the echo area - or even the modeline (see
glyph-tests.el for an example). The problem I found with this was that you
couldn't actually make progress gauges under X small enough to fit - they
seemed to have a minimum size below which meant they would just not display.
well, we should then just resize the echo area by default so it will fit the
smallest progress gauge under X with no need to resize temporarily.
With all of this stuff its easy to do something that looks good under
windows, much harder to do it under X. Still harder under Athena :). I
would like to see all of the displayable portions of XEmacs be widgets in
their own right so that you could arbitrarily put together the look and
feel. I don't see how we can do this easily without dropping tty support
however. The whole modeline / echo-area / minibuffer thing looks very
archaic to me, it would be nice to put all of the modeline info in a bottom
status bar and put the minibuffer under the toolbar with a little
combo-box like a browser, the echo area could live in the status bar. This
is all a lot of work needless to say, but there's an argument that say's we
are going to have to do it at some point if XEmacs is to survive at all.
Maybe we should fork a new branch and ditch tty (and Athena since Motif is
now free) .....
i definitely agree that this generalization of redisplay is necessary. but we
don't necessarily need to drop tty support -- we'd still need a
"redisplay" to
display the text area, and in essence this is all a tty frame is. [i'm assuming
that the first round would not mess with the text area, and just allow arbitrary
layout with a monolithic "text area widget" somewhere in it. furthermore, the
geometry management part of layouts should be completely implemented by xemacs, so
we could use the same under tty's, if anyone cared.]
btw andy what's a "native layout"?
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
--
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/
8:45 a.m.
Hrvoje Niksic wrote:
Some time ago I started using lesstif on my Linux machine. I
noticed
that the progress bar looks like a slider. Is that intentional? On
the cool side, the flicker is much less noticable than with Athena,
which flickers horribly.
Also, the `Stop' button does not seem to do anything. I don't know if
that's lesstif-specific.
i think this is a general problem.
Thirdly, it causes weird stuff in empty files. It might as well be a
font-lock bug, but slider/progress-gauge makes it very noticable. Try
opening a new .c file:
C-x C-f ~/a.c RET
Now start typing characters into it. What I notice is the bottom of
the screen flashing like mad because a gutter forms to create a
progress bar, and immediately disappears. The problem goes away once
you insert a newline character.
Either font-lock should be fixed so that it doesn't attempt to display
the spurious progress, or the progress bar should be adapted to handle
the case more gracefully.
--
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/
8:30 a.m.
At 04:21 PM 6/2/00 +0200, Hrvoje Niksic wrote:
Some time ago I started using lesstif on my Linux machine. I noticed
that the progress bar looks like a slider. Is that intentional? On
Yes - the other gauge is an athena widget in theory. It would be nice if
Motif had a real progress gauge. I notice that Sun have used sliders as
progress gauges in the past.
the cool side, the flicker is much less noticable than with Athena,
which flickers horribly.
Yes, I don't know whether this is the widget or the redisplay code at
fault. I would say the latter except that neither motif or windows flashes
like this.
Also, the `Stop' button does not seem to do anything. I don't
know if
that's lesstif-specific.
Hmm, it used to. I haven't tried compiling with Motif for a while - I'll
take a look when I get a chance.
Thirdly, it causes weird stuff in empty files. It might as well be a
font-lock bug, but slider/progress-gauge makes it very noticable. Try
opening a new .c file:
C-x C-f ~/a.c RET
Now start typing characters into it. What I notice is the bottom of
the screen flashing like mad because a gutter forms to create a
progress bar, and immediately disappears. The problem goes away once
you insert a newline character.
Hmmn.
Either font-lock should be fixed so that it doesn't attempt to
display
the spurious progress, or the progress bar should be adapted to handle
the case more gracefully.
Maybe the progress gauge shouldn't popup for incremental updates ...
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
8935
days inactive
8939
days old
10 comments
6 participants
participants (6)
-
Andy Piper -
Ben Wing -
Charles G Waldman -
Hrvoje Niksic -
Stephen J. Turnbull -
Valdis Kl=?iso8859-4?Q?=BA?=tnieks