July 2010 - mcclim-devel - mailman3.common-lisp.net

Re: [mcclim-devel] mcclim-devel Digest, Vol 39, Issue 6
by Irene DURAND 27 Mar '13

27 Mar '13

Hello, As my paste on irc lisp, did not have any answer, I turning again to this more specialized mailing list. I have this MClim problem. The application runs fine on Linux with SBCL 1.0.13, xorg-x11-server 1.3.0.0-9.fc7, a recent version of MClim. But doesn't on my Mac (Darwin PowerPC) with MacOS 10.5 (leopard), SBCL 1.0.16, cvs version of MClim, Xquartz 2.1.5 - (xorg-server 1.3.0-apple22)(2.1.5). I have tried to create the smallest as possible application where the problems occurs (attached). Just compile the file and launch mini::(start) On Linux, I have the desired behaviour: a circle blinks (red/green/red/...) on the display pane and at the bottom of the window application, the "quit" button is displayed and works. On the Mac, the circle blinks correctly but the "Quit" button never shows up. For a while the application is killable with C-c C-c (under Slime), but after a while there is no way to kill it than to stop Lisp and restart everything (even /the/ <http://www.lispworks.com/reference/HyperSpec/Body/s_the.htm> X server). Note that this application used to work on Mac OS 10.3 (Panther) with older versions of everything. I suspect the X server to behave differently from before. But now I don't see how to make the application work. This is too bad, as I usually use a similar application for my Lisp undergraduate course. If anyone has an idea, it will be welcomed. Irène (defpackage :mini (:use :clim :clim-extensions :clim-lisp)) (in-package :mini) (let ((colors (list +red+ +green+))) (setf colors (nconc colors colors)) (defun display-function (frame pane) (draw-circle* pane 10 10 10 :ink (pop colors)) (sleep 0.5) (redisplay-frame-panes frame))) (defun quit () (frame-exit *application-frame*)) (define-application-frame mini () () (:panes (display :application :display-function 'display-function :incremental-redisplay t) (quit :push-button :label "Quit" :activate-callback (lambda (x) (declare (ignore x)) (quit)))) (:layouts (defaults (vertically () display quit)))) (defun run-test (name) (loop for port in climi::*all-ports* do (destroy-port port)) (setq climi::*all-ports* nil) (let ((frame (make-application-frame name))) (run-frame-top-level frame))) (defun start () (run-test 'mini) 0) (defmethod run-frame-top-level :before ((mini mini) &key) (let* ((frame-manager (frame-manager *application-frame*)) (port (climi::frame-manager-port frame-manager)) (display (clim-clx::clx-port-display port))) (setf (xlib:display-after-function display) g#'xlib:display-force-output)))

4 4

[mcclim-devel] Push or Pull data in application
by Oliver Uvman 14 Jul '10

14 Jul '10

Hello! I'm now beginning to write my first GUI with McClim, and there seem to be an abundance of interface-building resources, so I'll be able to keep going for a while without help. I am writing this as an additional user interface to our backend program. The backend is a calendar program used at my university (Linköping University) to teach abstraction. The idea is that either manual interaction with the backend or interaction via the Clim frontend can be used, at the same time or separately. Anything done in one should be observable in the other. The problem I know I will eventually run into is updating the Clim interface when changes to data have been made through manual interaction with the backend. The solutions are either push or pull based, I guess. Push based is not really prefered, because the backend would have to keep track of the gui so it can send messages to it. We need to keep the backend as simple and clean as possible, because it is to be modified by the students. Thus I would rather prefer a pull-based approach where, every 80-90ms or so the application itself requests up-to-date data from the backend and redraws if necessary. Is there a standard way to go about this? It seems like it is a problem that would appear in almost any application. Regards, Oliver Uvman

3 3

[mcclim-devel] Errors installing McClim
by Oliver Uvman 13 Jul '10

13 Jul '10

Hello! I'm trying to follow the guide on http://mcclim.cliki.net/McCLIM%2BSBCL for installing McClim, but when I do (asdf-install:install :mcclim) I get an error, which I tried to accept and continue the install from, but the errors just keep coming after that so I thought I'd ask. The error I'm getting is: ; compilation aborted because of fatal error: ; SB-INT:SIMPLE-READER-PACKAGE-ERROR at 5151 (line 128, column 45) on #<SB-SYS:FD-STREAM ; for "file /usr/share/common-lisp/source/slime/swank-loader.lisp" ; {BF565E1}>: ; package "CLC" not found ; ; compilation aborted after 0:00:00.063 debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" RUNNING {A9F5811}>: The value NIL is not of type (OR (VECTOR CHARACTER) (VECTOR NIL) BASE-STRING PATHNAME STREAM). I tried (asdf-install:install :clc) but there doesn't seem to be a package with that name. I know it stands for common-lisp-controller, and I have it apt-getted on my system (Ubuntu Lucid x86). Anybody know what the problem is? Regards, Oliver Uvman

7 15

Re: [mcclim-devel] Push or Pull data in application
by matthieu.villeneuve＠free.fr 13 Jul '10

13 Jul '10

----- "Oliver Uvman" <oliver.uvman(a)gmail.com> a écrit : > Matthieu: Yes, that would be the push-type mechanism. The problem > about it then is that the backend would have to know when a gui is > running or not, and be able to send messages to that gui (keeping > some > address reference to it or whatever). I'd rather not touch the > backend > code at all, as that would muddy the waters for the people who are > looking at the first large lisp app in their lives. The thing is, even if the :after methods I was talking about are "attached" to backend generic functions, I consider that they belong to the GUI code, so the backend code doesn't have to maintain information about the GUI. Something like this: (in-package :app-gui) (defun draw-foo (object) ...) (defmethod app-backend:set-coords :after ((object foo) x y) (when *application-frame* (draw-foo object))) That way, the backend code doesn't depend on the GUI code. If you group those :after methods in a separate file, you could even choose to load it or not, depending on whether you want to allow direct modifications of backend data (which should be reflected in the GUI). > Maybe I should also note that this is the first time the students > meet > layered abstraction, so the app so far has a strict top-down > dependency model. Code in one layer may not depend on code in a layer > above it. Preferably I'd like to keep the gui in a layer of its own, > above all other layers. This would keep things simple for the > students, they'd never need to look in the gui code (if they don't > want to). > > /Oliver > > On Tue, Jul 13, 2010 at 16:01, <matthieu.villeneuve(a)free.fr> wrote: > > Hello, > > > > ----- "Oliver Uvman" <oliver.uvman(a)gmail.com> a écrit : > >> The problem I know I will eventually run into is updating the Clim > >> interface when changes to data have been made through manual > >> interaction with the backend. The solutions are either push or > pull > >> based, I guess. Push based is not really prefered, because the > backend > >> would have to keep track of the gui so it can send messages to it. > > > > [Disclaimer: I don't remember much about GUIs and CLIM...] > > > > Couldn't you define, as part of your GUI code, and for every > "relevant" > > backend method that updates the application data, an :after method > that > > updates or refreshes the interface contents? -- Matthieu Villeneuve

2 1

Re: [mcclim-devel] Push or Pull data in application
by matthieu.villeneuve＠free.fr 13 Jul '10

13 Jul '10

Hello, ----- "Oliver Uvman" <oliver.uvman(a)gmail.com> a écrit : > The problem I know I will eventually run into is updating the Clim > interface when changes to data have been made through manual > interaction with the backend. The solutions are either push or pull > based, I guess. Push based is not really prefered, because the backend > would have to keep track of the gui so it can send messages to it. [Disclaimer: I don't remember much about GUIs and CLIM...] Couldn't you define, as part of your GUI code, and for every "relevant" backend method that updates the application data, an :after method that updates or refreshes the interface contents? Cheers, -- Matthieu Villeneuve

2 1