GPS - I would like the Tk scrollbar to function properly with lines that wrap in version 9.0. I feel that having this bug present in new and old releases contributes to doubt about the capabilities and quality of Tcl/Tk. See Ideas to Fix the Tk Scrollbar

DKF - Why wait for 9.0? I want it fixed now and I wouldn't even consider it a real incompatability.

GPS - It seems like it will be a difficult bug to fix, because the bug has been in Tk for years. That is why I suggested it for 9.0.

DKF - While it is a fairly big change to the [text] internals (which are specifically designed not to try to work out the display area) it shouldn't be visible outside except as a change in scrollbar (and possibly scanning) behaviour. If someone can make the changes in time, I'm sure that this would make 8.4.0; I don't know of anyone that thinks the old behaviour is a Good Thing...

GPS - Anybody found the bug yet?

DKF - Easy one. The bug is in the conceptual design of the text widget. Which is why fixing it is a complete PITA since it forces re-engineering of the way the widget manages its internal data structures, and a round of performance tuning as well. :^(

Vince - Please test the patch for TIP 155, which fixes this problem...(it also fixes WHD's problem below).

DKF - This works for me in 8.5a0! TIP#155[L1 ] means that this request is fully satisfied.

IMPLEMENTED!

WHD - I'd hope this would fix the cursor key problem with wrapped lines as well.

IMPLEMENTED! (see above)

12. and 42. (duplicate) A native notebook widget. I believe this has been discussed, but I am not up to date on its status.

Steve Offutt 4/7/01 - mailto:[email protected] -- also still wanting...

(coalescing from elsewhere...)

Native 'tabbed page' or 'notebook' widget

Megawidget implementations are available, but these do not have quite the look and feel of the native widgets (esp. on MacOS X).

DKF - I agree with this very, very much. I'd like Tk on XP to not just have a notebook widget, but a notebook widget that looks like the notebook widgets used in the system properties dialogs. Doing the same on OSX only seems fair to me.

DKF: The Tile project has a notebook and a high probability of getting into Tk. It's also waaaay cool for many other reasons.

KJN: I've just run the Tile demo script (on X11) and I think it's not very nice-looking. BLT's tabnotebook looks more professional, because more care has been taken over the artwork.

In Tk 8.5, there is ttk::notebook.

IMPLEMENTED!

male - IMHO the notebook is NOT implemented? I have to switch to tiledTk to work with this and even if some people suggest all others to switch, I won't. So ... bad luck? No! A notebook should be part of the widget collection of the "old fashioned" Tk core!

DKF: There is a notebook widget in Tk. It's the themed one. (There's no hope of doing it otherwise, since platforms look radically different in this area.) If you prefer your own, that's cool, but I can't honestly see anyone doing another one in the old Tk method too. (It would have problems on Windows anyway.) Since there is a widget available — whether or not you like it — we can justifiably call this a completed suggestion.

MSH - The Tile notebook is still missing some important functionality, when there are too many tabs for the space they scrunch up, no scrolling as per Firefox no multiple rows (not the best solution) and I think no icon and close button (Firefox et al again). So for applications using dynamic tabs to display information it is not a viable solution.

DKF: I reckon those things count as bugs/misfeatures. Well, possibly. I actually reckon that the problem is having that many tabs in the first place; it's horrible to actually use since either things move around vertically — the “Windows” style — or they can't be seen all at once — the “Firefox” style. But in any case you want to argue with jenglish over this rather than deny the existence of the widget.

MSH - I'm not denying its existence. It just means that I have to learn/manage several different tab widgets to handle different situations. I have BLT tabs because they can be used on their own without the pages, BWidget because they scroll when there are lots and ttk for a 'standard' look that makes three differnet api's.

LV: It is my experience that nearly every widget has some aspect that someone, somewhere, thinks is missing or sub-optimal. The best thing that could be added to Tk would be a robust megawidget framework, so that people could start creating components that could be wired together to get the myriad combinations of features they find required for their application.

peterc: The Tile notebook on Mac has the appearance of the original notebook from Mac OS X 10.1-2. TclMacBag provides a notebook (the "pnb" widget) [L2 ] which looks more like tab notebooks on Mac since Mac OS X 10.3.

DKF: Has anyone filed a bug report over this? If nothing else, it will help remind us that it's an issue. (No, trawling the Wiki for stuff isn't the same...)

IDG Rotatable (at least in 90 deg increments) text in canvas widget.

GPS This is definitely needed in the Tk core. It is requested often enough to warrant it. If Xlib had functions for this we probably would have had it years ago. You can rotate to some degree some fonts with Tk in Unix, but it doesn't look very good, and last time I tried the script that does it, it didn't work in Windows.

If you need it now you can use BLT. I've heard that it allows drawing a font into a bitmap which can then be rotated.

DKF: Some Xservers can do rotate individual characters natively (and even by non 90-degree increments - see Rotated canvas text) but it is definitely not a universal capability.

CME: 2Jul2003 TkZinc or Zinc could easily be extended to rotate texts (using openGL). It already rotates all graphic items.

CME: 8OctJul2004 TkZinc or Zinc 3.3 can rotate texts (and images). Rendering is better with openGL, but also works with X11.

DKF: Fully rotatable text is in 8.6. See [L3 ]

IMPLEMENTED!

GPS I want the ability to use the XFree font antialiasing extension. I think someone even wrote a patch. Did this make it into the cvs head? I'm willing to write a patch in my spare time to do this if it hasn't been done.

DKF notes that there was a patch, but it was too grotty to go in as-is.

DKF: See Tk patch #535541 [L4 ]

See also Xft support

IMPLEMENTED!

Lars H: Cubic Bezier curves on the canvas. The current smooth curve are quadratic splines (mostly), and those are much too rigid (there is not much freedom in a segment) for my taste. Another annoying feature is that the only points you specify that actually fall on the spline are the endpoints. Cubic curves are what is used in the PS/PDF world, and supporting those in the canvas would simplify having the same curve in the canvas as in a PDF.

KPV See Cubic Splines.

FYI: one thing to know about the current spline system is that the spline will pass through the midpoint of the line segment between to control points. You can exploit that to force the spline through specific points. BTAIM, I'd still also like cubic splines. KPV

Lars H (2 April 2003): I just read about TkSpline [L5 ]. Does anyone know if these are true cubic splines, or just quadratic splines with an interface similar to the traditional cubic ones? (Either way would be an improvement on the current interface.)

JCE TkSpline just uses the spline code already in the canvas widget. It just bypasses the smoothing function to give access to the spline control points.

Lars H (20 December 2003): Having (finally) looked at how the -smooth option is implemented in the core (mostly in the TkMakeBezierCurve function of tkTrig.c, it seems), I am nothing short of amazed; the thing nearly qualifies as built-in uselessness! A -smooth true line or polygon geometrically becomes a spline whose curve segments are parametrized by quadratics. What is strange is that these curve segments are converted to cubic Bezier curves before they are rendered. Tk can render arbitrary cubic paths (as used in Postscript and friends) on the canvas, but this functionality is hidden from the script level!

Lars H (3 February 2004): I went ahead and TIPed my wish; see TIP 168 [L6 ].

IMPLEMENTED!

Ability to attach random data to an event -- particularly virtual events -- so they can be used as a general message-passing mechanism.

(Also from Bryan Oakley)

DKF - This is closely related to, but not the same as, TIP#42 [L7 ]

DKF / 11Mar2003 - I perhaps should note that this is definitely a feature that I'd like to see in the core. :^)

DKF: See TIP#165 [L8 ]

IMPLEMENTED!

MSW / 20. Feb 2003:

    % event add <<Banzai>>
    >> mind the lacking association with an actual event-sequence,
    >> i.e. TRUE virtual events.

DKF - I thought we supported virtual events without real event sequences backing them up already. In fact, I believe the core already uses quite a few of them for things like delivering modification notifications to text widgets...

MSW: If so, since when (and if so, I'll delete that point of course)?

    % info patchlevel
    8.3.3
    % event add <<Banzai>>
    wrong # args: should be "event add virtual sequence ?sequence ...?"

DKF - I think you can just use the virtual event without having to [event add] it first...

EB: Yes, no need to add, just generate:

    % info patchlevel
    8.4.1
    % event generate . <<Banzai>>
    % bind . <<Banzai>> {puts "Banzai!"}
    % event generate . <<Banzai>>
    Banzai!

MSW: aha! sorry then, feel free to delete this entry & thanks for the clarification :)

36. FW: An ability to set a scrollbar as disabled in Windows (usually represented as the scrollbar being "grayed out"). This is the recommended behavior for scrollbars that are not presently needed on Windows - at the moment, Tk handles this by simply making the elevator occupy the entire scrollbar.

DKF - This behaviour might have actually been implemented in 8.4.2 as part of fixing a bug! :^)

FW: Which bug? The one where the scrollbar locks up if you try to grab the elevator on a scrollbar that is not needed? 'Cause that happens for me.

DKF: Yes. That one.

FW: Yep, it is a general bug with Windows XP (unneeded but non-disabled scrollbars lock up when you try to manipulate their elevator), and now the disabling behavior has been implemented for all Windowses. Whee!

DKF: Perhaps I should contribute mine...? KPV or mine at Another Font Chooser Dialog. I'm quite pleased with this dialog, it's virtually identical to the native windows one, but it's all tcl and thus cross-platform.

40.1. FW: Access to the platform's native font selector, in a similar fashion to tk_chooseColor. This could revert to a Tcl version like chooseColor does.

Wish fulfilled by TIP#324 [L9 ].

IMPLEMENTED!

Bryan Oakley In Tk 8.5, there is ttk::combobox.

IMPLEMENTED!

male - Why the combobox is implemented? Again - repeating the words about the ttk::notebook, I won't switch to ttk only because of the need to have a combobox. Even the combobox should be part of the widget collection of the "old fashioned" Tk core! So the combobox is NOT implemented!

And ... in my eyes it is sad, that only the ttk widget set seems to be the level of development, that the original Tk gets lost behind ttk. Both should be nearly equal widget sets! And nearly equal means not that Tk has a subset of ttk widgets. So ... what's about setting a Tk compatible API over ttk and get rid of all the "old fashioned" Tk widgets? Or is the future plan to call the Tk widgets depreciated and to use ttk as the new Tk?

DKF: There's insufficient effort to do exactly what you seek, and on at least two supported platforms, what you want to do would just produce utterly sucky GUIs anyway. If you disagree, implement it yourself or hire someone to do it for you.