Tk_Window and TkWindow
in [TCL]
|
Prev: No serial ports when cross compiling to Linux on ARM
Next: Can't compile small extension due to linking problem
From: Georgios Petasis on 5 Nov 2009 15:55 O/H Don Porter έγραψε: > George Petasis wrote: >> O/H Donal K. Fellows έγραψε: >>> On 5 Nov, 03:27, Kevin Walzer <k...(a)codebykevin.com> wrote: >>>> As a result, I don't understand how to use [TkWindow] in my extension >>>> code, or even if I should use it. >>> >>> It's not described because is in fact part of the implementation, not >>> the interface. Don't use it if you're not writing Tk itself. >>> >>> Donal. >> >> There are cases where you cannot avoid using it. For sure I have used >> it at least in one of my extensions... >> (I don't remeber in which one though :-) ) > > Where can we find your Feature Request laying out the inadequacies > of the Tk public interface? > Dear Don, I always find this question ironic. Please stop asking the same thing over and over, at least to me. I think that I have every right to point areas where tcl/tk is lacking, without being compelled to care how & when will be fixed, and bother to submit SF feature requests. Why do you assume that anybody who finds a shortcoming must take action to correct it? I am a user of tcl/tk, and I have to live with what is there. I rarely have any interest in getting involved in a time consuming processing, with unpredictable results. If you see me as a plain user of tcl/tk (what I am actually :-) ), can you justify why do I have to use SF (which I find too chaotic to use) or read a tutorial on how to submit a TIP? When I need something, I need it now, and not in 2-3-4 years from now. So, if I implement the workaround now, I don't care if it is going to be fixed in the next stable tcl version. Really. For example, in April 2006 I was the first to understand that you cannot get the interpreter from a tk widget (of course I was not, everybody who had written a C widget would have notice this). As usual, I implemented a workaround and complained about this in the group. This is where I should have stopped. I have found a workaround to my problem, that worked will all contemporary tcl versions. Of course, out of plain stupidity, I read the tip guidelines and submitted a tip (tip #264). And so what? From April 2006, the implementation reached tcl in December 2007. Can I use it even today? NO. Because the code has to compile also with 8.4. Let alone the fact that I was developing it in March 2006 - perhaps I am not in the mood to make changes two and three years after the period I had time to spend on an extension. (No the extension still uses the hack). In my view a discussion in c.l.t should trigger preemptive actions towards the advance of tcl. If this does not happen, then I am sorry. If you expect that each user you identifies a lack must submit a tracker, you can expect it. I have written enough C extensions to know that when I have a problem I am alone: I am the first to get there, and nobody has been there before. Usually, in such a case I write a post in c.l.t not to find a solution (as probably I would have found a workaround before the first reply arrives) but just to have a hope that I may get some help. And in all cases, all the issues arise from the fact that I try to confine my self in using the public API, due to an unjustified obsession to make the extension public (why?). And irony will never motivate me to do more. Lets see the last relevant issue: I had some time and tried to build a gtk theme for tile. In the process of making it public, I thought it would be a good idea to not link with gtk, so as the binary to not be GPL. So, I implemented a stubs system for the extension, and raised the issue of exposing the functionality of loading symbols from a shared library, which is already in tcl. In the mean time, I used glib for that (making the binary again GPL). Do I care that nothing happen because I didn't submit a TIP? NO. Will ironic comments make me submit a TIP? Again NO. Perhaps will have the opposite effect, and give up the effort to make it public... So, if you think that feature requests are so important, and you want, feel free to submit them. But don't expect me to do it. I wont. Regards, George
From: Pat Thoyts on 5 Nov 2009 18:20 George Petasis <petasis(a)iit.demokritos.gr> writes: >O/H Donal K. Fellows έγ�α�ε: >> On 5 Nov, 03:27, Kevin Walzer <k...(a)codebykevin.com> wrote: >>> As a result, I don't understand how to use [TkWindow] in my extension >>> code, or even if I should use it. >> It's not described because is in fact part of the implementation, not >> the interface. Don't use it if you're not writing Tk itself. >> Donal. > >There are cases where you cannot avoid using it. For sure I have used >it at least in one of my extensions... >(I don't remeber in which one though :-) ) I think it was you and I who requested Tk_Interp for pulling the interp out of the TkWindow structure. And a quick check shows it was tip 264, with you as the author. Thats probably the one you;'re thinking about. -- Pat Thoyts http://www.patthoyts.tk/ To reply, rot13 the return address or read the X-Address header. PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
From: Georgios Petasis on 5 Nov 2009 18:23 O/H Pat Thoyts έγραψε: > George Petasis <petasis(a)iit.demokritos.gr> writes: > >> O/H Donal K. Fellows έγ�α�ε: >>> On 5 Nov, 03:27, Kevin Walzer <k...(a)codebykevin.com> wrote: >>>> As a result, I don't understand how to use [TkWindow] in my extension >>>> code, or even if I should use it. >>> It's not described because is in fact part of the implementation, not >>> the interface. Don't use it if you're not writing Tk itself. >>> Donal. >> There are cases where you cannot avoid using it. For sure I have used >> it at least in one of my extensions... >> (I don't remeber in which one though :-) ) > > I think it was you and I who requested Tk_Interp for pulling > the interp out of the TkWindow structure. > > And a quick check shows it was tip 264, with you as the author. Thats > probably the one you;'re thinking about. > Perhaps, but since my memory is weak, I am not sure it is the only one :-) George
From: Joe English on 8 Nov 2009 13:57
Kevin Walzer asked: > I'm confused about something I frequently see in source files that make > use of Tk's C API: Tk_Window and TkWindow. Here's an example that > returns the interpreter associated with a Tk window: > > Tcl_Interp * ip(Tk_Window tkwin) { > if (tkwin != NULL && ((TkWindow *)tkwin)->mainPtr != NULL) { > return ((TkWindow *)tkwin)->mainPtr->interp; > } > return NULL; > } > > I understand that Tk_Window refers to a Tk window; it's a publicly > exported function defined in the man pages. > > But what's a "TkWindow"? It appears to be some sort of struct, and I see > a reference to it in tkInt.h, but I see no discussion of it in the man > pages. As a result, I don't understand how to use it in my extension > code, or even if I should use it. TkWindow == struct TkWindow is the "real" data type, used internally. Tk_Window == struct Tk_Window_ * is a opaque "wrapper" type used in the public API. struct Tk_Window_ is actually not defined anywhere. (In C terms, it's a "pointer to incomplete type"). Extension code should generally only use 'Tk_Window's. Whenever you have a Tk_Window, it *really* points to a 'struct TkWindow', but the details of that type aren't publically visible. Tcl and Tk use this idiom a lot for opaque data types. The idea is to hide the internal details of the data structure from client code; that way it's possible to change the internal structure without having to worry about breaking binary/stubs compatibility with existing extensions. (That's the idea, anyway -- in practice, for Tk_Window/TkWindow, that hasn't worked out because of the Tk_FakeWin* hack. You probably don't want to understand the Tk_FakeWin* hack.) (I'd also add that Tcl's idiom for opaque types should not be used in any new code. The standard way of doing this is to say something like: typedef struct Foo_ *Foo; in the public interface, and only provide the definition of 'struct Foo_' in the internal interface. The way Tcl does things, with a "real" type and an incomplete "fake, public" type, the implementation has to add a lot of casts everywhere, which is tedious noisy and error-prone.) --Joe English |