Re: Motif support

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Po Lu <luangruo@yahoo.com> writes:

> I disagree. I worked on some code bases much larger than Emacs' C part,
> with an application domain much more technical and specialized, and
> achieved productivity on non-trivial tasks after a few hours of study.
> Those are projects that put a lot of thought on code architecture, both
> macro and micro, with no tolerance for long-lived hacks or "somehow this
> seems to work" changes.

If you spend a week of study on X-Windows and Xt, along with spending
some time to read the comments in keyboard.c, you will be able to
understand the code in the X port fairly well.  I've personally seen
both the "no tolerance for long-lived-hacks" and the "you don't have to
understand it to work on it" attitudes destroy decades-old pieces of
software, so I don't recommend following it unconditionally.

X is a very complicated system, so people interested in working on its
support in Emacs are recommended to spend at least a week of study on it
beforehand, just as they must also study C.

Either way, the discussion has turned to a tangent.  The original point
was that the complexity added by Motif is too negligble to be considered
extra.

> Well, we always can pick a counter-example where GTK simplifies the job,
> can't we? What XTflash does is somewhat weird, but for other more
> mundane tasks GTK can be better. Or so I'll guess, since I don't know
> that library and I've heard lots of times that it is a bit difficult to
> work with in comparison with other contemporary toolkits.

That sort of counter-example doesn't exist in the code in both kinds of
GTK builds, IME.  Both types of GTK build consistently need large
amounts of hacks to work correctly, which are usually one or to five
lines of straightforward code in an Xt or a no-toolkit build.

For example, you can look at the function `xg_update_scrollbar_pos', and
compare it to the code `XTset_vertical_scroll_bar' runs on an Xt or
no-toolkit scroll bars build:

This is run on Xt:

    XtConfigureWidget (SCROLL_BAR_X_WIDGET (FRAME_X_DISPLAY (f), bar),
                       left, top, width, max (height, 1), 0);

And this is run on when there are no toolkit scroll bars:

      /* Move/size the scroll bar window.  */
      if (mask)
        {
          XWindowChanges wc;

          wc.x = left;
          wc.y = top;
          wc.width = width;
          wc.height = height;
          XConfigureWindow (FRAME_X_DISPLAY (f), bar->x_window,
                            mask, &wc);
        }

Both of which are more straightforward to understand and work with than
`xg_update_scrollbar_pos', where even the tiniest detail can cause the
function to stop working correctly.