NexTk Design Questions
George Peter Staplin
I'm thinking of NexTk lately, in addition to my new filesystem, and a
dozen other things...
I have some design questions, and questions for those of you that have
tested or want to use NexTk.
For those of you that haven't heard of NexTk before:
http://wiki.tcl.tk/NexTk
I'm trying to decided whether to seriously replace X, or to focus on
using NexTk as a portable toolkit that runs under Win32 or X (or MacOS X
in the future) systems.
The future design involves changes to support this, and I'm not sure
which direction to go in.
Would you prefer a window system or a general toolkit, or both if
possible?
These are some current problems:
1. as a window system it can lockup with an endless loop in a task.
2. applications currently aren't separate from the window system's
process image.
So, my ideas for use as a window system and general display mechanism
involve:
A. Using separate processes for each application that connects to
NexTk. The processes would read/write to megaimage structures via
shared memory, and sockets for some message passing.
Pro:
1. This gives us the ability to use languages other than Tcl to
interface with NexTk.
2. If an application has a bug it doesn't mean that the running code
in the window system is potentially broken.
3. debugging may be easier, although research sometimes disagrees.
Con:
1. It means writing a library with an abtract interface to support
Win32 and unix shared memory.
2. The complexity increases, and semaphores will need to be used.
This means strict design is required, or serious faults will occur.
3. I'll have to write an allocator for shared memory, and stop using
malloc for some things.
B. Use Tcl threads for each application in the window system.
Pro:
1. Tcl threads may be easier.
Con:
1. Megaimage currently isn't designed for use in multithreaded apps,
and neither are rendertree and many other extensions used in NexTk.
2. Languages other than Tcl may be difficult to interface, or
possibly slow. Users of those foreign languages may not like this.
I've been reading papers by Rob Pike about his concurrent window system
8 1/2, as well as his followup to 8 1/2 called Rio. So far I'm not
terribly inspired, though some of it might be similar.
I've been much more inspired by James Gosling's paper about how he would
design a window system in 2002. I've also been reading papers about
Project Oberon, that may create further ideas.
Do you have any advice on further directions?
If you can think of ways to simplify my design or possibly improve it,
please speak up.
Sometimes I wish I could hand off some of these jobs to another
competent engineer... :)
Thanks,
George
Torsten Reincke
> using NexTk as a portable toolkit that runs under Win32 or X (or MacOS X
> in the future) systems.
> Would you prefer a window system or a general toolkit, or both if
> possible?
I would prefer a portable toolkit. I can imagine it is difficult to
replace X11 or any other windowing system and at the same time get a
large user community. There must be good reasons to replace X, before
anyone will do that.
But having a toolkit with the possibilities of NexTk is very
attractive. Being able to develop Tcl apps cross-platform without
having to force people to change their windowing system at the same
time is a good thing, IMO.
I can imagine something like ...
package require NexTK
nextk::canvas .c
.c create text 10 10 -text "hi there" -angle 34.6 -alpha 45 -antialias
yes -tags hi
.c rotate hi -step 5 -speed 7 -anchor [list 10 25]
... and this looking smooth and nice and pleasing.
I am dreaming of having better graphical possibilities in Tk. Something
like the charts on
http://www.gapminder.org/index.html
Look at the Flash animations (for example the third: "Has the world
become a better place?"). A student of the inventor Hans Rosling
worked for over a year (without getting payed the first time) to make
this a usable tool. Imagine some of the possibilities of Flash at your
Tcl'ers fingertips embedded into the ease of creating graphics in the
canvas (or BLT)! These graphs would be good for a month work then, not
for a year!
Perhaps I miss the point in NexTk but all this animation stuff,
antialiasing, transparency, smooth movements is what I'd like to see
(and wish I could code this myself, but my C knowledge is far too bad).
I can see quite some of these topics covered in NexTk demos!
I see NexTK as a step in this direction, so it could make a wonderful
toolkit!
Just my $0.02, Torsten
Fallen Angel
an Old friend/foe
Fallen Angel
an Old friend/foe
Christian Gollwitzer
> I'm thinking of NexTk lately, in addition to my new filesystem, and a
> dozen other things...
>
> I have some design questions, and questions for those of you that have
> tested or want to use NexTk.
>
> For those of you that haven't heard of NexTk before:
> http://wiki.tcl.tk/NexTk
>
> I'm trying to decided whether to seriously replace X, or to focus on
> using NexTk as a portable toolkit that runs under Win32 or X (or MacOS X
> in the future) systems.
>
> The future design involves changes to support this, and I'm not sure
> which direction to go in.
>
> Would you prefer a window system or a general toolkit, or both if
> possible?
>
I'd strongly argue for a NexTk to be a portable toolkit that supports
all major platforms, that is X, Win32 and MacOsX. The reason I like Tk
so much is ease of use, compared to all C++ toolkits I've ever seen its
the most efficient way to beat something together in short time.
However, Tk has some limitations due to its age. From the user side
these changes would appear to be small, but require a heavy rewrite of
the internals. That is transparency, the ability to rotate and scale
images and text, fast image manipulation on a pixel level (photo is
awfully slow), well the things you seem to provide on NexTk but without
loosing the excellent portability, possibility to export to postscript
and PDF (pdf supports transparency) and ease of use. Just bind to the
objects. Most of these wanted feaures are already possible with
extensions, but these are limited to a subset of platforms and/or
functionality, like e.g. postscript export. Your project looks promising
in that direction.
Replacing X does not seem to be useful to me. Using X instead of direct
access enhances portability, I don't want to distribute software only
for specific graphics cards.
Christian