vail@tegra.COM (Johnathan Vail) (05/29/90)
In article <1990May25.092932.15008@postmaster@turing.ac.uk> russell@glencoe.turing.ac.uk (Russell Ritchie) writes: What does Emacs want or need from a window system? or What should be in /etc/mousecap and /etc/windowcap? I use Emacstool under Sunview and have gotten quite used to editing with the mouse. The biggest fueature I would like to see on a future version is to have emacs windows be part of the windowing system. Maybe that is available now for X but not for emacstool. I have seen this work for Unipress emacs and I really liked that. It seems that in general, whatver approach is taken it should be as cleanly a part of the windowing system as possible (or tolerable?). This might include things like highlighted regions and real scroll bars. Ideally take it as far as possible with buttons and dialog boxes and such. Imagine pushbuttons for query replace, interactive spell-buffer and whatever else. I haven't been too impressed or found useful the menu system in emacstool but that may be parly to the feelings I have on the sunview menus in general. Just a few thought for the discussion.. jv Law of Stolen Flight: Only flame, and things with wings. All the rest suffer stings. _____ | | Johnathan Vail | tegra!N1DXG@ulowell.edu |Tegra| (508) 663-7435 | N1DXG@448.625-(WorldNet) ----- jv@n1dxg.ampr.org {...sun!sunne ..uunet}!tegra!vail
gamin@ireq-robot.UUCP (Martin Boyer) (05/31/90)
In article <982@atlas.tegra.COM> vail@tegra.COM (Johnathan Vail) writes: > >In article <1990May25.092932.15008@postmaster@turing.ac.uk> russell@glencoe.turing.ac.uk (Russell Ritchie) writes: > > What does Emacs want or need from a window system? > or > What should be in /etc/mousecap and /etc/windowcap? > >I use Emacstool under Sunview and have gotten quite used to editing >with the mouse. The biggest fueature I would like to see on a future >version is to have emacs windows be part of the windowing system. >Maybe that is available now for X but not for emacstool. I have seen >this work for Unipress emacs and I really liked that. I disagree; I have been a UniPress user for 4 great years, but I switched 6 months ago because it was getting too much of a pain to maintain the SunView window driver built into UniPress emacs. Because it was an integral part of the emacs kernel (the part written in C), good things were possible, at the price of greater complexity. I have since recoded that into a modified version of (GNU) emacstool and I can go on with a very standard and stable base (GNU emacs 18.55) while happily working on a smaller problem, the window/mouse interface. In version 2.20, UniPress went further and built a layer to create and control any kind of windows from emacs; it is truly an application level window system, but I don't think this approach has the right blend of power and flexibility to be successful in the long term. >It seems that in general, whatver approach is taken it should be as >cleanly a part of the windowing system as possible (or tolerable?). >This might include things like highlighted regions and real scroll >bars. Ideally take it as far as possible with buttons and dialog >boxes and such. Imagine pushbuttons for query replace, interactive >spell-buffer and whatever else. I second that. Some standard may be useful here, so that every "Look-and-feel" standard can be implemented by a separate tool/program, without requiring a different protocol. But I guess we are going full circle here; the original post asked the basic questions required before defining such a protocol: > What should be in /etc/mousecap and /etc/windowcap? Some ideas: mousecap: * what is sent by the various buttons, possibly modified by shift, ctrl, meta, etc. * set the double-click delays * set the double click mode (either two successive events, flagging the second one, or one event); handlling double clicks with a single event creates a problem: one has to wait a while after each click to see if another one is coming. The SunView mouse selection mechanism handles this by viewing the successive clicks as modifiers of the first click (hence issuing immediate feedback by generating as many events as clicks). In emacs, a sensible thing to do might be to execute one command per click, each command in a double (or triple, or...) click modifying its predecessor. * set the mouse dragging resolution (one event per character position swept, I guess) * set the absolute/relative mouse position * set the mouse shape * stream to open to get the mouse events (if not the same as the keyboard stream) windowcap: * multiple text "frames" (difficult, is it worth it?, see above) * read the character cell size (required to position the mouse, menus, etc). * set/read window label and state ("iconicity") * maintain menus by "name" (no need to recreate them, can be combined and reused), return an elisp object * create temporary menus "on the fly" * region highlighting * read the frame size in character coordinates * position the mouse * stream to open for window events Note that I have not specified things like font selection or window position/size control; these are well handled by the window system "frame" itself. OK now. I want it next month... Martin -- Martin Boyer ireq-robot!mboyer@Larry.McRCIM.McGILL.EDU Institut de recherche d'Hydro-Quebec mboyer@ireq-robot.uucp Varennes, QC, Canada J3X 1S1 +1 514 652-8136