From tmoore at common-lisp.net Mon Feb 6 08:51:02 2006 From: tmoore at common-lisp.net (tmoore) Date: Mon, 6 Feb 2006 02:51:02 -0600 (CST) Subject: [mcclim-cvs] CVS mcclim Message-ID: <20060206085102.3EE4A7100D@common-lisp.net> Update of /project/mcclim/cvsroot/mcclim In directory common-lisp:/tmp/cvs-serv30236 Modified Files: frames.lisp sheets.lisp Log Message: {raise,bury}-{frame,sheet,mirror} --- /project/mcclim/cvsroot/mcclim/frames.lisp 2006/01/28 00:47:18 1.112 +++ /project/mcclim/cvsroot/mcclim/frames.lisp 2006/02/06 08:51:02 1.113 @@ -689,6 +689,8 @@ (defgeneric enable-frame (frame)) (defgeneric disable-frame (frame)) (defgeneric destroy-frame (frame)) +(defgeneric raise-frame (frame)) +(defgeneric bury-frame (frame)) (defgeneric note-frame-enabled (frame-manager frame)) (defgeneric note-frame-disbled (frame-manager frame)) @@ -708,6 +710,12 @@ (disable-frame frame)) (disown-frame (frame-manager frame) frame)) +(defmethod raise-frame ((frame application-frame)) + (raise-sheet (frame-top-level-sheet frame))) + +(defmethod bury-frame ((frame application-frame)) + (bury-sheet (frame-top-level-sheet frame))) + (defmethod note-frame-enabled ((fm frame-manager) frame) (declare (ignore frame)) t) @@ -989,7 +997,7 @@ (setq frame (apply #'make-application-frame frame-name initargs)))) (when (and frame activate) (cond ((frame-process frame) - #-(and)(raise-frame frame)) ; not yet + (raise-frame frame)) (own-process (clim-sys:make-process #'(lambda () (run-frame-top-level frame)) --- /project/mcclim/cvsroot/mcclim/sheets.lisp 2005/01/11 13:35:18 1.48 +++ /project/mcclim/cvsroot/mcclim/sheets.lisp 2006/02/06 08:51:02 1.49 @@ -503,14 +503,16 @@ (setf (sheet-parent child) nil)) (defmethod raise-sheet ((sheet sheet-parent-mixin)) - (when (not (sheet-parent sheet)) - (error 'sheet-is-not-child)) - (raise-sheet-internal sheet (sheet-parent sheet))) + (when (sheet-parent sheet) + (raise-sheet-internal sheet (sheet-parent sheet))) + (when (sheet-direct-mirror sheet) + (raise-mirror (port sheet) sheet))) (defmethod bury-sheet ((sheet sheet-parent-mixin)) - (when (not (sheet-parent sheet)) - (error 'sheet-is-not-child)) - (bury-sheet-internal sheet (sheet-parent sheet))) + (when (sheet-parent sheet) + (bury-sheet-internal sheet (sheet-parent sheet))) + (when (sheet-direct-mirror sheet) + (bury-mirror (port sheet) sheet))) (defmethod graft ((sheet sheet-parent-mixin)) (graft (sheet-parent sheet))) From tmoore at common-lisp.net Mon Feb 6 08:51:02 2006 From: tmoore at common-lisp.net (tmoore) Date: Mon, 6 Feb 2006 02:51:02 -0600 (CST) Subject: [mcclim-cvs] CVS mcclim/Backends/CLX Message-ID: <20060206085102.89DF972001@common-lisp.net> Update of /project/mcclim/cvsroot/mcclim/Backends/CLX In directory common-lisp:/tmp/cvs-serv30236/Backends/CLX Modified Files: port.lisp Log Message: {raise,bury}-{frame,sheet,mirror} --- /project/mcclim/cvsroot/mcclim/Backends/CLX/port.lisp 2006/01/22 21:17:07 1.119 +++ /project/mcclim/cvsroot/mcclim/Backends/CLX/port.lisp 2006/02/06 08:51:02 1.120 @@ -467,6 +467,18 @@ (xlib:destroy-window (port-lookup-mirror port sheet)) (port-unregister-mirror port sheet (sheet-mirror sheet)))) +(defmethod raise-mirror ((port clx-port) (sheet basic-sheet)) + (let ((mirror (sheet-mirror sheet))) + (when (and mirror + (typep mirror 'xlib:window)) + (xlib:circulate-window-up mirror)))) + +(defmethod bury-mirror ((port clx-port) (sheet basic-sheet)) + (let ((mirror (sheet-mirror sheet))) + (when (and mirror + (typep mirror 'xlib:window)) + (xlib:circulate-window-down mirror)))) + (defmethod mirror-transformation ((port clx-port) mirror) (make-translation-transformation (xlib:drawable-x mirror) (xlib:drawable-y mirror))) From crhodes at common-lisp.net Mon Feb 6 13:42:09 2006 From: crhodes at common-lisp.net (crhodes) Date: Mon, 6 Feb 2006 07:42:09 -0600 (CST) Subject: [mcclim-cvs] CVS mcclim/Experimental/freetype Message-ID: <20060206134209.DEC7F4800B@common-lisp.net> Update of /project/mcclim/cvsroot/mcclim/Experimental/freetype In directory common-lisp:/tmp/cvs-serv5964/Experimental/freetype Modified Files: mcclim-freetype.asd Log Message: Begin reducing the size of gold.ac.uk's mcclim diff ... just add a newline --- /project/mcclim/cvsroot/mcclim/Experimental/freetype/mcclim-freetype.asd 2005/07/29 06:50:20 1.3 +++ /project/mcclim/cvsroot/mcclim/Experimental/freetype/mcclim-freetype.asd 2006/02/06 13:42:09 1.4 @@ -68,4 +68,4 @@ #-sbcl (defmethod perform :after ((o load-op) (s (eql (asdf:find-system :mcclim-freetype)))) - (warn-about-unset-font-path)) \ No newline at end of file + (warn-about-unset-font-path)) From crhodes at common-lisp.net Mon Feb 6 14:33:53 2006 From: crhodes at common-lisp.net (crhodes) Date: Mon, 6 Feb 2006 08:33:53 -0600 (CST) Subject: [mcclim-cvs] CVS mcclim Message-ID: <20060206143353.3AC392A034@common-lisp.net> Update of /project/mcclim/cvsroot/mcclim In directory common-lisp:/tmp/cvs-serv14210 Modified Files: incremental-redisplay.lisp Log Message: Some more reduction of .gold.ac.uk mcclim diff ... minor edits to incremental-redisplay.lisp -- the major functional change has been absorbed into application code, using a specialization of INCREMENTAL-REDISPLAY for an application-defined subclass of STANDARD-UPDATING-OUTPUT-RECORD. --- /project/mcclim/cvsroot/mcclim/incremental-redisplay.lisp 2005/08/18 03:17:21 1.52 +++ /project/mcclim/cvsroot/mcclim/incremental-redisplay.lisp 2006/02/06 14:33:53 1.53 @@ -305,7 +305,7 @@ (let ((res +nowhere+)) (loop for (r) in erase-overlapping do (setf res (region-union res r))) (loop for (r) in move-overlapping do (setf res (region-union res r))) - (replay history stream res)) )) + (replay history stream res)))) (defclass updating-stream-state (complete-medium-state) ((cursor-x :accessor cursor-x :initarg :cursor-x :initform 0) @@ -521,10 +521,11 @@ (with-output-recording-options (stream :record t :draw nil) (map-over-updating-output #'(lambda (r) - (setf (old-children r) (sub-record r)) - (setf (output-record-dirty r) :updating) - (setf (rectangle-edges* (old-bounds r)) - (rectangle-edges* (sub-record r)))) + (let ((sub-record (sub-record r))) + (setf (old-children r) sub-record) + (setf (output-record-dirty r) :updating) + (setf (rectangle-edges* (old-bounds r)) + (rectangle-edges* sub-record)))) record nil) (finish-output stream) @@ -548,8 +549,9 @@ ((record standard-updating-output-record) stream displayer) (multiple-value-bind (x y) (output-record-position record) - (when (sub-record record) - (delete-output-record (sub-record record) record)) + (let ((sub-record (sub-record record))) + (when sub-record + (delete-output-record sub-record record))) ;; Don't add this record repeatedly to a parent updating-output-record. (unless (eq (output-record-parent record) (stream-current-output-record stream)) @@ -721,7 +723,7 @@ (declaim (inline hash-coords)) (defun hash-coords (x1 y1 x2 y2) - (declare (type real x1 y1 x2 y2)) ;XXX Someday this should be float + (declare (type coordinate x1 y1 x2 y2)) (let ((hash-val 0)) (declare (type fixnum hash-val)) (labels ((rot4 (val) @@ -916,8 +918,6 @@ (t ;; It doesn't need to be updated, but it does go into the ;; parent's sequence of records - (when *trace-updating-output* - (format *trace-output* "clean ~S~%" record)) ;; (multiple-value-bind (cx cy) (stream-cursor-position stream) (multiple-value-bind (sx sy) (output-record-start-cursor-position record) @@ -925,8 +925,15 @@ (dy (- cy sy))) (unless (zerop dy) (move-output-record record dx dy) ) - (let ((tag (cond ((= dx dy 0) :clean) - (t :moved)))) + (let ((tag (cond + ((= dx dy 0) + (when *trace-updating-output* + (format *trace-output* "clean ~S~%" record)) + :clean) + (t + (when *trace-updating-output* + (format *trace-output* "moved ~S~%" record)) + :moved)))) (setf (output-record-dirty record) tag) (setf (output-record-parent record) nil) (map-over-updating-output #'(lambda (r) From crhodes at common-lisp.net Mon Feb 6 16:47:47 2006 From: crhodes at common-lisp.net (crhodes) Date: Mon, 6 Feb 2006 10:47:47 -0600 (CST) Subject: [mcclim-cvs] CVS mcclim/Backends/PostScript Message-ID: <20060206164747.33AE62A034@common-lisp.net> Update of /project/mcclim/cvsroot/mcclim/Backends/PostScript In directory common-lisp:/tmp/cvs-serv804/Backends/PostScript Modified Files: class.lisp Log Message: More divergence minimization ... make UPDATING-OUTPUT-STREAM-MIXIN a superclass of POSTSCRIPT-STREAM. Allows use of updating-output on postscript streams. --- /project/mcclim/cvsroot/mcclim/Backends/PostScript/class.lisp 2005/10/31 10:21:14 1.7 +++ /project/mcclim/cvsroot/mcclim/Backends/PostScript/class.lisp 2006/02/06 16:47:47 1.8 @@ -55,14 +55,19 @@ "Unknown") #-unix "") -(defclass postscript-stream (basic-sheet - sheet-leaf-mixin - sheet-mute-input-mixin - permanent-medium-sheet-output-mixin - sheet-mute-repainting-mixin - mirrored-sheet-mixin ; ? - standard-extended-output-stream - standard-output-recording-stream) +(defclass postscript-stream + (basic-sheet + sheet-leaf-mixin sheet-mute-input-mixin + permanent-medium-sheet-output-mixin sheet-mute-repainting-mixin + ;; ? + mirrored-sheet-mixin + ;; FIXME: Tim Moore suggested (2006-02-06, mcclim-devel) that + ;; this might better be a superclass of + ;; STANDARD-OUTPUT-RECORDING-STREAM. This should be revisited + ;; when we grow another non-interactive backend (maybe a cl-pdf + ;; backend?). -- CSR. + climi::updating-output-stream-mixin + standard-extended-output-stream standard-output-recording-stream) ((file-stream :initarg :file-stream :reader postscript-stream-file-stream) (title :initarg :title) (for :initarg :for) From cfruhwirth at common-lisp.net Thu Feb 9 13:20:38 2006 From: cfruhwirth at common-lisp.net (cfruhwirth) Date: Thu, 9 Feb 2006 07:20:38 -0600 (CST) Subject: [mcclim-cvs] CVS mcclim/Doc/Guided-Tour Message-ID: <20060209132038.AD95F7C03E@common-lisp.net> Update of /project/mcclim/cvsroot/mcclim/Doc/Guided-Tour In directory common-lisp:/tmp/cvs-serv19537 Modified Files: draw-frame.lisp guided-tour.tex Log Message: * Incorporate suggestions from Christophe Rhodes & Luis Oliveira. * Parenthesis error in draw-frame. --- /project/mcclim/cvsroot/mcclim/Doc/Guided-Tour/draw-frame.lisp 2006/01/30 16:14:01 1.1 +++ /project/mcclim/cvsroot/mcclim/Doc/Guided-Tour/draw-frame.lisp 2006/02/09 13:20:38 1.2 @@ -11,7 +11,7 @@ (interactor :interactor)) (:layouts (default-default (vertically () draw-pane - interactor)) + interactor))) (:menu-bar t) (:command-definer t) (:top-level (default-frame-top-level))) --- /project/mcclim/cvsroot/mcclim/Doc/Guided-Tour/guided-tour.tex 2006/01/30 16:14:01 1.1 +++ /project/mcclim/cvsroot/mcclim/Doc/Guided-Tour/guided-tour.tex 2006/02/09 13:20:38 1.2 @@ -2,6 +2,7 @@ \usepackage[dvips]{graphicx} \usepackage{color} % Need the color package \usepackage{listings} +\usepackage{url} %\usepackage{epsfig} \title{\Huge A Guided Tour of CLIM, \\ Common Lisp Interface Manager} \author{ @@ -36,7 +37,9 @@ \newcommand {\concept} [1] {{\sl #1}\index{#1}} \newcommand {\term} [1] {{\sl #1}} \newcommand {\code}[1]{{\sffamily #1}} -\newcommand {\CLIM}{{\small CLIM}} +\newcommand {\CLIM}{\textsc{clim}} +\newcommand {\CLOS}{\textsc{clos}} +\newcommand {\mcclim}{\textsc{McCLIM}} \let\class\code \let\method\code \let\constant\code @@ -54,7 +57,7 @@ output services, and mechanisms for constructing window types and user interface components; stream-oriented input and output facilities extended with presentations and context sensitive -input\footnote{Similar to the work pioneered in the Genera UI system}; +input;\footnote{Similar to the work pioneered in the Genera UI system} and a gadget-oriented toolkit similar to those found in the X world extended with support for look and feel adaptiveness. In this article, we present an overview of \CLIM{}'s broad range of functionality and @@ -62,25 +65,25 @@ article originally appeared in Lisp Pointers in 1991 and was updated in 2006 by Clemens Fruhwirth.\footnote{The CLIM 2 specification changed significant parts of \CLIM{} rendering legacy code - unusable. Clemens Fruhwirth has rewritten all examples and the - corresponding text section for the \CLIM{} 2 specification. In - addition, he restructured the whole article and added text sections + unusable. Clemens Fruhwirth has rewritten all examples and the + corresponding text sections for the \CLIM{} 2 specification. In + addition, he has restructured the whole article, adding sections to provide additional insights into \CLIM{} concepts.} All examples -in this article have been developed with McCLIM{}\cite{mcclim}, a free -\CLIM{} implementation. +in this article have been run with \mcclim{}\cite{mcclim}, a free +\CLIM{} implementation, as of January 2006. \end{abstract} \section*{Introduction} Common Lisp is a language standard that has provided a broad range of functionality, and that has, to a large degree, successfully enabled -the writing of truly portable Lisp programs. The emergence of CLOS and -the cleanup efforts of Ansi X3J13 have further enhanced the utility +the writing of truly portable Lisp programs. The emergence of \CLOS{} and +the cleanup efforts of ANSI X3J13 have further enhanced the utility and portability of Common Lisp. However, one major stumbling block remains in the path of those endeavoring to write large portable applications. The Common Lisp community has not yet provided a standard interface for implementing user interfaces beyond the most basic operations based on stream reading and printing.\footnote{Notice - that this sentence was written in 1991. Unfortunately, it is still + that this sentence was written in 1991; it is still true 15 years later.} The Common Lisp Interface Manager addresses this problem by specifying @@ -92,7 +95,7 @@ and high level facilities like context sensitive input, an adaptive toolkit, and an application building framework. -\CLIM{} will eventually support a large number of window environments +\CLIM{} implementations will eventually support a large number of window environments including X Windows, Mac OS X and Microsoft Windows. \CLIM{} is designed to exploit the functionality provided by the host environment to the degree that it makes sense. For example, \CLIM{} top level @@ -100,17 +103,17 @@ operations are ultimately performed by host window system code. Another example is that \CLIM{} supports the incorporation of toolkits written in other languages. A uniform interface provided by -\CLIM{} allows Lisp applications programmers to deal only with Lisp +\CLIM{} allows Lisp application programmers to deal only with Lisp objects and functions regardless of their operating platform. -An important goal that has guided the design of \CLIM{} has been to +An important goal that has guided the design of \CLIM{} was to layer the specification into a number of distinct facilities. Furthermore, the specification does not distinguish the use of a facility by higher level \CLIM{} facilities from its use by \CLIM{} users. For example, the geometry substrate, which includes transformations and regions, is designed for efficient use by the -graphics and windowing substrates as well as by \CLIM{} users. This -means that, in general, a \CLIM{} user can reimplement higher level +graphics and windowing substrates as well as by \CLIM{} programmers. This +means that, in general, a \CLIM{} programmer can reimplement higher level \CLIM{} facilities using the interfaces provided by lower level facilities. @@ -123,20 +126,20 @@ particular application. For example, \CLIM{}'s application framework and adaptive toolkit -allow users to develop applications that automatically adopt the look +allow programmers to develop applications that automatically adopt the look and feel of the host's environment. (We often call this ``adaptiveness,'' ``look and feel independence,'' or occasionally more picturesquely, ``chameleon look and feel''.) However, many users may need or want to define a particular look and feel that stays constant -across all host environments (we call this "portable look and -feel"). Such users can circumvent the look and feel adaptiveness +across all host environments (we call this ``portable look and +feel''). Such users can circumvent the look and feel adaptiveness provided by \CLIM{}, while still using most of the application framework facility and other high level \CLIM{} facilities like context sensitive input. Furthermore, using the lower level facilities of \CLIM{}, they can develop portable toolkit libraries that define and implement their own particular look and feel. For instance, the -\CLIM{} user can implement new gadget types on top of the drawing -primitives and treat them equally to the build-in gadget types. +\CLIM{} programmer can implement new gadget types on top of the drawing +primitives and treat them equally to the built-in gadget types. We will use the term \concept{CLIM implementor} for the party implementing low-level and high-level parts according to the \CLIM{} @@ -186,11 +189,11 @@ \paragraph*{Formatted Output} \CLIM{} provides a set of high-level macros that enable programs to produce neatly formatted tabular and graphical displays easily.\footnote{This also includes Graph - Formatting} + Formatting.} \paragraph*{Presentations} \CLIM{} provides the ability to associate semantics with output, such that Lisp objects may be retrieved later -via user gestures (e.g. mouse clicks) on their displayed +via user gestures (e.g.{} mouse clicks) on their displayed representation. This context sensitive input is modularly layered on top of the output recording facility and is integrated with the Common Lisp type system. A mechanism for type coercion is also included, @@ -213,9 +216,9 @@ facilities will automatically adapt to use whatever toolkit is available and appropriate for the host environment. In addition, portable Lisp-based implementations of the abstract gadget pane -protocols are provided.\footnote{McCLIM does not support look and feel - adaptiveness at the moment except for the experimental port for Mac - OS X. Hence, McCLIM mostly uses this portable Lisp-based +protocols are provided.\footnote{\mcclim{} does not support look and feel + adaptiveness at the moment except for the experimental beagle backend for Mac + OS X's Cocoa platform. Hence, \mcclim{} mostly uses this portable Lisp-based implementation.} \paragraph*{Application Building} \CLIM{} provides a set of tools for @@ -237,13 +240,14 @@ stream, the \CLIM{} programmer can also attach the code that generated the content to the content itself. Whenever necessary, the application programmer can ask an output stream to update itself. \CLIM{} will -query all code generators and in case, replace obsolete content. +query all drawn elements for obsolescence, and if necessary, rerun the +code to produce fresh output. \noindent\hrulefill -\noindent These are a lot of facilities to explore. The most -systematically way -- exploring from the most low-level to the most -high-level -- would also be the most longsome. Therefore, we start +\noindent This is a large number of facilities to explore. The most +systematic way -- progressing from the lowest-level to the highest +-- would also be the lengthiest. Therefore, we start with showing several facilities in action with the most fundamental example in the realm of programming: Hello World. @@ -270,6 +274,12 @@ references and hope that the interested reader starts to explore the surrounding text sections on his own. +After loading a \CLIM{} implementation, the package +\keyword{:clim-user} is available to absorb user code. This package is +a good start for experimentations and first steps. When proper +packaging is required, simply include the packages \keyword{:clim} and +\keyword{:clim-lisp} in your \keyword{:use} list. + The central element of \CLIM{} application programming is the \concept{application-frame}. An application frame is defined via \code{define-application-frame}.\footnote{See Section 28.2 ``Defining @@ -318,15 +328,13 @@ The one and only superclass of \class{hello-world-pane} is \class{clim-stream-pane}\footnote{See Section 29.4 ``CLIM Stream - Panes'' in \cite{clim-spec}.}. As there are no additional slot, an -experience CLOS user might have correctly guessed that we will use -\class{hello-world-pane} solely for method specialization. - -But before we do that, let us have a look what we have actually + Panes'' in \cite{clim-spec}.}. As there are no additional slots, an +experienced \CLOS{} user might guess that we will use +\class{hello-world-pane} solely for method specialization. Before doing so, +let us have a look what we have actually inherited from \class{clim-stream-pane}\footnote{Internal classes - removed from Listing}: + removed from listing.}: -\pagebreak % formathack \lstset{style=inlinestyle} \begin{lstlisting} CLIM-USER> (describe (find-class @@ -394,12 +402,12 @@ To \CLIM{}, geometry means \concept{regions}. A region is either bound or unbound and has a dimensionality of either zero, one or two. That corresponds to a point, a path or an area respectively. Regions can be -compared (region predicate protocol\footnote{\CLIM{} relays heavily on - CLOS. In CLOS, the term \concept{protocol} means a set of generic +compared (region predicate protocol\footnote{\CLIM{} relies heavily on + \CLOS{}. In \CLOS{}, the term \concept{protocol} means a set of generic functions that together form a coherent interface. A protocol - specification does not only include the syntactic details of the + specification not only includes the syntactic details of the function names and the number of function arguments, but also the - functions purpose and the semantic of the return values (and/or side + functions' purpose and the semantics of the return values (and/or side effects) must be given in a textual specification.}) and composed (region composition protocol). @@ -422,14 +430,14 @@ \subsection{The Windowing Substrate} \CLIM{} does not directly talk to the window system. Instead, \CLIM{} -is layered on top of a windowing substrate\footnote{former Silica}. +is layered on top of a windowing substrate.\footnote{formerly known as Silica.} This substrate is a middleware between \CLIM{} on one side and the host window system on the other. This middleware layer provides a portable windowing model that insulates higher levels of \CLIM{} and \CLIM{} programmers from the details of the host window system. From the perspective of a \CLIM{} programmer, talking to the window system is equal to talking to this abstraction layer. The implementation -details are hidden in \concept{backends}, like in McCLIM the CLX +details are hidden in \concept{backends}, like in \mcclim{} the CLX backend, which hides X11 details, or the beagle backend, which hides details for Mac OS X's toolkit. These backends will use the services of a host window system to provide efficient windowing, input and @@ -440,7 +448,7 @@ blocks: \begin{itemize} \item Windows like those in X, Mac OS X and Microsoft Windows. -\item Gadgets typical of toolkit layers, such as GTK, QT or Mac OS X's +\item Gadgets typical of toolkit layers, such as Gtk+, QT or Mac OS X's toolkit. The backend provides a frame manager which takes care of mapping the abstract gadget types found in \CLIM{} to appropriate gadget with a native look and feel. @@ -480,7 +488,7 @@ children. A sheet can be adopted by a parent sheet and disowned later. A sheet is grafted when it is connected to a \concept{graft} either directly or through it's ancestors. A graft is a special kind of sheet -that stands in for a host window, typically a root window (i.e. screen +that stands in for a host window, typically a root window (i.e.{} screen level). A sheet is attached to a particular host window system by making it a child of an associated graft. A host window will be allocated for that sheet; the sheet will then appear to be a child of @@ -545,12 +553,12 @@ sheet. % \footnote{Notice that the \CLIM{} specification \cite{clim-spec} % specifies draw-text, draw-line, draw-rectangle, etc. as functions -% that operate on mediums. McCLIM names these functions +% that operate on mediums. \mcclim{} names these functions % medium-draw-text, medium-draw-line, medium-draw-rectangle, and so -% on. The functions that are available in McCLIM without the +% on. The functions that are available in \mcclim{} without the % ``medium-'' prefix operate on sheets. These are trampoline % functions that call the appropriate medium-prefixed function on -% the sheet's medium. According to the McCLIM authors, this is done +% the sheet's medium. According to the \mcclim{} authors, this is done % for optimization.} The graphic output capabilities of sheets range from simple line style @@ -563,9 +571,9 @@ \CLIM{} lives in idealized world in terms of graphics operations. A \CLIM{} programmer can use an infinitely long and wide drawing pane -with an arbitrary precise resolution and continuously variable amount -of opacity. As rendering devices with these properties are rare these -days, we need to render the idealized graphic description to a device +with an arbitrarily precise resolution and continuously variable +opacity. As rendering devices with these properties are rare, +we need to render the idealized graphic description to a device with finite size and a fixed drawing precision. The rendering rules are specified in Section 12.4 ``Rendering Conventions for Geometric Shapes''of \cite{clim-spec}. @@ -596,7 +604,7 @@ To build a user interface, an application programmer defines one or more frames classes. These frame classes define a number of frame properties including application specific state and a hierarchy of -panes (i.e. user interface gadgets and regions for interacting with +panes (i.e.{} user interface gadgets and regions, for interacting with the users). Frame classes also provide hooks for customizing application behavior during various portions of the frame protocol. For example, an \keyword{:after} method on generic functions in the @@ -616,13 +624,13 @@ asynchronously handling confirmation or cancel button clicks. For instance, the programmer requests a string from the user and the user is presented with a prompt, an editable text field, and two buttons -for confirmation and canceling. Only after the user hit the -confirmation button, the string requesting function returns and the +for confirmation and canceling. Only after the user hits the +confirmation button, the string requesting function returns; the programmer can directly use the function's return value which is the -user provided string. A cancel button click is handled via throwing an -abort tag. +string provided by the user. Clicking the cancel button is dealt with by throwing to an +\code{abort} tag. -From the callers perspective, an attempt to separate application +From the caller's perspective, an attempt to separate application frames and dialogs could be: a dialog window itself is side-effect free with respect to the application state and therefore the whole sense of calling a dialog creation routine must arise from the values @@ -648,7 +656,7 @@ additional information for (or before) an operation. When the user selects the ``Search'' command, he is queried for a search string in an additional dialog window; probably offering other search options -like case insensitive search or backwards search. This is done in a +like case-insensitive search or backwards search. This is done in a synchronous manner, blocking until the requested input is made available by the user. @@ -669,9 +677,9 @@ An application frame is an interface that provides the user with a variety of commands to choose as his next step. For instance, the user may choose from commands like Open, Save, Search, or Quit. The frame -is a long-living GUI object compared to dialogs and there is no linear +is a long-living GUI object compared to dialogs, and there is no linear execution path as there is in after a dialog as the user is free to -select any commands he likes as next step. +select any commands he likes as his next action. Hence, the synchronous programming pattern for dialogs is more convenient because after dialog confirmations there is a predetermined @@ -701,7 +709,7 @@ top-level pane in \macro{define-application-frame}. This pane is usually a layout pane that contains more gadget and/or layout panes as its children. With the help of layout panes, a pane hierarchy can be -constructed. The top-level pane (and the whole hierarchy when its a +constructed. The top-level pane (and the whole hierarchy when it is a layout pane) is created when the application frame is adopted by a frame manager and made visible to the user. The programmer can compose an interface consisting of pre-defined gadget panes, layout panes, or @@ -717,27 +725,27 @@ augmenting the class with an active part. For instance, a button-pane actively draws its own button representation on its allotted screen area and a click on the correct button area triggers a callback for -the button. A composite pane lays out its children elements and -request them to draw themselves onto specific screen regions. +the button. A composite pane lays out its child elements and +requests them to draw themselves onto specific screen regions. \CLIM{} comes with a set of predefined gadget panes. They consist of push-button, toggle-button, slider, radio-box, text-field, text-editor panes ready for use by the \CLIM{} application programmer. These gadgets might be remapped to native system gadgets by the frame manager, so a native look and feel is possible.\footnote{Only possible - in McCLIM with the experimental beagle backend for Mac OS X.} + in \mcclim{} with the experimental beagle backend for Mac OS X.} Each gadget pane class is associated with a set of generic functions -that as callbacks in traditional toolkits. For example, a pushbutton +that act as callbacks do in traditional toolkits. For example, a pushbutton has an ``activate'' callback method which is invoked when its button is pressed. For this particular callback, a method named -\method{activate-callback} is invoked per default and a \CLIM{} -programmer can provide a specialized method to implementation -application specific behavior for a subclassed button-pane. But except +\method{activate-callback} is invoked by default, and a \CLIM{} +programmer can provide a specialized method to implement +application-specific behavior for a subclassed button-pane. But except in the case where the programmer needs a lot of buttons with related behavior, creating a subclass for changing a single specific callback is not economical. Hence upon gadget creation, the programmer can -specify an alternative callback method for all callback available. By +specify an alternative callback method for all callbacks available. By providing the \keyword{:activate-callback} initarg, the programmer can change the callback to any regular or generic function. By convention, all callbacks can be changed by providing an initarg keyword equal to @@ -810,14 +818,14 @@ separately. This example illustrates the use of gadget panes provided by \CLIM{}. In the code in Figure \ref{fig-color-editor}, we define an application frame using \method{define-application-frame}. As said -before, the syntax of this macro is similar to \class{defclass}. It +before, the syntax of this macro is similar to that of \class{defclass}. It defines a new frame class which automatically inherits from the class \class{frame} which provides most of the functionality for handling frames. One requirement must be fulfilled by all frame definitions: code to generate a pane hierarchy must be supplied. The \keyword{:pane} option -is the simplest way to supply this code. \class{hello frame} +is the simplest way to supply this code. The \class{hello-world} frame constructs a hierarchy with only one application pane via \method{make-pane}. The pane hierarchy of color editor is more interesting. @@ -896,7 +904,7 @@ whether the mouse button is held down during dragging, or whether the mouse button is pressed once to start and again to stop dragging. -We use the gadget id to distinguish between the red, green and blue +We use the gadget ID to distinguish between the red, green and blue slider in the callback code. We could use three different callback [270 lines skipped] From crhodes at common-lisp.net Fri Feb 17 14:16:39 2006 From: crhodes at common-lisp.net (crhodes) Date: Fri, 17 Feb 2006 08:16:39 -0600 (CST) Subject: [mcclim-cvs] CVS mcclim/Backends/CLX Message-ID: <20060217141639.85C082A5CB@common-lisp.net> Update of /project/mcclim/cvsroot/mcclim/Backends/CLX In directory common-lisp:/tmp/cvs-serv22211/Backends/CLX Modified Files: medium.lisp Log Message: Another .gold.ac.uk diff minimization: a translate-function which allows more than ASCII (and a long comment explaining why this is nowhere near the complete solution) --- /project/mcclim/cvsroot/mcclim/Backends/CLX/medium.lisp 2006/01/22 21:17:07 1.71 +++ /project/mcclim/cvsroot/mcclim/Backends/CLX/medium.lisp 2006/02/17 14:16:39 1.72 @@ -625,45 +625,78 @@ (defmethod text-style-width (text-style (medium clx-medium)) (text-style-character-width text-style medium #\m)) +(eval-when (:compile-toplevel :execute) + ;; ASCII / CHAR-CODE compatibility checking + (unless (equal (mapcar #'char-code '(#\Backspace #\Tab #\Linefeed + #\Page #\Return #\Rubout)) + '(8 9 10 12 13 127)) + (error "~S not ASCII-compatible for semi-standard characters: ~ + implement a CLX translate function for this implementation." + 'code-char)) + (let ((standard-chars " !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~")) + (dotimes (i 95) + (unless (eql (char standard-chars i) (code-char (+ i 32))) + (error "~S not ASCII-compatible for standard character ~S: ~ + implement a CLX translate function for this implementation." + 'code-char (code-char (+ i 32))))))) + +;;; The default CLX translation function is defined to work only for +;;; ASCII characters; quoting from the documentation, +;;; +;;; The default :translate function handles all characters that +;;; satisfy graphic-char-p by converting each character into its +;;; ASCII code. +;;; +;;; We provide our own translation function which is essentially the +;;; same as that of CLX, but with the ASCII restriction relaxed. This +;;; is by no means a proper solution to the problem of +;;; internationalization, because fonts tend not to have a complete +;;; coverage of the entirety of the Unicode space, even assuming that +;;; the underlying lisp supports it (as of 2006-02-06, only the case +;;; for SBCL and CLISP); instead, the translation function is meant to +;;; handle font sets by requesting the X server change fonts in the +;;; middle of rendering strings. However, the below stands a chance +;;; of working when using ISO-8859-1-encoded fonts, and will tend to +;;; lose in other cases. (defun translate (src src-start src-end afont dst dst-start) - ;; This is for replacing the clx-translate-default-function - ;; who does'nt know about accentated characters because - ;; of a call to cl:graphic-char-p that return nil with accentated characters. - ;; For further informations, on a clx-translate-function, see the clx-man. (declare (type sequence src) (type xlib:array-index src-start src-end dst-start) (type (or null xlib:font) afont) (type vector dst)) - #+cmucl(declare (xlib::clx-values integer - (or null integer xlib:font) - (or null integer))) + ;; FIXME: what if AFONT is null? (let ((min-char-index (xlib:font-min-char afont)) (max-char-index (xlib:font-max-char afont))) - afont (if (stringp src) (do ((i src-start (xlib::index+ i 1)) (j dst-start (xlib::index+ j 1)) (char)) ((xlib::index>= i src-end) i) - (declare (type xlib:array-index i j)) - (setq char (xlib:char->card8 (char src i))) - (if (or (< char min-char-index) (> char max-char-index)) - (return i) - (setf (aref dst j) char))) + (declare (type xlib:array-index i j)) + (setq char (char-code (char src i))) + (if (or (< char min-char-index) (> char max-char-index)) + (progn + (warn "Character ~S not representable in font ~S" + (char src i) afont) + (return i)) + (setf (aref dst j) char))) (do ((i src-start (xlib::index+ i 1)) (j dst-start (xlib::index+ j 1)) (elt)) ((xlib::index>= i src-end) i) - (declare (type xlib:array-index i j)) - (setq elt (elt src i)) - (when (characterp elt) (setq elt (xlib:char->card8 elt))) - (if (or (not (integerp elt)) - (< elt min-char-index) - (> elt max-char-index)) - (return i) - (setf (aref dst j) elt)))))) + (declare (type xlib:array-index i j)) + (setq elt (elt src i)) + (when (characterp elt) + (setq elt (char-code elt))) + (if (or (not (integerp elt)) + (< elt min-char-index) + (> elt max-char-index)) + (progn + (warn "Thing ~S not representable in font ~S" + (elt src i) afont) + (return i)) + (setf (aref dst j) elt)))))) (defmethod text-size ((medium clx-medium) string &key text-style (start 0) end) (when (characterp string) From rschlatte at common-lisp.net Sun Feb 19 18:08:24 2006 From: rschlatte at common-lisp.net (rschlatte) Date: Sun, 19 Feb 2006 12:08:24 -0600 (CST) Subject: [mcclim-cvs] CVS mcclim/Backends/CLX Message-ID: <20060219180824.870ED2A01B@common-lisp.net> Update of /project/mcclim/cvsroot/mcclim/Backends/CLX In directory common-lisp:/tmp/cvs-serv30890/Backends/CLX Modified Files: keysymdef.lisp Log Message: Escape constituent characters that are reserved to the programmer or the implementation, as per clhs 2.1.4. --- /project/mcclim/cvsroot/mcclim/Backends/CLX/keysymdef.lisp 2005/11/28 15:30:59 1.7 +++ /project/mcclim/cvsroot/mcclim/Backends/CLX/keysymdef.lisp 2006/02/19 18:08:24 1.8 @@ -373,7 +373,7 @@ ;; * Byte 3 = 0 ;; */ (define-keysym :| | #x20) -(define-keysym :! #x21) +(define-keysym :|!| #x21) (define-keysym :|"| #x22) (define-keysym :|#| #x23) (define-keysym :$ #x24) @@ -403,7 +403,7 @@ (define-keysym :< #x3c) (define-keysym := #x3d) (define-keysym :> #x3e) -(define-keysym :? #x3f) +(define-keysym :|?| #x3f) (define-keysym :@ #x40) (define-keysym :A #x41) (define-keysym :B #x42) @@ -431,9 +431,9 @@ (define-keysym :X #x58) (define-keysym :Y #x59) (define-keysym :Z #x5a) -(define-keysym :[ #x5b) +(define-keysym :|[| #x5b) (define-keysym :\\ #x5c) -(define-keysym :] #x5d) +(define-keysym :|]| #x5d) (define-keysym :^ #x5e) (define-keysym :_ #x5f) (define-keysym :|`| #x60) @@ -463,10 +463,10 @@ (define-keysym :|x| #x78) (define-keysym :|y| #x79) (define-keysym :|z| #x7a) -(define-keysym :{ #x7b) +(define-keysym :|{| #x7b) (define-keysym :\| #x7c) -(define-keysym :} #x7d) -(define-keysym :~ #x7e) +(define-keysym :|}| #x7d) +(define-keysym :|~| #x7e) (define-keysym :NOBREAKSPACE #xa0) (define-keysym :EXCLAMDOWN #xa1) (define-keysym :CENT #xa2) From tmoore at common-lisp.net Wed Feb 22 10:55:40 2006 From: tmoore at common-lisp.net (tmoore) Date: Wed, 22 Feb 2006 04:55:40 -0600 (CST) Subject: [mcclim-cvs] CVS mcclim Message-ID: <20060222105540.033122A034@common-lisp.net> Update of /project/mcclim/cvsroot/mcclim In directory common-lisp:/tmp/cvs-serv3495 Modified Files: gadgets.lisp Log Message: Fix some bit rot in the Beagle backend; not quite there. --- /project/mcclim/cvsroot/mcclim/gadgets.lisp 2005/12/01 11:10:55 1.94 +++ /project/mcclim/cvsroot/mcclim/gadgets.lisp 2006/02/22 10:55:40 1.95 @@ -513,7 +513,11 @@ :reader scroll-bar-scroll-up-page-callback) (thumb-size :initarg :thumb-size :initform 1/4 :accessor scroll-bar-thumb-size) - )) + ) + (:default-initargs :value 0 + :min-value 0 + :max-value 1 + :orientation :vertical)) (defmethod drag-callback ((pane scroll-bar) client gadget-id value) (declare (ignore client gadget-id)) @@ -1312,11 +1316,7 @@ (old-tb-y2 :initform nil) ;; (all-new-p :initform t) ) - (:default-initargs :value 0 - :min-value 0 - :max-value 1 - :orientation :vertical - :border-width 2 + (:default-initargs :border-width 2 :border-style :inset :background *3d-inner-color*)) From tmoore at common-lisp.net Wed Feb 22 10:55:41 2006 From: tmoore at common-lisp.net (tmoore) Date: Wed, 22 Feb 2006 04:55:41 -0600 (CST) Subject: [mcclim-cvs] CVS mcclim/Backends/beagle/native-panes Message-ID: <20060222105541.378762A03B@common-lisp.net> Update of /project/mcclim/cvsroot/mcclim/Backends/beagle/native-panes In directory common-lisp:/tmp/cvs-serv3495/Backends/beagle/native-panes Modified Files: beagle-scroll-bar-pane.lisp Log Message: Fix some bit rot in the Beagle backend; not quite there. --- /project/mcclim/cvsroot/mcclim/Backends/beagle/native-panes/beagle-scroll-bar-pane.lisp 2005/06/12 13:27:42 1.6 +++ /project/mcclim/cvsroot/mcclim/Backends/beagle/native-panes/beagle-scroll-bar-pane.lisp 2006/02/22 10:55:41 1.7 @@ -11,7 +11,7 @@ ;;; hackery out of gadgets.lisp (but shouldn't these be part of the abstract type?) ;;;(defclass beagle-scroll-bar-pane (scroll-bar) -(defclass beagle-scroll-bar-pane (scroll-bar-pane) +(defclass beagle-scroll-bar-pane (scroll-bar) ((tk-obj :initform (%null-ptr) :accessor toolkit-object))) From tmoore at common-lisp.net Thu Feb 23 17:39:32 2006 From: tmoore at common-lisp.net (tmoore) Date: Thu, 23 Feb 2006 11:39:32 -0600 (CST) Subject: [mcclim-cvs] CVS mcclim Message-ID: <20060223173932.C6BA82A1D6@common-lisp.net> Update of /project/mcclim/cvsroot/mcclim In directory common-lisp:/tmp/cvs-serv930 Added Files: Tag: 1.17 menu-choose.lisp Log Message: Move menu-choose out of Experiemental, because it isn't