webkit and Tk: how has this not been made?

[m***@gmail.com]

I realize we've got things like tkhtml and hv3 as well as gnocl::webkit, but how is there not a tightly integrated, works with core Tk, cross platform widget using webkit (or other HTML5, standards compliant engine)?

I can do some hackery like embed a chromium app-window into a tk frame, but that's not cross platform and I would like to be able to have tightly integrated script access (in the same sense as the canvas widget or the text widget) as well as have this work/easily compile against different graphical backends like sdlwish--that way I can drive and develop complex graphical interfaces straight from the framebuffer.

I know the usual chime in the OSS world is if you want it and it's missing, do it yourself. But I really do not have the C chops to implement this. Is there anything like a modern, well-supported html5 widget for standard Tk? Doesn't *have* to be webkit, but I assume that's the easiest to work with.

[m***@gmail.com]

Well, I did my due diligence after the fact--searching c.l.t for webkit shows relevant discussions from 9 years ago and nothing really to show for it. Anybody harboring any super-secret, super-awesome projects?

[r***@googlemail.com]

I also really miss the integration of Webkit into Tk. Do you know any document which describes the interface which has to be fulfilled for an integration (into any toolkit)? If such a document exists, and if the effort is not infinitely, then I would try to work on the integration - as a contributor to the Tk development I'm very familiar with the Tk stuff.

[m***@gmail.com]

I don't see any detailed documentation on the official site, but there are multiple widgets for various toolkits including gtk, qt, efl, and wx. Some appear to be officially supported and in the source code, others are separate projects. https://webkit.org/getting-started/

Let me know if that helps. I'll do what I can to help me out if you're serious about this--further research and possibly some financial help. I have several projects that would really benefit from a Tk webkit widget.

Post by r***@googlemail.com
I also really miss the integration of Webkit into Tk. Do you know any document which describes the interface which has to be fulfilled for an integration (into any toolkit)? If such a document exists, and if the effort is not infinitely, then I would try to work on the integration - as a contributor to the Tk development I'm very familiar with the Tk stuff.

[EL]

Post by m***@gmail.com
but how is there not a tightly integrated, works with core Tk, cross platform widget using webkit

Because nobody stepped forward so far and wrote the code :).
It certainly seems to be an interesting project, though!

Post by m***@gmail.com
But I really do not have the C chops to implement this.

You could hire somebody to do it, or sponsor somebody who wants to
create such a Tk widget anyway. That way you could also influence the
capabilities and features of the yet-tbd "Tkwebkit".

I'd be able and willing to write the code, but I am afraid, I don't have
the time...

[m***@gmail.com]

Post by EL
You could hire somebody to do it, or sponsor somebody who wants to
create such a Tk widget anyway. That way you could also influence the
capabilities and features of the yet-tbd "Tkwebkit".

You know, I've been wanting this and missing this long enough that I would be willing to pay for it. Any suggestions for a decent bounty amount? I'm not exactly made of money... suppose I could try crowd funding and start with putting up what I can.

[EL]

Post by m***@gmail.com

Post by EL
You could hire somebody to do it, or sponsor somebody who wants to
create such a Tk widget anyway. That way you could also influence the
capabilities and features of the yet-tbd "Tkwebkit".

You know, I've been wanting this and missing this long enough that I would be willing to pay for it. Any suggestions for a decent bounty amount? I'm not exactly made of money... suppose I could try crowd funding and start with putting up what I can.

Crowd funding may be a good idea.

As for the bounty price: Hm, I'd say, somebody who is decently involved
in Tk widgets development *and* webkit at the same time is hard to find.
Most people have to work themselves in to one or the other, if not
both... and I guess webkit is the harder part (meanwhile I had a look at
their sources and API, it is at least quite overwhelming at a first glance).
All in all I think it could take an experienced developer 4-6 weeks,
until he comes up with something usable. Maybe I am completely out of
bounds with that estimation, but from my perspective: senior programming
skills in C/C++, quite some experience with the Tcl C library, some
experience with the Tk C library and no experience with webkit, I would
have to learn webkit and then start to work on the widget. If I could
work full time on that task with no interruption, I think 4-6 weeks for
an initial release could be realistic. Maybe less, I always tend to
estimate more time than I finally need :).
But calculate that time or similar to pay a developer full time, I
think, and you have the price for the bounty.

On the other side: If somebody wants to do it, (s)he could start a crowd
funding project, and as soon as the money target is reached, he could
(evtl. take a break from her ordinary job and) get the "Tkwebkit" done...
I have seen that for other OSS projects, it apparently worked out.

[Alexandru]

Post by EL

Post by m***@gmail.com

Post by EL
You could hire somebody to do it, or sponsor somebody who wants to
create such a Tk widget anyway. That way you could also influence the
capabilities and features of the yet-tbd "Tkwebkit".

You know, I've been wanting this and missing this long enough that I would be willing to pay for it. Any suggestions for a decent bounty amount? I'm not exactly made of money... suppose I could try crowd funding and start with putting up what I can.

Crowd funding may be a good idea.
As for the bounty price: Hm, I'd say, somebody who is decently involved
in Tk widgets development *and* webkit at the same time is hard to find.
Most people have to work themselves in to one or the other, if not
both... and I guess webkit is the harder part (meanwhile I had a look at
their sources and API, it is at least quite overwhelming at a first glance).
All in all I think it could take an experienced developer 4-6 weeks,
until he comes up with something usable. Maybe I am completely out of
bounds with that estimation, but from my perspective: senior programming
skills in C/C++, quite some experience with the Tcl C library, some
experience with the Tk C library and no experience with webkit, I would
have to learn webkit and then start to work on the widget. If I could
work full time on that task with no interruption, I think 4-6 weeks for
an initial release could be realistic. Maybe less, I always tend to
estimate more time than I finally need :).
But calculate that time or similar to pay a developer full time, I
think, and you have the price for the bounty.
On the other side: If somebody wants to do it, (s)he could start a crowd
funding project, and as soon as the money target is reached, he could
(evtl. take a break from her ordinary job and) get the "Tkwebkit" done...
I have seen that for other OSS projects, it apparently worked out.
--
EL

I have no idea of webkit, but 4-6 weeks seems to me very unrealistic... Rather 4-6 months

[EL]

Post by Alexandru
I have no idea of webkit, but 4-6 weeks seems to me very unrealistic... Rather 4-6 months

If you have nothing else on the plate and can fully concentrate on just
that task?

Of course it depends on how fast you get started with webkit and how
experienced you are with C++ and the Tcl/Tk C libraries. As said, the
4-6 weeks are just my perspective :). And I could mistakenly
underestimate it, of course.

It also depends on the set of functionality. I guess if the "Tkwebkit"
should be just some browser utilizing webkit, it could be done
relatively fast. If one wants to control javascript or html5 elements
from outside via tcl, or vice versa, that takes more work (but then it
starts to become really interesting ;))

[r***@googlemail.com]

If a look into WebkitCore, I have the impression that a lot of stuff has to be done. And it's not yet clear which hurdles do you have to take. You have to consider that the Tk library is not such a sophisticated library like Cairo-based libraries. As an example: the lacking clipping functionality of the Tk library. If you need clipping functionality for the integration of the Webkit, then you don't have a 5 minute task:

- developing of a platform independent (X11, Win, Mac) clipping support, this requires also the adaption of the (platform independent) graphic context support
- testing on all platforms
- writing/updating the Tk documentation (mandatory)
- writing the test cases (mandatory)
- writing a TIP (Tcl Improvement Proposal; mandatory), and convincing the TCT (Tcl Core Team) that this functionality is needed (the TCT is quite conservative)

Only this task needs about 2 weeks. This is an example how the integration of extensions/enhancements into Tk works.

Moreover you have to implement/integrate some stuff for file storage (images, cookies, HTML cache), and probably other kinds of storage.

Also take into account that currently no (properly working) Drag&Drop support exists. The integration of a proper Drag&Drop requires some extensions inside the Tk library. (I'm planning to do this, but not currently.)

My estimation is that you need at least 6 months, and I did not yet look into JavascriptCore (integration of a Java engine).

The adaption of Webkit/Tk is (currently) beyond of my time scope.

Such a platform independent GUI development shouldn't be under-estimated. I'm the author of the revised Tk text widget (will be shipped out with 8.7), and the development took me more than one year (the text widget is indeed very complex), though I'm very experienced with GUI/widget development, and I'm very experienced with the Tk library. Especially testing on all platforms is very time consuming.

[William J Giddings]

Integrating Webkit into Gnocl was comparatively simple, but this was
only thanks to a pre-existing Gtk compliant api wrapped abound the
Webkit libraries offering a simplified widget API.

Taking the matter further, on the Tk side it would require more than in
Gnocl, the Tk is written in C and Webkit in C++.

Thereafter, of course, getting anything done in Webkit is not really
achieved in Tcl, but passing Javascript to the Webkit engine.

All complicated stuff, but the Gnocl offering works reasonably well. If
you need it in a Tk UI, then plug it into a socket.

The question arises is just how important is it to have a full-blown
browser engine embedded into a Tk app.

I created the gnocl::webkit package in order to provide access to rich
text formatting, because the GtkHTML package has been deprecated.

In the event control over Webkit for this purpose was limited, using a
fully featured web engine in my apps was resulting in unpredictable
behaviour because of conflicting events bindings and other issues. In
the end, I rolled up my sleeves and set to the task of producing a C
extension to the Gtk text widget to provide edit support for rich text
markup using Pango format which is largely HTML compliant.

If I were looking to develop browser apps, then I'd take a different
route than using Tk.

Best wishes

Will
Gnocl developer.

Post by r***@googlemail.com
- developing of a platform independent (X11, Win, Mac) clipping support, this requires also the adaption of the (platform independent) graphic context support
- testing on all platforms
- writing/updating the Tk documentation (mandatory)
- writing the test cases (mandatory)
- writing a TIP (Tcl Improvement Proposal; mandatory), and convincing the TCT (Tcl Core Team) that this functionality is needed (the TCT is quite conservative)
Only this task needs about 2 weeks. This is an example how the integration of extensions/enhancements into Tk works.
Moreover you have to implement/integrate some stuff for file storage (images, cookies, HTML cache), and probably other kinds of storage.
Also take into account that currently no (properly working) Drag&Drop support exists. The integration of a proper Drag&Drop requires some extensions inside the Tk library. (I'm planning to do this, but not currently.)
My estimation is that you need at least 6 months, and I did not yet look into JavascriptCore (integration of a Java engine).
The adaption of Webkit/Tk is (currently) beyond of my time scope.
Such a platform independent GUI development shouldn't be under-estimated. I'm the author of the revised Tk text widget (will be shipped out with 8.7), and the development took me more than one year (the text widget is indeed very complex), though I'm very experienced with GUI/widget development, and I'm very experienced with the Tk library. Especially testing on all platforms is very time consuming.

[m***@gmail.com]

Post by William J Giddings
If I were looking to develop browser apps, then I'd take a different

route than using Tk.

Yes, it does seem like an insurmountable amount of work to make something that will only ever half-work. :(

Perhaps I should look at integrating Tcl into something like electron and doing some sort of javascript<->tcl interface. Perhaps I can reuse the work from NaTcl+electron to achieve something working much faster. That doesn't neatly satisfy all my wishes, but better to have something that works and is imperfect.

[Gerry Snyder]

Post by William J Giddings

Post by William J Giddings
If I were looking to develop browser apps, then I'd take a different

route than using Tk.
Yes, it does seem like an insurmountable amount of work to make something that will only ever half-work. :(
Perhaps I should look at integrating Tcl into something like electron and doing some sort of javascript<->tcl interface. Perhaps I can reuse the work from NaTcl+electron to achieve something working much faster. That doesn't neatly satisfy all my wishes, but better to have something that works and is imperfect.

Are you aware of Aejaks?

http://aejaks.sourceforge.net/Aejaks_Home/index.html

It makes writing a web app about as easy as writing a native GUI in Tcl/Tk.


Downsides:

The server must be running Java

The Tcl is ~ 8.4

The GUI part is not Tk -- but it has a very similar feel.


I really like it a lot. It has decent reference docs, but a great widget
demo that you can have running locally within a few minutes of
downloading the package. Together they make learning it a snap.

Gerry Snyder

[m***@gmail.com]

Post by Gerry Snyder

Post by William J Giddings

Post by William J Giddings
If I were looking to develop browser apps, then I'd take a different

route than using Tk.
Yes, it does seem like an insurmountable amount of work to make something that will only ever half-work. :(
Perhaps I should look at integrating Tcl into something like electron and doing some sort of javascript<->tcl interface. Perhaps I can reuse the work from NaTcl+electron to achieve something working much faster. That doesn't neatly satisfy all my wishes, but better to have something that works and is imperfect.

Are you aware of Aejaks?
http://aejaks.sourceforge.net/Aejaks_Home/index.html
It makes writing a web app about as easy as writing a native GUI in Tcl/Tk.
The server must be running Java
The Tcl is ~ 8.4
The GUI part is not Tk -- but it has a very similar feel.
I really like it a lot. It has decent reference docs, but a great widget
demo that you can have running locally within a few minutes of
downloading the package. Together they make learning it a snap.
Gerry Snyder

Java and 8.4. Ouch and double ouch.

For running Tk in a browser I've found HTML5 VNC viewers and custom VNC configs to work well.

[EL]

Post by m***@gmail.com
Perhaps I should look at integrating Tcl into something like electron and doing some sort of javascript<->tcl interface. Perhaps I can reuse the work from NaTcl+electron to achieve something working much faster. That doesn't neatly satisfy all my wishes, but better to have something that works and is imperfect.

If that is what you're really after: I just found EmTcl:

https://aidanhs.github.io/emtcl/

A Tcl interpreter compiled into JavaScript, using emscripten. Really cool!

I checked with my emsdk installation and successfully managed to compile
Tcl 8.6.6 with just a few modifications*. It creates a file "emtcl.js"
which you include in your html and -voila- there is a Tcl interpreter in
your web page. Exciting! :)
It's actually something that I could use for a project at the moment...
just have to figure out how to call Tcl proc's from JavaScript and vice
versa. By then it should be possible to create something like Tk on top
of that, or a simulation of Tk which works via the DOM and html inside
the browser (i.e. a [button] command that creates the html for a button
and places it inside the DOM, etc.)


* some packages in pkgs/ cannot be compiled and the unix/configure
script needs some tweaks to strstr, strtol and strtod function checks.
Apparently it thinks that the emsdk implementations are buggy, then
enables some internal implementations, but later the emcc compiler
complains that these functions are doubly linked. Also there is a
problem with strlcpy defined in compat/fake-rfc2553.c, this function is
also not quite recognized by configure, but can be ifdef'ed out in this
file.
All in all I think it should be possible to compile standard Tcl for
emscripten with some improved configure.in

[m***@gmail.com]

Post by EL

Post by m***@gmail.com
Perhaps I should look at integrating Tcl into something like electron and doing some sort of javascript<->tcl interface. Perhaps I can reuse the work from NaTcl+electron to achieve something working much faster. That doesn't neatly satisfy all my wishes, but better to have something that works and is imperfect.

https://aidanhs.github.io/emtcl/
A Tcl interpreter compiled into JavaScript, using emscripten. Really cool!
I checked with my emsdk installation and successfully managed to compile
Tcl 8.6.6 with just a few modifications*. It creates a file "emtcl.js"
which you include in your html and -voila- there is a Tcl interpreter in
your web page. Exciting! :)
It's actually something that I could use for a project at the moment...
just have to figure out how to call Tcl proc's from JavaScript and vice
versa. By then it should be possible to create something like Tk on top
of that, or a simulation of Tk which works via the DOM and html inside
the browser (i.e. a [button] command that creates the html for a button
and places it inside the DOM, etc.)
* some packages in pkgs/ cannot be compiled and the unix/configure
script needs some tweaks to strstr, strtol and strtod function checks.
Apparently it thinks that the emsdk implementations are buggy, then
enables some internal implementations, but later the emcc compiler
complains that these functions are doubly linked. Also there is a
problem with strlcpy defined in compat/fake-rfc2553.c, this function is
also not quite recognized by configure, but can be ifdef'ed out in this
file.
All in all I think it should be possible to compile standard Tcl for
emscripten with some improved configure.in
--
EL

Hmm... EmTcl + Electron has some real possibilities. I'll have to play with that.

[Aidan Hobson Sayers]

Post by EL
I checked with my emsdk installation and successfully managed to compile
Tcl 8.6.6 with just a few modifications*. It creates a file "emtcl.js"
which you include in your html and -voila- there is a Tcl interpreter in
your web page. Exciting! :)

Ha, you're the first person I'm aware of who's actually compiled it themselves. Nice to know it still works.

[EL]

Post by Aidan Hobson Sayers
Ha, you're the first person I'm aware of who's actually compiled it themselves. Nice to know it still works.

Oh :). Thank you for starting that project, great work!

I actually want to realize something with emtcl, so I must compile it by
myself. The project involves "C" (resp. JavaScript) extensions as
well... I am glad you provided the [dom] command as an example.

Actually I wish that emscripten would be a first class supported
platform for Tcl, so that no hacks and patches are necessary. But that
would involve a little more work, i.e. to get [socket] fully functional
(currently it connects to a websocket with the "binary" protocol, but
its not possible to send anything there, a JS exception is raised on
[flush]). And of course the [clock] and [after] commands, and maybe some
more things to come.

As of now I guess it is best to create safe interpreters only, which
disable [socket], [exec], [file] and the like. These commands are not
supported in the browser anyway.

[Matthew Hiles]

Post by EL

Post by Aidan Hobson Sayers
Ha, you're the first person I'm aware of who's actually compiled it themselves. Nice to know it still works.

Oh :). Thank you for starting that project, great work!
I actually want to realize something with emtcl, so I must compile it by
myself. The project involves "C" (resp. JavaScript) extensions as
well... I am glad you provided the [dom] command as an example.
Actually I wish that emscripten would be a first class supported
platform for Tcl, so that no hacks and patches are necessary. But that
would involve a little more work, i.e. to get [socket] fully functional
(currently it connects to a websocket with the "binary" protocol, but
its not possible to send anything there, a JS exception is raised on
[flush]). And of course the [clock] and [after] commands, and maybe some
more things to come.
As of now I guess it is best to create safe interpreters only, which
disable [socket], [exec], [file] and the like. These commands are not
supported in the browser anyway.
--
EL

Getting off topic here, but would JimTcl work better for compiling with emscripten?

[Aidan Hobson Sayers]

Post by Matthew Hiles

Post by EL

Post by Aidan Hobson Sayers
Ha, you're the first person I'm aware of who's actually compiled it themselves. Nice to know it still works.

Oh :). Thank you for starting that project, great work!
I actually want to realize something with emtcl, so I must compile it by
myself. The project involves "C" (resp. JavaScript) extensions as
well... I am glad you provided the [dom] command as an example.
Actually I wish that emscripten would be a first class supported
platform for Tcl, so that no hacks and patches are necessary. But that
would involve a little more work, i.e. to get [socket] fully functional
(currently it connects to a websocket with the "binary" protocol, but
its not possible to send anything there, a JS exception is raised on
[flush]). And of course the [clock] and [after] commands, and maybe some
more things to come.
As of now I guess it is best to create safe interpreters only, which
disable [socket], [exec], [file] and the like. These commands are not
supported in the browser anyway.
--
EL

Getting off topic here, but would JimTcl work better for compiling with emscripten?

Well they're both there on the page so you can try them out to compare if you like :)

Looking at the page load (since it was a while ago now!), jimtcl is about 30% of the size of tcl when they're both gzipped. But I don't know anything about the jimtcl C api so you'd need to figure out how to create a dom.c example yourself. I suspect it's not too tricky and will just require some C knowledge.

[EL]

Post by Matthew Hiles
Getting off topic here, but would JimTcl work better for compiling with emscripten?

If size and loading speed matters, I'd go for jimtcl probably.
But regarding the compilation, I had no trouble with Emtcl, apart from 3
linker doubles (strdoul, strstr and strtod were considered to be buggy
by emconfigure and Tcl provides its own functions then. Later in the
link step, emcc complains that these functions were already present. I
deleted the checks from configure.in, ran autoconf and the linker errors
are gone. Not sure what effect this will have, but probably none,
because the "buggy" considerations were around pointers and pointers are
integers in emscripten).
Btw, I had linker doubles with jimtcl either, but I didn't follow up on
that.

Emtcl inherits many useful features from Tcl, which I need: TclOO,
sockets, [binary]...

Currently I try to get client sockets working. I figured out that they
are indeed functional: the [socket -async] command connects to a
websocket with the "binary" protocol. It is possible to connect and, by
some more tweaking, to send data, but fileevents are not fired
automatically. Anyway the data arrives on "system call" level, and I
managed to get the fileevent fired with [update] ([vwait] blocks the
browser).

I think that, if there would be an event loop running in a main()
function at module startup, it would be possible to use (web)sockets.
And [after <ms> <code>] would also work, because these are timer events.

(just a side remark, to get even more off topic ;)

[Alexandru]

Post by Aidan Hobson Sayers
Ha, you're the first person I'm aware of who's actually compiled it themselves. Nice to know it still works.

I got it! I have extended your prototype to a fully capable tclsh in the
browser!
Client sockets are working (as long as the servers are websockets), the
event loop is running and the tcl_library is initialized properly. This
means that [clock] is available, [after ms command] works, fileevents
are processed (important for sockets) and [package require] can be used
to load standard and custom packages. For the latter, they need to be
copied into the emscripten virtual filesystem in order to be available.
And the variables tcl_library, tcl_platform, auto_path, etc. are also set.
Now it is possible to write Tcl based browser applications, not only in
theory but in practice :).
Do you like to have the code / patches as a contribution for the
project? Otherwise I could share it as a fossil repo also... (but need
some time to set that up).
--
EL

I understand only 50% of what's being written here but I think that having a way of programming client side browser apps in Tcl would be awesome. Though a HowTo written in the language of the "normal" Tcl-er would be necessary...

[EL]

Post by Alexandru
I understand only 50% of what's being written here but I think that having a way of programming client side browser apps in Tcl would be awesome. Though a HowTo written in the language of the "normal" Tcl-er would be necessary...

Yes, that would indeed be awesome! I think the groundworks is done, the
building blocks are ready for something like client side Tk in the browser.

Meanwhile I wrapped everything up into a fossil repo and called it wasmTcl.
It is an extension of Aidans Emtcl, providing a bit more functionality.
Downside is, it is also bigger files to download, especially the
library, and because of this it is asynchronous: the code using the
module must be defined in a callback "onReady".
The original Makefile is completely different, the dom command is still
there but has moved to an own extension + namespace, which serves for
commands around the browser. As of now I added another command
"wasmtcl::jscall" there, to call javascript functions from Tcl.
The default compile output is webassembly, hence the name (can easily be
changed to compile to javascript, though). And it doesn't contain the
jimtcl part.

Webassembly is not only really cool, it is also relatively "bleeding
edge". It's just a month ago that Firefox and Chrome started to support
it officially, Microsoft Edge is apparently following this month. Safari
seems to be working on it, but no release yet.
I guess that makes Tcl one of the first interpreters being compiled for
webassembly... ;).

I think wasmTcl would be ready for a preview:

https://fossil.e-lehmann.de/wasmtcl/

As for being really official, I am not sure whether it should be merged
with Emtcl and maintained under one hood?

[Alexandru]

Post by EL

Post by Alexandru
I understand only 50% of what's being written here but I think that having a way of programming client side browser apps in Tcl would be awesome. Though a HowTo written in the language of the "normal" Tcl-er would be necessary...

Yes, that would indeed be awesome! I think the groundworks is done, the
building blocks are ready for something like client side Tk in the browser.
Meanwhile I wrapped everything up into a fossil repo and called it wasmTcl.
It is an extension of Aidans Emtcl, providing a bit more functionality.
Downside is, it is also bigger files to download, especially the
library, and because of this it is asynchronous: the code using the
module must be defined in a callback "onReady".
The original Makefile is completely different, the dom command is still
there but has moved to an own extension + namespace, which serves for
commands around the browser. As of now I added another command
"wasmtcl::jscall" there, to call javascript functions from Tcl.
The default compile output is webassembly, hence the name (can easily be
changed to compile to javascript, though). And it doesn't contain the
jimtcl part.
Webassembly is not only really cool, it is also relatively "bleeding
edge". It's just a month ago that Firefox and Chrome started to support
it officially, Microsoft Edge is apparently following this month. Safari
seems to be working on it, but no release yet.
I guess that makes Tcl one of the first interpreters being compiled for
webassembly... ;).
https://fossil.e-lehmann.de/wasmtcl/
As for being really official, I am not sure whether it should be merged
with Emtcl and maintained under one hood?
--
EL

The app at http://wasmtcl.e-lehmann.de/ does not work. I cannot input anything into the text box. It's like read only.

[Alexandru]

Post by Alexandru

Post by EL

Post by Alexandru
I understand only 50% of what's being written here but I think that having a way of programming client side browser apps in Tcl would be awesome. Though a HowTo written in the language of the "normal" Tcl-er would be necessary...

Yes, that would indeed be awesome! I think the groundworks is done, the
building blocks are ready for something like client side Tk in the browser.
Meanwhile I wrapped everything up into a fossil repo and called it wasmTcl.
It is an extension of Aidans Emtcl, providing a bit more functionality.
Downside is, it is also bigger files to download, especially the
library, and because of this it is asynchronous: the code using the
module must be defined in a callback "onReady".
The original Makefile is completely different, the dom command is still
there but has moved to an own extension + namespace, which serves for
commands around the browser. As of now I added another command
"wasmtcl::jscall" there, to call javascript functions from Tcl.
The default compile output is webassembly, hence the name (can easily be
changed to compile to javascript, though). And it doesn't contain the
jimtcl part.
Webassembly is not only really cool, it is also relatively "bleeding
edge". It's just a month ago that Firefox and Chrome started to support
it officially, Microsoft Edge is apparently following this month. Safari
seems to be working on it, but no release yet.
I guess that makes Tcl one of the first interpreters being compiled for
webassembly... ;).
https://fossil.e-lehmann.de/wasmtcl/
As for being really official, I am not sure whether it should be merged
with Emtcl and maintained under one hood?
--
EL

The app at http://wasmtcl.e-lehmann.de/ does not work. I cannot input anything into the text box. It's like read only.

Sorry, my bad. It works. I just did not see the second text box. The edge is almost invisible (it's white on white).

The description on fossil is very clear and easy to read. I like it a lot. Thanks for the great work. I'll test it more.

[Alexandru]

Post by EL

Post by Alexandru
I understand only 50% of what's being written here but I think that having a way of programming client side browser apps in Tcl would be awesome. Though a HowTo written in the language of the "normal" Tcl-er would be necessary...

Yes, that would indeed be awesome! I think the groundworks is done, the
building blocks are ready for something like client side Tk in the browser.
Meanwhile I wrapped everything up into a fossil repo and called it wasmTcl.
It is an extension of Aidans Emtcl, providing a bit more functionality.
Downside is, it is also bigger files to download, especially the
library, and because of this it is asynchronous: the code using the
module must be defined in a callback "onReady".
The original Makefile is completely different, the dom command is still
there but has moved to an own extension + namespace, which serves for
commands around the browser. As of now I added another command
"wasmtcl::jscall" there, to call javascript functions from Tcl.
The default compile output is webassembly, hence the name (can easily be
changed to compile to javascript, though). And it doesn't contain the
jimtcl part.
Webassembly is not only really cool, it is also relatively "bleeding
edge". It's just a month ago that Firefox and Chrome started to support
it officially, Microsoft Edge is apparently following this month. Safari
seems to be working on it, but no release yet.
I guess that makes Tcl one of the first interpreters being compiled for
webassembly... ;).
https://fossil.e-lehmann.de/wasmtcl/
As for being really official, I am not sure whether it should be merged
with Emtcl and maintained under one hood?
--
EL

So if get it right, the Tcl interpreter is already running in the Browser but the Tk commands are not yet supported, right?

[Matthew Hiles]

Post by Alexandru

Post by EL

Post by Alexandru
I understand only 50% of what's being written here but I think that having a way of programming client side browser apps in Tcl would be awesome. Though a HowTo written in the language of the "normal" Tcl-er would be necessary...

Yes, that would indeed be awesome! I think the groundworks is done, the
building blocks are ready for something like client side Tk in the browser.
Meanwhile I wrapped everything up into a fossil repo and called it wasmTcl.
It is an extension of Aidans Emtcl, providing a bit more functionality.
Downside is, it is also bigger files to download, especially the
library, and because of this it is asynchronous: the code using the
module must be defined in a callback "onReady".
The original Makefile is completely different, the dom command is still
there but has moved to an own extension + namespace, which serves for
commands around the browser. As of now I added another command
"wasmtcl::jscall" there, to call javascript functions from Tcl.
The default compile output is webassembly, hence the name (can easily be
changed to compile to javascript, though). And it doesn't contain the
jimtcl part.
Webassembly is not only really cool, it is also relatively "bleeding
edge". It's just a month ago that Firefox and Chrome started to support
it officially, Microsoft Edge is apparently following this month. Safari
seems to be working on it, but no release yet.
I guess that makes Tcl one of the first interpreters being compiled for
webassembly... ;).
https://fossil.e-lehmann.de/wasmtcl/
As for being really official, I am not sure whether it should be merged
with Emtcl and maintained under one hood?
--
EL

So if get it right, the Tcl interpreter is already running in the Browser but the Tk commands are not yet supported, right?

Correct, but we're at a good spot to implement a UI using javascript and wasmtcl now. Someone get on that :)

[EL]

Post by Alexandru
So if get it right, the Tcl interpreter is already running in the Browser but the Tk commands are not yet supported, right?

Yes. The Tk commands are not yet there, but could be relatively easy
implemented. E.g. by using the wasmtcl::dom command to write innerHTML
and CSS styles to <div> tags.

And a wrapper for the html5 canvas would be exciting :)

[Alexandru]

Post by EL

Post by Alexandru
I understand only 50% of what's being written here but I think that having a way of programming client side browser apps in Tcl would be awesome. Though a HowTo written in the language of the "normal" Tcl-er would be necessary...

Yes, that would indeed be awesome! I think the groundworks is done, the
building blocks are ready for something like client side Tk in the browser.
Meanwhile I wrapped everything up into a fossil repo and called it wasmTcl.
It is an extension of Aidans Emtcl, providing a bit more functionality.
Downside is, it is also bigger files to download, especially the
library, and because of this it is asynchronous: the code using the
module must be defined in a callback "onReady".
The original Makefile is completely different, the dom command is still
there but has moved to an own extension + namespace, which serves for
commands around the browser. As of now I added another command
"wasmtcl::jscall" there, to call javascript functions from Tcl.
The default compile output is webassembly, hence the name (can easily be
changed to compile to javascript, though). And it doesn't contain the
jimtcl part.
Webassembly is not only really cool, it is also relatively "bleeding
edge". It's just a month ago that Firefox and Chrome started to support
it officially, Microsoft Edge is apparently following this month. Safari
seems to be working on it, but no release yet.
I guess that makes Tcl one of the first interpreters being compiled for
webassembly... ;).
https://fossil.e-lehmann.de/wasmtcl/
As for being really official, I am not sure whether it should be merged
with Emtcl and maintained under one hood?
--
EL

I have one issue when trying to integrate wasmtcl into my website:
I'm trying to load wasmtcl from another directory so I'm using absolute (root) path:
<script type="text/javascript" src="/wasmtcl/wasmtcl.js"></script>
Then I get an error about wasmtcl.data not found.
I was trying to write the absolute path into wasmtcl.js but got another error about a "magic number".

How to solve this issue?

[EL]

Post by Alexandru
<script type="text/javascript" src="/wasmtcl/wasmtcl.js"></script>
Then I get an error about wasmtcl.data not found.
I was trying to write the absolute path into wasmtcl.js but got another error about a "magic number".
How to solve this issue?

The build you have requires that all .wasm and *.data files are in the toplevel directory. I haven't tried it, but I think you can move the .js file.

But since this is suboptimal, I switched to requirejs (http://requirejs.org/) just yesterday. Now there is a module "tcl/wasmtcl" define'd, which lives in a tcl/ subdirectory in the same directory where require.js is. To include it in a webpage, you write e.g.
<script data-main="js/main" src="js/require.js"></script>
when you have directories js/ and js/tcl/ with all the wasmtcl.* files in js/tcl/. This way you can also include your own, or other javascript modules with requirejs. To use the module you type
"require(['tcl/wasmtcl'], function(wasmTcl) { ... })"
in another <script> tag (see the example)

I just updated the download for an example, and the web page. If you prefer a different location than tcl/, you must build it yourself I am afraid, since the download paths for .wasm and .data files are baked into wasmtcl.js. As of now you could place the tcl/ directory inside a different directory than js/, but require.js must be a sibling of the tcl/ directory.

[Alexandru]

Post by EL

Post by Alexandru
<script type="text/javascript" src="/wasmtcl/wasmtcl.js"></script>
Then I get an error about wasmtcl.data not found.
I was trying to write the absolute path into wasmtcl.js but got another error about a "magic number".
How to solve this issue?

The build you have requires that all .wasm and *.data files are in the toplevel directory. I haven't tried it, but I think you can move the .js file.
But since this is suboptimal, I switched to requirejs (http://requirejs.org/) just yesterday. Now there is a module "tcl/wasmtcl" define'd, which lives in a tcl/ subdirectory in the same directory where require.js is. To include it in a webpage, you write e.g.
<script data-main="js/main" src="js/require.js"></script>
when you have directories js/ and js/tcl/ with all the wasmtcl.* files in js/tcl/. This way you can also include your own, or other javascript modules with requirejs. To use the module you type
"require(['tcl/wasmtcl'], function(wasmTcl) { ... })"
in another <script> tag (see the example)
I just updated the download for an example, and the web page. If you prefer a different location than tcl/, you must build it yourself I am afraid, since the download paths for .wasm and .data files are baked into wasmtcl.js. As of now you could place the tcl/ directory inside a different directory than js/, but require.js must be a sibling of the tcl/ directory.
--
EL

Now I get the weird error:
19:05:47.308 Error: Not Found : https://www.meshparts.de/Configurator-for-ball-screw-simulation/index2js/tcl/wasmtcl-custom.data 1 wasmtcl.js:1:33012
fetchRemotePackage/xhr.onload https://www.meshparts.de/Configurator-for-ball-screw-simulation/js/tcl/wasmtcl.js:1:33012

The current path of the index.html is concatenated with the relative path.

I'm using:

<script data-main="js/main" src="js/require.js"></script>

and

require(['tcl/wasmtcl', 'jquery-3.2.0.min'], function(wasmTcl) {
wasmTcl.onReady(function (interp) {
'use strict';
alert(interp.Eval('expr 1+6'));
});
});

Is this a bug?

[EL]

Post by Alexandru
19:05:47.308 Error: Not Found : https://www.meshparts.de/Configurator-for-ball-screw-simulation/index2js/tcl/wasmtcl-custom.data 1 wasmtcl.js:1:33012
fetchRemotePackage/xhr.onload https://www.meshparts.de/Configurator-for-ball-screw-simulation/js/tcl/wasmtcl.js:1:33012
The current path of the index.html is concatenated with the relative path.
<script data-main="js/main" src="js/require.js"></script>

...

Post by Alexandru
Is this a bug?

Hm, possible... what does your directory structure look like? Have you
got require.js next to the tcl/ subdirectory? And jquery-3.2.0.min.js?
Where did you put the above <script> tag, at the top or bottom?

I didn't try it with https yet as well. I tried it with a subdirectory
unterneath the toplevel / though, and that works.

[EL]

Post by EL

Post by Alexandru
Is this a bug?

Hm, possible... what does your directory structure look like? Have you

Ah yes, it was a bug. Now I stumbled over it as well, it happens when
you have an URL that ends in an HTML file rather than a directory.
It's fixed in the code. I didn't update the test webpage yet, will do
that tomorrow...

[Braden Napier]

Nothing is working for me. Sounds awesome though!

[Braden Napier]

Let me clarify - all the wasm links in this thread go to "Not Found" or some other related error.

[EL]

Post by Braden Napier
Let me clarify - all the wasm links in this thread go to "Not Found" or some other related error.

Err, well.

It's still work in progress and I decided last week to rename the
project to "wacl" (an acronym for "w" eb "a" ssembly T "cl"). I also
defined the project goal more clearly: it is supposed to be a Tcl
distribution for Webassembly, rather than just the Tcl interpreter
itself. Fair enough, it builds almost alltogether on code that already
exists.

As of now I included tDOM and a handful useful packages from tcllib.
More will come... I think it would be good to have Jsonc ported from
critcl to a "normal" "C" extension and compile + statically link that
with the Tcl interpreter. It'll probably inevitable for data exchange
between Javascript and wacl.

So the URLs have changed. Its

https://fossil.e-lehmann.de/wacl/index

and

http://wacl.e-lehmann.de/

Ah, and the tDOM commands are in the namespace ::tdom::. To not collide
with any other "dom" commands ;)

[Braden Napier]

Awesome! This is great work - much appreciated.

How difficult would it be to allow using a tclkit / perhaps one created my rkeene's kit creator?

https://fossil.e-lehmann.de/wacl/home

Would be awesome to be able to output the kit and customize the distribution -- especially so that people can self-upgrade their distributions as new versions are available.

[EL]

Post by Braden Napier
Awesome! This is great work - much appreciated.

Thanks :).

Post by Braden Napier
How difficult would it be to allow using a tclkit / perhaps one created my rkeene's kit creator?

Hm, not sure. First of all, the vfs:: packages would need to be
compiled, metakit and so on. That's not very easy, I've heard not even
in normal operating systems. I don't know how much work it would be in
emscripten.
Then, C extensions in starkits do rely on the stubs mechanism. The stubs
mechanism doesn't work yet, because it still depends on some kind of
dynamic loading, and webassembly doesn't support that (yet). So it would
anyway only be possible to have pure Tcl in starkits.

And the downsize is: size. All extensions, starkits, binary or
otherwise, need to be downloaded into the browser. If these files are
too big and bandwidth is too small, its not a good user experience...

Well, we have something similar to starkits with the emscripten VFS and
the .data files. They can contain arbitrary Tcl packages in any
imaginable configuration, same as starkits. So I don't see much of a
point for starkits yet - you can simply package all your Tcl code in the
wacl-custom.data file.
As for C extensions, they need to be statically linked and initialized
anyway. This is a webassembly limitation, but according to the design
spec there could be dynamic linking in the future:

https://github.com/WebAssembly/design/blob/master/DynamicLinking.md

[Christian Gollwitzer]

Post by EL
As of now I included tDOM and a handful useful packages from tcllib.
More will come... I think it would be good to have Jsonc ported from
critcl to a "normal" "C" extension and compile + statically link that
with the Tcl interpreter. It'll probably inevitable for data exchange
between Javascript and wacl.

How about using the bleeding-edge rljson instead?

https://github.com/RubyLane/rl_json

Christian

[EL]

Post by Christian Gollwitzer
How about using the bleeding-edge rljson instead?
https://github.com/RubyLane/rl_json

Thanks for the hint, this looks great!
I included it right away, its in wacl now as ::rljson::json :)

[EL]

Post by EL
I included it right away, its in wacl now as ::rljson::json

I mean ::rl_json::json
As the original command...

[Braden Napier]

http://wiki.tcl.tk/48276

I created this as a little addition to RL_JSON awhile back as well. Basically just makes it even easier and more effective to work directly with JSON values.

[Braden Napier]

Post by EL

Post by EL
I included it right away, its in wacl now as ::rljson::json

I mean ::rl_json::json
As the original command...
--
EL

https://github.com/Dash-OS/tcl-modules/blob/master/json_tools-1.0.tm

Also here as a tm

[EL]

Post by Braden Napier
https://github.com/Dash-OS/tcl-modules/blob/master/json_tools-1.0.tm

Hm, I already created a namespace ::rl_json:: on C level and made the
command json exported. So now you can do

% namespace import ::rl_json::*

and have "json" in your current namespace for usage.

What I miss is something like [json lappend]. And something that maps
TclOO object variables automatically to json...

[Donal K. Fellows]

And something that maps TclOO object variables automatically to
json...

TclOO object variables are *really* just ordinary variables in the
instance's namespace. That means that if you get the name of them (e.g.,
with [my varname $thevar]) then you can use that from outside of TclOO
just fine, allowing them to be used with stuff like [vwait] and so on.
So all you need to do is to come up with a way to map a namespace's
variables to JSON, probably via the template mechanism…

Donal.

[Braden Napier]

the link i gave is a toolset on top of rl_json. It gives you exacty what you just mentioned actually.

[Braden Napier]

It's just a pure-tcl wrapper but it provides the (undocumented) [json object] command

---------------

package require json_tools

set j {{
"foo": "bar",
"baz": [ "foo", "bar", "qux" ]
}}

set nux null
set tux 500

json push j nux tux

puts $j

json object lappend j baz one

puts $j

------------------

# {"foo":"bar","baz":["foo","bar","qux"],"nux":null,"tux":500}
# {"foo":"bar","baz":["foo","bar","qux","one"],"nux":null,"tux":500}

[Emmanuel Frecon]

Just to let you know that this is currently hot on hacker news

Wacl: Tcl distro customized for WebAssembly - https://news.ycombinator.com/item?id=14228849

[Alexandru]

Post by Emmanuel Frecon
Just to let you know that this is currently hot on hacker news
Wacl: Tcl distro customized for WebAssembly - https://news.ycombinator.com/item?id=14228849

I couldn't help to notice that again, one of the arguments against Tcl/Tk in the posted link are the looking of Tk:

"Compared to Tcl/tk you get (A) catch errors at compile time, and (B) Qt apps usually look better than Tk apps."

This is not true anymore, but do to the resistance of most Tcl/Tk developers to update their apps to ttk, we generate a false impression for potential Tcl/Tk beginners. Sad...

[Matthew Hiles]

Post by Alexandru

Post by Emmanuel Frecon
Just to let you know that this is currently hot on hacker news
Wacl: Tcl distro customized for WebAssembly - https://news.ycombinator.com/item?id=14228849

"Compared to Tcl/tk you get (A) catch errors at compile time, and (B) Qt apps usually look better than Tk apps."
This is not true anymore, but do to the resistance of most Tcl/Tk developers to update their apps to ttk, we generate a false impression for potential Tcl/Tk beginners. Sad...

Not to mention, it's only 'ugly' on X11. Unless you consider the native kits on OSX and windows ugly (which I do).

Also, it takes very little config to make pretty or at least not identifiable as Tk. Like so: Loading Image...

[EL]

Post by Alexandru
do to the resistance of most Tcl/Tk developers to update their apps to ttk,
we generate a false impression for potential Tcl/Tk beginners. Sad...

Well, I think it's definitely considerable and better to use ttk nowadays.
But I don't think that updating old apps to ttk would leverage the
impression of Tcl/Tk to beginners. Tcl is a language that you fall in love
with right from the beginning, or you don't. In the latter case you will
never like it and always try to avoid it, no matter how great or easy it is
or how good ttk looks.

And there are lots of alternatives today.... Most people don't have the
"Tcl gene" or even need it. Maybe a pity, but true.

[Alexandru]

Post by EL

Post by Alexandru
do to the resistance of most Tcl/Tk developers to update their apps to ttk,
we generate a false impression for potential Tcl/Tk beginners. Sad...

Well, I think it's definitely considerable and better to use ttk nowadays.
But I don't think that updating old apps to ttk would leverage the
impression of Tcl/Tk to beginners. Tcl is a language that you fall in love
with right from the beginning, or you don't. In the latter case you will
never like it and always try to avoid it, no matter how great or easy it is
or how good ttk looks.
And there are lots of alternatives today.... Most people don't have the
"Tcl gene" or even need it. Maybe a pity, but true.
--
EL

This is true for one part of the users, especially for programing specialists. But for sure not for all. I'm sure one part is refusing Tcl/Tk simply because of visual properties of the examples found on the web. They do this even before they take a look at the programming paradigm. The vast majority are not programming specialists. They are people with only basic programming skills, looking for a meaning of quickly implementing an idea. Quite the spirit of IoT.

My call to the community: Open your code in your preferred text editor, call the "search and replace" feature and add replace all "button" by "ttk::button". Bang! 10% more Tcl users. Replace "checkbutton" by "ttk::checkbutton". Bang! 20% more Tcl users. And so on... ;) It's simple, so why not do it?

[Aidan Hobson Sayers]

Post by Alexandru
"Compared to Tcl/tk you get (A) catch errors at compile time, and (B) Qt apps usually look better than Tk apps."
This is not true anymore

Not sure if you were exclusively referring to B, but I'm pretty sure A is still true! Lack of compiler/typing is often considered an advantage in the world of Tcl, but not everyone thinks that way and each side has valid arguments. Though in this specific case you're then using C++ which comes with the possibility of memory unsafety, but that doesn't affect the general principle.

[Alexandru]

Post by Aidan Hobson Sayers

Post by Alexandru
"Compared to Tcl/tk you get (A) catch errors at compile time, and (B) Qt apps usually look better than Tk apps."
This is not true anymore

Not sure if you were exclusively referring to B, but I'm pretty sure A is still true! Lack of compiler/typing is often considered an advantage in the world of Tcl, but not everyone thinks that way and each side has valid arguments. Though in this specific case you're then using C++ which comes with the possibility of memory unsafety, but that doesn't affect the general principle.

Yes, I'm referring to B.

[p***@yahoo.com]

This is pretty amazing stuff. Excited to see where it leads!

/Ashok

Post by EL
https://fossil.e-lehmann.de/wasmtcl/
As for being really official, I am not sure whether it should be merged
with Emtcl and maintained under one hood?
--
EL

[Aidan Hobson Sayers]

Do you like to have the code / patches as a contribution for the
project?

Yes please do, I'm always up for keeping things up-to-date.

If you want, I can add you as a maintainer on the emtcl repo so you can do future work there. It's up to you.

[m***@gmail.com]

Post by r***@googlemail.com
I'm the author of the revised Tk text widget (will be shipped out with 8.7), and the development took me more than one year (the text widget is indeed very complex)

Oh snap, I love the text widget. I've been working with it a lot to make client for a game I'm working on. Got a link to a changelog? I cannot express how excited I am for improvements to the text widget :D

[r***@googlemail.com]

Post by m***@gmail.com
Oh snap, I love the text widget. I've been working with it a lot to make client for a game I'm working on. Got a link to a changelog? I cannot express how excited I am for improvements to the text widget :D

http://scidb.sourceforge.net/tk/revised-text-widget.html

[m***@gmail.com]

Post by r***@googlemail.com

Post by m***@gmail.com
Oh snap, I love the text widget. I've been working with it a lot to make client for a game I'm working on. Got a link to a changelog? I cannot express how excited I am for improvements to the text widget :D

http://scidb.sourceforge.net/tk/revised-text-widget.html

Well I see lots of things on my wish list checked off! Thanks for all your work!

[EL]

Post by r***@googlemail.com
- developing of a platform independent (X11, Win, Mac) clipping support, this requires also the adaption of the (platform independent) graphic context support
- testing on all platforms
- writing/updating the Tk documentation (mandatory)
- writing the test cases (mandatory)
- writing a TIP (Tcl Improvement Proposal; mandatory), and convincing the TCT (Tcl Core Team) that this functionality is needed (the TCT is quite conservative)

I see. Certainly I didn't consider any TIP processes or changes to the
Tk core ;).

How about gecko, the mozilla rendering engine? Would that be simpler? A
vice versa integration in form of the Tclplugin as NPAPI exists already...

[Bruce Johnson]

Post by m***@gmail.com
I realize we've got things like tkhtml and hv3 as well as gnocl::webkit, but how is there not a tightly integrated, works with core Tk, cross platform widget using webkit (or other HTML5, standards compliant engine)?
I can do some hackery like embed a chromium app-window into a tk frame, but that's not cross platform and I would like to be able to have tightly integrated script access (in the same sense as the canvas widget or the text widget) as well as have this work/easily compile against different graphical backends like sdlwish--that way I can drive and develop complex graphical interfaces straight from the framebuffer.
I know the usual chime in the OSS world is if you want it and it's missing, do it yourself. But I really do not have the C chops to implement this. Is there anything like a modern, well-supported html5 widget for standard Tk? Doesn't *have* to be webkit, but I assume that's the easiest to work with.

I haven't worked on it in quite a while (and not sure if I'll get back to it), but my TkFX project (which was just a prototype) had an example of creating a WebKit based widget ( http://wiki.tcl.tk/28803 ). TkFX is a combination of JTcl and JavaFX.

[Georgios Petasis]

Post by m***@gmail.com
I realize we've got things like tkhtml and hv3 as well as gnocl::webkit, but how is there not a tightly integrated, works with core Tk, cross platform widget using webkit (or other HTML5, standards compliant engine)?

I have started such a project 4 years ago, but at that time webkit was
not the popular one, so I wasted my time on gecko:

https://sourceforge.net/projects/tkgecko/

I lost my interest when mozila announced that the embedding API will be
abandoned...

George