November 2006 - mcclim-devel - mailman3.common-lisp.net

[mcclim-devel] stupid newbie question re: initializing text-field
by John Morrison 11 Nov '06

11 Nov '06

Sorry for what might be either a Stupid Newbie Question or Pilot Error: I am trying to implement a frame that allows "form-like" pop-editing of a CL data structure which include strings. How can I initialize the text fields and text editors? If I do what seems like the recommended thing according to the Harlequin CLIM manual -- a :before method on run-frame-top-level, it seems like maybe some goatee buffer pointer is not initialized until after the primary run-frame-top-level method gets called. (I made my own :around run-frame-top-level method, and the setf gadget-value, in fact, succeeds after the (call-next-method) has run -- but of course that's a little late for me.) The attached lisp program seems to exhibit the symptoms: the "test1" command works as expected and sets the value, but the :before method does not seem to. I only tried this under Linux (CentOS 4.4) on a relatively recent SBCL (0.9.14 RPM), using a relatively recent McCLIM (CVS updated approx Sept 15th). If anybody would please suggest further experiments, I would carry them out post-haste. Sorry if this is a stupid mechanical question: also, is there a stylistically better way to do this? Thanks, -jm -- ==== John Morrison ==== MAK Technologies Inc. ==== 68 Moulton Street, Cambridge, MA 02138 ==== http://www.mak.com/ ==== vox:617-876-8085 x115 ==== fax:617-876-9208 ==== jm(a)mak.com

4 5

[mcclim-devel] Sheet size/redisplay issues
by Troels Henriksen 09 Nov '06

09 Nov '06

This patch by David Lichteblau (http://common-lisp.net/pipermail/mcclim-cvs/2006-November/000612.html) causes problems in McCLIM with respect to redisplay - sheets are not fully redisplayed, but are cutoff some pixels from the edge, at least with the CLX backend. I don't know enough about how sheets work in McCLIM to feel comfortable fixing this, but I hope this message will catch the eye of some McCLIM hacker who can figure out the right fix. -- \ Troels "Athas" /\ Henriksen

2 1

[mcclim-devel] Drei - a replacement for Goatee
by Troels Henriksen 08 Nov '06

08 Nov '06

For a while, I have been working on something I call Drei (acronym currently ambiguous - I like Drei Replaces EINE's Inheritor personally, but Drei Reimplements Emacs Internals is also nice). It's a CLIM editing component based on Climacs, that I have used to implement a text-editor gadget, text-field gadget and input-editor (input-editing stream) for McCLIM. I would like to commit this to McCLIM, but due to the fairly large amount of code required (about 17.000 lines), I thought I'd post a description here first to allow people to object, if they see a problem. Due to the large number of added lines, and a few new directories, I have a hard time getting CVS to create a patch. Instead, I have created a tarball containing my modified McCLIM (with the Doc and Webpage folders removed to reduce size). It is available here: http://sigkill.dk/code/mcclim-drei.tar.gz Drei is basically Climacs, but everything that assumes it runs in a dedicated editor application (such as buffer-switching functionality) has been removed. Also, only Lisp syntax and Fundamental syntax is included. Apart from this, a programmatic interface to Drei has been created, as well as an implementation of the CLIM input-editing-stream protocol (based on Goatee code, but extensively modified and completely independent of Goatee) and a minor bit of indirection, that makes requests for :text-editor and :text-field gadgets create Drei gadget panes. Drei cannot be run as an independent application, but it has been designed so that it would be easy to base Climacs on Drei. Since Drei requires much of the functionality of ESA, I also intend to add ESA to McCLIM. This has required me to do a bit of hacking around in mcclim.asd because ESA normally requires McCLIM to be loaded, but due to Drei, it is necessary to load ESA before McCLIM has been fully loaded. Of course, a standard esa.asd is also provided, and while the internals of ESA have been rather extensively modified (especially the command processing code), the API should be fully backwards-compatible. Since Goatee deviates slightly from the CLIM spec, especially in the input-editor, I have also patched a few places in McCLIM that rely on internal Goatee implementation details or Goatee assumptions to be more general. I have also added a switch variable clim-internals::*use-goatee* (T by default) that switches between the use of Drei and Goatee. Generally, the number of changes (as opposed to additions) to the McCLIM code is extremely limited, except for the input-editing.lisp file. Here is a probably incomplete executive summary of some Drei/Goatee details: DREI PROS: * Drei has more functionality than Goatee, including a proper buffer protocol and the use of syntaxes (permitting, among other things, syntax-highlighting). * Drei is a better CLIM citizen - Goatee does not use command tables to tie gestures to commands and does not permit the binding of a sequence of gestures (such as C-x C-f) to a command. Drei uses a number of perfectly normal CLIM command tables that the user can freely define his own commands for. This could also be phrased as "Drei is easier to customize". * Drei has more commands than Goatee. * Drei can print information in the minibuffer if one is avaiable. When no minibuffer is available, Drei will attempt to use the *pointer-documentation* stream (doesn't work very well yet, though). * Drei is flexible enough to be used anywhere - if you define an editing command for Drei, it can be used in the input-editor, text-editor gadgets and Climacs. Goatee does not (at the moment) have enough functionality to be used for implementing something like Climacs. * The Drei text-editor gadget supports more options than the Goatee gadget (everything in the CLIM spec I think). * Drei supports arbitrary objects in the buffer. Check my customized accept method for `expression' (the bottom of Drei/input-editor.lisp) to see how this can be exploited. * Drei has `add-input-editor-command'! DREI CONS: * Drei is _vastly_ slower than Goatee and uses way more memory. I think the situation can improve by improving the incremental-redisplay code, but in general, Drei will always be slower because it does so much more (such as presentational output) than Goatee. * Drei is not as well tested as Goatee. * Drei does not support linebreaks in noise-strings. This is fixable with a moderate amount of work (it's related to the way Drei handles redisplay - it gets surly and grumpy if anything but an explicit #\Newline character causes a jump to the next line). * Drei does not support input-editor-typeout (neither does Goatee AFAIK, though). So, what are your thoughts? -- \ Troels "Athas" /\ Henriksen

1 1

[mcclim-devel] Wrong function name in guided tour
by Stefan Lang 05 Nov '06

05 Nov '06

On page 12 in guided-tour.dvi, the code: (run-top-level-frame ... should read (run-frame-top-level ... Stefan

2 2

[mcclim-devel] xxxx
by Jack Unrue 01 Nov '06

01 Nov '06

Greetings, I've had a few days now to sort of stumble around in my initial attempts at implementing a new backend[1]. The existing backend code and the spec help a lot, so the stumbling is just me getting familiar with a new codebase which for me is always a challenge. I think various concepts are starting to sink in. Apologies in advance for naive statements in the following and feel free to correct my understanding :-) I've got the general idea that a backend implements a class hierarchy with the responsibility of tying backend-specific constructs (represented by mirrors) to the system-agnostic representation (panes, sheets, and gadgets). The resulting McCLIM object hierarchy needs to shadow the logical structure in the native windowing system (e.g., window parent/child relationships). In McCLIM, one implements specializations of make-pane-1 and realize-mirror to accomplish that. Correct? Looking at the existing backends, it appears to my inexperienced eye that I have considerable latitude in establishing the mapping. That includes making use of various classes, functions, etc whose symbols are in the climi package, as needed. It's nice that there are various sanity checks in place that help catch mistakes. But essentially there are no prohibitions beyond those sanity checks and expected behavior as described by the spec? I haven't yet found any list of "do's and don'ts", e.g. on McCLiki, but hopefully folks will provide review feedback to that effect. At the moment, my event dispatching solution consists of implementing get-next-event for my port, returning the appropriate event type based on my mapping between Windows messages and CLIM events. I'm not sure yet whether I can implement the timeout feature. Anyway, I'm not otherwise touching any of the event queue-related stuff that I see in McCLIM proper, and I'm assuming for the time being that this backend will not enable multi-processing -- if and when SBCL/Win32 gets multi-threading then I'll have to revisit this. I haven't yet delved into mediums and designs, as I'm still trying to get basic window, menu, and gadget construction working correctly. But graphics support is obviously on the near horizon. I'm looking forward to making code available as soon as I'm not completely embarrassed by it :-) -- Jack Unrue [1] for those that haven't heard, I'm working on a Win32 backend via Graphic-Forms, which is my CL library for Windows GUIs.

2 1

[mcclim-devel] introduction, was: xxxx
by Jack Unrue 01 Nov '06

01 Nov '06

Sorry about the nonsensical subject line. -- Jack Unrue

1 0