[cells-devel] Re: Celtk: setting the content of a text widget ? Fileevent working !
Am 20.05.2006 um 20:16 schrieb Frank Goenninger:
Am 20.05.2006 um 18:24 schrieb Ken Tilton:
Frank Goenninger wrote:
Hi Kenny, hi all:
I do have a text widget which is created using mk-text-widget:
(mk-text-widget :id :receive-window :state 'disabled :md-value (c?n "...") :height 10 :width 80 :borderwidth 2 :relief 'sunken :pady 5))
No matter what I do (even setting :state to 'enabled) I do get anything printed in the text widget.
I actually execute a setf on md-value of the text widget:
(setf (md-value (fm-other :receive-window)) data)
Any idea? Thx!
Hmmm, looks like I did not finish implementing text widgets.
Yep, meanwhile I recognized that an observer is missing in file entry.lisp.
Well, actually I had to do (in file entry.lisp): ;; Method CLEAR: clears a text widget to zero content (defmethod clear ((self text-widget)) (tk-format `(:variable ,self) "~a delete 1.0 end" (^path))) ;; This observer puts text to the widget if md-value has been set ;; Also takes care of edge cases like initialization time and setting ;; strings of length 0... (defobserver .md-value ((self text-widget)) (trc "md-value output" self new-value) (if (or (and (not old-value) (string= new-value "")) (not new-value)) (tk-format `(:variable ,self) "~a delete 1.0 end" (^path)) (if (> (length new-value) 0) (tk-format `(:variable ,self) "~a insert end ~a" (^path) new- value)))) With this and my fileevent stuff I can now say: ;; Model for a simple terminal output window. (defmodel fileevent-test-window (window) () (:default-initargs :kids (c? (the-kids (mk-stack (:packing (c?pack-self)) (mk-label :text "Receive window" :pady 10) (mk-text-widget :id :receive-window ;:state 'disabled :md-value (c-in "") :height 10 :width 80 :borderwidth 2 :relief 'sunken :pady 5)) (mk-fileevent :id :fileevent-test :read-fn 'read-from-pipe :iostream (open "/Users/frgo/tmp/frgo-test" :direction :input)))))) ;; The method read-from-pipe reads data from a pipe generated by ;; mkfifo /Users/frgo/tmp/frgo-test and puts this as the data of a ;; text widget (defmethod read-from-pipe ((self tk-fileevent) &optional (operation :read)) (declare (ignorable operation)) (let ((stream (^iostream))) (let ((data (read-line stream nil nil nil))) (trc "*** READ-FROM-PIPE: data = " data) (when data (setf (md-value (fm-other :receive-window)) data)))) ) ;; Test function that fires up the test case (defun test-fileevent () (trc "----------------------------------------------------------------------- ------") (test-window 'fileevent-test-window) (trc "----------------------------------------------------------------------- ------") ) Now, whenever I do a $ echo "Heya this is a test" > /Users/frgo/tmp/frgo-test the text gets displayed in the window. Of course there's other uses for this: You also can open a socket and send application commands to the application. The read-from-pipe function would then be a little interpreter kicking of actions in the application... For me I put the reading function to listen to a RS232C port that is connected to an AVR-based microcontroller. The controller send status information and voltage and current values from a power supply to be displayed as info by my application... Fileevent to be put to Celtk CVS in a few days ... watch out. Frank
On 5/20/06, Frank Goenninger <fgoenninger@prion.de> wrote:
Am 20.05.2006 um 20:16 schrieb Frank Goenninger:
Am 20.05.2006 um 18:24 schrieb Ken Tilton:
Frank Goenninger wrote:
Hi Kenny, hi all:
I do have a text widget which is created using mk-text-widget:
(mk-text-widget :id :receive-window :state 'disabled :md-value (c?n "...") :height 10 :width 80 :borderwidth 2 :relief 'sunken :pady 5))
No matter what I do (even setting :state to 'enabled) I do get anything printed in the text widget.
I actually execute a setf on md-value of the text widget:
(setf (md-value (fm-other :receive-window)) data)
Any idea? Thx!
Hmmm, looks like I did not finish implementing text widgets.
Yep, meanwhile I recognized that an observer is missing in file entry.lisp.
Well, actually I had to do (in file entry.lisp):
;; Method CLEAR: clears a text widget to zero content
(defmethod clear ((self text-widget)) (tk-format `(:variable ,self) "~a delete 1.0 end" (^path)))
;; This observer puts text to the widget if md-value has been set ;; Also takes care of edge cases like initialization time and setting ;; strings of length 0...
(defobserver .md-value ((self text-widget)) (trc "md-value output" self new-value) (if (or (and (not old-value) (string= new-value "")) (not new-value)) (tk-format `(:variable ,self) "~a delete 1.0 end" (^path)) (if (> (length new-value) 0) (tk-format `(:variable ,self) "~a insert end ~a" (^path) new- value))))
I took your stuff and whittled it down to: (defobserver .md-value ((self text-widget)) (trc "md-value output" self new-value) (with-integrity (:client `(:variable ,self)) (tk-format-now "~a delete 1.0 end" (^path)) (when (plusp (length new-value)) (tk-format-now "~a insert end ~s" (^path) new-value)))) That way two (setf (md-value self) "Hi mom") calls do not produce "Hi momHi mom". I was not sure the API entry point CLEAR was needed elsewhere. I can see that it would be, though. Really, the more I look at the text widget the more I think it needs imperative processing by application code that has a clear idea of what it wants to do with all the capabilities of the widget. I also brought both commands within the same integrity bundle by skipping the tk-format syntactic sugar and open-coding with-integrity. That just saves one enqueue, no big deal. A bigger deal is that the sort done by tk-user-queue-handler was not (until just now <g>) a stable sort, so the delete could have been executed after the insert. Bringing both operations into the single integrity bundle also fixes that.
Now, whenever I do a
$ echo "Heya this is a test" > /Users/frgo/tmp/frgo-test
the text gets displayed in the window.
Isn't great when we get stuff like that working? Is there a universal law: any time the effect produced by your own code surprises you, you are probably onto something good. Programming never gets old.
Fileevent to be put to Celtk CVS in a few days ... watch out.
Thx. I am switching all my code to LLGPL now, btw. I think we settled on that for your stuff, yes? kt
Am 21.05.2006 um 22:48 schrieb Ken Tilton:
I took your stuff and whittled it down to:
(defobserver .md-value ((self text-widget)) (trc "md-value output" self new-value) (with-integrity (:client `(:variable ,self)) (tk-format-now "~a delete 1.0 end" (^path)) (when (plusp (length new-value)) (tk-format-now "~a insert end ~s" (^path) new-value))))
That way two (setf (md-value self) "Hi mom") calls do not produce "Hi momHi mom".
Hm, yes, but ... ;-) This changes behavior. Ok, I never really said anywhere anything about the implied behavior ... <g> Now, whenever the model is set the whole text widget gets cleared and then the whole widget is set again. Which brings me to the "Hi mom" example above: I actually wanted the widget to behave that way. Now, seeing what you made of it, I see the need to really broaden the API to the text widget to have APPEND and SET functions for the model.
I was not sure the API entry point CLEAR was needed elsewhere. I can see that it would be, though. Really, the more I look at the text widget the more I think it needs imperative processing by application code that has a clear idea of what it wants to do with all the capabilities of the widget.
hehe, exactly. As I said above...
I also brought both commands within the same integrity bundle by skipping the tk-format syntactic sugar and open-coding with- integrity. That just saves one enqueue, no big deal. A bigger deal is that the sort done by tk-user-queue-handler was not (until just now <g>) a stable sort, so the delete could have been executed after the insert. Bringing both operations into the single integrity bundle also fixes that.
Oookkaaayy....
$ echo "Heya this is a test" > /Users/frgo/tmp/frgo-test
the text gets displayed in the window.
Isn't great when we get stuff like that working? Is there a universal law: any time the effect produced by your own code surprises you, you are probably onto something good. Programming never gets old.
Right. Which is why we sit here after finishing our 2 hours of ballroom dancing on Sunday evening writing Cells code and emails like crazy. My wife is in bed already so I can pretend there's noone feeling bad about me sitting in the home office room here... <g>
Fileevent to be put to Celtk CVS in a few days ... watch out.
Thx. I am switching all my code to LLGPL now, btw. I think we settled on that for your stuff, yes?
Well, yeah, LLPPL or MIT is just fine.
kt
Frank
participants (2)
-
Frank Goenninger -
Ken Tilton