How to get at -data field of virtual event from C?
Ken Tilton
doing it from Tcl to C, since I am using the C interface to Tcl/Tk.
My current ploy is to give a widget the command:
event generate <<callback>> -data <string of desired callback args>
I have registered an eventhandler (Tk_CreateEventHandler) and am happily
receiving events, now I just gotta find that pointer to the data string.
The source code shows a little structure for virtual events but not
much. I am sifting through the source now looking for the implementation
of "event generate", but any ideas are welcome.
thx, kenny
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ken Tilton
Ken Tilton wrote:
> I need to fake callbacks from Tcl/Tk to Common Lisp. We can pretend I am
> doing it from Tcl to C, since I am using the C interface to Tcl/Tk.
>
> My current ploy is to give a widget the command:
>
> event generate <<callback>> -data <string of desired callback args>
>
> I have registered an eventhandler (Tk_CreateEventHandler) and am happily
> receiving events, now I just gotta find that pointer to the data string.
Oh, shucks, never mind. It looks as if the doc is wrong. I checked the
source and -data is not supported (exactly the eror I get, too, if I
execute "event generate <<myevent>> -data {Hi mom}"
Still wondering where are those other fields I can send, though. And
still reading the source...
btw, Does nobody here utilize Tcl/Tk from a C or other HLL app via the C
interface? Should I be asking these questions of the Tcl/Tk developers
themselves? Should I buy an ActiveState development seat?
Michael Schlenker
>
>
> Ken Tilton wrote:
>> I need to fake callbacks from Tcl/Tk to Common Lisp. We can pretend I
>> am doing it from Tcl to C, since I am using the C interface to Tcl/Tk.
>>
>> My current ploy is to give a widget the command:
>>
>> event generate <<callback>> -data <string of desired callback args>
>>
>> I have registered an eventhandler (Tk_CreateEventHandler) and am
>> happily receiving events, now I just gotta find that pointer to the
>> data string.
>
> Oh, shucks, never mind. It looks as if the doc is wrong. I checked the
> source and -data is not supported (exactly the eror I get, too, if I
> execute "event generate <<myevent>> -data {Hi mom}"
>
> Still wondering where are those other fields I can send, though. And
> still reading the source...
You may use Tcl 8.5 documentation with an older Tcl version. The -data
option is new in Tcl 8.5 (see http://www.tcl.tk/cgi-bin/tct/tip/165.html ).
Michael
Ken Tilton
Michael Schlenker wrote:
> You may use Tcl 8.5 documentation with an older Tcl version. The -data
> option is new in Tcl 8.5 (see http://www.tcl.tk/cgi-bin/tct/tip/165.html ).
Brilliant, thx. I dropped back to 8.4.12 when following religiously the
build instructions for Togl 1.7, never thought to then try 8.5.
Gracias, kenny
ps. Still no C API to get at the virtual event fields? Gotta study the
source to see how the options are encoded? kt
Cameron Laird
.
.
.
>btw, Does nobody here utilize Tcl/Tk from a C or other HLL app via the C
>interface? Should I be asking these questions of the Tcl/Tk developers
>themselves? Should I buy an ActiveState development seat?
.
.
MANY people embed Tcl/Tk in a larger application through
the C interface. Are you asking this because you regard
the documentation as so flawed that it couldn't be in use
by an active developer community (I could show you other
open-source projects that certainly put *that* proposition
to the test)? I suspect you might be using 8.5 documenta-
tion with an 8.4 library, as Michael hinted in a follow-up.
In fact, the documentation is quite good--extraordinarily
so, in fact--and I think you'll feel a lot more satisfaction
after unraveling a confusion or two.
I don't know what you mean by "the Tcl/Tk developers them-
selves" as a contrast to comp.lang.tcl.
I think ActiveTcl Pro Studio's quite a good value, but I
don't see how it bears on your other questions. On the
other hand, I know Jeff has thought quite a bit about how
"foreign" languages can best make use of Tk, so anything
you can do to get a slice of his time should pay off.
Ken Tilton
Cameron Laird wrote:
> In article <Pt89g.51$vH7...@fe09.lga>, Ken Tilton <kent...@gmail.com> wrote:
> .
> .
> .
>
>>btw, Does nobody here utilize Tcl/Tk from a C or other HLL app via the C
>>interface? Should I be asking these questions of the Tcl/Tk developers
>>themselves? Should I buy an ActiveState development seat?
>
> .
> .
> .
> MANY people embed Tcl/Tk in a larger application through
> the C interface. Are you asking this because you regard
> the documentation as so flawed that it couldn't be in use
> by an active developer community (I could show you other
> open-source projects that certainly put *that* proposition
> to the test)?
Wow, calm down, dude. I asked a simple question about one possible flaw
in quite a huge amount of documentation. From that you get "so flawed it
couldn't be in use"? Get a grip. :)
I suspect you might be using 8.5 documenta-
> tion with an 8.4 library, as Michael hinted in a follow-up.
> In fact, the documentation is quite good--extraordinarily
> so, in fact--and I think you'll feel a lot more satisfaction
> after unraveling a confusion or two.
Where do you see me saying I am not satisfied with the doc? I would
appreciate it if you did not put words in any mouth other than your own.
As for satisfaction, well, I happen to be putting the finishing touches
on a perfect marriage of Common Lisp, Tcl/Tk, and my <cough> brilliant
Cells constraints package, OpenGL included thx to the splendid Togl widget.
If you want satisfaction, try /that/ package. LGPL in CVS tied to
project under my sig.
>
> I don't know what you mean by "the Tcl/Tk developers them-
> selves" as a contrast to comp.lang.tcl.
Response on technical questions comes slowly here if at all. Perhaps I
am just spoiled by comp.lang.lisp.
>
> I think ActiveTcl Pro Studio's quite a good value, but I
> don't see how it bears on your other questions.
because maybe paid support responds faster? <sigh> You are much too
disputatious. remind me of some Lispniks. :)
peace, kenny
Donald Arseneau
> > I don't know what you mean by "the Tcl/Tk developers them-
> > selves" as a contrast to comp.lang.tcl.
>
> Response on technical questions comes slowly here if at all. Perhaps I am
> just spoiled by comp.lang.lisp.
Several frequent responders here are members of the Tcl Core Team,
http://www.tcl.tk/community/coreteam/
which I suppose is what you mean by the Tcl/Tk developers.
--
Donald Arseneau as...@triumf.ca
Ken Tilton
Not frequent enough! :)
That question hung out there for seven hours without anyone saying,
"Hunh? You say you have the XVirtualEvent pointer and you want to know
where the data is? You might look at X.h, you simpleton. (Don't forget
to call Tcl_GetString on the data pointer once you find it.)"
I really am spoiled by c.l.lisp. I do not get stuck often after ten
years, but when I do I just blast off a question and fifteen minutes
later the answers start pouring in. From the three other people on Earth
using Lisp.
But seriously, folks, i could not be happier. Common Lisp needs a GUI
and now not only does it have one (Tk), but it has OpenGL and an entire
portable scripting language to boot. A lack of libraries is a big knock
on Lisp compared to Java and Python, and now I have tunneled through to
all the Tcl/Tk libraries.
Life is good. :)
Neil Madden
[...]
> I really am spoiled by c.l.lisp. I do not get stuck often after ten
> years, but when I do I just blast off a question and fifteen minutes
> later the answers start pouring in. From the three other people on Earth
> using Lisp.
That is truly remarkable. If you really want that level of service, then
I would definitely look into buying support from ActiveState.
>
> But seriously, folks, i could not be happier. Common Lisp needs a GUI
> and now not only does it have one (Tk), but it has OpenGL and an entire
> portable scripting language to boot. A lack of libraries is a big knock
> on Lisp compared to Java and Python, and now I have tunneled through to
> all the Tcl/Tk libraries.
Hmm... I'd be very surprised if Common Lisp didn't already have a Tk
binding. Googling brings up http://www.cliki.net/Lisp-Tk but it doesn't
look all that promising. A bit of further digging brings up
http://www.peter-herth.de/ltk/ which looks current (docs dated January
this year).
Tcl/Tk and Lisp must be a very satisfying environment. I must try it
sometime.
-- Neil
suchenwi
> interface?
I consider Tcl a much HigherLL than C :) - but the merit of C is that
it makes Tcl run fast.
Donal K. Fellows
> Not frequent enough! :)
Hardly my fault you insist on asking when I'm at (and flying home from)
a conference. :-)
> That question hung out there for seven hours without anyone saying,
> "Hunh? You say you have the XVirtualEvent pointer and you want to know
> where the data is? You might look at X.h, you simpleton. (Don't forget
> to call Tcl_GetString on the data pointer once you find it.)"
That's correct for picking the value up (I used a Tcl_Obj* for that
field because it makes the data management easier and the values never
cross threads anyway). For generating them, you have to put the Tcl_Obj
pointer in the right field and increment its reference count; the
reference count will be decremented when the event has been fully
processed. For backward compatability, if the field is NULL it is not
managed (and the [bind] command's guts substitute an empty string in
that case). The one thing remaining really is for someone to go through
the Tk source and decide what existing virtual events ought to have
non-NULL data fields, but that's a separate issue...
(Reading off event values from the C level? Hmm, not something I do
very often these days; I prefer bindings to be in Tcl since that makes
everything more flexible. YMMV.)
Donal.
Ken Tilton
Neil Madden wrote:
> Ken Tilton wrote:
> [...]
>
>> I really am spoiled by c.l.lisp. I do not get stuck often after ten
>> years, but when I do I just blast off a question and fifteen minutes
>> later the answers start pouring in. From the three other people on
>> Earth using Lisp.
>
>
> That is truly remarkable.
You should see the stampede when a noob asks an easy one. :)
> If you really want that level of service, then
> I would definitely look into buying support from ActiveState.
I think a "seat" is definitely in the cards. Quite reasonable for any
serious enterprise.
>
>>
>> But seriously, folks, i could not be happier. Common Lisp needs a GUI
>> and now not only does it have one (Tk), but it has OpenGL and an
>> entire portable scripting language to boot. A lack of libraries is a
>> big knock on Lisp compared to Java and Python, and now I have tunneled
>> through to all the Tcl/Tk libraries.
>
>
> Hmm... I'd be very surprised if Common Lisp didn't already have a Tk
> binding. Googling brings up http://www.cliki.net/Lisp-Tk but it doesn't
> look all that promising. A bit of further digging brings up
> http://www.peter-herth.de/ltk/ which looks current (docs dated January
> this year).
Actually, I am standing on the shoulders of LTk, to which I owe a great
debt. I first added my indispensible Cells package (think "active state"
<g>) giving me a new widget class hierarchy on the Lisp side, then when
I wanted to use Togl and talk to OpenGL efficiently I needed the OpenGL
context in the same process so I had to stop using the LTk stdin/stdout
interface and embed an interpreter also via the C API.
>
> Tcl/Tk and Lisp must be a very satisfying environment. I must try it
> sometime.
I am just finishng up the last fixes after the most recent upheaval (to
do true callbacks via "event generate" instead of polling a global
tk-event variable I used to kludge callbacks), should be done today or
tomorrow. The link in my sig points to a repository from which you need
Cells, Celtk, and Gears to see an OpenGL demo. You will also need ASDF,
CFFI, and (for the Gears demo) cl-opengl.
Hmm, maybe I should put all that in a read-me. :) will do.
Ken Tilton
suchenwi wrote:
>>btw, Does nobody here utilize Tcl/Tk from a C or other HLL app via the C
>>interface?
>
>
> I consider Tcl a much HigherLL than C :)
Yeah, i was looking for a word, found the wrong one. 3GL? Actually, i
should have just said "via the C API".
kt
Ken Tilton
Donal K. Fellows wrote:
> Ken Tilton wrote:
>
>>Not frequent enough! :)
>
>
> Hardly my fault you insist on asking when I'm at (and flying home from)
> a conference. :-)
And you did not arrange for someone to cover for you?! :)
> (Reading off event values from the C level? Hmm, not something I do
> very often these days; I prefer bindings to be in Tcl since that makes
> everything more flexible. YMMV.)
Absolutely, but something strange is going on. My Cells package (see
sig) is a general solution to what I guess motivated the name
"ActiveState". My motivation was the same as Mr. Oakley's in developing
Actions:
http://www.tcl.tk/community/tcl2004/Papers/BryanOakley/oakley.pdf
So I have a curious blend of automatic state management, some being done
by Tk, some by Cells. basically, whatever Tk does well, I let it do.
Then I augment, as did Mr. Oakley:
"Two large problems exist for developers of such user interfaces. One is
the need to constantly synchronize the controls with the ever-changing
state of the application or data. When no text is selected, for example,
the cut and copy buttons should be disabled.
"Another problem is that as programs evolve over time it can become
tedious and error prone to update the parts of the code that act upon
these controls..."
Aside: I discovered early on that not just a GUI benefits from automatic
state management. Anyway, to augment Tcl/Tk I really need my Lisp code
to see all the action. So as powerful as Tcl/Tk is with things like the
textVariable config option and "trace add variable write", i do better
by also tapping the event stream.
So why use Tcl/Tk at all? I have a retail commercial app to deliver and
I need both Mac and win32, Linux a bonus. I am using Tcl/Tk for its
portability, which I am delighted to discover extends beyond GUI matters
to general OS mechanisms such as file directories and sockets. We in the
Lisp community spend a lot of time moaning about not having those things
standardized across Lisp implementations and/or OSes.
Not me, anymore. :)