import tkd.tkdapplication; // Import Tkd.
import std.conv;
class MyTkdApplication : TkdApplication{ // Extend TkdApplication.
Frame frame;
Entry entry;
Button button;
Label label;
Button exitButton;
private void exitCommand(CommandArgs args){ // Create a callback.
this.exit(); // Exit the application.
}
private void buttonPressed(CommandArgs args){ // Create a callback.
string fs=entry.getValue();
float f=to!float(fs);
float c=(f-32.0)*5.0/9.0;
string cs=to!string(c);
label.setText(cs);
}
override protected void initInterface(){ // Initialise user interface.
frame = new Frame(2, ReliefStyle.groove) // Create a frame.
.pack(10); // Place the frame.
entry = new Entry(frame) // Create a entry.
.pack(10); // Place the entry.
button = new Button(frame, "Convert ") // Create a button.
.setCommand(&this.buttonPressed) // Use the callback.
.pack(10); // Place the button.
label = new Label(frame, "____________") // Create a label.
.pack(10); // Place the label.
exitButton = new Button(frame, "Exit") // Create a button.
.setCommand(&this.exitCommand) // Use the callback.
.pack(10); // Place the button.
}
}
void main(string[] args){
auto app = new MyTkdApplication(); // Create the application.
app.run(); // Run the application.
}
#!/usr/local/bin/wish8.6
proc myresult {} {
.f.r configure -text [ expr ([ .f.v get ] - 32.0) * 5.0 / 9.0 ]
}
frame .f -relief groove -borderwidth 2 -pady 10 -padx 10
entry .f.v
button .f.c -text "Convert" -command myresult
label .f.r -text "____________"
button .f.q -text "Exit" -command exit
pack .f.v .f.c .f.r .f.q -pady 10 -padx 10
pack .f -pady 10 -padx 10
Tk, an extension of tcl, was mentioned many times in conjunction with other scripting languages,The same in Tcl/Tk would look like this (done in 5 Minutes):
I love Tcl (and Tk) for its simple, but powerfull and complete command syntax - just a few commands can do anything. It's rock solid since ever, platform independent since ever (even when it comes to file paths, accessing fonts etc.), and: still alive (!).Tk, an extension of tcl, was mentioned many times in conjunction with other scripting languages,
but you were the first mentioning tcl. Why?
Tcl combines best with sqlite3, for example for using the db as file format for your own application.my alterantive to a spreadsheets
I do not think you must bind to all that. Tcl/tk C-API allow your C program to run tcl/tk scripts.I would end up spending too long having to write bindings against all the other native middleware I use.
If you go that way round instead, those tcl/tk scripts will need to then call back into the C / C++ code (i.e on a button click). So you will end up indirectly having to make tcl bindings for your own software.I do not think you must bind to all that. Tcl/tk C-API allow your C program to run tcl/tk scripts.
But I think it is no catastrophe.So you will end up indirectly having to make tcl bindings for your own software.
This is the tricky bit. Consider if you have to exchange an OpenSSL BIO or some composite type (like a struct). You can't pass those between language boundaries. If you try, you will need to describe the layout in both languages.some variables are exchanged between
But the idea is to use tcl/tk only for bulding the GUI, for configuration scripts, mainly for interaction with the user.Consider if you have to exchange an OpenSSL BIO
Oh right. I tend to write GUI programs that need to do a little more than that. If it is just for simple configuration, then perhaps Zenity or CDialog is good enough.But the idea is to use tcl/tk only for bulding the GUI, for configuration scripts, mainly for interaction with the user.
More than GUI is written in C with complex structures, the GUI in tcl/tk.I tend to write GUI programs that need to do a little more than that.
Not necessarily Xlib but the main functionality of the program is often written entirely in C or C++.Or does "GUI programs" mean that the main functionality of the program is written in Xlib?!
And you can bind tcl/tk in your own applications: hence, main functionality in C.The main bindings of Tk that are in common use are Perl (Perl/Tk) and Python (Tkinter).
Tcl is implemented in a C library that is easy to integrate into an existing application. By adding the Tcl interpreter to your application, you can configure and control it with Tcl scripts, and with Tk you can provide a nice graphical interface to it. This was the original model for Tcl. Applications would be largely application-specific C code and include a small amount of Tcl for configuration and the graphical interface. However, the basic Tcl shells proved so useful by themselves that relatively few Tcl programmers need to worry about programming in C or C++.
I really love that book. It enabled me in starting with Tcl very quick. At that time I have had to do a lot realted to automatic tests using signal generators, spectrum anaylsers and that kind of stuff. Tcl8.4 has been up to date and with the installation of the company ActiveState it was easy to start with, even on Windows.And you can bind tcl/tk in your own applications: hence, main functionality in C.
As said, this was the now almost forgotten original idea of tcl that is perhaps alive in lua. I quote a well know
tcl textbook:
The approach in the middle is to program critical things in C, extend tcl with that, and continue
programming in tcl.
Heh yes but don't forget Perl and Python bindings have had teams spending decades on developing these bindings. It is too much for smaller projects.And you can bind tcl/tk in your own applications: hence, main functionality in C.
But they were not only making a widget for their programs, you have complete control of Tk in perl and python.Perl and Python bindings have had teams spending decades on developing these bindings. It is too much for smaller projects.
This is very much something I would like with C or C++. These bindings demonstrate that the market is there or they would not have gone through the effort of binding. Instead these communities could have just recommend using tcl from within Perl or Python directly.you have complete control of Tk in perl and python.
So many other binding layers (i.e Java's JNI or Lua) present you with a void * which you need to do an unsafe cast to the correct type. This is certainly something I want to avoid. In large programs it is very difficult to keep track of with some pretty nasty results in terms of debugging time.In C there is no much type safety to loss with a C library.
And then people would have begun using tcl instead of perl or python. It is really a joke thatInstead these communities could have just recommend using tcl from within Perl or Python directly.
Then you do not need a GUI, but a new widget toolkit?!This is very much something I would like with C or C++.
So many other binding layers (i.e Java's JNI or Lua)
BTW, if you insist on dealing with complex structures, see clientData here:. Consider if you have to exchange an OpenSSL BIO or some composite type (like a struct). You can't pass those between language boundaries. If you try, you will need to describe the layout in both languages.
Whilst it does look to have nicer FFI facilities than a lot of scripting layers, can you see here the unsafe cast (4th parameter)? https://github.com/flightaware/tclx/blob/master/doc/ObjCmdWrite.3#L396
can you see here the unsafe cast (4th parameter)?
As far as I know, ClientData type is void*. And the pointer is passed to the function callback when theThe last parameter is also particularly awkward; that is the delete / finalizer function pointer.