About Andrew Choi
MIDI File Player (External Device)
Cocoa Sample Programs
A blog where I will write mostly about programming in Cocoa and CoreMIDI, and experiences from my ports of Emacs and XEmacs to the Mac OS.
Clipboard, pasteboard, scrap, selection, whatever you want to call it. Heres a screen shot that demonstrates the clipboard support that I implemented for Carbon XEmacs today. The text in the XEmacs window is copied from Apples blurbs for OS X on their web pages in the respective languages.
Clipboard support on other platforms, especially MSW, is quite elaborate. My implementation only supports text (and not images for instance). So my entire
Well, Ive got mouse events (including mouse wheel events) working. Buttons 1, 2, and 3 can send button press and release events. The mouse wheel rolled up and down send button 4 and 5 release events, respectively. Single, double, and triple clicks work, thanks to XEmacss code to recognize them. I only had to provide millisecond resolution time stamps for the events. Mouse drags work. Mouse drags can follow single, double, and triple clicks, which extend the selection by characters, words, and lines, respectively. Modifiers associated with button presses are also passed along with the events. Scrolling also occurs automatically if the mouse is moved off the frame during a selection. Kind of interesting to see, even though I havent implemented scroll bars yet.
I almost didnt get the mouse drag implementation to work tonight (I needed to run errands most of the day). Who would guess that modifiers for key events are the usual control, shift, meta keys but modifiers for pointer motion (i.e., mouse drag) events must also include the numbers of the buttons that are down. Took a little while to track that problem down because the mouse tracking code is done in Lisp. Nothing wrong with that. I just needed to spend a little time to remind myself how to use the Lisp debugger. Also a little awkward to debug code for handling mouse moves while my computer has only one mouse!
I also took another look at
Wrote some code to handle window activation today. Since XEmacss redisplay code doesnt allow execution of code that modifies display objects during event polling times, Carbon window activation events are placed in the magic event queue so XEmacs can handle it when its able to. Of course I still had to write the code to handle the magic events myself! This is unlike events that are used to evaluate Lisp expressions, which I used for procesing menu commands in the past few days. XEmacs already has code for processing them. Anyway windows can now be activated by mouse clicks. I still have to display cursors correctly for active and inactive windows and write code to handle application activate and deactive events (i.e., suspend and resume).
Just a short note; no screen shots to show. I finished up the implementation of menu display and menu command processing. The coding was complicated by the need to call Lisp functions and evaluate Lisp expressions in C call-back functions, and reentrance problems in redisplay must be avoided (warning and error messages cannot be written to the frame, for example). Anyway the menubar code is now quite reliable.
XEmacss menus are a complete system unto itself. The interface to the device-dependent code is deceptively simple: a single Lisp variable
The contents of the menus are identical to those in the X version of XEmacs, although there are differences in their detail appearances. Only check marks have been used for selected items in the Carbon version so that the interface looks consistent with other Aqua applications. Accelerators indicated in the X version by underscores below their letters are currently just omitted in the Carbon version for the same reason. Key bindings are shown in parentheses following menu labels as in Carbon Emacs. Carbon menus support only single-character command keys.
Less-Known Facts About Emacs
Less-Known Facts About Emacs
|Copyright © 2003, 2004, 2005 Andrew Choi (Contact Information).||Created with FCBlog|