4:44 a.m.
the widgets are not quite so bad under windows but i agree that the progress gauge should
be turned off by default. the widgets are unfortunately a project that was abandoned at
the 75% stage, and we should not be forcing something like this on our users. unless
someone objects, i'll probably turn progress gauges off by default until i or someone
else gets around to completing the widget code.
------- Original Message -------
On
Mon, 17 Mar 2003 09:20:41 -0800 Martin Buchholz?wrote:
>>>>> "SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>>> "mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
mb> Here are my recommendations for future XEmacs development:
SJT> Thanks!
mb> I don't know how anyone can live with the hideous progress
mb> guages on Unix. Turn them off by default.
SJT> I make them "small" but otherwise find them bearable. IMO.
mb> Some other experimental features could be turned off by
mb> default as well. I'm thinking esd here.
SJT> ESD _is_ off, I thought. If it's not on your platform, I'd like to
SJT> know details.
Well done.
Perhaps I was confused by the example in configure.usage:
(e.g., `--with-sound=noesd' to disable ESD).
You should change that to refer to a feature that defaults to ON.
SJT> 2001-07-22 Stephen J. Turnbull <stephen(a)xemacs.org>
SJT> * configure.in (with_esd_sound): Default to no.
mb> The idea behind the test suite was to never release an xemacs
mb> that didn't pass 100% on all tested platforms. I recommend
mb> that you don't tolerate any test failures.
SJT> I wish. Not practical in current circumstances, sad to say.
mb> If necessary, introduce the concept of "expected" failure.
SJT> Done in 21.5, not yet synched back to 21.4. With that boot in the
SJT> pants, I'll submit a patch. With your suggestion and nearly 6 months
SJT> in 21.5, I bet Vin will take it. (See log below.)
SJT> To make improvement of test-harness.el easier, and more easily usable
SJT> in packages, I have been considering moving it to xemacs-devel or
SJT> perhaps xemacs-base. To be effective, this requires distribution of
SJT> that package with XEmacs, which is something you've always wanted (and
SJT> mention here). Also, I think the regression tests (at least) should
SJT> be a package, or perhaps part of xemacs-devel. Your comments on this
SJT> approach would be appreciated.
SJT> 2002-10-19 Stephen J. Turnbull <stephen(a)xemacs.org>
SJT> * automated/test-harness.el (test-harness-expect-bug): New variable.
SJT> (Known-Bug-Expect-Failure): New macro.
SJT> (Skip-Test-Unless): New macro.
Well done.
The design of the test harness interface is good, but the
implementation is not something I'm proud of. I took the
implementation of the byte-compiler framework and hacked it till it
was a test harness, and you can probably still find a few
byte-compilerisms in test-harness.el. A cleanup of test-harness.el
is a good project.
I am not convinced that packagizing the tests is a good idea. It
would discourage testing by users. In general, unless disk space is
an issue, tests should be distributed with the sources that they test.
mb> I believe there has been no release of 21.5 that has met my
mb> release criteria since the last one I did the release
mb> engineering for.
SJT> That's partly because I at least explicitly disagree with some of
SJT> those criteria. If you would be specific about your criteria, it
SJT> would be a lot of help to the 21.5 engineer, and to me (likely to find
SJT> myself in that position again in the near future).
Get lots of diverse machines with lots of diverse compilers. Build
xemacs with lots of diverse options. Run make check with each build.
Completely automate this.
Get friends on the Net to give you access to odd machines.
Get obsolete PCs and install odd OSes like OpenBSD on them.
Get icc for Linux.
Build debug and optimized.
Build with and without union-type.
Push the envelope on optimized builds, including ANSI aliasing.
I'm still greatly annoyed by Ben breaking my AIX cc (with ANSI
aliasing) build, me fixing it, and Ben deliberately undoing my fix. I
assume 21.5 is still broken with regard to ansi-aliasing, and still
consider it unacceptable.
mb> If I were to become a major contributor again, I might adopt
mb> Linus' model. Let everyone keep their own tree, and no one
mb> gets guaranteed write access to my tree. XEmacs has been hurt
mb> by a too lenient commit access for core contributors.
SJT> Probably. But for those who want a gated community, there's an easily
SJT> accessible one at gnu.org. That model also has its disadvantages, and
SJT> most of us are at xemacs in part because of a strong preference for
SJT> the more free-wheeling environment we now have.
The Linus model is not a gated community; it's a freewheeling
community. But that doesn't mean you get to commit to Linus' tree.
Linus is successful in spite of (or perhaps because of) being a bastard.
For XEmacs, the stable branch is run Linus-style by Vin, fairly successfully.
SJT> As for personal trees (CVS branches), that's been explicitly on offer
SJT> since mid-2000. Several people on the Review Board have taken
SJT> advantage of the opportunity, but nobody really likes working that way
SJT> under CVS. So everybody wants to merge to trunk.
CVS sucks for branches. Switch to something else, medium-term.
SJT> The personal releases model also suffers from the fact that several
SJT> reviewers perceive multiple branches as creating competition for
SJT> testers.
True. Freedom of choice implies terrible inefficiencies.
Martin
5:46 a.m.
New subject: Will Martin contribute to XEmacs in the future?
|--==> "BW" == Ben Wing <wing(a)666.com> writes:
BW> unless someone objects, i'll probably turn progress gauges off
BW> by default until i or someone else gets around to completing the
BW> widget code.
No objection here. Go ahead, Ben.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
5:57 a.m.
New subject: Will Martin contribute to XEmacs in the future?
the widgets are not quite so bad under windows but i agree that
the progress gauge should be turned off by default. the widgets
are unfortunately a project that was abandoned at the 75% stage,
In my defence I think its widgets under X that are at the 75% stage :)
I wish I had never bothered doing X support. Motif sucks, athena sucks.
and we should not be forcing something like this on our users.
unless someone objects, i'll probably turn progress gauges off by
default until i or someone else gets around to completing the widget code.
Since you are developing and I am not you get to say, but I guess I would
be interested in knowing what you would change that would make them
acceptable.
andy
5:03 a.m.
New subject: Will Martin contribute to XEmacs in the future?
----- Original Message -----
From: "Andy Piper" <andy(a)xemacs.org>
To: <ben(a)666.com>; <martin(a)xemacs.org>; <stephen(a)xemacs.org>
Cc: <xemacs-beta(a)xemacs.org>
Sent: Monday, March 17, 2003 10:57 PM
Subject: RE: Re: Will Martin contribute to XEmacs in the future?
> the widgets are not quite so bad under windows but i agree that
> the progress gauge should be turned off by default. the widgets
> are unfortunately a project that was abandoned at the 75% stage,
In my defence I think its widgets under X that are at the 75% stage :)
I wish I had never bothered doing X support. Motif sucks, athena sucks.
imo this is a cop-out. xemacs should work under both x and windows. "motif
sucks" because you're less familiar with its weirdnesses than with those of ms
windows -- many people with the opposite sort of experience say the same about
windows.
> and we should not be forcing something like this on our users.
> unless someone objects, i'll probably turn progress gauges off by
> default until i or someone else gets around to completing the widget code.
Since you are developing and I am not you get to say, but I guess I would
be interested in knowing what you would change that would make them
acceptable.
there are no dialog boxes written using the code except Edit->Find.
there are tons of redisplay bugs in the widgets, even in Windows. running
Edit->Find, a see a bunch of flashing and resizing at the beginning, which
should not be there. run your glyph-tests.el and you see lots of weird problems
[some are fixed in my glyph ws].
accelerators don't work in Edit->Find.
hitting Enter in the text field doesn't do anything.
hitting Esc does not cancel Edit->Find.
etc. etc.
these things are standard in all Windows programs.
problems like this are typical of an 80% implementation. 80% implementations
make good demos but aren't really usable.
ben
5:36 a.m.
New subject: Will Martin contribute to XEmacs in the future?
imo this is a cop-out. xemacs should work under both x and
windows. "motif
sucks" because you're less familiar with its weirdnesses than
with those of ms
windows -- many people with the opposite sort of experience say
the same about
windows.
You misunderstand me. I mean that motif has 75% of the widget set that
windows does, and athena 50%. I'm sure all have their share of bugs
and weirdness and in some ways I am more familiar with Motif than I
am with windows. But writing widgets or debugging half written ones
really sucks. And the smiley meant that I knew it was a copout :)
there are no dialog boxes written using the code except
Edit->Find.
there are tons of redisplay bugs in the widgets, even in Windows. running
Edit->Find, a see a bunch of flashing and resizing at the beginning, which
should not be there. run your glyph-tests.el and you see lots of
weird problems
[some are fixed in my glyph ws].
accelerators don't work in Edit->Find.
hitting Enter in the text field doesn't do anything.
hitting Esc does not cancel Edit->Find.
etc. etc.
The question was what about the _progress bars_ would make them acceptable.
Not what needs fixing in the widget support. We both know all of the above
and
have discussed them at length. I am asking for user feedback about what
works for them and what doesn't. I know that for Martin nothing visual is
pleasing
to him, but others may have different opinions.
andy
1 p.m.
New subject: Will Martin contribute to XEmacs in the future?
----- Original Message -----
From: "Andy Piper" <andy(a)xemacs.org>
To: "Ben Wing" <ben(a)666.com>; "Andy Piper"
<andy(a)xemacs.org>;
<martin(a)xemacs.org>; <stephen(a)xemacs.org>
Cc: <xemacs-beta(a)xemacs.org>
Sent: Thursday, March 20, 2003 10:36 PM
Subject: RE: Re: Will Martin contribute to XEmacs in the future?
> imo this is a cop-out. xemacs should work under both x and
> windows. "motif
> sucks" because you're less familiar with its weirdnesses than
> with those of ms
> windows -- many people with the opposite sort of experience say
> the same about
> windows.
You misunderstand me. I mean that motif has 75% of the widget set that
windows does, and athena 50%. I'm sure all have their share of bugs
and weirdness and in some ways I am more familiar with Motif than I
am with windows. But writing widgets or debugging half written ones
really sucks. And the smiley meant that I knew it was a copout :)
> there are no dialog boxes written using the code except Edit->Find.
> there are tons of redisplay bugs in the widgets, even in Windows. running
> Edit->Find, a see a bunch of flashing and resizing at the beginning, which
> should not be there. run your glyph-tests.el and you see lots of
> weird problems
> [some are fixed in my glyph ws].
> accelerators don't work in Edit->Find.
> hitting Enter in the text field doesn't do anything.
> hitting Esc does not cancel Edit->Find.
> etc. etc.
The question was what about the _progress bars_ would make them acceptable.
Not what needs fixing in the widget support. We both know all of the above
and
have discussed them at length. I am asking for user feedback about what
works for them and what doesn't. I know that for Martin nothing visual is
pleasing
to him, but others may have different opinions.
sorry, your wording implied that you were asking about the widgets as a whole.
anyway, the resizing of the window in order to fit in the progress bars has
*got* to go. the progress bar needs to be small enough to fit into the echo
area. i remember you said at one point that this sometimes worked and sometimes
didn't ... can you clarify? if the progress bar can be made to fit into the
echo area, it can stay; otherwise, it will go.
andy
5:33 a.m.
New subject: Will Martin contribute to XEmacs in the future?
anyway, the resizing of the window in order to fit in the
progress bars has
*got* to go. the progress bar needs to be small enough to fit
into the echo
Like a status bar? I guess that might work - although a true status bar
would be better.
area. i remember you said at one point that this sometimes
worked and sometimes
didn't ... can you clarify? if the progress bar can be made to
The main problem is that the X widgets don't like being that small - motif
in particular. However, I only really tried putting it in the modeline - and
the modeline has its own set of redisplay issues.
fit into the
echo area, it can stay; otherwise, it will go.
You would have to experiment. Do we actually have glyph support in the echo
area?
andy
7705
days inactive
7709
days old
6 comments
4 participants
participants (4)
-
Andy Piper -
Ben Wing -
Ben Wing -
Steve Youngs