Site Home > Tk Revitalization > Widget Changes
Key Pages
ProjectsWhat changes need to be made to the existing widgets, e.g. configuration option defaults that need to be changed. We can get a good start here with what people like Brian Griffin have already done.
For those that have not already read Brian's paper, here it is: [link]
Actions Items:
Here are some thoughts on how the Unix version can be improved. The default background color for the following widgets should be white: entry, listbox, and text. I think this follows the Windows way, as well as most other toolkits. Actually, background color and other similar factors have defaults which the user can override via either themes or by individual selection (I do it myself, liking a much more muted palette). Tk on Windows should honor those settings as far as is easily doable. Steve Simmons
Better yet here are some options:
option add *background #dfdbd7 option add *Listbox.background white option add *Listbox.selectBorderWidth 0 option add *Listbox.selectForeground white option add *Listbox.selectBackground #4a6984 option add *Entry.background white option add *Entry.selectBorderWidth 0 option add *Entry.selectForeground white option add *Entry.selectBackground #4a6984 option add *Text.background white option add *Text.selectBorderWidth 0 option add *Text.selectForeground white option add *Text.selectBackground #4a6984 option add *Menu.activeBackground #4a6984 option add *Menu.activeForeground white option add *Menu.activeBorderWidth 0 option add *Menu.highlightThickness 0 option add *Menu.borderWidth 2 option add *MenuButton.activeBackground #4a6984 option add *MenuButton.activeForeground white option add *MenuButton.activeBorderWidth 0 option add *MenuButton.highlightThickness 0 option add *MenuButton.borderWidth 0 option add *highlightThickness 0 option add *troughColor #bdb6ad
I think the Unix version of Tk could be greatly improved with very little effort if a few keys widgets were changed. If you closely compare the default Gtk theme to Tk you'll notice that there really is only a few minor differences in the way widgets are drawn. I spent about 2 hrs tweaking the Unix Tk code and was able to get the scrollbar and button widgets to draw just like Gtk. Ok, some of you might not like that look but its my opinion that it is a big improvement. So with that said I think that the scrollbar, frame, labelframe, radiobutton, and checkbutton should be every so slightly tweaked to draw themselves differently. For instance the checkbutton should more closely match Windows/Gtk by drawing a square sunken box with a checkmark inside if its checked. I really think these types of changes are easy and will make a huge impact on Unix Tk. Another thing that might make a huge improvement is to change the way Tk draws the 3d rectangle, a slight change to this code and we could reap the benefits throughout Tk. I'll put up some screenshots if someone is interested. Yes please! - Mark
Screenshots of my quick changes to the button and scrollbar are here: [link]
To get even more nit picky simple things like increasing the "cell" padding in the listbox would add to the look of the listbox.
Brian Griffin: I've already implemented a patch to the *nix checkbutton/radiobutton that changes to the *indows style. TIP#109: [link]
Posted at Aug 13/2003 04:17 PM:
DKF: FWIW, I should be checking TIP #109 into the core in a few hours. Should we pretend that is a product of the revitalization project? ;^)
Posted at Aug 14/2003 07:24 AM:
DKF: #109 is now in the core. A quick note for everyone: please remember to test your changes, since the #109 sample implementation caused crashes and had to be immediately debugged... :^/
Brian Griffin: I too was recently thinking about the Tk 3d drawing. It should be using 2 ligher and 2 darker colors instead of just 1. This would give it a softer, more round looking 3d effect.
DKF: Tk didn't used to do that because it really sucked on 256 colour displays. But there's no reason to not use a more rounded look (similar to what Windows actually does) when the pixmap depth is 15 or more.
Jeremy Collins: I've submitted a patch for improved 3D borders. [link]
Removed discussion started by Joe English about doing a NextStep like scrollbar, e.g. [link], which would be outside the goals of this project. - Mark
May I ask why that was deemed outside the goals of the project? It would be a small change to the look & feel, with a big (positive) impact on usability. And it's not a major departure from established conventions, either -- Mac OS X and several Gnome and KDE themes have adopted the same layout for scrollbars. - Joe
Jeff Godfrey: tk_getOpenFile / tk_getSaveFile on Windows do not expose all the options that are available to the raw Win dialogs. For example, the Windows "fileOpen" dialog has the ability for the User to specify the name of a non-existent file, but TK does not expose this ability. Kevin Kenny looked into this for me recently and thought it would be fairly trivial to expose the missing functionality.
Will Duquette: Ideally, we don't simply want to expose the missing functionality; we want to expose it, and then update the pure-Tk dialog to work the same way.
TFW: Another thing missing on windows is the ability to resize the tk_*File and tk_chooseDirectory dialogs. - Oops, the tk_*File dialogs do resize, just need the tk_chooseDirectory to resize.
Jeff Godfrey: Is that really a matter of missing functionality at the Tk level, or more a matter of *which* common dialog set Tk is using? I think it uses some of the older(est?) versions of the file dialogs available. I'd like to see them upgraded to some of the newer ones also - which I assume gives us (among other things) the ability to resize by default (maybe not?)...
Vince: Most (all?) platforms allow one to extend the native dialogs with application-specific code (to preview, for example, or add a few checkboxes for special file options). It would be very nice if some portion of this could be exposed to Tk, and work cross-platform. Best would be if one could create a few Tk frames which go into the dialog (I assume each platform has some standard locations into which such frames would slot: e.g. right hand side, or bottom).
Will Duquette: Also on the topic of widget changes--we should update the panedwindow widget so that it handles window resizing in a sensible way.
Joe English: That's a good question: how _should_ panewindows resize? There was considerable discussion on this issue on tcl-core when the panedwindow was added (TIP 41), but I don't think a conclusive conclusion was reached. See <URL: http://sourceforge.net/mailarchive/forum.php?forum_id=3854 >, search for "panedwindow" for the discussion. My thoughts are here: <URL: http://sourceforge.net/mailarchive/message.php?msg_id=371285 >.
Posted at Aug 15/2003 08:37 AM:
Will Duquette: I'm a newcomer to the discussion; all I know is, I spent a good bit of the last week trying to get panedwindow to react sensibly, and couldn't. Here's the simple case: a large window, containing two scrolled text widgets, each in a pane of a paned window. Each scrolled text should initially be 80x25 characters; the overall window should be big enough to contain the whole thing. If I resize the window, the panes should resize as well; proportional resizing would be nice, but isn't required. The point is, the scrolled text widgets within the panes should be resized to fit the panes. They do when the window is enlarged; but they don't when the window is made smaller.
Typically, what happens is one of the scroll text widgets gets clipped. And here's the real bit of poison--the size at which it gets clipped can grow larger over time, but it never gets smaller.
What it really comes down to is that panedwindow should support packing or gridding within its panes, so that the programmer can explicitly describe the behavior they want.
Posted at Aug 15/2003 03:05 PM:
DKF: I think there was a bug fixed in this area recently. Were you testing with 8.4.4 or an earlier release? (I also suspect that this is starting to get off-topic.)
Posted at Aug 18/2003 09:09 AM:
Will Duquette: I was using 8.4.2; I'll give it a try with 8.4.4.
Posted at Aug 19/2003 09:58 AM:
Damon Courtney: Jeremy Collins' 3d patches look pretty damn good if you ask me. Of course, I would also love options to specify the border color. As it stands now, while writing theme support for XP, I have to create a frame of the border color I want and then drop a flat entry into the frame to create the border color.
Sho' would be nice if I could specify that. 0-]
Posted at Aug 20/2003 10:32 PM:
Damon Courtney: Has anyone taken a look at Jeremy's patches? Any of you core guys think maybe they're worth moving into the core as part of this revitalization project?
Posted at Aug 21/2003 02:54 AM:
DKF: His Win border patch has gone in. His X11 border patch is waiting for someone to have the time to review it.
Posted at Aug 21/2003 04:32 AM:
Jeremy Collins: Just to be clear, I'm still actively working on these patches. Joe English pointed out that my 3D border patch for Unix made the interface look inconsistent so I'm trying to fix that by updating other widgets. So far I've sort of got new looking scrollbars working, a new arrow for cascading menus, and new menubuttons, as well as even better (better == more windows like) 3D borders.
Posted at Aug 21/2003 08:34 AM:
DKF: OK, cool.
Posted at Aug 25/2003 10:35 AM:
DGP: So has anyone signed up
Jeremy Collins to be the Tk
maintainer for the appropriate
Categories ? :D
Posted at Aug 25/2003 02:23 PM:
DKF: That's not my job; I'm not a Tk project admin, unlike you Don... ;^)
Posted at Aug 25/2003 03:13 PM:
Will Duquette: I've tried panedwindow with Tcl 8.4.4. It fixes one piece of behavior, but leaves the widget still broken. When managing two text widgets with a sash in between, the second now resizes appropriately when the toplevel is resized. However, the panedwindow will never resize the first text widget when the toplevel is resized; once the second text widget is as small as it can go, the the panedwindow retains that size and gets clipped instead.
Posted at Aug 27/2003 02:57 PM:
Ala: How about support for transparent backgrounds through a mask? This can allow for non-rectangular toplevels.
Posted at Aug 28/2003 05:35 AM:
DKF: The hard bit is working out an abstraction for describing non-rectangular shapes. Once you've got that, the rest is pretty easy. (Just programming!) I've even got some code [link] that can do that, and which I've been meaning to try to get into Tk for years. It's just that there's always been something more pressing to do first... :^/
Posted at Sep 20/2003 08:59 AM:
DKF: Just a note to say that it is highly likely that I will be making Tk correctly handle the display of images with non-trivial alpha channels. Right now, it makes a bit of a pig's ear out of it...