From peter.denno at nist.gov Wed Feb 2 17:29:25 2005 From: peter.denno at nist.gov (Peter Denno) Date: Wed, 2 Feb 2005 12:29:25 -0500 Subject: [cells-gtk-devel] Lispworks Linux / SuSE 9.2 In-Reply-To: <41FD65B2.4060904@nyc.rr.com> References: <200501282126.50470.peter.denno@nist.gov> <200501301348.55451.peter.denno@nist.gov> <41FD65B2.4060904@nyc.rr.com> Message-ID: <200502021229.25632.peter.denno@nist.gov> The following works: diff -r --context cvs-cells-gtk/root/cells-gtk/gtk-app.lisp cells-gtk/root/cells-gtk/gtk-app.lisp *************** *** 81,87 **** (when *gtk-debug* (trc nil "STARTING GTK-MAIN") (force-output)) ! (gtk-main))))) (defvar *gtk-global-callbacks* nil) (defvar *gtk-loaded* #+clisp t #-clisp nil) ;; kt: looks like CLisp does this on its own --- 81,89 ---- (when *gtk-debug* (trc nil "STARTING GTK-MAIN") (force-output)) ! (loop ! (loop while (gtk-events-pending) do ! (gtk-main-iteration-do))))))) (defvar *gtk-global-callbacks* nil) (defvar *gtk-loaded* #+clisp t #-clisp nil) ;; kt: looks like CLisp does this on its own Of course, it now sits in the outer loop forever -- even after killing the window. If I knew what a quit-app event looked like, maybe I could exit the outer loop. I start the window in its own process and can kill it easily enough. So the above is OK with me. On Sunday 30 January 2005 17:54, Kenny Tilton wrote: > Peter Denno wrote: > >OK. My first question: Is this code running mp:without-scheduling, or > >something like it? (grepping, it appears not). In my code, when a callback > >attempts a mp:process-run-function, the function doesn't start until I > > kill the cells-gtk window. Hmmm... In fact, I don't get the listener back > > until after I kill the cells-gtk window, even when I start the gui with: > > > >(mp:process-run-function > > (format nil "Ion Version ~A" *m-version*) () > > #'(lambda () > > (cells-gtk-init) > > (cells-gtk:start-app 'cgui :debug dbg))) > > OK, I see at least that the AllegroCL IDE is not responsive after > control is given to gtk-main. I imagine this explains also why > mp:process-run-function does not work (or help when used to spawn the > demo originally). > > I am using ACL 6.2 on win32 which is documented as using native OS > threads, so I am not sure why gtkMain is blocking the other ACL IDE > windows. I do find that a break statement within a callback gets me to > the debugger and then all IDE windows are responsive, for what little > that is worth. > > One ugly workaround I used in the same situation with the OpenGL GLUT > application framework was to call glutMainLoopEvent repeatedly instead > of giving up control to glutMainLoop with one call. i would then sleep > 0.05 seconds in the loop, which gave ACL a chance to process events for > IDE windows. It seemed, btw, that if I set the sleep duration too low > (such as 0.03) the trick stopped working. > > I just looked at Gtk main documentation: > > http://developer.gnome.org/doc/API/2.0/gtk/gtk-General.html#gtk-main > > It looks as if a similar hack is possible, perhaps involving > gtk_main_iteration_do. > > of course I am only guessing that this will even work, and there may be > a simpler fix. if you want to try this approach and code something up > and have problems, send me what you come up with and I will try to find > time to look at it. > > cheers, kenny -- Best Regards, - Peter Peter Denno National Institute of Standards and Technology, Manufacturing System Integration Division, 100 Bureau Drive, Mail Stop 8264 Tel: +1 301-975-3595 Gaithersburg, MD, USA 20899-8264 FAX: +1 301-975-4694 From peter.denno at nist.gov Wed Feb 2 17:40:25 2005 From: peter.denno at nist.gov (Peter Denno) Date: Wed, 2 Feb 2005 12:40:25 -0500 Subject: [cells-gtk-devel] tree-view children Message-ID: <200502021240.26128.peter.denno@nist.gov> Hi, Does anyone here know how the tree-view widget in the example test-gtk/test-tree-view.lisp gets its children? I'd expect that you'd have to supply it with a function which takes an element of the tree and returns a list of its children. By the name of it, :items-factory seems to fit that description, but apparently it only provides the printed representation. :items (c? (list (upper self gtk-app))) :items-factory #'(lambda (item) (list (format nil "~a" (class-name (class-of item))) (case (class-name (class-of item)) (gtk-app "home") (vbox "open") (hbox "open") (window "index") (t "jump-to")) (length (kids item)) (format nil "~a" (when (subtypep (class-name (class-of item)) 'cells-gtk::gtk-object) (cells-gtk::id item))))) -- Best Regards, - Peter Peter Denno National Institute of Standards and Technology, Manufacturing System Integration Division, 100 Bureau Drive, Mail Stop 8264 Tel: +1 301-975-3595 Gaithersburg, MD, USA 20899-8264 FAX: +1 301-975-4694 From peter.denno at nist.gov Wed Feb 2 17:51:36 2005 From: peter.denno at nist.gov (Peter Denno) Date: Wed, 2 Feb 2005 12:51:36 -0500 Subject: [cells-gtk-devel] More on the gtk event loop usurping Message-ID: <200502021251.36828.peter.denno@nist.gov> Hi again, My last note suggested that the lisp process could just sit is a busy loop. Of course that isn't really very nice. I'll come up with something better. Sorry for the premature post. -- Best Regards, - Peter Peter Denno National Institute of Standards and Technology, Manufacturing System Integration Division, 100 Bureau Drive, Mail Stop 8264 Tel: +1 301-975-3595 Gaithersburg, MD, USA 20899-8264 FAX: +1 301-975-4694 From ktilton at nyc.rr.com Wed Feb 2 17:51:53 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 02 Feb 2005 12:51:53 -0500 Subject: [cells-gtk-devel] Lispworks Linux / SuSE 9.2 In-Reply-To: <200502021229.25632.peter.denno@nist.gov> References: <200501282126.50470.peter.denno@nist.gov> <200501301348.55451.peter.denno@nist.gov> <41FD65B2.4060904@nyc.rr.com> <200502021229.25632.peter.denno@nist.gov> Message-ID: <42011339.2010502@nyc.rr.com> Peter Denno wrote: >Of course, it now sits in the outer loop forever -- even after killing the >window. If I knew what a quit-app event looked like, maybe I could exit the >outer loop. > I do not think a window close entails an application quit, tho that is how things work on windows. Gtk is more general. So what you want to do (to get that win32 behavior) is call gtk-main-quit when you see a window closing (I was too lazy to look that up, but I think there must be some way to intercept that). If this were a Mac app, there would be an explicit "quit app" command unrelated to windows closing. The handling of that by your app should again be gtk_main_quit. One thing I like to do as a quicky in Cello development is bind the quit processing to the event key. The quit processing also sets a global *gtk-main-loop-exit* or some such, and then the outer loop is (loop while *gtk-main-loop*...) I will look at your tree-view question next. kt From ktilton at nyc.rr.com Wed Feb 2 18:06:23 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 02 Feb 2005 13:06:23 -0500 Subject: [cells-gtk-devel] Lispworks Linux / SuSE 9.2 In-Reply-To: <42011339.2010502@nyc.rr.com> References: <200501282126.50470.peter.denno@nist.gov> <200501301348.55451.peter.denno@nist.gov> <41FD65B2.4060904@nyc.rr.com> <200502021229.25632.peter.denno@nist.gov> <42011339.2010502@nyc.rr.com> Message-ID: <4201169F.4030906@nyc.rr.com> Kenny Tilton wrote: > One thing I like to do as a quicky in Cello development is bind the > quit processing to the event key. Sorry, that should be "escape key". > The quit processing also sets a global *gtk-main-loop-exit* or some > such, and then the outer loop is (loop while *gtk-main-loop*...) From ktilton at nyc.rr.com Wed Feb 2 18:42:45 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 02 Feb 2005 13:42:45 -0500 Subject: [cells-gtk-devel] tree-view children In-Reply-To: <200502021240.26128.peter.denno@nist.gov> References: <200502021240.26128.peter.denno@nist.gov> Message-ID: <42011F25.8040303@nyc.rr.com> Peter Denno wrote: >Hi, > >Does anyone here know how the tree-view widget in the example >test-gtk/test-tree-view.lisp gets its children? I'd expect that you'd have to >supply it with a function which takes an element of the tree and returns a >list of its children. By the name of it, :items-factory seems to fit that >description, but apparently it only provides the printed representation. > >:items (c? (list (upper self gtk-app))) >:items-factory #'(lambda (item) > (list > (format nil "~a" (class-name (class-of item))) > (case (class-name (class-of item)) > (gtk-app "home") > (vbox "open") > (hbox "open") > (window "index") > (t "jump-to")) > (length (kids item)) > (format nil "~a" > (when (subtypep (class-name (class-of item)) > 'cells-gtk::gtk-object) > (cells-gtk::id item))))) > > > > Right, items-factory might be better named "item-label-factory", since what it does is return the string to be displayed in the widget to describe the corresponding underlying item, which can be any arbitrary object. Now, as for where the items come from, well, we can see above the root items being defined, so I am guessing you mean where does the subtree of items come from once you "open" the tree item. Damned if I know. :) I have been poking around treebox and tree-view for a while, cannot spot anything. My guess, therefore, is that eventually we get a callback from Gtk which asks "what are the children of this object?". Then some GF is being dispatched on that object. So we have to find the callback and then the GF. My guess is that the ubiquitous "kids" slot is being sampled in this example, which would be a reasonable default for a Cells app. But I would expect an override (what "items-factory" sounds like but is not), so perhaps there is some GF which calls kids but can be overrode, or some other factory slot is being bound to #'kids. I will look around a little more later on. kt -- Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/ Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film "Doctor, I wrestled with reality for forty years, and I am happy to state that I finally won out over it." -- Elwood P. Dowd From vasilism at sch.gr Wed Feb 2 18:56:55 2005 From: vasilism at sch.gr (=?iso-8859-7?b?zMHRw8nP1cvB0yA=?= =?iso-8859-7?b?wsHTycvFyc/T?=) Date: Wed, 2 Feb 2005 20:56:55 +0200 Subject: [cells-gtk-devel] tree-view children In-Reply-To: <200502021240.26128.peter.denno@nist.gov> References: <200502021240.26128.peter.denno@nist.gov> Message-ID: <1107370615.42012277509e9@webmail.thess.sch.gr> >Peter Denno : > Hi, > > Does anyone here know how the tree-view widget in the example > test-gtk/test-tree-view.lisp gets its children? I'd expect that you'd have to > > supply it with a function which takes an element of the tree and returns a > list of its children. :items initarg takes a list of objects of type family (see doc/01-Cell-basics.lisp in cells for family documentation) Objects which subclass family have kids. In tree-view each kid is a leave (have no kids) or a subtree. So to use tree-view construct a list of one or more 'root' objects of type family. In example code tree-view is used to show the widget hierarchy of demo app All widgets in cells-gtk subclass family and gtk-app is the main window. > By the name of it, :items-factory seems to fit that > description, but apparently it only provides the printed representation. Right, it only provides the printed representation. ------------------------------------------------- This mail sent through Greek School Network: http://www.sch.gr/ ?? ?????? ?????? ???? ??? ??????????? ???????? ???????: http://www.sch.gr/ From vasilism at sch.gr Wed Feb 2 19:45:59 2005 From: vasilism at sch.gr (=?iso-8859-7?b?zMHRw8nP1cvB0yA=?= =?iso-8859-7?b?wsHTycvFyc/T?=) Date: Wed, 2 Feb 2005 21:45:59 +0200 Subject: [cells-gtk-devel] tree-view children In-Reply-To: <42011F25.8040303@nyc.rr.com> References: <200502021240.26128.peter.denno@nist.gov> <42011F25.8040303@nyc.rr.com> Message-ID: <1107373559.42012df7cd278@webmail.thess.sch.gr> Kenny Tilton wrote > I have been poking around treebox and tree-view for > a while, cannot spot anything. My guess, therefore, is that eventually > we get a callback from Gtk which asks "what are the children of this > object?". Then some GF is being dispatched on that object. So we have to > find the callback and then the GF. My guess is that the ubiquitous > "kids" slot is being sampled in this example, which would be a > reasonable default for a Cells app. But I would expect an override (what > "items-factory" sounds like but is not), so perhaps there is some GF > which calls kids but can be overrode, or some other factory slot is > being bound to #'kids. gtk-tree-store-set-kids traverse family-kids hierarchy and sets tree-store model. forcing :items to be of type family was propably a bad idea ------------------------------------------------- This mail sent through Greek School Network: http://www.sch.gr/ ?? ?????? ?????? ???? ??? ??????????? ???????? ???????: http://www.sch.gr/ From ktilton at nyc.rr.com Wed Feb 2 22:29:24 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 02 Feb 2005 17:29:24 -0500 Subject: [cells-gtk-devel] tree-view children In-Reply-To: <1107373559.42012df7cd278@webmail.thess.sch.gr> References: <200502021240.26128.peter.denno@nist.gov> <42011F25.8040303@nyc.rr.com> <1107373559.42012df7cd278@webmail.thess.sch.gr> Message-ID: <42015444.3030607@nyc.rr.com> ?????????? ????????? wrote: >Kenny Tilton wrote > > > >>I have been poking around treebox and tree-view for >>a while, cannot spot anything. My guess, therefore, is that eventually >>we get a callback from Gtk which asks "what are the children of this >>object?". Then some GF is being dispatched on that object. So we have to >>find the callback and then the GF. My guess is that the ubiquitous >>"kids" slot is being sampled in this example, which would be a >>reasonable default for a Cells app. But I would expect an override (what >>"items-factory" sounds like but is not), so perhaps there is some GF >>which calls kids but can be overrode, or some other factory slot is >>being bound to #'kids. >> >> > >gtk-tree-store-set-kids traverse family-kids hierarchy and sets tree-store >model. >forcing :items to be of type family was propably a bad idea > Well, not too bad looking at this: > (defun gtk-tree-store-set-kids (model val-tree par-iter index > column-types items-factory &optional path) > (with-tree-iter (iter) > (gtk-ffi::gtk-tree-store-append model iter par-iter) > (gtk-ffi::gtk-tree-store-set model iter > column-types > (append > (funcall items-factory val-tree) > (list (format nil "(~{~d ~})" (reverse (cons index path)))))) > (when (subtypep (class-name (class-of val-tree)) 'cells:family) > (loop for sub-tree in (cells:kids val-tree) > for pos from 0 do > (gtk-tree-store-set-kids model sub-tree iter > pos column-types items-factory (cons index path)))))) It looks as if we simply need to work in a GF (gtk-tree-kids?) specialized on Family and do some relatively trivial refactoring. Then if someone wants a different source of tree branches they simply specialize gtk-tree-kids on their class. (defmethod gtk-tree-kids ((self family)) (^kids)) and: ..... (loop for sub-tree in (gtk-tree-kids val-tree).... kt From peter.denno at nist.gov Thu Feb 3 01:25:36 2005 From: peter.denno at nist.gov (Peter Denno) Date: Wed, 2 Feb 2005 20:25:36 -0500 Subject: [cells-gtk-devel] tree-view children In-Reply-To: <42015444.3030607@nyc.rr.com> References: <200502021240.26128.peter.denno@nist.gov> <1107373559.42012df7cd278@webmail.thess.sch.gr> <42015444.3030607@nyc.rr.com> Message-ID: <200502022025.36731.peter.denno@nist.gov> On Wednesday 02 February 2005 17:29, Kenny Tilton wrote: > ?????????? ????????? wrote: > > > >gtk-tree-store-set-kids traverse family-kids hierarchy and sets tree-store > >model. > >forcing :items to be of type family was propably a bad idea > > Well, not too bad looking at this: > > (defun gtk-tree-store-set-kids (model val-tree par-iter index > > column-types items-factory &optional path) > > (with-tree-iter (iter) > > (gtk-ffi::gtk-tree-store-append model iter par-iter) > > (gtk-ffi::gtk-tree-store-set model iter > > column-types > > (append > > (funcall items-factory val-tree) > > (list (format nil "(~{~d ~})" (reverse (cons index path)))))) > > (when (subtypep (class-name (class-of val-tree)) 'cells:family) > > (loop for sub-tree in (cells:kids val-tree) > > for pos from 0 do > > (gtk-tree-store-set-kids model sub-tree iter > > pos column-types items-factory (cons index path)))))) > > It looks as if we simply need to work in a GF (gtk-tree-kids?) > specialized on Family and do some relatively trivial refactoring. Then > if someone wants a different source of tree branches they simply > specialize gtk-tree-kids on their class. > > (defmethod gtk-tree-kids ((self family)) (^kids)) > > and: > ..... > (loop for sub-tree in (gtk-tree-kids val-tree).... > > kt Yeah, but is it really necessary for the things in the tree to be CLOS objects, and subclasses of family? My trees have over 1000 objects in them. I have been using structs. I eliminated the test (when (subtypep (class-name (class-of val-tree)) 'cells:family) and wrote a method on cells:kids for my structs. Seems to work. Am I violating the cells model by doing that? Will I pay a price later? (I don't know, I have 0 experience with this). If my approach is OK, it is better (faster, more flexible) to allow the user to provide a children function and not use cells:kids at all --- or allow cells:kids to be the default if the child function isn't supplied. -- Best Regards, - Peter Peter Denno National Institute of Standards and Technology, Manufacturing System Integration Division, 100 Bureau Drive, Mail Stop 8264 Tel: +1 301-975-3595 Gaithersburg, MD, USA 20899-8264 FAX: +1 301-975-4694 From ktilton at nyc.rr.com Thu Feb 3 02:16:54 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 02 Feb 2005 21:16:54 -0500 Subject: [cells-gtk-devel] tree-view children In-Reply-To: <200502022025.36731.peter.denno@nist.gov> References: <200502021240.26128.peter.denno@nist.gov> <1107373559.42012df7cd278@webmail.thess.sch.gr> <42015444.3030607@nyc.rr.com> <200502022025.36731.peter.denno@nist.gov> Message-ID: <42018996.6020909@nyc.rr.com> Peter Denno wrote: >On Wednesday 02 February 2005 17:29, Kenny Tilton wrote: > > >>?????????? ????????? wrote: >> >> >>>gtk-tree-store-set-kids traverse family-kids hierarchy and sets tree-store >>>model. >>>forcing :items to be of type family was propably a bad idea >>> >>> >>Well, not too bad looking at this: >> >> >>>(defun gtk-tree-store-set-kids (model val-tree par-iter index >>>column-types items-factory &optional path) >>> (with-tree-iter (iter) >>> (gtk-ffi::gtk-tree-store-append model iter par-iter) >>> (gtk-ffi::gtk-tree-store-set model iter >>> column-types >>> (append >>> (funcall items-factory val-tree) >>> (list (format nil "(~{~d ~})" (reverse (cons index path)))))) >>> (when (subtypep (class-name (class-of val-tree)) 'cells:family) >>> (loop for sub-tree in (cells:kids val-tree) >>> for pos from 0 do >>> (gtk-tree-store-set-kids model sub-tree iter >>> pos column-types items-factory (cons index path)))))) >>> >>> >>It looks as if we simply need to work in a GF (gtk-tree-kids?) >>specialized on Family and do some relatively trivial refactoring. Then >>if someone wants a different source of tree branches they simply >>specialize gtk-tree-kids on their class. >> >> (defmethod gtk-tree-kids ((self family)) (^kids)) >> >>and: >>..... >> (loop for sub-tree in (gtk-tree-kids val-tree).... >> >>kt >> >> > >Yeah, but is it really necessary for the things in the tree to be CLOS >objects, and subclasses of family? My trees have over 1000 objects in them. I >have been using structs. > That is fine. You can specialize a method on the struct just as well as any CLOS class. As you did.... > >I eliminated the test (when (subtypep (class-name (class-of val-tree)) >'cells:family) and wrote a method on cells:kids for my structs. Seems to >work. Am I violating the cells model by doing that? Will I pay a price later? > Oh, I would break the Family-to- Gtk-tree thing once and for all by creating an API entry (gtk-tree-kids) and letting the Family class answer with KIDS, but let other things answer any way they like. I think specializing KIDS as you did will work (haven't checked to see if I myself messed up and assumed somewhere that KIDS was only specialized on Family or its descendants) but that could happen eventually. The way I attack close calls like this goes like this: do you really want your structures to behave like Family in some way, or do you just want gtk-trees to accept your non-Family structures? I see the latter as what is really going on, in which case gtk-trees are not justified in using KIDS to get the branches of a tree. gtk-trees should offer a GF which anyone can specialize to answer the branches question. >(I don't know, I have 0 experience with this). If my approach is OK, it is >better (faster, more flexible) to allow the user to provide a children >function and not use cells:kids at all --- or allow cells:kids to be the >default if the child function isn't supplied. > > Sorry, did you mean to say "is it better"? Anyway, I say gtk-trees should not know about the Family class unnecesssarily (I have not checked to see if it already has some other dependencies). In which case the cells-gtk package should just support a gtk-trees-kids (or -branches or -children or -subtrees) call, provide a default method which returns nil, and let clients supply a callback as needed. kt -- Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/ Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film "Doctor, I wrestled with reality for forty years, and I am happy to state that I finally won out over it." -- Elwood P. Dowd From peter.denno at nist.gov Thu Feb 3 15:51:20 2005 From: peter.denno at nist.gov (Peter Denno) Date: Thu, 3 Feb 2005 10:51:20 -0500 Subject: [cells-gtk-devel] tree-view children In-Reply-To: <42018996.6020909@nyc.rr.com> References: <200502021240.26128.peter.denno@nist.gov> <200502022025.36731.peter.denno@nist.gov> <42018996.6020909@nyc.rr.com> Message-ID: <200502031051.20327.peter.denno@nist.gov> On Wednesday 02 February 2005 21:16, Kenny Tilton wrote: > >I eliminated the test (when (subtypep (class-name (class-of val-tree)) > >'cells:family) and wrote a method on cells:kids for my structs. Seems to > >work. Am I violating the cells model by doing that? Will I pay a price > > later? > > Oh, I would break the Family-to- Gtk-tree thing once and for all by > creating an API entry (gtk-tree-kids) and letting the Family class > answer with KIDS, but let other things answer any way they like. > > I think specializing KIDS as you did will work (haven't checked to see > if I myself messed up and assumed somewhere that KIDS was only > specialized on Family or its descendants) but that could happen eventually. > > The way I attack close calls like this goes like this: do you really > want your structures to behave like Family in some way, or do you just > want gtk-trees to accept your non-Family structures? I see the latter as > what is really going on, in which case gtk-trees are not justified in > using KIDS to get the branches of a tree. gtk-trees should offer a GF > which anyone can specialize to answer the branches question. Agreed, I favor the latter also. In fact, I'd not use a GF but a user supplied function -- and thereby eliminate the overhead of identifying the effective method. But, a GF is an OK with me if that's what you guys want. > >(I don't know, I have 0 experience with this). If my approach is OK, it is > >better (faster, more flexible) to allow the user to provide a children > >function and not use cells:kids at all --- or allow cells:kids to be the > >default if the child function isn't supplied. > > ? > > Sorry, did you mean to say "is it better"? Poorly worded, wasn't it? I meant only what I just said above: that ideally the user would supply a function. Whether or not it names a GF or is regular function would be his business....You might also have an accessor on the slot referencing this function so that it can be changed to address different presentations. The construction of the trees in my application takes about 15 seconds. But I don't know yet where the time is going. (Is it in calls to the child method or something else?) > Anyway, I say gtk-trees > should not know about the Family class unnecesssarily (I have not > checked to see if it already has some other dependencies). In which case > the cells-gtk package should just support a gtk-trees-kids (or -branches > or -children or -subtrees) call, provide a default method which returns > nil, and let clients supply a callback as needed. I like the cells concept, but there will always be places where for reasons of efficiency or just mismatch of design, it would be good to "have an out." Another place where I think I will need "an out" in my code is updating a progress bar: I check the size of a hash-table to determine the size of the progress bar. Its not the value in a cells slot that changes, (the value is always the same hash-table) it is the size of the table. And ideally I wouldn't update the bar after every write to the table -- that would be too often -- but maybe every 50 or 100. So maybe what I'd do here is use cells to start and stop the periodic (by timer timeout) invocation of a progress bar update process. -- Best Regards, - Peter From ktilton at nyc.rr.com Thu Feb 3 16:52:06 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 03 Feb 2005 11:52:06 -0500 Subject: [cells-gtk-devel] tree-view children In-Reply-To: <200502031051.20327.peter.denno@nist.gov> References: <200502021240.26128.peter.denno@nist.gov> <200502022025.36731.peter.denno@nist.gov> <42018996.6020909@nyc.rr.com> <200502031051.20327.peter.denno@nist.gov> Message-ID: <420256B6.5080302@nyc.rr.com> Peter Denno wrote: >On Wednesday 02 February 2005 21:16, Kenny Tilton wrote: > > >> .... >> >>gtk-trees should offer a GF >>which anyone can specialize to answer the branches question. >> >> > >Agreed, I favor the latter also. In fact, I'd not use a GF but a user supplied >function -- and thereby eliminate the overhead of identifying the effective >method. But, a GF is an OK with me if that's what you guys want. > A slot for a user-supplied function seems like a good idea to me, though for a different reason (than GF dispatch performance, which I think is pretty decent since most implementations optimize that nicely). I see it as offering more flexibility, in that different instances of the same class can have different functions to determine the subtrees. This happens also to be a nice feature of Cells: different instances of the same class can have different rules for the same slot. So, yeah, go ahead and create a (what?) subtrees-factory slot. Other suggestions for the name are welcome. > The construction of the trees in my application takes about 15 > seconds. But I > >don't know yet where the time is going. (Is it in calls to the child method >or something else?) > Yikes. Let's take a look at this. Is this under AllegroCL? Which version? I have 5, 6.2, and 7. Can I just hack the tree test panel to add 1000 subtrees and see the same result? As soon as I saw that 1000 number I started thinking there might be a problem, because all 1000 get processed into gtk objects in one shot just to put up the list. It would be interesting (to me anyway) to have a diagnostic print out the interval between the creation of each object: (defvar *gtk-spawn-time* nil) then somewhere where a gtk object gets created, perhaps in a new initialize-instance method: .... (when *gtk-spawn-time* (format t "~>k spawn interval: ~a msec for type ~a" (- (get-internal-real-time) *gtk-spawn-time*) (type-of self))) (setf *gtk-spawn-time* (get-internal-real-time)) I am wondering if they are all roughly 15 msec apart, or if it gets slower and slower over time because gtk is sorting them (or some cell dependency is growing exponentially). I am no GTk programmer. Is this something (1000 list itmes) you have done in other Lisp-Gtk systems or from another language, and you know it to be fast? (Just as background--either way I would like to help you find a fix for this.) > I like the cells concept, but there will always be places where for > reasons of > >efficiency or just mismatch of design, it would be good to "have an out." > Sure. But I have a few optimization tricks in Cells, and more could be added, so feel free to check with me when you think you need an out. For example: >Another place where I think I will need "an out" in my code is updating a >progress bar: I check the size of a hash-table to determine the size of the >progress bar. Its not the value in a cells slot that changes, (the value is >always the same hash-table) it is the size of the table. > Right. You would need to set up artificially a second cell slot called ????-table-size and then increment that after each write. Then the progress bar can just "watch" the size slot. Cells includes a feature called Synapses which would let you set the sensitivity to an arbitrary value to avoid excessive updates. Or do I what I did in our commercial application: since any number of things could be slow enough to warrant giving the user some indication that the app was busy working, I created a little progress-bar system. Come to think of it, it is pretty silly because it does not attempt to show actual progress, it just keeps filling and refilling the bar to keep the user entertained. Anyway, with that I just have a progress-make function which I sprinkle around anywhere I suspect the system will run slow. If there happens to be a progress bar displayed somewhere, it gets a bump. If not, it is a no-op. Then any time I see process X is slow, I put up the progress bar before initiating X. > And ideally I >wouldn't update the bar after every write to the table -- that would be too >often -- but maybe every 50 or 100. > Let me know if you need help with synapses, if you want to go that route. > So maybe what I'd do here is use cells to >start and stop the periodic (by timer timeout) invocation of a progress bar >update process. > That would work. Peter, I will contact c-l.net today to see about getting you authorized as a Cells-gtk project admin. The acceleration from that black hole is getting pretty intense already. :) kenny From peter.denno at nist.gov Sat Feb 5 16:18:01 2005 From: peter.denno at nist.gov (Peter Denno) Date: Sat, 5 Feb 2005 11:18:01 -0500 Subject: [cells-gtk-devel] Suggested patches Message-ID: <200502051118.01737.peter.denno@nist.gov> Hi, Attached is a patch file of suggested revisions. I don't have CVS rights yet. I don't think you should apply these because there is also a new file (conditions.lisp, the start of a condition taxonomy). The attachment is just so you can see what I have in mind. These are mostly as discussed, regarding tree-view: 1) A new initarg :children-fn 2) :items-factory --> :print-fn 3) :items --> roots 3.1) In listbox, a subclass of tree-view, I added the initarg :items (since it is called :roots in the superclass). I also wrote accessors for items that call the roots accessors, so it would go through the def-c-output for root. (Do I understand this stuff correctly?) 4) Some other stuff to clean up the loading. More to do here. 5) An attempt at dealing with the process usurping and error handling. The error handling stuff needs work, and I should probably grab the mp compatibility functions from the port library... and #-clisp it... Like I say, this patch is just for discussion. -- Best Regards, - Peter Peter Denno National Institute of Standards and Technology, Manufacturing System Integration Division, 100 Bureau Drive, Mail Stop 8264 Tel: +1 301-975-3595 Gaithersburg, MD, USA 20899-8264 FAX: +1 301-975-4694 -------------- next part -------------- A non-text attachment was scrubbed... Name: cells-gtk.patch Type: text/x-diff Size: 25779 bytes Desc: not available URL: From peter.denno at nist.gov Sun Feb 6 02:28:38 2005 From: peter.denno at nist.gov (Peter Denno) Date: Sat, 5 Feb 2005 21:28:38 -0500 Subject: [cells-gtk-devel] table with dynamic elements Message-ID: <200502052128.39031.peter.denno@nist.gov> Hi, I'm a bit lost about how to do this. I'd like to add elements to a table and have them appear. What I am getting is this error: (setf md-slot-value)> cellular slot ELEMENTS of # cannot be setf unless initialized as inputp. I thought maybe it was because the elements slot of table is not a cell slot, so I tried changing it by adding (c-in nil): (def-widget table () ((elements :accessor elements :initarg :elements :initform (c-in nil)) No difference. An example is below. If I stop and check the table, it has only 5 cell slots, and none for elements. If I make a table at the command line with (make-instance 'example) it has many more cell slots, including one for elements. I suppose I am doing something obviously wrong. I don't have much experience with this yet. (in-package :test-gtk) (defmodel example (gtk-app) ((ndisp :cell t :accessor ndisp :initform (c-in 2))) (:default-initargs :expand t :fill t :md-name :example :title "example" :kids (list (mk-vbox :kids (list (mk-hbox :kids (list (mk-button :label "more" :on-clicked (callback (w e d) (incf (ndisp (upper self example))))) (mk-button :label "less" :on-clicked (callback (w e d) (decf (ndisp (upper self example))))))) (mk-table :md-name :my-table :height 200 :elements (c? (list (list (mk-entry :init "Hello")) (list (mk-entry :init "World")))))))))) (def-c-output ndisp ((self example) newval oldval) (when (and newval oldval) (let ((table (cells::fm-descendant-named self :my-table))) ; better way? (cond ((< newval oldval) (pop (elements table))) ((> newval oldval) (push (list (mk-entry :init (format nil "New ~a" newval))) (elements table))))))) (defun doit () (cells-gtk-init) (cells-gtk:start-app 'example)) -- Best Regards, - Peter From peter.denno at nist.gov Sun Feb 6 17:59:00 2005 From: peter.denno at nist.gov (Peter Denno) Date: Sun, 6 Feb 2005 12:59:00 -0500 Subject: [cells-gtk-devel] table with dynamic elements In-Reply-To: <42058F28.6000008@nyc.rr.com> References: <200502052128.39031.peter.denno@nist.gov> <42058F28.6000008@nyc.rr.com> Message-ID: <200502061259.00548.peter.denno@nist.gov> Hi kenny, My use of ndisp was not very well thought out, it was there because the example is based on code I was porting from CAPI. Here I don't have any need for a slot that counts the number of elements. I wasn't able to get your example to work because I am under a bit of pressure to go for a hike, it being so nice out today. But if I eliminate all the ndisp junk I get a pretty simple program that still doesn't work (same error). (one quick try is all I had time for). Keep in mind that I am guessing a lot about how table works, and putting the (c-in nil) in Vasilis's code was just a guess: (def-widget table () ((elements :accessor elements :initarg :elements :initform (c-in nil)) (defmodel example (gtk-app) () (:default-initargs :expand t :fill t :md-name :example :title "example" :kids (list (mk-vbox :kids (list (mk-hbox :kids (list (mk-button :label "more" :on-clicked (callback (w e d) (push (list (mk-entry :init "new")) (elements (fm-other :table))))) (mk-button :label "less" :on-clicked (callback (w e d) (pop (elements (fm-other :table))))))) (mk-table :md-name :table :height 200 :elements (c? (list (list (mk-entry :init "Hello")) (list (mk-entry :init "World")))))))))) That pretty much eliminates my use of cells, leaving only my reliance on the assumption that the elements slots uses them in a way that makes updates possible. On Saturday 05 February 2005 22:29, Kenny Tilton wrote: > Peter, I had written quite a bit before realizing the problem. I think > it is useful background, so I am leaving it in. The good stuff, tho, is > towards the end. > > Peter Denno wrote: > >Hi, > > > >I'm a bit lost about how to do this. I'd like to add elements to a table > > and have them appear. > > > >What I am getting is this error: > >(setf md-slot-value)> cellular slot ELEMENTS of #
cannot > > be setf unless initialized as inputp. > > > >I thought maybe it was because the elements slot of table is not a cell > > slot, so I tried changing it by adding (c-in nil): > > If elements were not a cell slot, you would be allowed to setf it. > Unless I have a bug in there, non-cell slots should work according to > standard CLOS rules. And the default is to make a slot a cell. > > btw, I have gone back and forth on this so I would have to check, but I > did have a validation check that warned me if I specified a cell (via c? > or c-in) for a non-cell slot. I am a little fuzzy on that, tho. > > The error you show is for precisely the case where a cell slot has been > initialized or defaulted to some maked literal value, including nil, and > one attempts a setf on it. So your adding (c-in nil) should have worked. > Lesseee..... > > >(def-widget table () > > ((elements :accessor elements :initarg :elements :initform (c-in nil)) > > > >No difference. > > The (c? (list ...hello...world) initarg supplanted the (c-in nil), which > is why this had no effect. > > To make your code work, at mk-table time you could have just specified > (c-in (list ...hello...world)). But down below I offer a neater > solution, avoiding the echo. > > >An example is below. If I stop and check the table, it has only 5 cell > > slots, and none for elements. If I make a table at the command line with > > (make-instance 'example) it has many more cell slots, including one for > > elements. I suppose I am doing something obviously wrong. I don't have > > much experience with this yet. > > How are you counting up the cell slots? There are two ways to count. One > is to ask how many slots have been defined as being cells slots. This > means they get special plumbing on their accessors. But I can then > initialize such a slot to nil or 42 or anything else, as well (c?...) or > (c-in ...). I think you are saying you only see a few cells (c?, c-in) > for the many cell slots. And yes, that depends on what is suppliet at > make-instance. > > Note also that c?-type cells can get optimized away if their rule does > not access some other c? or c-in, and this cascades, so I can start off > with all C?, some referencing each other, but if those get optimized > away, then those depending on them may get optimized away. I have a > second intenals slot in each instance for "optimized-away" or somesuch. > > Now if I am guessing right...oh, wait, I think i see the problem: > >(in-package :test-gtk) > > > >(defmodel example (gtk-app) > > ((ndisp :cell t :accessor ndisp :initform (c-in 2))) > > (:default-initargs > > > > :expand t :fill t > > :md-name :example :title "example" > > :kids (list > > > > (mk-vbox > > > > :kids > > > > (list > > (mk-hbox > > > > :kids > > > > (list > > (mk-button :label "more" > > > > :on-clicked (callback (w e d) > > > > (incf (ndisp (upper self > >example))))) > > (mk-button :label "less" > > > > :on-clicked (callback (w e d) > > > > (decf (ndisp (upper self > >example))))))) > > (mk-table > > > > :md-name :my-table > > :height 200 > > :elements (c? > > > > (list (list (mk-entry :init "Hello")) > > (list (mk-entry :init "World")))))))))) > > > >(def-c-output ndisp ((self example) newval oldval) > > (when (and newval oldval) > > (let ((table (cells::fm-descendant-named self :my-table))) ; better > > way? (cond ((< newval oldval) > > (pop (elements table))) > > ((> newval oldval) > > (push (list (mk-entry :init (format nil "New ~a" newval))) > > (elements table))))))) > > > >(defun doit () > > (cells-gtk-init) > > (cells-gtk:start-app 'example)) > > Here is a new rule for elements: > :elements (c? (let ((ex (upper self example))) > > (bwhen (ndisp-delta (f-delta () (ndisp ex))) > (cond > ((eql delta 1 (cons (mk-entry :init (format nil "New > ~a" (ndisp ex))) > .cache))) > ((eql delta -1 (cdr .cache))) > (t (list )))))) > > That bit at the end is a little sketchy. I /think/ it will work to > initialize the list. > > Caveat: I am actually working on the black hole right now so I have not > time to test the above, but if it does not work i will take a few > minutes to make sure I get you something that works. I hesitate because > I changed synapses (such as f-delta above) recently and i am not sure > the code I borrowed from is valid. > > Two tricks: f-delta, the synapse, returns the change in ndisp, not the > value. > Second: .cache is a symbol-macro which returns the current value of > cell, so you can change it without re-consing the whole thing. Just amke > sure a new cons cell gets returned (do not do delete on an item in the > middle) or Cells will not see the change (the default test is EQL). > > All this said, I am concerned about having to hard-code the (c-in 2). > What if we had the more/less buttons operate directly on the list and > made ndisp simply (c? (length (elements (fm-other :table))? > > I am guessing you are just experimenting, but in this case you have a > hybrid situation where elements starts as a specified list of hello and > world but then becomes a function of changes to ndisp. And ndisp starts > as a function of elements (the 2 matching the 2 elements) but then gets > controlled by the user. > > So I think your experimenting (if I am right!) has led to a tough case > for Cells, but only because of shisting relationships I would not expect > in a real interface. > > cheers. kt > > ps. I am really rushing this and I am beat after a day on the slopes, so > just come back with anything I screwed up and I will sort it out, > perhaps tomorrow. -- Best Regards, - Peter Peter Denno National Institute of Standards and Technology, Manufacturing System Integration Division, 100 Bureau Drive, Mail Stop 8264 Tel: +1 301-975-3595 Gaithersburg, MD, USA 20899-8264 FAX: +1 301-975-4694 From asimon at math.bme.hu Mon Feb 7 15:44:17 2005 From: asimon at math.bme.hu (Andras Simon) Date: Mon, 7 Feb 2005 16:44:17 +0100 (CET) Subject: [cells-gtk-devel] pulse Message-ID: The Pulse button in the Display demo sends cmucl immediately to the debugger. The following patch corrects this, but cmucl ffi experts should refrain from looking at it. --- cells-gtk/widgets.lisp 3 Jan 2005 22:33:16 -0000 1.7 +++ cells-gtk/widgets.lisp 7 Feb 2005 14:45:36 -0000 @@ -247,6 +247,12 @@ (trc nil "timeout func really returning" r2) r2)) +#+cmu +(alien:def-callback timeout-handler-callback + ((boolean 1) (data (* integer))) + (let* ((id (elti data 0)) + (r2 (gtk-global-callback-funcall id))) + (if r2 1 0))) (defun timeout-add (milliseconds function) (let ((id (gtk-global-callback-register Allegro (6.2/Linux) on the other hand will happily start to pulse, but will not stop, no matter what. I wonder if it's like this on Windows, too. Andras From asimon at math.bme.hu Mon Feb 7 16:08:24 2005 From: asimon at math.bme.hu (Andras Simon) Date: Mon, 7 Feb 2005 17:08:24 +0100 (CET) Subject: [cells-gtk-devel] pulse In-Reply-To: References: Message-ID: On Mon, 7 Feb 2005, Andras Simon wrote: > > Allegro (6.2/Linux) on the other hand will happily start to pulse, but > will not stop, no matter what. I wonder if it's like this on Windows, > too. Actually, the same kludge (returning an integer instead of a boolean) solves this. I.e., now I have #-cmu (ff-defun-callable :cdecl :int timeout-handler-callback ((data (* :int))) ;;(print (list :timeout-handler-callback data)) (let* ((id (elti data 0)) (r2 (gtk-global-callback-funcall id))) (trc t "timeout func really returning" r2) (if r2 1 0))) in widgets.lisp and it seems to work for acl. (Don't know abot LW or acl/windows.) > > Andras > _______________________________________________ > cells-gtk-devel site list > cells-gtk-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-gtk-devel > From ktilton at nyc.rr.com Mon Feb 7 21:40:56 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 07 Feb 2005 16:40:56 -0500 Subject: [cells-gtk-devel] pulse In-Reply-To: References: Message-ID: <4207E068.7050608@nyc.rr.com> Andras Simon wrote: > The Pulse button in the Display demo sends cmucl immediately to the > debugger. The following patch corrects this, but cmucl ffi experts > should refrain from looking at it. > > --- cells-gtk/widgets.lisp 3 Jan 2005 22:33:16 -0000 1.7 > +++ cells-gtk/widgets.lisp 7 Feb 2005 14:45:36 -0000 > @@ -247,6 +247,12 @@ > (trc nil "timeout func really returning" r2) > r2)) > > +#+cmu > +(alien:def-callback timeout-handler-callback > + ((boolean 1) (data (* integer))) > + (let* ((id (elti data 0)) > + (r2 (gtk-global-callback-funcall id))) > + (if r2 1 0))) > > (defun timeout-add (milliseconds function) > (let ((id (gtk-global-callback-register > Thanks for the patches. > > > Allegro (6.2/Linux) on the other hand will happily start to pulse, but > will not stop, no matter what. I wonder if it's like this on Windows, > too. Yes, it is the same on Windows. This is the relevant code: (defmodel test-display (vbox) () (:default-initargs :md-value (c? (when (md-value (fm-other :pulse)) (timeout-add (md-value (fm-other :timeout)) (lambda () (pulse (fm-other :pbar2)) (md-value (fm-other :pulse)))))) Apparently with Gtk, if the callback returns true the timeout gets reposted, if it returns false it does not. Just guessing. If so, does this mean we have to translate the return value to 0/1 instead of nil/t? Maybe I broke this porting to UFFI, which does not have the same trick as CLisp's FFI of translating automaticall between Lisp and C truth values. I hacked that up (IIRC) for explicit API wrappers, but not lambdas. Sorry, I am guilty of a lot of guesswork, but I am caught up now in a commercial project and do not have time to look into this. kt From peter.denno at nist.gov Tue Feb 8 22:21:45 2005 From: peter.denno at nist.gov (Peter Denno) Date: Tue, 8 Feb 2005 17:21:45 -0500 Subject: [cells-gtk-devel] clisp version? Message-ID: <200502081721.45675.peter.denno@nist.gov> Hi, The cells-gtk web page talks about the original clisp version. And INSTALL.TXT in the .tar file refers to it as clisp-cgtk.lisp, but it appears that such a file does not exist. Is there still a clisp version? Did it get merged in? -- Best Regards, - Peter Peter Denno National Institute of Standards and Technology, Manufacturing System Integration Division, 100 Bureau Drive, Mail Stop 8264 Tel: +1 301-975-3595 Gaithersburg, MD, USA 20899-8264 FAX: +1 301-975-4694 From asimon at math.bme.hu Tue Feb 8 22:37:08 2005 From: asimon at math.bme.hu (Andras Simon) Date: Tue, 8 Feb 2005 23:37:08 +0100 (CET) Subject: [cells-gtk-devel] clisp version? In-Reply-To: <200502081721.45675.peter.denno@nist.gov> References: <200502081721.45675.peter.denno@nist.gov> Message-ID: On Tue, 8 Feb 2005, Peter Denno wrote: > Hi, > > The cells-gtk web page talks about the original clisp version. And INSTALL.TXT > in the .tar file refers to it as clisp-cgtk.lisp, but it appears that such a > file does not exist. > > Is there still a clisp version? Did it get merged in? This is the original clisp version: http://common-lisp.net/cgi-bin/viewcvs.cgi/clisp-cgtk/?cvsroot=cells-gtk The link on http://common-lisp.net/project/cells-gtk/ is misleading (mislinking?). Andras > > -- > Best Regards, > - Peter > > Peter Denno > National Institute of Standards and Technology, > Manufacturing System Integration Division, > 100 Bureau Drive, Mail Stop 8264 Tel: +1 301-975-3595 > Gaithersburg, MD, USA 20899-8264 FAX: +1 301-975-4694 > _______________________________________________ > cells-gtk-devel site list > cells-gtk-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-gtk-devel > From peter at petermcd.com Fri Feb 11 23:24:40 2005 From: peter at petermcd.com (Peter McDermott) Date: Sat, 12 Feb 2005 00:24:40 +0100 Subject: [cells-gtk-devel] Cool Message-ID: <1108164280.29254.14.camel@pingpong> I managed to get the cells-gtk demos to run earlier today on clisp. Very cool! If, in the next few days, I'm able to transform the gtk-demo code into the beginnings of the lisp/gtk application I working on, I will be very, very happy. I read the documentation on cells itself and briefly checked out the gtk example code. One thing that isn't quite clear to me, is, why does UI programming lend itself to a system like cells? I mean, I understand the spreadsheet analogy for a spreadsheet, but not necessarily for a UI. Any pointers on how to wrap my traditional message-loop-dispatch thought processes around cells-gtk would be much appreciated. Also, is there any relationship between cells-gtk can cello? By the way, I'm new to lisp--just started six days ago after much reading about it. So that may explain some of my thickness. -Peter M P.S. I couldn't get the tarball from cvs to run on cmucl. It gave me a cryptic error about something related to "usr/lib." Is this known? If not, I can try it out again tomorrow. From peter.denno at nist.gov Fri Feb 11 17:14:07 2005 From: peter.denno at nist.gov (Peter Denno) Date: Fri, 11 Feb 2005 12:14:07 -0500 Subject: [cells-gtk-devel] Cool In-Reply-To: <1108164280.29254.14.camel@pingpong> References: <1108164280.29254.14.camel@pingpong> Message-ID: <200502111214.07920.peter.denno@nist.gov> On Friday 11 February 2005 18:24, Peter McDermott wrote: > I managed to get the cells-gtk demos to run earlier today on clisp. > Very cool! > > If, in the next few days, I'm able to transform the gtk-demo code into > the beginnings of the lisp/gtk application I working on, I will be very, > very happy. I did the same over the last week or so. It wasn't too hard. > I read the documentation on cells itself and briefly checked out the gtk > example code. One thing that isn't quite clear to me, is, why does UI > programming lend itself to a system like cells? I mean, I understand > the spreadsheet analogy for a spreadsheet, but not necessarily for a UI. Well, having not written cello or cells-gtk, but now used it, I guess I am somewhat a neutral observer: GUI programming can get very messy very fast. It appears to me that the cells approach really does manage the complexity of the code nicely. And WRT to the implementation of a GTK binding for lisp, and what I can see studying Vasilis's code, it seems it made the implementation more elegant too. > Any pointers on how to wrap my traditional message-loop-dispatch thought > processes around cells-gtk would be much appreciated. > > Also, is there any relationship between cells-gtk can cello? Cello is the "cells" in "cells-gtk" You loaded cello to get things running. > By the way, I'm new to lisp--just started six days ago after much > reading about it. So that may explain some of my thickness. > > -Peter M > > P.S. I couldn't get the tarball from cvs to run on cmucl. It gave me a > cryptic error about something related to "usr/lib." Is this known? If > not, I can try it out again tomorrow. I am working with Andras on this. He has the cmucl stuff working. The belief was that the tarball version supported cmucl, but that hasn't been my experience. (And there is more to it than not finding the libraries). I am going to make some cvs commits, maybe later today, to fix some things with tree-view selection on #-Clisp... and some other stuff. I hope to get the cmucl patches in there too.. -- Best Regards, - Peter From ktilton at nyc.rr.com Fri Feb 11 18:45:47 2005 From: ktilton at nyc.rr.com (ktilton at nyc.rr.com) Date: Fri, 11 Feb 2005 11:45:47 -0700 Subject: [cells-gtk-devel] Cool Message-ID: <203d78e203cd92.203cd92203d78e@rdc-nyc.rr.com> ----- Original Message ----- From: Peter Denno Date: Friday, February 11, 2005 10:14 am Subject: Re: [cells-gtk-devel] Cool > On Friday 11 February 2005 18:24, Peter McDermott wrote: > > I managed to get the cells-gtk demos to run earlier today on clisp. > > Very cool! > > > > If, in the next few days, I'm able to transform the gtk-demo > code into > > the beginnings of the lisp/gtk application I working on, I will > be very, > > very happy. > > I did the same over the last week or so. It wasn't too hard. > > > I read the documentation on cells itself and briefly checked out > the gtk > > example code. One thing that isn't quite clear to me, is, why > does UI > > programming lend itself to a system like cells? I mean, I > understand> the spreadsheet analogy for a spreadsheet, but not > necessarily for a UI. > > Well, having not written cello or cells-gtk, but now used it, I > guess I am > somewhat a neutral observer: GUI programming can get very messy > very fast. It > appears to me that the cells approach really does manage the > complexity of > the code nicely. Yes and yes. As GUIs get more interesting, they get more and more user controls, and more and more visible things which must stay consistent with the changing state of those controls. How often do we hide/uncover a window or resize it when the display gets all messed up, just to get the code to redraw from scratch and get past some update bug? With Cells, a control does not need to go change, say, the justification of a text widget. The control just changes it's own internal bound value from :left (or 'left) to :center to :right. The text widget is coded to watch the changing state of the justification control. This kind of thing decouples widgets and makes widget self-documenting: if you want to know how the text widget gets justified differently, look at the rules (...well, maybe the rendering method) for the text widget. One can look at this way: Cells support a declarative style of development. I just think about all the things that can effect the state of one slot and I write a rule to cover those things exactly as I want. Then the Cells engine makes it all work. And, again, one gets nice documentation of that slot. When all sorts of different code in different places is dumping values into any given slot, well, you can see a buggy value in a slot and not be sure where to look to find out how it got there. In the declarative model, there is never any doubt, just one rule to stare at. > And WRT to the implementation of a GTK binding > for lisp, and > what I can see studying Vasilis's code, it seems it made the > implementation > more elegant too. Cool. Vasilis did an amazing job, with no input from me at all. Zero. I am still in shock. I have not cast a critical eye on his use of Cells, so I am not sure it is as declarative as it could be. I see a lot of SETFs in c-output functions, and wonder if the place SETF'ed could not have had a rule simply sampling the cell with the c-output. But I also think Vasilis may be a better programmer than me, so I should keep my mouth shut until I find an actual case of that. > > > Any pointers on how to wrap my traditional message-loop-dispatch > thought> processes around cells-gtk would be much appreciated. If you at least download the Cello code, you will see how I tend to glue the declarative model of cells with the event/message-loop model of typical gui programming. In brief, any event/message such as keydown is handled by creating a cell proxy for the event. ie, I give the Window class a cell slot for "keyDown" (or "keyState" to do a little early processing of keyDown/keyUp and collapse it into one). Then in the message/event handler you just see: (case (message-type this-os-event) ... (WM_KEYDOWN (setf (keystate this-window) 'down)) ...) If I am using a window manager that just gives me event/messages, you might just see: (defun registered-event-handler (window event) (setf (event window) event)) Then diff cells on the window look to see if they care about the event. After that, it is all a cascade of Cells firing and calling their output functions. > > > > Also, is there any relationship between cells-gtk can cello? > > Cello is the "cells" in "cells-gtk" You loaded cello to get > things running. I named Cells and Cello too closely. :) Cello uses Cells. Cells-gtk uses Cells (not Cello). Celtik uses Cells (and Ltk). Otherwise, those three have nothing in common. > > > By the way, I'm new to lisp--just started six days ago after much > > reading about it. So that may explain some of my thickness. Well, don't feel bad if Cells gives you fits at first. Even veteran Lispniks sometimes get frustrated by the lack of documentation. And it seems like magic until you get used to it. And it is a paradigm shift. I invented it (ignorant of all the prior art) but I still found myself falling into an imperative style from time to time for a good 6-9 months. kenny From peter.denno at nist.gov Fri Feb 11 20:08:31 2005 From: peter.denno at nist.gov (Peter Denno) Date: Fri, 11 Feb 2005 15:08:31 -0500 Subject: [cells-gtk-devel] Cool In-Reply-To: <203d78e203cd92.203cd92203d78e@rdc-nyc.rr.com> References: <203d78e203cd92.203cd92203d78e@rdc-nyc.rr.com> Message-ID: <200502111508.32685.peter.denno@nist.gov> On Friday 11 February 2005 13:45, ktilton at nyc.rr.com wrote: > > Cello is the "cells" in "cells-gtk" ?You loaded cello to get > > things running. > > I named Cells and Cello too closely. :) > > Cello uses Cells. Cells-gtk uses Cells (not Cello). Celtik uses Cells (and > Ltk). Otherwise, those three have nothing in common. Oops. Sorry. I thought they were the same. I'll have to check out Cello. -- Best Regards, - Peter From peter at petermcd.com Wed Feb 16 00:20:21 2005 From: peter at petermcd.com (Peter McDermott) Date: Wed, 16 Feb 2005 01:20:21 +0100 Subject: [cells-gtk-devel] menu questions In-Reply-To: <200502111508.32685.peter.denno@nist.gov> References: <203d78e203cd92.203cd92203d78e@rdc-nyc.rr.com> <200502111508.32685.peter.denno@nist.gov> Message-ID: <1108513221.29254.69.camel@pingpong> Sat down for a good day and played around with cells-gtk some more. Fun! I have a few questions: - Text is centered inside the pulldown menus when I expected it would be left-aligned. Is there some way to change this to left-aligned? - Any way to create a menu-item with a mnemonic? (Note: using ":stock :new" when creating a "new" menu-item creates a left-aligned menu-item with a mnemonic. But this only works for stock menu-items.) - Exiting the app. Seems my Exit callback should signal a delete-event to get gtk to properly shutdown my application. I can't quite figure it out from the example code. Any suggestions? -Peter M From peter.denno at nist.gov Tue Feb 15 17:48:26 2005 From: peter.denno at nist.gov (Peter Denno) Date: Tue, 15 Feb 2005 12:48:26 -0500 Subject: [cells-gtk-devel] menu questions In-Reply-To: <1108513221.29254.69.camel@pingpong> References: <203d78e203cd92.203cd92203d78e@rdc-nyc.rr.com> <200502111508.32685.peter.denno@nist.gov> <1108513221.29254.69.camel@pingpong> Message-ID: <200502151248.27874.peter.denno@nist.gov> On Tuesday 15 February 2005 19:20, Peter McDermott wrote: > Sat down for a good day and played around with cells-gtk some more. > Fun! > > I have a few questions: > > - Text is centered inside the pulldown menus when I expected it would be > left-aligned. Is there some way to change this to left-aligned? > > - Any way to create a menu-item with a mnemonic? > > (Note: using ":stock :new" when creating a "new" menu-item creates a > left-aligned menu-item with a mnemonic. But this only works for stock > menu-items.) FWIW, I have some code that I haven't committed to CVS yet. It allows you to define your own stock icons (which then can be used in menus etc, and are left justified as the existing stock icons). Look for it in a day or so. Of course, we ought to find a way to left justify the ad hoc items too. > - Exiting the app. Seems my Exit callback should signal a delete-event > to get gtk to properly shutdown my application. I can't quite figure it > out from the example code. Any suggestions? I'm not sure if this is related, but I was just looking at gtk-app.lisp where I see it has a default :on-delete-event : :on-delete-event (lambda (self widget event data) (declare (ignore self widget event data)) (gtk-main-quit) 0))) > _______________________________________________ > cells-gtk-devel site list > cells-gtk-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-gtk-devel -- Best Regards, - Peter From ktilton at nyc.rr.com Tue Feb 15 23:38:21 2005 From: ktilton at nyc.rr.com (ktilton at nyc.rr.com) Date: Tue, 15 Feb 2005 18:38:21 -0500 Subject: [cells-gtk-devel] setting parent Message-ID: <21492852148612.21486122149285@rdc-nyc.rr.com> Peter, You asked about setting the parent directly. I think that will be a mess. First of all, there is an "adoption" sequence in cells intialization (part of to-be processing). Second, instance should then appear in the parents kids slot. ie, The Family class is kind of an API, and setting the fm-parent would be breaking the API. Why do you need this? I wager answering that will avoid the need to setf the fm-parent. btw,as an aside, there has been one time when I made the parent slot a cell. Pretty scary (speaking as the author of the Family class) but it worked. cheers, kenny From peter.denno at nist.gov Wed Feb 16 01:11:29 2005 From: peter.denno at nist.gov (Peter Denno) Date: Tue, 15 Feb 2005 20:11:29 -0500 Subject: [cells-gtk-devel] setting parent In-Reply-To: <21492852148612.21486122149285@rdc-nyc.rr.com> References: <21492852148612.21486122149285@rdc-nyc.rr.com> Message-ID: <200502152011.29545.peter.denno@nist.gov> On Tuesday 15 February 2005 18:38, ktilton at nyc.rr.com wrote: > Peter, > > You asked about setting the parent directly. I think that will be a mess. > First of all, there is an "adoption" sequence in cells intialization (part > of to-be processing). Second, instance should then appear in the parents > kids slot. ie, The Family class is kind of an API, and setting the > fm-parent would be breaking the API. Kenny, Thanks. Yes, that is the problem I am facing. The cells-gtk application of the cells defmodel (and thus the Family API) describes a decomposition of widgets. One widget contains others etc. It is a happy coincidence that this is the pattern that applies to most uses of the widgets, but... > Why do you need this? I wager answering that will avoid the need to setf > the fm-parent. Right. For those just tuning in the code was this, recently added to cells-gtk/widgets.lisp: (def-c-output popup ((self event-box)) ? (when new-value ? ? (setf (fm-parent new-value) self))) The kid of the event-box is the widget that is going to respond to with the popup. ... Here's the whole thing: (mk-event-box :popup (mk-menu :kids (list (mk-menu-item :label "Test 1") :on-activate (callback (w e d) (setf (choice (upper self regexp-box)) "whatever")))) :kids (list ...))) The problem is that the object made with mk-menu above isn't in the hierarchy. (If it were, I suppose it would show up as a menu, not be a popup menu). But it needs to refer to things in the hierarchy -- like it is doing with (choice (upper self regexp-box)). I tried all sorts of things, closures etc to get it to reference outside of its own little hierarchy. I couldn't find a way. [ugh, now I've got to go back and prove that again....] Vasilis's test code (test-menu.lisp) doesn't get an error because the menu items for the popup don't do anything. At least that's my theory. I hope you can disprove it, by showing me how to do the referencing. * * * I actually have another example where the strict 1-1 mapping between widget hierarchy and kids hierarchy doesn't work: user-specified stock icons. But I think I have a solution to that one. (clos object aren't really needed here, but getting the stock icons defined before the model build happens has been a challenge.). > btw,as an aside, there has been one time when I made the parent slot a > cell. Pretty scary (speaking as the author of the Family class) but it > worked. I don't understand cells well enough to know why that is scary. There are ways of adding and removing elements from the model, right? I suppose it means recalculating a lot of stuff though. > > cheers, kenny -- Best Regards, - Peter From ktilton at nyc.rr.com Wed Feb 16 15:43:31 2005 From: ktilton at nyc.rr.com (ktilton at nyc.rr.com) Date: Wed, 16 Feb 2005 10:43:31 -0500 Subject: [cells-gtk-devel] setting parent Message-ID: <2172b35216b89c.216b89c2172b35@rdc-nyc.rr.com> > Thanks. Yes, that is the problem I am facing. The cells-gtk > application of the > cells defmodel (and thus the Family API) describes a decomposition > of > widgets. One widget contains others etc. It is a happy coincidence > that this > is the pattern that applies to most uses of the widgets, but... First the good news: the pattern has been made to work for all sorts of hairy problems with widgets dynamically appearing and disappearing, so I think we will be OK. But I am taking a few minutes before heading out for a day of skiing so I might not be able to give you the full story until later today. > > > Why do you need this? I wager answering that will avoid the need > to setf > > the fm-parent. > > Right. For those just tuning in the code was this, recently added > to > cells-gtk/widgets.lisp: > > (def-c-output popup ((self event-box)) > ? (when new-value > ? ? (setf (fm-parent new-value) self))) > > The kid of the event-box is the widget that is going to respond to > with the > popup. ... Here's the whole thing: > > (mk-event-box > :popup > (mk-menu > :kids (list > (mk-menu-item :label "Test 1") > :on-activate > (callback (w e d) > (setf (choice (upper self regexp-box)) "whatever")))) > :kids > (list ...))) Two possible tricks. First, always make kids a rule: (c? ....) Then you can have code somewhat like: :responder (make-responder) :kids (c? (list (when ))) Or you can have a "socket" widget: :kids (c? (list (make-socket :kids (c? (when )) Another trick is to have the pop-up always exist, but make it visible/invisible based on some condition. (Less desirable, to my taste.) > > The problem is that the object made with mk-menu above isn't in > the hierarchy. > (If it were, I suppose it would show up as a menu, not be a popup > menu). But > it needs to refer to things in the hierarchy -- like it is doing > with (choice > (upper self regexp-box)). I tried all sorts of things, closures > etc to get > it to reference outside of its own little hierarchy. I couldn't > find a way. > [ugh, now I've got to go back and prove that again....] If you make the pop-up a c? rule, you always have "self" to link you into the hierarchy: :pop-up (c? (make-menu :owner self....)) Note that self would be the event-box in this context, and that I just invented the owner slot (tho I usually use "owner" in cases like this, which I have encountered before. Mind you, a popup is in most guis its own window, so the conenction to the other visible widget is just by physical proximity (and by trapping self for the semantic connection.) > I actually have another example where the strict 1-1 mapping > between widget > hierarchy and kids hierarchy doesn't work: user-specified stock > icons. But I > think I have a solution to that one. (clos object aren't really > needed here, > but getting the stock icons defined before the model build happens > has been a > challenge.). We can look at that, too, if you give me more specifics. Mind you, to a degree we have to blind-lead-blind since I do not know Gtk. But I reckon we can muddle thru. > > > btw,as an aside, there has been one time when I made the parent > slot a > > cell. Pretty scary (speaking as the author of the Family class) > but it > > worked. > > I don't understand cells well enough to know why that is scary. > There are ways > of adding and removing elements from the model, right? I suppose > it means > recalculating a lot of stuff though. No, there are a couple of tricks for that. One is the Family-values class, which is efficient about building/removing kids. Another applies to any c? rule: their is a .cache symbol-macro which lets you preserve kids from a prior evaluation without recreating them (and in general with any rule work off the prior computed value (unless on the first evaluation). gotta run, kenny From peter.denno at nist.gov Wed Feb 16 23:06:33 2005 From: peter.denno at nist.gov (Peter Denno) Date: Wed, 16 Feb 2005 18:06:33 -0500 Subject: [cells-gtk-devel] setting parent In-Reply-To: <2172b35216b89c.216b89c2172b35@rdc-nyc.rr.com> References: <2172b35216b89c.216b89c2172b35@rdc-nyc.rr.com> Message-ID: <200502161806.33626.peter.denno@nist.gov> On Wednesday 16 February 2005 10:43, ktilton at nyc.rr.com wrote: > Two possible tricks. First, always make kids a rule: (c? ....) Do you really mean "always" here? I haven't done it before. I don't see it used in Vasilis's demo either. > > If you make the pop-up a c? rule, you always have "self" to link you into the hierarchy: > :pop-up (c? (make-menu :owner self....)) > > Note that self would be the event-box in this context, and that I just > invented the owner slot (tho I usually use "owner" in cases like this, > which I have encountered before. This worked, thanks. Is self being bound to the containing mk- something we can count on? > > > I actually have another example where the strict 1-1 mapping > > between widget > > hierarchy and kids hierarchy doesn't work: user-specified stock > > icons. But I > > think I have a solution to that one. (clos object aren't really > > needed here, > > but getting the stock icons defined before the model build happens > > has been a > > challenge.). > > We can look at that, too, if you give me more specifics. Mind you, to a > degree we have to blind-lead-blind since I do not know Gtk. But I reckon we > can muddle thru. This turns out to be something that can, and probably should be, done without using the clos objects, it is all gtk calls. I added an initialize-instance :after method to gtk-app that you can see in the cvs repository, cells-gtk/gtk-app.lisp. Thanks for the help. -- Best Regards, - Peter From ktilton at nyc.rr.com Thu Feb 17 14:47:51 2005 From: ktilton at nyc.rr.com (ktilton at nyc.rr.com) Date: Thu, 17 Feb 2005 09:47:51 -0500 Subject: [cells-gtk-devel] setting parent Message-ID: <204be03204a3fd.204a3fd204be03@rdc-nyc.rr.com> ----- Original Message ----- From: Peter Denno Date: Wednesday, February 16, 2005 6:06 pm Subject: Re: [cells-gtk-devel] setting parent > On Wednesday 16 February 2005 10:43, ktilton at nyc.rr.com wrote: > > > Two possible tricks. First, always make kids a rule: (c? ....) > > Do you really mean "always" here? I haven't done it before. I > don't see it > used in Vasilis's demo either. No, I did not mean it. That happens to be my policy for reasons I cannot explain in this quick response before heading out, but you are right, it is not always required. > > > > > If you make the pop-up a c? rule, you always have "self" to link > you into > the hierarchy: > > :pop-up (c? (make-menu :owner self....)) > > > > Note that self would be the event-box in this context, and that > I just > > invented the owner slot (tho I usually use "owner" in cases like > this,> which I have encountered before. > > This worked, thanks. Is self being bound to the containing mk- > > something we can count on? Yes. C? has the incidental quality of not running until just after instance-initialization. Without the c?, as you know, the form after the initarg gets evaluated very early, so the value can be passed to make-instance. With c?, you can supply an initialization form which is aware of the instance being made. I think expanding or examining the macro c? will be helpful. > > > > > > I actually have another example where the strict 1-1 mapping > > > between widget > > > hierarchy and kids hierarchy doesn't work: user-specified stock > > > icons. But I > > > think I have a solution to that one. (clos object aren't really > > > needed here, > > > but getting the stock icons defined before the model build happens > > > has been a > > > challenge.). > > > > We can look at that, too, if you give me more specifics. Mind > you, to a > > degree we have to blind-lead-blind since I do not know Gtk. But > I reckon we > > can muddle thru. > > This turns out to be something that can, and probably should be, > done without > using the clos objects, it is all gtk calls. I added an > initialize-instance :after method to gtk-app that you can see in > the cvs > repository, cells-gtk/gtk-app.lisp. OK, I will be back home late tonight, but the black hole commercial Lisp opportunity is really accelerating. I will do my damndest to keep any cells-gtk user going until I can get you some proper doc, but it may be hit or miss. cheers, kenny From peter.denno at nist.gov Sun Feb 20 18:12:14 2005 From: peter.denno at nist.gov (Peter Denno) Date: Sun, 20 Feb 2005 13:12:14 -0500 Subject: [cells-gtk-devel] error message Message-ID: <200502201312.14955.peter.denno@nist.gov> Hi, Could someone tell me what this 'error message' means? whoa. more than 64 used by [?#:=[0]TEXT/#