MDL I would like to be able to tie scale widgets to scrollable widgets the same way as it's usually done with scrollbars. Now it's not possible.

GPS See Scrolling Widgets With a Scale

27. Compatible way to get scrollbars on canvas and text automatically (Roy T)

DKF: Why not also for listboxes and entries?

28. and 43. (dup) - Enable a frame to scroll; the put-it-on-a-canvas trick is truly tired and annoying (Roy T)

DKF: Peter Spjuth has some ideas about allowing the grid geometry manager to work with scrolling. There are aspects to this that I don't fully grasp. See Possible Grid Enhancements.

Mark G. Saye in comp.lang.tcl wishes for (and is working on - See eWidgets Toolkit):

Text widget enhancements

Read-only text widget is one wish I have seen elsewhere on the wiki...

FW: -state disabled is and has been the official solution to this, no? It was written for that purpose. I'm still confused as to why that page exists. Other than the lack of a flashing position cursor, and a now-fixed (and workaround-able) focus bug on Windows, it's identical to the proposed solutions there.

slebetman: -state disabled is not the same as -state readonly. Disabled means the text widget can't be written to while readonly means that the text widget can't be written to by the user - big difference if you've ever tried to use disabled to emulate readonly. And please, don't change the behavior of disabled to do readonly because they both have different semantics and are both useful in different circumstances.

Larry Smith Isn't this otherwise known as a "label"?

Print-option for text widget AM

'''Text Widget accepting html-style markup for normal formatting. This will enhance the compatibility of the text widget with the html world, and make it easier to save and restore formatted text in a standard format, which the text widget currently cannot do, since the formatting information (the tags) are external to the flow of text. I don't think full html is necessary or desirable, I'm talking things like <i>and</i>, font changes and so forth - all the basic nitty-gritty that html now stuffs into CSS, but which is massive overkill for just having some nicely formatted and justified text.

These should be pretty self-explanatory. There are three things required:-

• Background images (eg; GIFs and JPEGS).
• Background images with transparent pixels.
• Totally transparent backgrounds.

Although the TEXT Widget is the main target for these, they should really be applicable to ALL relevant widgets. In other words, the standard -background option should be enhanced to provide all those alternatives.

tonytraductor I second that. I would like either a transparent (configurable -alpha) text widget or be able to configure a -bgimage (with configurable -alpha) to be able to create an ascii art creation tool.

reh This capability would advance the use of TCL/TK in the e-learning marketplace where 'hot spots' and overlays are used extensively.

66. wdb -- The text widget should handle the soft hyphenation character in word-wrap mode like a word processor as follows:

1. Inside the line, it should not render.
2. It should be treated as wrapping char as well as space
3. When word-hyhenating, it should render as hyphenation character (-).

I've not yet thought of the consequences, possibly it is necessary to make this behaviour switchable.

bll 2016-11-11 This is the subject of ticket: http://core.tcl.tk/tk/info/1096580fffffffff . It is currently working on Windows and Linux, but not quite on Mac OS X. It might make it into 8.6.7 or 8.6.8.

bll 2017-1-19 See also: http://www.unicode.org/L2/L2002/02279-muller.htm#4 Hyphenation is different for different languages. In some cases the spelling may change.

FM: possibility to synchronize automatically peer texts widgets (ie, the text at the end of the first peer continue at the beginning of the second peer etc...).

With this, it would be possible to do easily :

1. float-like layout (an image at the left of a text which has the same height than the image, then we can puts a peer below the image and the text)
2. multicolumn layout (the end of the first column continue at the beginning of the second column).

Canvas widget enhancements

Shaded triangles in the canvas (so that it becomes easier to have colour gradients) AM

CME: 2Jul2003 TkZinc or Zinc a canvas-like implements triangles item (requires openGL)

74. wdb I'd like the canvas to anti-alias its contours. I know that the zinc does already, but canvas should do it, too.

DKF: It does it on OSX.

GPS I want the ability to draw clipped fonts. Tk currently seems to lack the ability to use the clipping abilities provided by the X font mechanisms. I'm not sure how to implement this change in Tk though.

DKF 07-Aug-2012: The low-level capabilities are now there (they were needed for fixing a bug in Ttk) but aren't exposed to scripts. Be aware that setting a clip in the GC is not enough; that only works in Win, Aqua, and old X11 font engines, but with the new X11 font engine you have to call TkUnixSetXftClipRegion(TkRegion r) (which will then use it in that thread until you call TkUnixSetXftClipRegion(None) to restore things to unclipped); availability of the internal API needs to be guarded by the HAVE_XFT macro.

We probably ought to clean things up here, but it was good enough to make things work. See generic/ttk/ttkEntry.c for how to use it, and unix/tkUnixRFont.c for how it is implemented. (The problem is that Xft does internal management of its own GCs, and you can't easily copy the clip from an existing GC.)

GPS I want to be able to draw things on the canvas using different GC function attributes, such as GXclear, GXor, GXxor. This would be incredibly useful for the text widget as well. How would this fare across platforms? Does Windows provide something similar in device contexts? How about MacOS X?

Lars H: If by this you mean "drawing modifies (rather than replaces) the pixels" (e.g. foreground xor foreground becomes background) then this was available already in the oldest QuickDraw (MacOS Classic). Hence MacOS X should support this too.

GPS An XDrawLine type of command would be useful. It's limiting to only be able to draw lines on a canvas. This can be faked by placing colored frames, but it seems hackish.

Froggy More about drawing lines on widgets If you look at the Forte for Java IDE, one of its features is it draws a line at the 7.5" margin in the editor. I think it would be a nice extension to the text widget if it could have a "canvas-style" background, allowing developers to provide users editors with margin lines, or even just a snazzy watermark. I am struggling with a platform-independent way to do this now. #ifdef WIN32 anyone?

See Images behind text.

GPS Pixmap rotation at the Tk C level.

Something like

Tk_RotateAndCopyPixmap(pix, &newPix, gc, &width, &height);

This would make it easier for extensions to rotate text and images.

CME: 2Jul2003 TkZinc or Zinc a canvas-like can rotate icon item which could display a pixmap (requires openGL)

DKF: Even rotation of photo images would be nice. You can do it in pure Tcl (see photo image rotation) but it is slow and there are unpleasant edge cases, especially with non-rectangular images.

CME: 2Jul2003 TkZinc or Zinc a canvas-like can rotate icon item which could display a photo image (requires openGL)

DKF: Not acceptable for what I was thinking of at all. That only rotates the display, not the image data itself.

Clipping rectangles or regions in the canvas

CME: 2Jul2003 TkZinc or Zinc a canvas-like implements such clipping

KPV Flood fill on the canvas. I've composed an object out of arcs, splines and lines and I'd like to fill it with certain color. If I could read individual pixels I could write the algorithm in tcl.

DKF: The canvas isn't meant to work that way. It's not a area you can paint on, but rather an area where you place geometric items (and semi-geometric items like text, images and windows). A way to paint on a photo image (or a new image type) might be nice though.\

KPV: Just because the canvas designed that way doesn't mean it can't be extented to do so. The problem with extending image to allow painting is that you'll also need to extend it to allow you to draw geometric items and then semi-geometric items and next thing you know you've reinvented the canvas.

Alternatively, how about allowing for the intersection, union and subtraction of items. For example, a crescent moon would be the subtraction of one circle from another. The sail shape in tkGoldberg would be defined as the union of a circle and rectangle with another circle subtracted from it. (NB. union differs from just tagging two items with the same tag because the outline would be different.)

DKF: That's more of the idea of some kind of general path item (to use the PostScript terminology). It'd be nice to have (and compatible with the canvas's conceptual model), but tricky to actually do. Still, if someone wants to write the code, I'd be happy to vote it into the core! :^)

CME: 2Jul2003 TkZinc or Zinc a canvas-like implements most of the above wishes: multicontour curves with fill-rule attribute, combination of bezier and straight lines in a curve contour (but not yet arc segment)...

DKF: You can also get a lot of this with a standard line or polygon item with -smooth enabled and intelligently chosen control points.

David Easton: Alpha transparency support in the canvas (why stop there?!) would be nice so that photo images specifying RGBA (such as data from PNGs) could be overlaid to provide shadows, for example.

DKF: I'd love to see this, but I worry about rendering on 256-bit displays (which some of us still labour under, alas.)

CME: 2Jul2003 TkZinc or Zinc a canvas-like implements alpha transparency (requires openGL)

FW: I brought up this idea in 22.

TR: Tip 244 is about transparency and png.

• DKF that is implemented in 8.6.

DKF: We now do alpha blending of images. Not sure that performance is perfect yet. No alpha blending of anything else on the canvas though. Note: The canvas is antialiased on OSX.

ZB 2009-04-14 I'm not sure, whether it is covered by mentioned "Alpha transparency support in the canvas": it would be nice to have translucent "canvas windows" - f.e. to place onto canvas a text labelframe, that won't cover the chosen part of canvas area completely (like having "glass labelframe"), or "transparent button" and so on.

Update current tag in all circumstances, i.e. also when dragging.

(see bug http://sourceforge.net/tracker/index.php?func=detail&aid=2543460&group_id=12997&atid=112997 )

DKF: The “current” tag behaviour is not a bug; it's designed that way. I don't see what the link has to do with it.

FF: Ooops! Link corrected. It is an issue, and there is a considerable amount of tcl code needed to workaround it. And isn't this a wishlist? :-) Btw, why that bug has been put in Group: obsolete: 8.5.6? What does that mean?

FM : Some various geometry manager for canvas.

Since a canvas is a place where to draw things, it should be interesting to have some geometry managers to be able to dispose items more easely (in Inkscape, the objects can be aligned, ...). Actually objects are disposed like the place algorithm. pack-like and grid-like algorithms could be added (restricted in some regions). Other interactions and dispositions are possible like Attracting objects on the canvas. But as it depends on the "logic" of the drawing which is done by the developer, a way to create some specific geometry manager, should be good.

A layer concept could be introduced, so that on each layer, we could use a different geometry manager.

FM : Align canvas on tkpath so that it can handle new items type, handle transparency, with svg-like options and svg-like concepts (gradient, ...)

beware (Not entirely sure how the numbering system is working for this page now....) :

Rotatable ovals. extend canvas create oval x1 y1 x2 y2 to allow canvas create coords list where coords list can define any quadrilateral - the oval would then be (possibly not oval if the coords aren't rectangular) rotatable. It could also provide a way to create interesting shapes easily.

Canvas view zoom. Add a 'canvas zoom' command, so I don't have to manually keep track of the scale when inserting new objects. The canvas widget could have it's own view port commands.

Texture from photo. (I haven't researched - this may already be possible). I'd like to use something like canvas create ... -fill white -texture image create -file somepicture.gif

gold Group text and drawing objects on-top ovals and rectangles for game tokens and common movement on canvas. There are examples on the tcl wiki in domino and A crossword game.

RLE (2011-07-09): This request would appear to exist in the current canvas feature set. Note from the canvas manpage:

 pathName move tagOrId xAmount yAmount
    Move each of the items given by tagOrId in the canvas coordinate
    space by adding xAmount to the x-coordinate of each point associated
    with the item and yAmount to the y-coordinate of each point associated 
    with the item.  This command returns an empty string.

So simply give each set of grouped items a common tag value that is unique to the set as a whole. Then when the "set" needs to be moved, use the tag value as the "tagOrId" operand to the canvas move command and everything moves as a group.

rattleCAD 2015-04-20: I'd like to have

• antialiasing in canvas
• full svg support as it is currently available for postscript-export
• just a wish: "0/0" in bottom left instead of top left as option to use as CAD-Canvas

bll 2015-09-04:

With the advent of 4K screens and other high resolution displays, making scalable graphics becomes much more important. Converting the canvas to be SVG underneath would seem to be advantageous.

bll 2015-09-17: Moved from Tcl 9.0 wishlist

bll 2015-9-04:

Enhance the theming engine to use SVG for displaying buttons, arrows, and gradients for the widgets. New themes would be easier to create and support. They would scale properly for the high variance of screen resolutions that are out nowadays.

• Rounded rectangles
• Rectangles
• Circles
• Text
• Triangles
• Lines
• Textures: Crosshatch, Lnes
• Fills: Gradients, Basic

bll 2015-9-17: Moved from Tcl 9.0 wishlist.

    To simulate the "3D" tilt of a geographic map, for example.

Other existing widgets (not text, canvas) enhancements

GPS - I would like a menubar that by default allows movement of the entire menubar to any side in the window.

For example I would like the following code to allow movement of the menubar:

 menu .mb
 . config -menu .mb

DKF - ? Menubars are not supposed to be moveable for good reason. It is toolbars that are supposed to be moveable, and even then not on all platforms (have you seen RiscOS in action?)

GPS - I think that it would be nice to have menubars and toolbars that are moveable. I would prefer to have my menubar at the bottom or side of a window rather than at the top. Giving the user a choice is a good thing IMO.

DKF - User choice might be usually good, but in the case of menubar positioning, no, don't do it. They're not effective at the side of a window anyway, and nobody puts them at the bottom. Some platforms won't support the feature anyway, and you can cobble it together from menubuttons and a frame anyway.

MGS - Menus at the bottom of the window do make sense for PDA/handheld devices (so your hand doesn't obscure the screen when using the menu).

GPS - STk [L1 ] allows a menubar to be moveable to any side of a window (by default), so I thought it might be a nice feature for Tk 9. BTW DKF, I have seen screenshots of RiscOS. Is there something special about the way that RiscOS deals with menus?

DKF - RiscOS is a very different take on the general concept of a windowing system, and all the users of it that I've seen have been very productive with it (or at least gave that impression to me at the time.) The problem is that screenshots don't give the real feel for how it works at all. (Do macs allow the movement of the menubar to other screen edges? Your ideas for menus are certainly not in line with the general concept on that platform.) The majority of X toolkits draw their roots in the IBM CUA work of the 80's (?) and Windows is another descendent. MacOS has quite different parentage, and RiscOS is different again.

IMHO, a good GUI designer will have seen all these things in action so that he can at least appreciate just how different graphical environments can actually be. It stops them from assuming that their particular prejudices represent the only way that the world can be arranged (always a good thing!)

KPV - Joel on Software [L2 ] has some comments about moveable menus in his essay on user interfaces.

FW: Tk makes use of its platform's native menubar functionality. Few interfaces other than a few X window managers allow menubar moving by default, so you'd have to write custom menubar code using something like the officially deprecated menubutton method that was used in Tk for about a decade before the current way was introduced, with bindings for dragging the window to a different side. Special-interest, implementable perfectly well in Tcl, incompliant with the normal method, non-native style - would make a good megawidget at best IMO.

Menuitems that are both command- and cascade- items. They look something like this:

 +--------------------------------------+
 | pixmap  Item-label              | [> |
 +--------------------------------------+

If you click on the pixmap or text, the action is invoked. If you click on the little triangle (righthand side of item), the cascade-menu is popped up. For keyboard-navigation: If you press Return the current action is invoked. If you press Right, the cascade-menu is popped up.

  + allows more concise UI (imho)
  - may be difficult or impossible to do on platforms that do their own menu-handling :-(

FW: See my comments on 6. Your (whoever you are ;) ) negative is a big one. I'm not sure there's still a major platform Tk's on that doesn't do its own handling.

DKF: It would be nice to have that sort of thing for toolbar buttons, where the idiom is now quite well known.

FW A way to specify text-filled label and button sizes in pixels, maybe a -pixelheight switch?

MGS - A quick workaround is to use 8.4's -compound option with a null image:

   set image [image create photo]
   label .l -text "Hello World" -image $image -compound center -width 100 -height 50 -bg yellow
   pack  .l
   bind  .l <Destroy> [list image delete $image]

Donald Arseneau: Selection of text from label widgets. I wind up abusing text or (disabled) entry widgets for labels just to allow text selection. (Maybe this could be pre-9.0?)

DKF: Selection of the entire text of a label is fairly easy to do; you just need to write suitable selection handlers. The awkward bit is handling the display aspects. Still, this is fairly easy if someone wants to do the work.

See: label selection

MGS [2003/09/06] - I'd like to see listboxes be able to display images. This encroaches (slightly) on the territory of multi-column listboxes, but it's really more like labels with a -compound option. Images should be on the left (since text can only ever be left-aligned). I'm not sure what should happen for listbox entries with different sized images. Hmm. Maybe just clip images at a certain size? 16x16? Have a -iconsize/-iconwidth/-iconheight option?

FW: If there's something pivotal about all the entries being the same height, I'd just have all the entries grow to match the largest image.

DKF: Or you could clip to the height of the font (well, the interior size of the row which is governed by the height of the font.) Only thing to choose at that point is whether the image should be clipped centrally, from the top or from the bottom.

MGS - I presume that all listbox entries must be the same height. If not, then we should be able to entryconfigure -font and such like. I agree with FW that, if all entries must be the same height, then all entries should be set at the largest height. Different sized entries would be nice, though.

FW: Besides, I don't actually know that they have to be the same height - the listbox is built on the same code as the text widget internally, right? (DKF: Wrong. Alas.) And that can support different line lengths, obviously.

I am using tk_getSaveFile to save the content of a text widget to a file. I'm on Windows and tk_getSaveFile saves the file with LF/CR (DOS) line ending. What if I want to save the file with LF (Unix) line ending? It seems there is no such option.

DKF: In fact, tk_getSaveFile doesn't specify the line ending at all. Instead, this is something that is configurable from the Tcl level via the fconfigure command, and especially the -translation option. (Request Ignored as Invalid!)

UKo: not so invalid on second sight. Maybe the fileselector can provide more information than the filename(s)? Now it is possible to include the fileselector in a container. But then you must manage a whole new window. What about making a user definable area (or more than one) inside of the fileselector? And embedding the system one into a tcl window can make custom widget in there, too. This may be useful for extra options like setting the Lineending or picture or sound previews or file informations. (But to provide this information one needs callbacks from the fileselector and I don't know if the system fileselector give this informations)

DKF: No chance. Anything involving tk_getSaveFile has to be portable to Windows and MacOSX too. Adding extra bits to the window... That's sufficiently non-trivial that I'd suggest just copying the code out and reimplementing instead.

SLB: This seems similar to TIP#67[L3 ], which does also discuss the approach for Windows. It does seem to be quite common for Windows apps to have an extended save dialog.

DKF: That TIP was withdrawn on the grounds that there's no way to make it portable.

Formatted Entry eg. "9G999G999D99-", I'm not satisfied with the current "alternatives" , Entry should handle this on its own. HolgerJ: - I would like to have a placeholder in entry widgets, just like the ones in HTML5. The placeholder shows in grey and automatically disappears as soon as the user makes some input. When all input is deletet, it shows again.

MaxJarek: - I would like to see transparent -bg color for label. This is needed for good-looking labels on gradients

MaxJarek: - I would like to see gradients as -bg option for frame, text, ...

Fabricio Rocha - 13 Feb 2011 - I wonder why there's nothing here about this so popular feature request (if it is a dreamers wish list, why not make a try?). So I throw a coin to the fountain and wish that ttk::notebook had some extra options:

-tabsposition n|s|e|w- Where the line of tabs will be placed around the notebook's page frame. (RLE (2013-09-24): Already present as the -tabposition option to style configure.)

-tabscroll boolean - If the value is true, the line of tabs will receive a pair of scrolling buttons whenever the number of tabs become larger than the widget's size would be able to display entirely.

-closebutton command - Tab option. If present, adds a "close" button to the tab, and associates command to it.

tomturkey- 13 Dec 2013 - Currently one has to delete and insert to change an item in place. But this moves the list in the window if the last item in a long list (longer than the window) is being displayed. To keep the window position one must use yview, but only after 'update'. This introduces jitter. A replace option should be able change and item in place without jitter.

RLE 2013-12-13: Use the -listvariable option to listbox and the lreplace command.

Try this in a wish shell (you need to do it in a shell to see each command in action as it happens):

 listbox .lb -listvariable lblist -yscrollcommand [ list .vsb set ]
 scrollbar .vsb -orient vertical -command [ list .lb yview ]
 grid .lb .vsb -sticky news
 for {set i 0} {$i < 40} {incr i} { lappend lblist $i }

You should now have a listbox filled with 40 elements. Using the scrollbar, scroll the listbox so that element "38" is at very bottom of the window, with element 39 invisible below the window bottom. Now, type in this command, it will replace elements "38" and "39" with three new elements:

 set lblist [ lreplace $lblist end-1 end "Visible" "Not Visible 1" "Not Visible 2" ]

On my system (Linux, using Tcl 8.5) I see item 38 disappear, item "Visible" appear, and items "Not Visible 1" and "Not Visible 2" out of view below the bottom of the window. I.e., the listbox position did not change. If I scroll down, the two invisible elements become visible.

tomturkey Yes, I agree that is the way it works, but now try this: select an item in the list box and then delete that item in the listvariable. What I see is that the selection shifts to the next item. In fact, it seems the selection hangs on the item number so deleting (or inserting) an item in the listvariable will shift the selection. On the other hand using the widget insert/delete the selection stays with the item (and not its place in the list).

My current solution is to use the wiget commands to insert and delete and the listvariable to update and item. I am using this method to update file directory lists on inotify notifications (see sourceforge.net/projects/filerunner).

RLE (2014-03-02): Indeed the selection does shift to the next one - although actually what happens in the next fills in the slot left open by the one deleted.

In all fairness, however, your original suggestion was about the scroll position of the window shifting, not about the "selected" element moving around. So this is a different issue than your first submission. Your current solution is probably best for now, given that there is not a "replace" subcommand (yet).

NEW WIDGETS

- now split into subcategories

• Basic widgets - not toplevel dialogs or implemented megawidgets
• Requests to standardise or include in the core something that has existing megawidget implementations
• New toplevel dialogs

Basic Widgets

that are neither toplevel dialogs nor implemented megawidgets

Moved to Hyperlink widget due to length.

GPS - I would like a roller widget that is similar to the Fltk [L4 ] roller widget.

DKF - http://www.fltk.org/doc/Fl_Valuator.html includes a picture of one. And I think this is better done with an adapted canvas...

Schlenk - http://www.fltk.org/documentation.php/doc-2.0/common.html#4_3 has the picture now, the above link doesn't work anymore.

AMucha - http://www.fltk.org/doc-2.0/html/fluid.html has a picture now, the above link doesn't work anymore

CLN - Can someone tell me how a roller widget works? How a user interacts with it? How it's different from or preferable to a spinbox or scale or whatever? The screenshot really doesn't do much in that regard.

GPS - It acts like a wheel that can be rotated to change the value of a variable. It is similar to the Tk scale widget.

CLN - So, to interact with it, a user clicks (to "grab" the wheel), then drags to "rotate" it? To move a large distance, you'd click, drag, move back, click, drag, etc. (kind of like moving a mouse on a small pad to move across a big screen)?

GPS - Rollers that I have seen allow clicking the wheel and dragging past the edge of the widget, and they still continue moving as long as a mouse button is pressed. Most modern toolkits have something like a Roller. I believe that the idea originated from SGI.

CLN - That sounds like a great way to manipulate something that isn't bounded like scrolling a calendar.

MG See Another dials widget.

DKF coalescing from elsewhere on this page...

• An OpenGL widget that supports 3D.
• An OpenGL widget that supports 2D only (a fancier canvas). Perhaps based on Zinc.

Desirable sub-features:

• Rotation of items
• Transparency/alpha-channel for items
• Splines (Q: How does the -smooth option to line/polygon items not approach this?)
• Clipping
• Complex fills (e.g. gradients, images)
• General paths (though current line/polygon items are very close to this)

These features are also requested elsewhere here, and may also be desirable whether or not we add OpenGL support in the first place.

GWM 26 Oct 2004 An openGL canvas is all that is really required. There are many OpenGL projects such as [L5 ] which produce really high quality, fast graphics but could use a good Widget set and scripting language to control it. I have built into an OpenSceneGraph [OSG] application a Tcl event handler which works well but needs some C++ code to interact with the OSG core. The OSG window is a separate window controlled by the Tk widgets; an embedded canvas for OpenGL such as togl is useful; however togl has proven a little jerky when windows are resized. Then some commands to generate OSG scenegraph nodes [insert own favourite OpenGL scenegraph here] could be built as an add on library or two in future.

previous discussion follows

GPS - An OpenGL widget included in the standard distribution is needed. It should allow creating OpenGL objects from a Tcl script. Perhaps VTk [L6 ] could be used as an example of how to do such a thing. Note: I'm aware of two extensions that provide OpenGL support, but they aren't quite what I think we need.

DKF - And on the fair number of platforms without OpenGL support...?

GPS - What systems don't have OpenGL support? Almost any system with X can use Mesa with software rendering. There are a fair number of systems that don't have hardware accelerated OpenGL (including mine), but that doesn't mean that it's of no use. Perhaps Tkogl [L7 ] by Claudio Esperanca should be the standard interface to OpenGL from the Tcl/Tk core because of its public domain licensing. FOX, FLTK, and EZWGL all include an OpenGL widget that works with both software and hardware accelerated rendering. Also Windows has an implementation of OpenGL, which is used by Quake 3. Am I missing some vital reason for not including OpenGL support?

DKF - I have no idea. But that's beside the point. I don't want to make Tk significantly more difficult to build than it is at present (there's enough build problems as it is.) On the other hand, I've absolutely no objection to having an OpenGL widget as a contributed package in some sense. Contributed packages is something that Jeff's been talking about for a while. (Is there a TEA2 OpenGL widget package out there anyway?)

CME: 2Jul2003 TkZinc or Zinc is an openGL canvas, but limited to 2D. Sorry I could not say if it follows the TEA2.

TV Just as a quick remark from glancing over the page: OpenGL may itself be about as big or more as Tcl/Tk in terms of executable/library size, though I didn't check. I recently built glut examples (the most recent openGl/Mesa application layer interface standard) on RedHat 9 on a machine with 3D graphics card, and got it to get supported, which is all very nice graphics, but a overall project of software size of the order of the whole of tcl/tk. Of course one could make the library bindings available, and link to an OS supported api, but that still is pretty big a binding.

And remember that tcl/tk nicely runs on a lot of platforms, including some small/slow ones, and contains graphics and utilities to make the reasonable. Even a 2D image rotation takes quite some processor cycles on unpowerfull systems, comparitively speaking.

I agree though that gl is a de facto standard enough on various modern OSes, though I'm not exactly sure on the practical status of all that: XFree86 can be made to allow acceleration with it, and I think I saw that on XP, too, but than the openGL library version is also important. Unix workstations should be fine, as a software version I compiled and ran the whole openGL suite from that time without effort 7 years ago. I remember that some years ago (when I happened to work on G3's) that the next generation of Macs and os9 or x where supposed to get native opengl support, too. But I'm sure most handhelds and such will not, for some time to come.

When it concerns a subset of opengl, many things go, there are many ways to do decent/fast/professional/useful 2D graphics. There are less ways to do that potentially accelerated in a portable way, but on modern machines, that also is less relevant, see some recent pages on doing such things even in tcl (which is like orders of magnitude away from C speed in the area). OpenGL (on the original Silicon Graphics machines) was primarily popular for its 3D stuff, which is by nature computation intensive, and a pretty bulky library, and also arguably not the best, though I'd say probably the most popular, widespread, and at least fun enough.

DKF: Zinc is GPL and thus impossible to integrate with the core.

DKF: Correction: It's LGPL. Integrating with it is still tricky, but might be possible after all.

MH: ToGL [L8 ] is a goog starting point. It lacks Aqua support though.

GJP: We also built an OpenGL tk canvas which basically only replaces the rendering engine from XWindows to OpenGL with no fancy extensions other than adding transparency to canvas items. We wanted to keep it entirely compatible with the original Tk canvas but be able to create new OpenGL items for the canvas which can be hardware accelerated. This is how we built our virtual globe/GIS tool [L9 ]. I just ported it to tk8.6. It currently runs only under XWindows but it should be fairly simple to make it run under windows and OSX. if interested I can provide the code.

RZ Could you please give some more information about performance, printing (postscript) and license or the code :)

GJP: Performance mainly depends on your graphic hardware/drivers but it's quite respectable, as for printing, it uses mainly what's already done in the regular canvas but transparency is not supported. Whatever other item you add to the opengl canvas has to provide it's postscript method as we did with our virtual globe item. You can also grab the canvas into a tk image. I'm in the process of making it TEA compliant and I'll post it once done.

GJP: I have built our TkglCanvas [L10 ] with the latest TEA specification. It still needs some tweaks on the memory management of bitmaps and fonts but you can have a look at it if you are interested. The license is currently LGPL.

CME suggests (2Jul2003) : add TkZinc also known as Zinc:

1. Because it seems interesting by itself as an evolution of the canvas
2. Because it offers solution or partial solutions to many many previous wishes:
   • it offers openGL support for 2D only (suggestion # 7)
   • it could offer rotatable text (suggestion # 14), this is still to be done, but should be easy to implement when openGL is available
   • it does rotate images or photo with openGL, (suggestion # 19)
   • it does offer alpha-transparency for items (assuming you have openGL) (suggestion # 22 and # 38)
   • it does offer an easy way to use the X SHAPE extension to draw non-rectangulare windows, which can be holed. (suggestion # 22) SHAPE does not work with every windowd manager and is not available on Windows.
   • it does offer cubic bezier (combined with line segments in the curve item) (suggestion # 26)
   • it does offer named color (called named gradient, because every color can be a gradient) (suggestion # 30)
   • it does triangles item to fill a surface with openGL triangles and gradiated colors (suggestion # 33)
   • it does offer clipping of items through complex form such us curves, with multiple contours, bezier (suggestion # 34)
   • it does offer curves which can combine cubic bezier and line segments in one contour. curves can be multi-contour and fill-rule option caz be used to combine multi-contour curves (suggestion # 36)
   • it does display png images with alpha-transparency (suggestion # 38)
   • it also offers line anti-aliasing (requires openGL), group items...

FW: It's also not available outside of UNIX...

FW: My bad, seems the new version works on Windows (and with some hacking it presumably works on OS X anyway).

DKF: Shaping of internal windows can be supported without regard for the window manager. That's one reason for having internal windows! Any window manager that can't handle non-rectangular windows has a bug (which should be reported to the maintainer of the window manager; complain about their poor handling of the vital X applications xeyes and oclock!) And Windows does support shaping of windows; just not with the same API as X (as you'd expect knowing Redmond...)

DKF: The point has been made that the main problem is that porting anything based on OpenGL to a low-resource environment (e.g. handheld/palmtop) is going to be really difficult.

DKF: Zinc is GPL and thus impossible to integrate with the core.

DKF: Correction: It's LGPL. Integrating with it is still tricky, but might be possible after all.

RM: A canvas with grid

DKF: What exactly do you mean by this?

RLH: I can only think he means a spreadsheet type widget.

DKF: Like tktable?

put tktable into the core?

DKF - Is that to be as an integrated part of the core or as a contributed package?

DKF: IS this a duplicate of item 23?

FW: Fat chance ;)

DKF: TkHTML already exists. Don't know how good it is. Don't know how easy it is to build. Don't know if it could ever be an option for anything other than a batteries-included distro (like ActiveTcl.)

FW: Tkhtml is limited. It's slow and only supports HTML 3.2 at best, without frames. BrowseX extends it into a passable HTML viewer, though. Overall, Tkhtml claims to be fast but image loading seems to really slow it down. If you're developing Windows-only, you may want to just use optcl and any browser that provides a COM interface (COM on! - a tiny web browser)

DKF: ISTR that someone was working on an update.

NEM: A couple of times recently I've wanted something like a cross between the canvas and text widgets. For instance, when creating an editor, it was a natural choice to use the text widget. Then at one point, I thought "wouldn't it be cool to have a thin vertical line after the 80th column?". It was a nice idea (and is quite a few programmers' editors, particularly those in IDEs), but seemingly impossible to do with the stock text widget. Another area was work I am currently doing on a CSS parser, and playing with rendering XML into a widget. Again, the text widget has great text editing abilities (I wanted editing), but can't support the CSS box model, and the non-text oriented features (borders, floating images, columns, tables, lines etc). So, what would be super-cool would be some widget which combined the text and canvas widgets into one all-powerful mighty-widget. Oh, and if it was designed around an MVC pattern, that would be very useful too, so you can separate the data model from the presentation (for instance, having an XML DOM tree as backend, instead of Tk's b-tree). A huge amount of work to do, but it would be a real killer widget.

AM Here is an experiment with A vertical line in a text widget. Not quite the real thing, but it may be a workaround.

FM The problem is that in A vertical line in a text widget, the line hide the text which stay behind it. It's seem be cause by the place algorithme. Change the text widget so that it "knows" that there is something above and draws its text around ?

I proposed upwards to add some geometry manager in canvas to dispose drawings and I propose too to be able to synchronize peers text widgets. So, a canvas in which we can create any synchronized peers text we wants, and dispose them efficiently in the canvas, is'nt it what you need, NEM ?

NEM: Not so much a new widget, as access to new types of widgets. For instance, on Mac OSX there are various different window types (help windows, drawer windows, etc). Some of these are available through the ::tk::unsupported::MacWindowStyle command, but it's somewhat clumsy to use, and people who don't develop on a Mac tend to not know of its existance, which usually means that some porting work has to be done to get a Tk app looking and behaving right on OS X. It would be nice if this could be somehow generalised and moved into the wm command or the toplevel command or somewhere similar. I'm not sure how well some of the concepts map on to features available on non-Mac platforms, though. For instance, there's really nothing like drawer windows on Windows or X11 that I've seen - the nearest thing might be a panedwindow.

lm As memtioned in https://wiki.tcl-lang.org/37973 ttk::combobox styling still needs the option database to set up some options. Font setting through ttk::style also fails. It would be great to have a coherent way to set up this widget instead of joggling between ttk::style and option database.

bll 2015-09-17 Essentially this is a request for ttk::listbox. Supposedly ttk::treeview can do this, but I've never tried that. Can a ttk::listbox be written that would leverage ttk::treeview?

Also, ttk::combobox can return the popdown widget with ttk::combobox::PopdownWindow, but then to style the individual listbox, the programmer must know to append .f.l. It would be better to have a ttk::combobox::Listbox routine to return $popdown.f.l

And now since ttk::combobox has leveraged listbox, all the code out there assumes listbox. So to preserve backwards compatibility, ttk::combobox will need to have an additional option -ttklistbox to implement the new model. Or much better with a pragma (which don't exist): pragma ttkversion 2.0 or pragma usettklistboxwithttkcombobox

Alternatively, ttk::style could have a special case (I don't really like this idea) to set the options database when styling for ttk::TListbox was applied, and leave ttk::combobox as is.

Megawidgets for the core

Requests to standardise or include in the core something that has existing megawidget implementations.

Much of these next few things would be made easier with a megawidget framework so the basic bits and pieces to work like a widget are taken care of and the megawidget implementor/maintainer can focus on the unique functionality.

KPV: I'd like to see tooltips (aka balloon help) more integrated into the core widget set.

I know there are plenty of home spun code that does it (see Balloon Help), but having it built in would be useful. You'd probably get more programmers adding it to their programs, you'd get a more uniform look and feel, and save some headaches for many programmers.

There are some thorny issues, however. How do megawidgets work (you don't want to tooltip unmapping and remapping when leaving and entering a megawidgets component widgets)? Do canvas items have tooltips? Do listbox entries? Do menu entries? FW: Plus there's no standard native way to do it on X, so on that platform you might as well use an extension anyway

caspian: would like to have built-in tooltips, as well. I'd love to be able to do:

 button .b -text "Next" -tooltip "Proceed to next entry"

RLH: I would like the -tooltip as well. You could go one farther with adding a -balloonhelp as well with the caveat of the the text being able to wrap inside the balloonhelp itself. The would, of course, be visually different as well.

ALH: I am using dynamic tip text, that may (or may not) need refresh while balloon is displayed. I am also using menu/menu-item tooltips. A text-command and a update-delay arguments would handle this (currently I am using a modified tooltips for this):

 label .l -text "Time" -tiptextcmd {clock format [clock seconds]} -tiptextupdate 1000
 menu .m -tiptextcmd {getToolTipTextFromMenuIndex %W} tiptextupdate 0
 or .m add command -tiptextcmd {getToolTipText %W "1rst entry"} -label "1rst entry"

42.1 GWM: Buttons that need not be rectangular — elliptical, polygonal or defined by the opaque pixels of a GIF image would look good.

Michael Schlenker on comp.lang.tcl:

39. Multi-column listboxes (something like mclistbox or tablelist)

DKF: Is 8.5's ttk::treeview sufficient? You can turn off the tree part…

KHM: A tree widget with columns (Treetable).

DKF: Is 8.5's ttk::treeview sufficient?

i.e. MDI (possibly)

Nicolas Boretos wishes for: compound label-entry

DKF 02-Jun-2003: Why not combine a labelframe with a normal entry or are you after something else?

toolbox like iwidgets

DKF: What does this mean? Is there a toolbox widget? Or is this a request for “include everything”?

KJN: Yes, that's stating the bleedin' obvious - but how should we decide which of the many add-ons should be included in Tk or Tklib? I suggest the following as a minimum.

When a particular feature has been independently implemented in three or more different add-on packages, that is (a) compelling evidence that it's something lots of users want, and (b) a good indicator of a feature that is already part of the mainstream in GUI design. Scrollable frames (28) and tabbed notebooks (12) are examples.

Examine the different implementations; if possible, combine the best features of each. This would save users the trouble of doing the trawl themselves each time they want a slightly different widget. I have been through this very time-consuming exercise for 12 (I like BLT's tabnotebook best) and 28 (I'm still trying the different implementations).

FM : A way to register to Tk pseudo-widget (object, or command), so that we are able to use destroy, or other tk-commands on it as usual and so the real widget isn't show in response to winfo children.

Ex :

tk registrer .pseudowidget -path .pseudowidget_ -destroy {destroy .pseudowidget_; do other things} 
% winfo pseudowidget .pseudowidget 
1
% winfo pseudowidget .pseudowidget -path
.pseudowidget_
% winfo children .
.pseudowidget
% pack .pseudowidget 
% destroy .pseudowidget

Toplevel dialogs

date selector (possibly)

DKF: Megawidget/script/tklib candidate?

hae: see tklib/modules/widget/dateentry.tcl

time selector (possibly)

DKF: Megawidget/script/tklib candidate?

72. RLH 2006-08-21: How about a Tk calendar widget that only relies on Tk and not external widget sets?

DKF: Sounds like something for tklib to me.

hae: see tklib/modules/widget/calendar.tcl

MHo: I agree. A calendar which combines the features of the many good variations already exist (but each of them with a specific drawback...).

OTHER NEW FEATURES

slebetman: For all widgets that accepts a -textvariable option, also accept a -formatcommand option to format the textvariable for display. Exactly like tablelist's -formatcommand option for columns. I'd like to be able to do:

  proc myformat {x} {
    if {$x == 0} {return "undefined"}
    format %0.2f $x
  }
  label .l -textvariable foo -formatcommand myformat

63. (?) MAK - Make configurations like -textvariable, which currently resolve from the global namespace, assume [namespace current]. I don't know about anyone else, but I always use e.g. -textvariable [namespace current]::foo, so I never pollute the global namespace and never have to worry about changing those options should my namespaces get reorganized. IMHO, it ought to be the default. If you really want it in a different (or global) namespace, then that should be what must be explicitly indicated.

SLB How about adding a new option -variable (say) which behaves as described above so that -textvariable can be left unchanged. -textvariable could then be deprecated and eventually removed.

MAK - Well, don't forget: -variable is used in other widgets. There's also -listvariable, -command, etc. I mean for all of those to be as if specified with [namespace current], [namespace code], etc.

DKF: Since this is a wishlist for 9.0 and not 8.5, you've got my support on this. :^)

MAK - Oh yeah. bind, too.

SLB Sounds like this should also apply to Tcl commands such as after, vwait and fileevent.

Curiously 'info proc *' already acts on the current namespace.

GPS - I would like the ability to use foreign windows as drawables for widgets at the script level, by assigning a Tk path to a foreign window id.

KBK — I want more than that! If I've got a native drawable object, I want to be able to let Tk draw in it, whether it's a window or not!

It would make printing on Windows and Mac a whale of a lot easier; simply grid or place a canvas or text onto a printer device context, and scribble away. (If the core team will volunteer to do the hard part of making foreign device contexts work, I'll be glad to integrate with the Win32 printer dialogs, and maybe even code up a PostScript driver so that there will be at least limited portability onto Un*x!)

AK — See the references to TkGS in Tk Performance.

KBK — TkGS has the right idea in terms of allowing any device context for a window, but it may be going too far. The problem with the TkGS approach, as I understand it, is that you don't get to use native components to achieve native L&F. That's not a show stopper, but the idea that a canvas or text could draw on another device context is less radical.

FB — TkGS doesn't prevent using native components. It only takes care of the drawing. You're still free to use native widgets. Of course, if you want to allow output of such widgets on any drawable (eg. postscript or canvas), you have to provide TkGS code for that.

GPS - I'm a little scared to submit this TIP (fear of flames), but here goes... How about merging the BLT tile code into the standard Tk core. I've tried promoting Tk several times to new Unix GUI programmers, but some people have been reluctant to try using Tcl/Tk, because it doesn't have the eye candy.

 For example:
 <newbie> I want to start developing Linux applications.
 <GPS> You should try Tcl/Tk.  It's cross-platform, easy to use, and extensible.
 <newbie> Yuck! I hate the Motif look!
 <GTK zealot> Motif is terrible.
 <GPS> But Tcl/Tk isn't Motif.
 <GTK zealot> GTK+ looks much better, has more widgets, and *pixmap themes*.  blah blah blah...

? - I don't understand how the BLT tile is going to make any difference here.

Tk still looks like Motif on Unix, even with the BLT tile code. It still has less widgets than GTk+, still doesn't have pixmap themes, etc.

If someone wants to do Tcl and Alternative GUI toolkits, I think there are several. Last time I heard, they tended to use a syntax other than Tk syntax which make them, to me, significantly less attractive.

GPS - The tile code in BLT provides the ability to have pixmap themes in Tk. You should get BLT and try the Tcl scripts in the examples directory. There are several script level widgets that don't have the Motif appearance. I'm working on a Tk scrollbar script which doesn't look like Motif. See: [L11 ]

LV As marvelous as the BLT tile code may be, it isn't going to be up to what a GTk developer - or user for that matter - wants to see happen with Tk. They want Tk to make full use of GTk's native widget set, without having to try to emulate them to fool the user into thinking that they have GTk.

so There are two things that I would personally love to see happen in 9.0. I will admit to not keeping up with the TIPs and TCT, so I have dug out my asbestos undergarments....

DKF: During the editing of this page, it has ceased to be clear what the above paragraph was referring to…

11. (and also 73. which is very closely linked) I want, let me re-phrase that, I need a commmand that says print widget -options, that works cross-platform. Yes, I know how difficult this is, and I am the first to admit that I personally am not capable of coding this. IMVHO, this would be a huge step forward.

SO March 3, 2003 still wanting...

DKF: Isn't there a TkPrint extension for this sort of thing?

RLH 2006-08-26: I just thought of adding this since it was on the newsgroup. One thing that is always sticky with "scripting" languages is printing. I am not sure if this is just "Tk" but native printing dialogs per platform is doable.

DGP: Adopt GAH's ideas from 1998 on Data Objects. Have entirely separate packages provide these objects, then have Tk [package require] those packages, as it does with msgcat today.

LV - this seems like it would be a basic Tcl function rather than a Tk one - with then Tk updated to take advantage of the new data structure. Right?

DGP Almost. I imagine the data objects would be supplied by new packages, and Tk would depend on them while Tcl (especially a more modular Tcl envisioned elsewhere in Tcl 9 planning) would not. Also, these would not be simply "data structure"s. Each would be a data objects -- a Tcl commands that provide access to data, similar to the ideas in the struct package found in tcllib.

FW: A "transparent" Tk color, or even maybe degrees of transparency, so you could make a transparent circle on a canvas to make a round hole in a window through which you could see the window behind it. And maybe another type of transparency, for a widget, which allows you to see through it to the stuff behind it within the window (like a transparent image).

DKF: AFAIK, only binary transparency (it's either transparent or it's not) is portable across platforms, and that's currently most easily done by way of a separate bit-mask.

NEM: 2Jun2003 Full alpha-channel support for the canvas would be very cool. You say that this wouldn't be cross-platform, though. Is it possible to add something like this from an extension?

CME: 2Jul2003 TkZinc known as Zinc does offer both alpha-channel (this requires openGL) and the use of the X extension SHAPE to draw non rectangulare window, which even can be holed.

''REH: This capability would advance the use of TCL/TK in the e-learning marketplace where 'hot spots' and overlays are used extensively. The inability to implement a 'hotspot' or transparent button (or widget) in general is very limits the ability to leverage the other features of TCL/TK in the user interactive learning environment. (the use of top level windows is not 'the' way to do it).

Named colors, much like named fonts.

This would go a long way to supporting themes. Eg:

     color create myFavoriteColor #ffffff
     frame .f -background myFavoriteColor
     button .b -background myFavoriteColor
     ...
     button .makeItRed -command {
         color configure myFavoriteColor #ff0000
     }

(Suggested by Bryan Oakley on comp.lang.tcl)

MGS - Windows already seems to use a sort of "named color" i.e. the color names taken from the registry, such as:

   % . cget -bg
   SystemButtonFace
   % winfo rgb . SystemButtonFace
   54484 53456 51400

but these colors cannot be modified AFAIK (except through the registry). I too would like to see named colors that can be created/modified/deleted, like fonts for example.

There are also the colors taken from the X11 rgb.txt color definition table, which are already used, just not modifiable. I suppose this should be the standard list of color names.

DKF: See TIP#154[L12 ]

Luciano ES says:

There is this program, PowerPro [L13 ], a Windows shell extension. I just can't afford to use my computer for five minutes without it. When I switch to Linux, I miss it terribly. I've been looking forward to making a Linux version of PowerPro with Tcl/Tk, but there are three things I'd terribly miss because Tk still cannot do:

1. The ability to detect key presses even when not having focus, i.e. globally! The ultimate goal would be to drop all key shortcut functionality provided by the window manager and rely on this app for that, only.
2. The ability to send keys to other windows, not necessarily Tcl/Tk apps. Say, I press a key combo and the Tk app sends my e-mail address to a text editor or e-mail program, even if neither has the focus.
3. The ability to capture data from several parts of other windows. For example, with PowerPro I can detect and capture the content of the preview pane in my e-mail program and send it to my favorite text editor. I can also detect info like From: and Subject, just because they are visible in the GUI. Or capture the entire content of any document in my MDI text editor. Or press a key combination to detect what is displayed in my browser's address bar, get the page title from the caption bar and do something with that information, like a custom bookmarking system. Such an app would be a major improvement to that idea (posted somewhere in the wiki's wild wilderness) about making a desktop manager with Tcl/Tk. I do all of the above with PowerPro, endless fun. And I would love to "port" it to Linux with Tk.

DKF: This all sounds like an extension to me, but there may be one already that does at least some of this. (Global key capture requires cooperation from something else, e.g. the window manager on X-based systems.) But I don't follow extensions that closely... :^/

218: 1 is supported by xbindkeys.

DKF: Also, for Win equivalent you might want to check out AutoHotkey. It's not Tk, but it's a space they specialize in.

DKF: My idea here is to make the bindtags for every widget to include all frame widgets on the way up to the first toplevel widget. This would make doing megawidgets based on frames much easier since people would be able to bind to the megawidget normally and still have something sensible happen. I think...

MGS [2003/09/05] - I think all Tk commands should be moved into the ::tk namespace. This keeps in line with the concept that 'package require <package>' should only expose an API. Commands can then be namespace import'ed into the desired (global?) namespace. This also alleviates polluting the global namespace. Starting 'wish' could (possibly) automatically import all exported tk commands into the global namespace (for backwards compatibility?).

KJN Stacking order should be based on the master/slave hierarchy, not the parent/child hierarchy.

See Stacking Order for discussion and detailed suggestion.

Extend -use to source

kroc [2003/09/25] - I'd like to have the possibily to source a Tk script in a container frame like it's actually possible to do for a toplevel or exec wish (see winfo id for details) :

    source script.tcl -use [winfo id .holder]

MGS - This doesn't make much sense. I agree that sometimes it is useful to pass arguments to the source command (See: source with args), but this example does not make sense. If you already have the widget .holder, then Tk must be loaded and "." must exist. If you are source'ing script.tcl into the same interp, you are telling it to put "." inside its own child widget .holder. Makes no sense. I think it is a mistake to confuse the wish application command-line argument -use with a script option. I suggest using a different option name (-embed?), and modularise script.tcl so that it can run independently of the main script.

and 57. (dup) - TV @ 2 April 2003 Configuration Interface

Copied from Tcl 9.0 WishList with remark that it surprises me it didn't even raise comments from the tcl wishlist.

I'm not sure how to date this request is, but long ago when I started with tcl/tk, I found it possible to take the configuration information of components in tk, check whether they are all default value, and automatically scan the whole hierarchy of windows and store their state, for instance like ilist. More or less, that worked. I don't have access to the work I did then, and I know that there is a list of values for each configuration property of which roughly the last value is the current active value, but I didn't check recently whether it is reasonably possible to save the state of a graphical interface by neatly walking a window hierarchy and intelligently storing all config info. I guess the request is to allow that in an organised manner, which to me, apart from porting that information, would technically seem reasonable. Maybe one should purchase tclpro instead?

TV: Maybe just talking to myself on this item, but I just found there is no distinction possibility between

  $widget conf -text
  $widget conf -textvariable

possible without checking the widget class. Or in other words, the handy shortcut idea cannot be overridden to force a complete match.

PR: Discussion arises over and over again: it would be nice to have more image types in the core; above all, common types like jpeg and png are indispensable for people working with images.

Even cooler was support for pdf in the core!

FW: I think pdf sypport calls for a package - it's dead weight in the core for most users. Also, any new image types would go in Img, not the core, which will always have a very basic set of image commands.

DKF: 8.6 has png support.

RJH: Remebering experience of using FVWM; once of the greatest advances in usability came when they introduced support for SVG. It is wonderfully helpful when constructing a user interface to know that:

• You do not need to choose an icon size - the system will handle that for you.
• In the unusual cases of resizeable widgets (generally buttons - although image does get used elsewhere), the system will automatically resize the image to suite the containing widget.

Basically imagine a world where something like this worked:

  image create svg -file pic.svg -keepaspect 1
  button .b -image .i

etc.

KJN: Does anyone from the TCT represent Tk at freedesktop.org? They are working on, for example, cross-toolkit mechanisms for IPC (D-BUS) and theming (Gtk-Qt theme engine).

http://www.freedesktop.org/Software/dbus
http://www.freedesktop.org/Software/gtk-qt

DKF: Joe English is keeping an eye on FreeDesktop stuff.

Also note that the interesting standards are those listed in the first and second section of http://www.freedesktop.org/Standards/Home

KPV Better after idle handling. I have an app where I want to download stuff off the web when the user is idle. The problem with the current after idle is that it can fire when the user really isn't idle such as temporarily pausing while panning or scrolling. Yes, the event queue is empty so the system is technically idle but the user is really in scroll mode.

What I'd like is something like after idle <milleseconds> which will fire only if the system been idle for <millesconds>.

My work around is to have the after idle handler start a timer when it fires. If any mouse or keyboard or etc. event occurs before that timer goes off, it resets that timer and restarts the idle one. The problem is trying to enumerate and catch all the various events.

DKF: You have access to the global (i.e., not just Tk) activity monitor with tk inactive.

RLH: I would like to see Tcl/Tk on a PocketPC with an as "native" as possible look and feel. Hey it is a wish list!
DKF: :^D

FW: It's not quite as native as it can be, though; still uses standard CE windows instead of the special full-screen ones (and growing the window so the titlebar is obscured by the top is kind of a cheat). - RS: eTcl (while being 8.4) comes as close to CE "native" as I've seen so far.

DLR Ability to dock in system tray. You can already do this with winico in Windows, would be interesting to fold this into Tk itself and add support for docking under KDE and Gnome

RLH: Making Tk thread safe, if possible. This is a from a c.l.t posting: " Brent Welch states that even Tk "isn't truly thread-safe," (4th ed., page 323) although you can get away with using it in a threaded program if only one thread uses Tk."

DKF: We're working on this (intermittently) in 8.5 anyway because it's needed as part of making Tk play well in a number of embedded scenarios (especially COM support on Win) but there are some horribly gnarly edge cases to do with especially shutdown which currently can cause crashes. It's difficult to do without breaking lots of existing extensions...

Kroc - I would like all bindings written for lowercase letters (such as <Control-c>) work for uppercase letters too (like <Control-C>), even for builtin bindings.

KPV: I feel that the option database is old X legacy code that has some serious drawbacks:

• confusing (what's the difference between *button.background and *Button.background?)
• alien to Windows users
• you can't query existing values
• to be useful to end users you have to publish your widget hierarchy
• modern users expect friendlier interfaces for configuration

I think one possible better scheme would be one similar to what bind does, specifically letting you work with either a widget instance or a widget class. To wit, with bind you can say: bind .b ... or bind Button.... I think you should be able to do the same with widget configuration: .b config... or Button config....

Some examples: to get the current font used by Buttons:

   Button cget -font

To set the background for Labels:

   Label config -bg magenta

NEM I quite like this idea. It could exist alongside the option db, though? i.e.

 Label configure -foo

could just be a shorthand for

 option add Label.foo ... widgetDefault

(or whatever the syntax is, it's been a long time since I last used the option db). BTW, is there any particular reason why Button instead of button? AFAIK, all the widget commands currently expect their first argument to be a widget path which must begin with ".", so it should be possible to add sub-commands without breaking backwards compatibility. i.e.:

 button configure ...

is not currently a valid syntax.

gcramer - 2010-05-30 19:06:09

The current "wm manage" command is deficient and flickering (see bug item #112997 ). It needs a re-implementation and an additional option like "-unmapped". With the current "wm manage" command undocking of windows is flickering a lot.

kknd: A bitmap editor with fast speed can be implemented in tk. Some enhancement for canvas to support it become realizable. I never find a good bitmap editor implemented in pure tcl. It may need some functions to manipulate the buffer. It is a basic need actually.

KJN: Revise the behaviour of Modifier keys: remove any unnecessary differences between platforms. See Modifier Keys for discussion.

KJN: For historical reasons, mouse buttons are numbered (from left to right) 1, 2, 3 on non-Mac platforms, and 1, 3, 2 on the Mac. We must stick with this for 8.x to preserve compatibility, but 9.0 would be a good time to standardise button numbering on all platforms.

Lectus: I'd like to see official support for Qt and Gtk themes on ttk. Something like:

ttk::setTheme qt
ttk::setTheme gtk

I believe tile/ttk theming was the best feature of TK 8.5 and it completely destroys the "Tk is ugly" idea, at least on Windows. Now it needs to be done for Linux too and that means Qt and Gtk themes. I think this can greatly increase Tcl/Tk adoption.

uniquename - 2012mar29: When '-compound center' is used, '-anchor' does not function. For example, '-anchor w' will not put the text on the west (left) side of the image. Example (that does not work ; text always remains centered):

image create photo img4buttn -format GIF -file buttonBkgnd_sheeny_blue_432x28.gif
button .b1 -text "This is test line1." -anchor w \
      -image img4buttn -compound center -padx 0 -pady 0
button .b2 -text "This is test line2 --- another test line." -anchor w \
      -image img4buttn -compound center -padx 0 -pady 0
pack .b1 .b2

I am trying to make a 'prettyfied' toolchest of tool-drawers, made with buttons with nice image backgrounds. I cannot find a way to line up the text of the drawers, precisely, on the left side of the buttons. (Doing this with a canvas would take a lot more code; button has some nice built-in features.)

If anyone has a way to 'justify' the text to the left (I tried '-justify left'. That does not work either.), I would love to know how. It appears that there is no nice way to pad the text (in a variable-width/proportional font) so that it lines up precisely on the left. Padding the text appears to be the closest I can come to a proper solution to this situation.

By the way, it may have been better if the option '-compound center' had been called '-compound txt-overlay-img' or '-compound txt-on-img' (or some such). That would have indicated that the image would not overlay the text (which the 'button' man help does not indicate — in fact, it says “the value 'center' specifies that the bitmap or image should be displayed on top of the text”), and it would have perhaps indicated to the implementors of this feature that options other than '-anchor center' should be allowed — at least in future enhancements.

Note that a '-compound img-on-txt' option could be possible with the new PNG image capability, with its alpha channel. And the result of 'img-on-txt' would be different from 'txt-on-img'. (Similar considerations apply to transparent GIF's.)

By the way, it would really be nice if there were also an option for the image in each button to 'tile' to the width of the packed buttons. Thus in the above example, the GIF could be a little 3x28 or 1x25 'sliver', say — or much wider — and the common, x-filled button-width of the buttons is determined by the longest line of text (and its font). Too much to ask? Well, at least offer an option to tile the image to a width specified in a '-width' parameter of the button. More reasonable?

Note that we could do a lot of our own 'theme-ing' — even on Linux — if the '-anchor' suggestion were fixed/implemented.

DKF: While I'm not at all opposed to improving things in this area, you've got several feature requests there that are a bit jumbled together. I'm going to try to break them down into specific things:

• Tiling of images in widgets (esp. the button family, which includes labels, checkbuttons and radiobuttons too)
• Stacking control of images/text in widgets
• Text positioning control when images are present
• Full-justification of text

Have I missed anything?

Assessing the complexity of them, the first three are relatively simple to do (I think). The fourth is much more complex; I've written code to do it in a text or canvas in the past (in the text, I inserted transparent images to generate space inside words, in the canvas I just did pixel-level placement of words) and the key is to use font measure extensively. (Actually, line breaking and hyphenation handling make this all enormously more complex; the code in question wasn't especially simple even without those features and Knuth's written at least one paper on line breaking algorithms based off his experience with TeX…)

uniquename - 2012apr03.

Thanks for the reply, DKF. The main thing I'm requesting is the first item I requested (above, in the title), which was the 3rd that you listed (above) — 'Text positioning control when images are present'. Actually I am just asking for the case when text is 'on' the image — not the compound top/bottom/left/right options — '-anchor' might actually work in those cases — I have not tried it in those cases. Quite specifically, I am asking for '-anchor w' (or something similar) to work, to locate text on top of an image.

The 4th item on your list — 'Full-justification of text' — is not something I need, since I am dealing with just one line of text on the buttons — no hyphenation or line-breaks to handle — and no need for simultaneous left-and-right justification. I just mentioned text-justification in one place. I mentioned that I tried '-justify left' — to try to get the text aligned to the left side of the image. (I guess I had the align="left" and align="justify" options in HTML floating around vaguely in the back of my mind. I suppose I was hoping that '-justify left' would work, on a single line of text, like align="left" in HTML. No such luck.)

The 1st item on your list — 'Tiling of images in widgets' — I mentioned as a 'nice-to-have' (in the horizontal direction). I can probably work around lack-of-tiling for now — by using very-wide images and clipping them with the '-width pixels' option. Yes, it would be nice if tiling — along with position control of text-on-image — worked for labels, checkbuttons, and radiobuttons, as well as buttons. It would allow for more complete 'theme-ing'.

The 2nd item on your list — 'Stacking control of images/text in widgets' — was simply an observation I was making — on the possibility of an 'img-on-text' option in addition to a 'text-on-img' option. The 'text-on-img' option is probably the only one, of the two, that I would ever use.

So they (my 'a bit jumbled' original paragraphs) boil down to a main request and a secondary request:

• a working '-anchor' (or similar alignment) option, for text 'on' an image, in buttons (and similar widgets)
• a tiling-of-the-image capability in those widgets, at least in the horizontal direction

For the main request, either of the following would work for me — for text positioning on the image:

• -textadjust n/s/e/w/ne/se/sw/nw/center
• -align left/center/right[/justify] — like HTML — where there is also a '-valign' option.

And actually '-textadjust w' or '-align left' is all I am looking for.

I was actually suggesting one more thing, that is not on your list. I was suggesting that the '-compound center' option be replaced by something like '-compound txt-on-img'. This could be done by adding 'txt-on-img' as a synonym for 'center', and eventually deprecating 'center'. As I indicated, 'center' suggests that the only option is for the text to be centered on the image. But this is a matter that you developers should decide how to handle. I'll be satisfied with using 'center' if you want to leave it that way.

I favor the hyphenated names for the '-compound' options, because one does not have to go searching for the 'button' 'man' page to find that the '-compound' options refer to the location of the image relative to the text, and not the other way around. But if you do not like the hyphenated names, I would suggest 'behind' (image behind text) rather than 'under' (image under text) or 'beneath' (image beneath text). 'under' and 'beneath' sound too much like they would mean the same thing as 'bottom'.

Furthermore, if anyone ever decided to implement what I have been referring to as the 'img-on-text' option, I would suggest calling it 'cover' (image covers text) rather than 'over' (image over text) or 'above' (image above text), because 'over' and 'above' sound like they would mean the same thing as 'top'.

One more thing — having to do with documentation, not coding:

I was trying to point out, above, that the documentation about the 'txt-on-img' compound option is misleading, because it is stated 'wrongly'. It says

“the value 'center' specifies that the bitmap or image should be displayed on top of the text”

when it should have said

“the value 'center' specifies that the text should be displayed on top of the bitmap or image”.

Of course, I suspected that it really meant the text would display on top of the image (and thus not be hidden by the image), but, to be sure, I had to construct the little code example shown above, to verify that the text would indeed not be hidden by the image.

If 'Text positioning control when images are present' were implemented — and if the 'center' option would eventually be deprecated in favor of the more accurate 'behind' descriptor — then the documentation should be changed to read something like:

“the value 'behind' specifies that the text should be displayed on top of the bitmap or image.
... The '-align' (or whatever) option can be used to locate the text relative to the image.”

uniquename - 2012apr09.

I tried out the top,bottom,left,right options of '-compound' in my simple code example above, and it appears that '-anchor' does not function with those compound options either. (CORRECTION: See the '-fill' note in the 2012apr14 post below. The following comments still apply.)

So I guess that if someone were to implement my request for 'text positioning' to work for the '-compound center' option, that implementor would feel compelled to make it work for the top,bottom,left,right options also.

But I would be a happy camper if '-textalign' or '-textadjust' (or whatever it were called) were simply made to work for the '-compound center' option.

Furthermore, I'd be happy if 'behind' (or 'text-on-img') were made an alias/synonym for 'center' — and 'center' were deprecated.

In relation to the documentation: Implementing 'text positioning' for the top,bottom,left,right options makes the wording describing 'text positioning' a little more complicated. If it were implemented with a new keyword like '-textalign', then perhaps something like:

"For '-compound behind', the '-textalign' option can be used to locate the text relative to the image. For the top,bottom,left,right options of '-compound', the '-textalign' option can be used to adjust the text within its 'sub-frame' below, above, to-the-right-of, or to-the-left-of the image."

uniquename - 2012apr14.

I did a little more experimenting with the '-compound left' option and found that '-anchor w' DOES work "as desired" in THAT ('left') case — PROVIDED THAT one puts '-fill x' on the 'pack' command. That is, '-anchor w' DOES "snug" the start of the text up next to the image, which is on the left.

Unfortunately, the '-fill x' parameter does not work "as desired" for the '-compound center' case. That is, '-anchor w' does NOT move the text to the left side of the image, when the image is larger than the text.

Probably, the '-anchor w', in the '-compound center' case, also works — but only applies to the larger of the image and the text. (The 'Probably' can be taken off that sentence. I just confirmed the conjecture with some further testing. Sample code is in a 2012jul29 note below.)

So you were right, DKF, to word this suggestion without using the term '-anchor'. However, I would say that the generic title that you suggested for my suggestion — namely 'Text positioning control when images are present' — covers more ground than I was suggesting.

Perhaps the title of my suggestion should be something like 'Implement (left) positioning of compound text ON image'. (I hesitate to change the title that drastically until I get your OK — or the OK of some other moderator.)

Providing a new '-align' option (like in HTML) might be a good way of implementing that capability.

Or use another keyword, like '-textadjust' or '-textanchor', if you prefer a different word from 'align' — say, because this text positioning works a little differently from HTML's '-align', in relation to other elements within the window.

But (further) text-alignment doesn't appear to be needed — at least by me — that is, in the left/right/top/bottom cases of the '-compound' option.

I'm only requesting that '-align' or '-textadjust' (or whatever it would be called) work for the 'center' ( = 'behind' = 'txt-on-img') case. It would be up to implementors if they wanted to 'tackle' the left/right/top/bottom cases.

uniquename - 2012jul29:
To see how '-anchor' performs --- (1) when a button is narrower than the text, and (2) when a button is wider than the text — I simply added a '-fill' option on the pack command of the code sample above — as in the following example code.

image create photo img4buttns -format GIF -file \
   buttonBkgnd_sheeny_blue_400x24.gif
button .b1 -text "This is test line1." -anchor w \
   -image img4buttns -compound center -padx 0 -pady 0
button .b2 -text "This is test line2 --- another test line." -anchor w \
   -image img4buttns -compound center -padx 0 -pady 0
pack .b1 .b2  -side top  -anchor nw  -fill x  -expand 0

I also added the '-side', '-anchor', and '-expand' parms on the 'pack' command, to make clear the values used for the four, main pack parameters.

I ran two tests — one with a button size of 100x24 and one with size 400x24.

Here are the two images from the tests:

From these images it is clear that '-anchor w' is indeed doing something — it anchors the wider of text and image to the west.

But, for the 'button' widget, there is no nice way to make the text lines, in the second image above, be located on the left side of the buttons, instead of in the center of the buttons.

Hence this request for enhancement — to have an anchor-like parameter to locate the text on the button.

P.S. I'm working on a way to do this with 'canvas' widgets instead of 'button' widgets. It looks promising. See Experiments in making embellished GUI's.

RLE (2012-08-14): Have you looked at Paved Widgets?

uniquename - 2012aug05:

In various paragraphs above, I made comments/suggestions on new/renamed/alias/alternative/deprecated values for the '-compound' parameters.

To create a little bit of order out of the chaos, it is probably helpful to summarize the comments/suggestions in the form of a table, below.

Note that the value of '-compound' that needs the most attention is the 'center' value.

The values 'left', 'right', 'top', and 'bottom' suffer mainly from their vagueness (not clear how the text and the image figure into each of those specifications).

It would be nice if Tk code can be self-documenting as much as possible. Currently, the values 'left', 'right', 'top', and 'bottom' require the reader — who isn't using '-compound' everyday — to reach for a reference manual or to perform a web search to understand what is going to transpire when those values are used. In the table below are some suggested synonyms (aliases) to be allowed for the current parameters. Hopefully, if implemented, they would drastically reduce the need to reach for manuals or do web searches.

No doubt someone can think of a better aliases (alternative, allowed names for the values of '-compound').

tomturkey 2013may13

It is clear that the core of tk has this info but it is really hard to get it. It would be really nice to be able to pop up a window and KNOW it is all on one display of a multi-display screen.

[tomturkey 2013jun26

To actually make a color chooser that uses color names one needs to know the names. The man page implies that they differ by platform. Also it is not exactly easy to get tcl/tk to read its own man page(s) :). I suggest winfo as it seems to already have such a list given that it can take color names.

uniquename 2013aug03

This is a request to support a '-format jpeg/jpg' option for the '$p read -format ...' capability, where $p denotes a photo image handle returned by the 'image create photo' command. This is in addition to GIF and PNG formats. It seems that this is a reasonable request for two main reasons:

• JPEG is actually a more popular image file format than GIF and PNG, nowadays. This is evident when one notes that on web pages most images are posted as JPEG files rather than GIF or PNG files.
• Of course, it is great that GIF and PNG files are supported because they have the 'transparency' and 'alpha channel' features. But, on the other hand, JPEG would probably be easier to implement than GIF or PNG because JPEG does not support transparency or alpha channel --- so probably it would be easier to implement JPEG-read than GIF-read or PNG-read.

Note that I am not requesting a JPEG-write implementation --- although that would be nice :-). I could live with doing image captures (with a utility like 'gnome-screenshot' on Linux) to capture Tk canvas images and convert the captured file to JPEG.

Note that one can lose quality in converting a JPEG file to GIF or PNG and then reading the GIF or PNG into a Tk 'photo' structure. Besides, that is labor-intensive --- especially on a big batch of files, for example from a digital camera. It would be much better to be able to simply read a JPEG file into a Tk 'photo' structure without doing conversion to GIF or PNG. Thank you for your attention to this matter ... :-)

DKF: Isn't having the img::jpeg package enough? (IIRC, we've been keeping it out of the core because of the build dependencies. And because most interesting JPEG images tend to get large now, so perhaps the photo image data model is a little sucky…)

uniquename 2013aug06: I guess that you are referring to the 'Img' 'extension' that has to be added to a base Tcl-Tk installation. I think that anytime the installation of an additional 'extension' to Tcl-Tk is required, the audience for a utility using that extension is reduced by 90%.

Who wants to spend time doing installations? --- especially if such an installation has even one iota of a chance of messing up a nicely functioning operating system. (One thing leads to another. Typical scenario: The 'Img' extension requires a more recent version of Tcl-Tk, so not only does the user have to install the 'Img' extension, but they need to update their Tcl-Tk installation.)

Another point: Look at the dearth of image 'slideshow' utilities done in Tcl-Tk. (I have found only one such script on this wiki --- and it is an overly-simple 'demo' script that switches between 2 GIF files.) Meanwhile look at the huge variety of slideshow implementations in HTML on web pages. And with HTML 5, we are likely to see even more varieties of slick looking slideshow implementations. If the JPEG-read capability were available in base Tcl-Tk, I think it is a sure thing that we would have had a plethora of slideshow implementations by now, done in Tcl-Tk. I probably would have tried one by now, using some of the techniques of my Version 2 of a demo of THEMES for Tk GUI's, using images and colors page, to get a really shiny-looking GUI.

A third point: Digital cameras. What is the image file format that they produce --- other than 'raw'? Answer: JPEG --- not GIF, not PNG. And digital cameras will probably never produce PNG output. PNG is good for making image files from SVG (Scalable Vector Graphics) files --- as can be seen by the many PNG files on Wikipedia, made from SVG files --- BUT PNG files are really not a good option for photos. Who wants to take 100 or 200 photos from their digital camera and convert them to PNG files?

By the way, as a code developer, I can really appreciate your concerns about making 'the builds' more complicated. But I think this is a feature that is really worth the various types of costs. JPEG-read will really help make Tcl-Tk more appealing --- more useful. (On the image size issue, in most cases, the PNG file of the same scene as a JPEG file will probably take about the same amount of memory, once stored in the 'photo' structure.)

---

uniquename UPDATE 2014jan08:

I noticed today the wiki page Img indicates that there have been some serious performance problems with JPEG reading via the 'Img' extension --- at least, circa version 1.3. This seems to argue for including a good, robust JPEG/JFIF file reading capability within Tk --- since we cannot seem to count on its performance in that 'go-to' extension.

Back in 2013aug, I meant to supply the following info. I supply it now, since this info might help make JPEG/JFIF-read 'relatively easy' to implement --- and facilitate selecting a good code base to implement.

1) First, I would like to point out that there are quite a few open source apps that use JPEG libraries --- for example, the 'mtpaint' image editor program that I use almost daily on Linux --- available at freecode.com [L14 ].

Of course, there are many other open-source image viewer/editor programs that could serve to provide sample code for reading JPEG-JFIF files:

• eog (Eye of Gnome) image viewer
• gpicview image viewer
• gwenview image viewer
• mirage image viewer
• gthumb image viewer
• GIMP image editor
• KolourPaint image editor
• Krita image editor
• the ImageMagick 'convert' command
• GraphicsMagick, a fork of ImageMagick
• Inkscape vector editor (imports JPEG)
• 'Photivo' open source photo processor [L15 ]
• 'dupeGuru' duplicate picture finder at freecode.com [L16 ]
• 'Opticks' for images for GIS applications at freecode.com [L17 ]
• 'dbblast' (Dust Bunny Blaster) to remove spots from JPEGs from digital cameras [L18 ]

and the list goes on and on.

You can see more possible JPEG source code sources at this list of imaging freeware [L19 ]. And a list of free image conversion software is available at sourceforge.net [L20 ].

Furthermore, there are open source jpeg image libraries (that are probably used by some of the programs above) --- such as:

• 'libjpeg' at freecode.com [L21 ]
• 'libjpeg-turbo' [L22 ]
• 'freeimage' open source library project [L23 ]

2) Second, I would like to point out that it is not really necessary to support JPEG 2000. JPEG-JFIF should suffice.

Here [L24 ] is a 2007 blog post --- 'Do you use JPEG 2000?' --- that indicates that JPEG 2000 was not catching on with camera manufacturers --- and a JPEG 2000 plug-in that was being supplied with Adobe Photoshop would no longer be supplied with the software by default.

In using the Gnu/Linux 'file' command on JPEG files on my computer lately (in 2013), I only see JPEG-JFIF files --- no JPEG 2000 files. I do not think it would be necessary to support JPEG 2000. In the case where someone wants that, it appears it would be quite reasonable to refer those people (using Tk) to use of a conversion program to convert JPEG 2000 to JPEG-JFIF --- based on the low ratio of JPEG-2000 to JPEG-JFIF files 'out there'.

Some background on the JFIF format is at Wikipedia [L25 ]. And there is some information there on libjpeg and libjpeg-turbo [L26 ].

3) Third, I think this quote from a 1999 book by John Miano --- 'Compressed Image File Formats (JPEG, PNG, GIF, XBM, BMP)' --- page 40 --- is helpful:

"One of the most striking things about the JPEG standard, especially considering how sprawling it is, is what it did not define: a file format. The JPEG standard does not specify what an application needs to do in order to create images that can be exchanged among different applications. For example, it says nothing about how colors are represented, but deals only with how component values are stored. Nor is there any definition of how the components values are mapped within a colorspace. An implementer of JPEG software is not told if component one is red, two is green, three is blue, or even if the RGB color model is used at all. While a standard that is independent of colorspace is flexible, it is also impossible to implement.

Nature abhors a vacuum, and into this one came JFIF (JPEG File Interchange Format), created by Eric Hamilton. This specification fills in the gaps left by JPEG in creating files that can be exchanged among applications. 'JFIF' has become synonymous with 'JPEG File'. While other file formats, such as TIFF, use JPEG compression, a file with a JPG or JPEG extension invariably is in the JFIF format. JFIF is what we are going to cover in this book."

The 1992 specification by Eric Hamilton is available on-line at [L27 ].

And the 1999 John Miano book could be a good reference to a Tcl-Tk 'wish' developer who might someday put a JFIF-read capability in the 'wish' interpreter.

osch ttk::treeview replaced the old listbox. But listbox is easier to use because of the option -listvariable. Please add a ttk::listbox too.

osch It would we good to have a widget like tktable with scrollbars that is connected to a database. The widget shouldn't load the whole database at once but only read that part of the database that is displayed. The slider of the vertical scrollbar should show its position corresponding to the row numbers of the database. And if you move the slider of the scrollbars the widget should update its content by reading the corresponding part of the database.

As in Cloverfield.

osch Most of the time users select no hidden files or hidden directories. It would be nice to have an option that defines if hidden files and hidden directories are visible in the dialog. The advantage for the user would be that the dialog shows less files or directories and is more clearly.

osch It is complex to transform a list into a treeview and vice versa to identify the selected treeview elements in the list. If you have a sorted list (e. g. a file structure as /a, /a/b, /a/b/x.txt, /a/b/y.txt, /a/c, /a/c/z.txt) it would good if it could be automatically transformed into the treeview. Each item of the treeview should get an additional ID that represents the index of the element in the list. The treeview of this example would be e.g.

(if folded)

a+b (Index 1)

 |
 +c   (Index 4)

(if expanded)

a+b+x.txt (Index 2)

 | |
 | +y.txt   (Index 3)
 |
 +c+z.txt   (Index 5)

If the user selects /a/b/y.txt the selection-variable should be set to 3. The selection-variable should be a list variable because of selectmode extended.

Discussion

Hmm. Some of these suggestions don't really need to wait for a major version change. They're really waiting on code (that meets the usual engineering guidelines and is reasonably cross-platform where appropriate) supplied from someone who knows what they're doing. All they take is a bit of effort...

KJN - Many suggestions, including some of my own, can be deferred to 9.1 etc. 9.0 should focus on two things:

• Changes that cannot be implemented in 8.x or 9.1 because they would break compatibility.
• Simplifications (e.g. to the C API) and other changes that create a better starting point for development of the 9.x series.

DKF: In general, I'd agree with that. The truly hard part is being wise enough to spot what needs to be in 9.0 because it causes breakage, as opposed to what is just extending the functionality.

Has everyone given up on Tk 9? I don't see this page a) being reorganized, b) being added to, c) or for that matter, discussion ongoing about where Tk and Tcl should go next?

DKF comments "well, I have been a bit busy sorting out other things (work, TIPs, existing Tcl/Tk bugs, etc.) so my following of this page has fallen behind a bit..."

GPS - I'm not sure what to name the new pages that would split from this page. Also, with the TIP (Tcl Improvement Proposal) process this may be a useless page, until someone writes TIP's for the various ideas.

KJN - I've attempted to put the uncategorised proposals into the correct categories, without removing anything.

LVwikignome - 2009-11-23 09:02:51

Has anyone began a list of Tcl and Tk deprecated options, commands, and packages, with an eye towards discussion of when the removal should occur?

dkf - 2009-11-23 09:46:16

->LV: Such as might be called Deprecated Parts of Tcl and Tk perhaps?

bigdakine - 2017-01-19 17:38:42

I honestly think it would be crazy not to merge BLT with TK. And I would use the WIZE version of BLT which is already compatible with Tk8.5

http://pdqi.com/w/pw/pdqi/Wize/Blt

There are many of us who find this an extremely attractive package; vector processing, the tie-in between vectors and graphs and a whole host of other features that standard Tk does not have.

Another package I would recommend is the inclusion of the BWidget package.

This enables the easy construction of mega-widgets like strip-charts.

Yours,

Stuart Weinstein