Marcus Harnisch writes:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> But I have no idea how it performs on a 1GB buffer, and I have
> idea how it performs in a buffer with 30000 GtkTextTags. I wonder
> if it can keep up with a buffer that's being fed by a process, and
> so on.
This is an excellent example of where we could benefit from using a
toolkit. One of our users complains, we identify GtkTextView and can
tap a much larger pool people to look at the issue than just XEmacs
"Much larger"? Wishful thinking. Performance problems are usually
the province of a *very* small group of core developers (one to
three), plus whoever is suffering. We need to be realistic about the
benefits we may get from this proposed rewrite. "Many eyes" is
probably not one.
Doe anyone know a GTK expert? Perhaps one of the gedit developers? I
suspect that gedit was the driving force behind all these features. It
has grown into more than a Notepad-for-Gnome.
Please, no, let's not do that. You yourself say:
I would probably start with desktop integration features before
tackling buffer rendering. In fact I guess this would be the last
thing to convert simply because it does work smoothly on the
platforms I use.
Please focus on the desktop integration features. What is it you
need? Which toolkits provide everything you need? Then we can look
at the question of whether it's worth trying to get cross-platform
support from a single toolkit. We could, instead, concentrate on
getting *one* X11-based toolkit, Windows, and the Mac in good shape.
Maybe it's time to abandon Xt support, as Lucid found it necessary to
abandon plain Xlib support. But we need to stop dreaming pipe dreams
of a cross-platform toolkit that does what XEmacs does, with much less
effort on our part. If we find one, use it, but really, don't expect
to find one.
What we surely *can* find is a small set of toolkits that provides
features we want but don't have yet, and won't cost more to support
than the current platforms.
XEmacs-Beta mailing list