A part of Google Summer of Code.
In case brainstorms strike as this year's projects progress.
These are things that weren't accepted then. See Project Ideas for Google Summer of Code 2009 for full descriptions.
Tcl: Better string sentence and title case handling Tk: Demo Expansion Tcllib: XLS Read/Write Tcl Application Server Tclhttpd: refurbish Tk: Curses implementation of Tk Tk: Factor Photo Image Handling Tk: Icon Themes Gnocl Tk: Megawidget development AOLserver: libpurple integration Tcl[?]: FireFox Scripting and DOM access Tcl[?]: Complete TclScript project for IE scripting Tcl/Tk Browser Plugin: User-Privileged Security Tcl/Tk Browser Plugin: OSX Port Improving dotLRN Tcl: Constraints Tk: Drag-n-drop for Aqua OpenScripting Tcl Glade XML to Tk translator Cicero refurbish
From Things holding Tcl back:
XMLVM [L1 ] is an experimental modular compiler that takes bytecode from various input modules, casts it into a standard XML bytecode format, then retargets the standardized bytecode to various output platforms. Current bytecode inputs are Java, .NET and Ruby. Current outputs are Java, .NET, Javascript, Python, Objective C, C++.
The goal of the proposed project would be to create an input module for Tcl bytecode.
DKF: I don't think this is a good idea. Tcl uses a different model of values and different model of variables to those other languages, so you'd only be able to do the targeting with the aid of a substantive support library…
Its a good time to get involved with Gnocl. The major topic discussed regarding GSOC was the implementation of support from Glade generated XML UI description files. Well, that's pretty well complete now although there are other things worth working on. Gnocl support for native Gnome printing is there but incomplete, support for image manipulation is due for inclusion in the next major release due around Eastertime. Support for Cairo would be a nice project for anyone with the time on their hands. This would allow direct vector drawing onto any GdkWindow. Combine this with the forthcoming feature for the runtime allocation of widget properties for the gnocl::drawingArea widget provides the basis for a nice environment for Tcl/Gnocl megawidget development. Other package 'germs' waiting for TLC are OpenGL via the GtkGlext bindings, webkit and poppler bindings.The broader topic of print support for Tcl, certainly under Gnome, might be approached via the GtkPrintContext .
If some of these project suggestions don't make it into the GSOC programme, no matter, if anyone wants to develop their C/Gtk/Tcl programming skills then they can still contribute to Tcl/Gnocl development.
In terms of cross platform issues, the Gtk packages are available for Window and MacOS. Some help on porting the latest versions of Gnocl to to these platforms would be most welcome.
Tkpath implements path drawing modelled after SVG. It is very flexible and reproduces all standard drawing canvas items. Features include: opacity, antialiasing, gradient fills, affine transformations, and fill rules. Backends include: CoreGraphics on MacOSX, GDI on Win32, GDI+ on WinXP, Cairo on X11, and Tk drawing as a fallback
TkPath is a powerfull, yet not completed, extension to the tk canvas.
It could be an interesting idea to go further in this direction which allow to take advantages of the canvas with the power of TkPath new functions.
PT Since the introduction of the theming engine into Tk in version 8.5 it is now possible to make Tk applications appear native on Windows and MacOSX. This is achieved by having the graphical elements of the Tk widgets (things like borders, backgrounds or indicators) be drawn using the native drawing functions. For instance on Windows XP and above the Tk vsapi style engine makes calls to the DrawThemeBackground() Windows API when drawing so that it always matches the users current desktop.
Unfortunately on X Windows we still have no real idea what 'native' really means. Maybe the user desktop is using KDE, maybe GNOME. There is no reliable way to find out but we can let the user configure a suitable theme using the *TkTheme XRDB resource. What we require to make Tk applications fit smoothly into X desktops is a ttk style engine that uses Qt or Gtk to do the drawing of the theme elements. In fact we do have an early version of this: tile-qt and tile-gtk originally done by G. Petasis and currently make TEA compatible and hosted in git repositories at SourceForge [L2 ] and [L3 ]. Both of these need work. tile-qt is working but incomplete and segfaults on exit. tile-gtk doesn't work at the moment.
A project to get these themes working properly should suit someone interested in Gtk and/or Qt development with Tk and a strong in GUI usability and design. A benefit of getting these working should yield a significant reduction in the amount of complaining from git users on unix that gitk and git-gui (both Tk applications) are ugly on that platform. Both have already been 'ttk-ified' - they just need suitable theme engines to make them pretty and to fit into the modern unix desktop. Ultimately this should benefit all Tk users, including Python Tkinter and any Perl/Tk users out there too.
hat0 Our very own Joe English wrote in 2006, "testing $KDE_FULL_SESSION and $GNOME_DESKTOP_SESSION_ID makes for a reasonable discriminant" for whether or not the user's running a gtk-based or qt-based desktop. quoted from here . So we can make a good guess at what "native" means that covers 95% of *nix users in 2010.
Lars H: Modern font technologies (TrueType/OpenType, SVG, Postscript Type 1) describe glyph graphics by parametrising the outlines. There are however at least one older font technology (MetaFont) and certainly many scripts (e.g. Chinese/Japanese/Korean) that rather view glyphs as composed from a number of intersecting pen- or brush strokes. A naive approach to generating glyph outlines would be to first parametrise the outline of each stroke in isolation and then compute the outlines of their union, but this has turned out to be difficult; the equation systems one has to solve are highly nonlinear, and often ill-conditioned, resulting in numerical instability. An alternative approach is to start with a 2D analogue of intervall arithmetic, and first describe the individual strokes using inner and outer bounding polygons. From computational geometry with these it is possible to compute the outline topology and also get a good approximation of which part of which stroke determines which section of the combined outline, thus avoiding most of the ill-conditioned problems.
A good first step towards realising the above programme would be to create a package (in Tcl, possibly later with some C accelleration if necessary) for computational geometry with polygons in the plane (probably through translation to the dual problem of arithmetic with circulations on geometric graphs) that also admits tagging vertices with information about "what gave rise to them". Such a package would be useful also for other things (polygon intersection being a trivial example).
Benefit for student: Learn about computational geometry, some graph theory.
Benefit for Tcl: Get a code library capable of computing with polygons.
SEH: Right now, memory allocated by the interpreter for Tcl objects is reserved for recycling after the objects are destroyed; the memory is never freed until the interpreter exits. This is fine if the volume of data your program handles is low and steady for the life of the interpreter, but if the program handles spikes of data volume, a very large percentage of the computer's RAM can be stuck in a reserved state: neither in use nor available for use by other non-object-creating actions of the language, not to mention out of reach of all other processes on the computer.
The objective of this project would be to write a garbage collector for Tcl objects. Memory reserved for Tcl objects would be periodically examined and excess memory freed. This would lead to Tcl making more efficient use of computer resources, this efficiency would complement Tcl's other strengths: its otherwise superb stability and economy.
A general discussion of the problem can be found here , and some proposed solutions are here .
Benefits for the student: learn about memory management and garbage collection, one of the most challenging fields for programmers.
Benefits for Tcl: Tcl would become more usable in a wide range of demanding usages, in the coming era of terabyte-scale data sets. Since just about all of the major dynamic languages suffer from similar limitations, Tcl would instantly distinguish itself as the superior choice in this field.
AM Mathematical expressions like those parsed by the [expr] command are not easily manipulated via Tcl commands. What I mean is, if I want to use complex numbers or add support for array expressions (see TIP 363 ([L4 ]), I can do that via Tcl's prefix notation:
set sum [+ $op1 $op2]
or
set dotp [inprod $vector1 $vector2]
That is okay for simple expressions, but when things get more complicated, like:
set diffusion [expr {$diff*(2.0*$conck - $conckm1 - $conckp1)/$deltx**2}]the prefix notation is cumbersome:
set diffusion [vecmult $diff [vecdiv [vecsub [vecmult 2.0 $conck] $conckm1 $conckp1] [expr {$deltx**2}]]]My idea is to make a small extension to convert expression from the mathematical infix notation to Tcl's prefix automatically. I currently have something that almost does the job, but it is still a fair amount of work to make it practical. You could even add extra functionality here, like the introduction of custom operations.
Benefits for the student: learn about parsing.
Benefits for Tcl: more flexibility in mathematical/physical applications.
Lars H: This is not so far from what the infix package does already, but I suppose you might want the extra speed of a C-coded parser (and a slightly nicer calling convention). One thing I've thought about is relation to these things is that one could make it possible to stash parsed/translated/compiled forms of expressions within the intRep of the Tcl_Obj of the expression, like Tcl does with its expressions. Or rather, I've though about whether it would be possible to expose such functionality at the script level. Currently infix stashes its "compiled code" in an array instead, which is a major reason why the calling convention is unintuitive…
AM As mentioned on the Tclode I have been playing with the idea to wrap a lot of existing numerical libraries (some written in the venerable FORTRAN 77 programming language, others in C). For C we have Critcl to facilitate the wrapping, for FORTRAN we can use my Wrapfort (in my ftcl project on SourceForge [L5 ]). The problem with many of these libraries is not so much the wrapping in itself, but the design of the interface.
For example, wrapping the LAPACK library (see wrapper extension for LAPACK) is a lot of work because there are so many routines. However, a lot of it can be automated (I have done that part already). The next step is to make the interface Tclish enough: The routines require the dimensions of arrays to be passed explicitly. If you map Tcl lists to arrays (or use byte arrays for efficiency), then the dimensions can be deduced from the data. So the interface exposed by the wrapper can be simpler.
A second part of the work is to package the source code with appropriate make files