----- "Oliver Uvman" oliver.uvman@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@free.fr wrote:
Hello,
----- "Oliver Uvman" oliver.uvman@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
Oh, Matthieu, thanks! That is perfect :D! I didn't know :after functions could be defined away from the function itself. Does this also work with normal (defun ..) functions? We are not using the OS part of CLOS in this lab series, so the entire lab is implemented with just normal functions (not even macros).
If this can't be managed, it seems like the 'incremental redisplay' facility is just what I need. Always a pity to reinvent the wheel.
/Oliver
On Tue, Jul 13, 2010 at 16:48, matthieu.villeneuve@free.fr wrote:
----- "Oliver Uvman" oliver.uvman@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@free.fr wrote:
Hello,
----- "Oliver Uvman" oliver.uvman@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
-
matthieu.villeneuve＠free.fr -
Oliver Uvman