11:06 a.m.
[XEmacs doesn't maximise correctly for me. Others don't, so the WMs
can't be broken]
What is the basis for your conclusion?
Experience and common sense. See below.
Saying "it works with other applications" doesn't meant
that
there isn't a bug, only that the bug doesn't affect other
applications.
Generally, I agree. Let's assume for a moment that metacity, kwin (yes,
it's KDE's WM) and others all share one and the same bug that gets
triggered by XEmacs. Other apps aren't bothered by that bug.
Apart from the fact that I don't believe all other apps implemented
some workaround, the question IMHO is: If this hypothetical bug is so
wide-spread but of almost no impact [on Linux] - is it in XEmacs'
and its users' best interest to be standards-compliant but affected?
How many of those other applications specify a resize increment?
I have no idea and I don't really care to speak frankly. Maybe that's
simply a bad idea?
It isn't about /enforcing/ anything. However there is a limit to
how
much fault-tolerance you can provide.
Absolutely true. Still, XEmacs3 has troubles being used with at least
two major WMs and a minor one. I think that warrants investigation and
fixing this issue.
IME, the XEmacs development process tends to give less credence to
the
"follow the rest of the herd" idiom. Mostly because it isn't a
Linux/Gnome/KDE application; it is supposed to run on any Unix system,
including those which follow standards in preference to trends.
That's great. I'd just prefer if they did not run in the opposite
direction compared to the rest of the herd. :-)
Around here, the ICCCM actually counts for something. It isn't
considered scripture, but nor is it considered irrelevant. In general,
compatibility with broken software (even really, really popular broken
software) isn't achieved at the expense of compatibility with correct
software (even if it's relatively obscure).
While I do *not* speak in favour of populism in general, I prefer my
software fully functional. And I think most users do.
I do understand your point, Glynn, but I'm more pragmatic. If something
is broken with "really, really popular" software, fix it. If that means
sacrificing some compatibility with correct software, investigate the
impact and *then* decide about what to do.
Sure. But the issue is whether you should be taking this up with the
application developers or with the WM developers.
How do you think will WM devs react if I tell them XEmacs features
this strange behaviour but no other software? :-)
Unless they're using XEmacs themselves they'll more or less politely
ignore me. Actually, last time I addressed this issue with the KDE guys
they did exactly that and I can't really blame them.
Mit freundlichen Grüßen,
Wulf C. Krüger
11:15 p.m.
Krueger, Wulf wrote:
[XEmacs doesn't maximise correctly for me. Others don't, so
the WMs
can't be broken]
> What is the basis for your conclusion?
Experience and common sense. See below.
> Saying "it works with other applications" doesn't meant that
> there isn't a bug, only that the bug doesn't affect other
> applications.
Generally, I agree. Let's assume for a moment that metacity, kwin (yes,
it's KDE's WM) and others all share one and the same bug that gets
triggered by XEmacs. Other apps aren't bothered by that bug.
Apart from the fact that I don't believe all other apps implemented
some workaround,
By "other apps", are you including those which don't specify a resize
increment (which is most applications)? Because they aren't remotely
relevant here.
For all I know XEmacs might be the only application you've tried that
specifies a resize increment
The reason why resize increments are signficant here is that it's
quite likely that the WM will overlook them and and attempt to specify
a size which corresponds to a fractional number of cells.
That in itself isn't a problem, providing the WM is willing to force
the issue.The WM built in to Cygwin's rootless X server implements
maxmising in the Windows sense: the window occupies the whole usable
desktop area (i.e. the screen minus the task bar), and cannot be moved
or resized. This leaves some blank space on the right and bottom of
the window, but it doesn't result in loops or windows leaping around.
OTOH, if the WM expects the application to actually request that size,
it's going to be out of luck. Applications are allowed to ask for size
which conforms to the gridding constraints, and its up to the WM to
deal with it.
the question IMHO is: If this hypothetical bug is so
wide-spread but of almost no impact [on Linux] - is it in XEmacs'
and its users' best interest to be standards-compliant but affected?
> How many of those other applications specify a resize increment?
I have no idea and I don't really care to speak frankly. Maybe that's
simply a bad idea?
No, specifying a resize increment is definitely appropriate for an
application which largely operates in terms of character cells.
If you want another test case which uses a resize increment, try
xterm.
> It isn't about /enforcing/ anything. However there is a
limit to how
> much fault-tolerance you can provide.
Absolutely true. Still, XEmacs3 has troubles being used with at least
two major WMs and a minor one. I think that warrants investigation and
fixing this issue.
It certainly warrants investigation; a fix is likely to be conditional
on that being possible without breaking conformant WMs or removing
useful functionality.
> Around here, the ICCCM actually counts for something. It
isn't
> considered scripture, but nor is it considered irrelevant. In general,
> compatibility with broken software (even really, really popular broken
> software) isn't achieved at the expense of compatibility with correct
> software (even if it's relatively obscure).
While I do *not* speak in favour of populism in general, I prefer my
software fully functional. And I think most users do.
I do understand your point, Glynn, but I'm more pragmatic. If something
is broken with "really, really popular" software, fix it. If that means
sacrificing some compatibility with correct software, investigate the
impact and *then* decide about what to do.
Well, that's the usual approach. However, verifying compatibility with
correct-but-obscure systems can take time. As can trying to code to a
non-existent specification. Reading the ICCCM is unlikely to tell you
anything about how the behaviour of your typical "popular" WM. If
you're lucky, the author (and this includes people who the FOSS crowd
consider GUI "gurus") will admit to not being particularly familiar
with the ICCCM; if you're unlucky, the response will be "ICC-what?".
> Sure. But the issue is whether you should be taking this up with
the
> application developers or with the WM developers.
How do you think will WM devs react if I tell them XEmacs features
this strange behaviour but no other software? :-)
How do you think XEmacs developers will react if you tell them "the WM
developer says he thinks it's an XEmacs bug"? :-)
Amongst people for whom the phrase "desktop standards war" brings to
mind Motif vs OpenLook (rather than e.g. KDE vs Gnome), WM developers
are held in roughly the same regard as web designers.
If the WM developers can't be convinced that failure to maximise the
window when you click on the maximise icon is a bug, either live with
it or find another WM.
Remember that it's the WM that's actually setting the window size.
XEmacs is merely stating its preferred size. It's the WM's job to
either honour or ignore the request as it sees fit. If merely issuing
a request causes the WM to do weird stuff, the solution is to fix the
WM, not ask applications to refrain from making such requests.
--
Glynn Clements <glynn(a)gclements.plus.com>
6777
days inactive
6777
days old
1 comments
2 participants
participants (2)
-
Glynn Clements -
Krueger, Wulf