TCL 8.5 Headers translated for FreeBASIC

[sir_mud]

Download: https://www.dropbox.com/s/pj3kg9gg3263a ... eebasic.7z
I also have these in my fbc github here: https://github.com/mudhairless/fbc/tree/tcl8.5-headers

I have tested using the example provided under Debian wheezy, i'm going to look at the windows distribution to see what's different there with Tk because a lot of it on Linux is dependant on X11 headers so I've commented those out for now. I'm posting this here first so we can try and improve these headers because I know there will be problems. ATM everything works on .24 and git HEAD under Linux, I'll test later under Windows 7. Once I feel these are "good enough"(tm) i'll put a pull request in.

[AGS]

Download: https://www.dropbox.com/s/pj3kg9gg3263a ... eebasic.7z
I also have these in my fbc github here: https://github.com/mudhairless/fbc/tree/tcl8.5-headers

I have tested using the example provided under Debian wheezy, i'm going to look at the windows distribution to see what's different there with Tk because a lot of it on Linux is dependant on X11 headers so I've commented those out for now. I'm posting this here first so we can try and improve these headers because I know there will be problems. ATM everything works on .24 and git HEAD under Linux, I'll test later under Windows 7. Once I feel these are "good enough"(tm) i'll put a pull request in.

I think the tk situation is not that bad.

The tk interface is the same for all platforms involved.
There are only a handful of functions that are platform - specific.
For win32 those are

Code: Select all

declare function Tk_AttachHWND(_
                               byval tkwin as Tk_Window,_
                               byval hwnd as HWND) as Window

declare function Tk_GetHINSTANCE() as HINSTANCE
declare function Tk_GetHWND(byval window as Window) as HWND
declare function Tk_HWNDToWindow(byval hwnd as HWND) as Tk_Window
declare sub Tk_PointerEvent(_
                            byval hwnd as HWND,_
                            byval x as integer,_
                            byval y as integer)
declare function Tk_TranslateWinEvent(_
                                      byval hwnd as HWND,_
                                      byval message as UINT,_
                                      byval wParam as WPARAM,_
                                      byval lParam as LPARAM,_
                                      byval result as LRESULT ptr) as integer

Some of the above functions have a problem: the use of the word window.
Window is a reserved word in fb so something has to be done to correct
that.

Apart from the six functions above the tk interface is the same regardless
of the platform used. All the functions from your tkdecls.bi can be used
on winlin.

Quite a few functions seem to be missing from tkdecls.bi

I'd expect the tk interface to include all the functions found here:
http://www.tcl.tk/man/tcl8.5/TkLib/contents.htm

And the tcl interface to include all the functions found here:
http://www.tcl.tk/man/tcl8.5/TclLib/contents.htm

What's nice about tcl/tk is that it has a place layout (referred
to as 'rubber sheet' in the tcl/tk documentation) algorithm that
allows to set the position and size of a child widget based on the size of
the parent.

http://www.tcl.tk/man/tcl8.5/TkCmd/place.htm#M13

When the parent changes size the size and place of
a child changes accordingly.

Example.

Code: Select all

Parent size: 600x600
Widget position and size in percentages of parent size:
x: 10%
y: 10%
width: 10%
height: 10%

Widget position and size in pixels:
x: 60
y: 60
width: 60
height: 60

After a resize of the parent to 900x900 the widget will
be at 90,90 and have size 90x90. Which is usually what
you want.

Looking at your example I think mixing fb with a tk script is a good idea.
The awkward tk api is not user friendly (at least not friendly
enough to create an entire gui using nothing but the api).

Creating the gui using a textual tk script and leaving the
handling of events to fb code seems like a good idea.

You could use the approach taken in your example and
add handlers using Tk_CreateEventHandler before the
main loop. Every time an event occurs it would get posted
to fb handlers.

Or new tcl commands can be created using Tcl_CreateCommand.
Bindings can then be added to the binding table.

Every binding needs a tcl script that is to be invoked when the binding
is activated. That script could consist of a single command implemented by
fb code. Etc... etc... (glueing a tk gui to fb code can be done in numerous
ways I guess).

As an aside (and perhaps a warning):
I don't think it is possible to copy the tk and tcl dynamic link libraries
(tcl85.so and tk85.so) to a computer and create working tcl/tk programs using
nothing but those two dynamic link (-and associated import-) libraries.
It is fairly likely that you need a full tcl/tk installation to get examples to work.

A full tcl/tk installation contains more than tcl85.so and tk85.so.

And some of what gets copied to a computer when doing a full tcl/tk
install is needed to create working tcl/tk programs.

Perhaps I'm wrong about the need for a full tcl/tk installation but I highly
doubt it.

[D.J.Peters]

Years ago there wasn't any GUI lib for FreeBASIC I tried to use TK the GUI toolkit with FreeBASIC but without success.
TK works only together with TCL the Tool Command Language.
Of course you can use TCL interpreter with FreeBASIC and TCL than will use TK,
but that was not what I wanted.

Joshy

[AGS]

I checked my claim that in order to use tcl/tk you have to install
tcl/tk and what I found was this.

Tcl_Init uses a tcl script. That script is called init.tcl. That
script is not part of tcl85.dll or tk85.dll. You get the script
when you install tcl/tk. A program that utilizes tcl/tk may or
may not need to call Tcl_Init but to prevent nasty things
from happening calling Tcl_Init is (almost) mandatory.

On Linux tcl/tk is part of most package repositories.
On Windows you can get tcl/tk from ActiveState
http://www.activestate.com/activetcl/downloads

@D.J.Peters
The fact that you have to install tcl/tk in order to use
tcl tk (and the need to combine your code with tcl/tk code)
will make most fb programmers shy away from using tk.

Having to install a programming language in order
to create a gui might be a bit too much for fb programmers.

In terms of size tcl/tk might wel be smaller than a full gtk+
installation so size should not be an issue. Maybe I am wrong
here and fb programmers don't care about installing another
programming language in order to use it's gui component.

You could write the gui using a file. And then load
that file using Tcl_EvalFile. And add a button to the
gui called 'reload' ( or similar).
And then create a program that
-calls Tcl_EvalFile()
-creates commands for the fb callbacks
(or create one command that handles all
callbacks without performing any useful task)
-binds tk events to fb commands
-calls Tk_MainLoop()

Using the above setup the user gets to see the gui,
try it out a bit and if it's not okay the user can edit the tk script.

After editing the tk script the user saves the script and
presses the reload button.
Tk_MainLoop() exits, the program 'jumps' to the line with the call to
Tcl_EvalFile and the 'new' (edited) gui is loaded.
At which point everything starts all over again. But this time with
the new and improved gui.

This gives you a nice way to create a gui incrementally. After
every change to the gui you get to see what the gui looks like
without having to recompile your program.

Aside:
I must say, J.D., that you have done a marvellous job on creating
fltk bindings/wrappers. I can hardly read C++ code and creating a wrapper
for a library written in C++ is well beyond my abilities as a programmer.

It's a good thing that there are fb programmers like you and sir_mud
that know a thing or two about programming in languages other than
FreeBASIC.

[TJF]

...

This gives you a nice way to create a gui incrementally. After
every change to the gui you get to see what the gui looks like
without having to recompile your program.

In a similar way I work with GTK+. The GUI gets styled in Glade3, the 'look' can get checked out there. When I need real testing (Ie when testing lists or trees with context), the application (skeleton generated by GladeToBac3) loads the GUI description (*.ui file) and displays its context. In big projects I use a reload button to regenerate a certain window while the application is running (or modules which load their part of the GUI independant from the main application).

I still cannot see any point in using a further component (interpreter language). All additional features the tcl/tk language has over FB are also included in GLib. And much more. And this code is faster since it's compiled binary.