Projected for after 8.6.0 (they represent co-distributed packages, not Tcl itself in a sense):
|Harald Oehlmann||TIP #399||Dynamic Locale Changing for msgcat||Likely to be Withdrawn and superseded by TIP #412 (desired functionality is not acheved)|
These are all the current “Priority 9” bugs in the Tcl and Tk trackers, and all should be either fixed or reduced in priority (i.e., marked as not being really blockers) before 8.6.0 is released. Note that just because a bug is assigned to someone doesn't mean that they have to be the person to fix it. It's just formally their responsibility; they can also badger someone else into actually doing it…
|[L1 ]||Tcl||thread::cancel not reporting error||mistachkin||semantics|
|[L2 ]||Tcl||lappend inconsistency with respect to read traces||hobbs||semantics|
|[L3 ]||Tcl||http::geturl abuses vwait on async call||patthoyts|
|[L4 ]||Tk||Crash in open/save file dialog in Windows 7 libraries||hobbs||crash|
|[L5 ]||Tk||Change to grab on windows breaks application behaviour||patthoyts||semantics|
|[L6 ]||Tk||wish8.5 hangs up in tkcvs and nVidia driver. wish8.4 working||hobbs||portability|
|[L7 ]||Tk||Win32 menu keyboard traversal broken||tmh||portability|
|[L8 ]||Tk||Windows-style Open and Save file dialog on Unix||dkf||usability/GOOBE|
|[L9 ]||Tk||TIP 145: Font handling enhancements||pt||TIP impl.|
|Link||Module||Feature Request Title||Who||Categorization|
|[L10 ]||Tcl||Add msgcat current file local||oehhar||msgcat package improvement|
|[L11 ]||Tcl||override-able CFLAGS?||dgp||build|
LV - 2009-10-28 07:50:11
I don't notice this bug, listed 2762041 , in the list above. Is it too hard, or deemed harmless enough, to not make it into the next release?
dkf - 2009-10-28 10:27:52
It's not too hard, and there's no reason at all to not fix it; we're just not currently planning to block the release until it is fixed. In fact, of the ones above some are probably not release blockers either, and shouldn't be prio9. From the perspective of the roadmap, it is the blocking issues that are critical...
LV - 2009-10-28 12:34:37
Okay, that makes sense. I just was uncertain how the determination of where the bug fixes stop and the release happens worked. Thanks DKF!
dkf - 2009-10-28 17:42:00
Sometimes prio9 bugs come and get fixed so fast they don't have time to show up here (as this list is manually maintained). For example issue#2888044 came and went too fast for me to note...
thomasmenez - 2009-11-30 13:29:00
Why not add SF queries links to have up-to-date bug lists ? And get rid of those 'manually maintained' tables...
Note : I had to tweak SF URLs a bit (I actually removed the brackets) as this Wiki page was unable to display them correctly. Fortunately, those tweaked SF links still work that way.
dkf - 2009-11-30 08:50:29
The links in the summary table are live, and have been for a while. Or at least they work for me. Part of my reasoning for listing them here is as part of a "naming and shaming" exercise. It helped prompt me to nail a lot of the bugs that had been assigned to myself ...
Martyn Smith - 2010-03-27 10:00:55 Donal is there any particular reason why Schelte Bron's File selection dialog for Tile could not be used as the replacement for tk_getOpenFile, I use is in a few applications and have not had any problems so far ?
Maybe the license is not compatible it says # Copyright (C) Schelte Bron. Freely redistributable. And there does not seem to be a specific license file.
dkf - 2010-03-27 10:53:44
Quite apart from the fact that I'm not keen on having directories separate, I'd like to be able to do things like having a details view so that I can do things like sorting by file mtime.
I'm also taking the opportunity to work on changing the previously-existing megawidgets used to implement the dialog into more robust things. Who knows, the framework that comes out of that might be properly published in 8.7...
Martyn Smith - 2010-03-27 18:55 Have you looked at the little tool menu, I unselected 'Separate Folders' and then selected 'Detailed View' the sort/reverse sort by date and folders first options are also available. It only seems to be missing the click on the titles to change the sort order. Maybe treeview would look good here.
Schelte Bron - 2010-06-10 The license was just slapped on there as suggested by Joe English. Any license that makes it fit for inclusion in Tk is fine with me. I sent the code to Joe for exactly that purpose in the first place.
At the time I started writing the dialogs, ttk::treeview still had several serious shortcomings, especially on unix/linux. That has improved by now, so probably the code could be simplified and/or functionality enhanced by using ttk::treeview.
RLH - 2011-05-31 In a very real sense, does anybody really follow this?
DKF 2011-06-01: Not really. :-(
witek 2012-01-26 it seems 8.6 is approaching asymptotically and never really comes.
APE 2012-03-27 : Did you notice that the 8.6 development started nearly 4 years ago ? It could be great if we can have an update of the schedule to know when it will be available. Thanks !
MG Are there any recent 8.6 Tclkits available? I found a "tclkit86b1.2.exe" for Windows, but it predates the feature I wanted 8.6 for (native/built-in IPv6 support), and I can't find anything more recent. Not sure if anyone is actually building them while 8.6 is still in beta, but if so I'd be very grateful for a link (for Windows and Linux, ideally). Thanks. :)
RLE (2011-06-01) Tclkit Kitgen Build System will build 8.6 Tclkits, but I don't know if the version it builds includes what you desire. On Linux it works quite well, I built some 8.6 tclkits with it a month or so ago and it worked fine once I updated a couple URL's in the script that had changed (unless that has been fixed now). There is also Building Tclkit with kitgen on Windows but I have no input on how well that works as I avoid windows myself.
APN Check out http://www.rkeene.org/devel/kitcreator/kitbuild/nightly/ from Roy Keene for daily builds on multiple platforms.
MG Awesome, thanks for the quick responses, guys.
LV The tip at https://www.tcl-lang.org/cgi-bin/tct/tip/311 only covers changes through 2010 releases of 8.6. Have any additional tips been implemented in 8.6 since that time? Has there been any discussion regarding freezing features for 8.6.0 and releasing it and doing subsequent work against 8.6.1 and beyond?
DKF: Since it is manually-maintained, it only gets changed occasionally.
HaO: 2012-12-06 Donald Porter posted on MS VC++ build using win/Makefile.vc on the tdbc-devel list:
HaO: 2012-12-07 Twylite gave on tdbc-devel those two contributions, one to enlight cmake and one to compare build methods:
I'd really like to convince you that CMake should replace NMake for Windows only (thus not 'another'). A cross-platform cmake build by comparison would be 'another' build method to maintain, because I can't see everyone agreeing to drop autoconf. I've looked at the work that Clifford Yapp has done on a cross-platform CMake build (http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2011/CliffordYapp/tcltk_cmake_paper.pdf) and it's really good, but it tries to shoehorn the Windows build into a Unix model, and in doing so it reproduces a bunch of the complexity and problems of the current (autoconf + NMake) approach. The build - and particularly the install - needs of Windows are different from *nix. You _can_ support both in one build system, but when you do you end up complicating the *nix build and getting an un-Windowsy result on Windows. You also end up with frequent breaks of the Windows build when developers on a *nix platform make non-trivial updates to the build files (and that's a problem in Tcl where there are relatively few developers building on Windows). The main reason why I started work on a CMake build was to be able to build Tcl extensions. Tcl went through about a four-year period of chronic build failures on Windows (from 2007 to 2011 I could not once check out HEAD/trunk from Tcl, Tk, Itcl, Thread and get a successful build+install using NMake), and many other extensions had woefully out of date NMake support (or none at all). I'm no stranger to NMake, but getting an extension building and installing with it is not a task for the faint of heart. Even maintaining an NMake build over time is tricky. I wanted something that I could easily use to get extensions building, and that would be easy for a non-Windows developer to set up (with a high chance of success). That is why Coffee (my CMake builds) focuses on _really simply_ CMakefiles and targets Windows only. The CMakefile feels more like a config.in than a Makefile.in. You can't achieve that level of simplicity in a cross-platform build. TL;DR: replace NMake with CMake, then we have the same number of supported build methods, but the build is easier to maintain on Windows and supports more compliers.
and a reply to me:
> I will not try CMake, as it will not bring us further to the aim. I agree with that approach, which is why I contributed the attempt at a makefile.vc for tdbcodbc. I would like to see a move to CMake in the longer term, but it won't help towards an 8.6.0 release. > There should be a general decision like: > 1) we use CMAKE and MSVC++ 6,7,8,9,10 (any set of them) Yes. In fact the CMake team made specific changes to support the path quoting needed for pkgConfig defines passed in from the build file, which require some really weird quoting in MSVC 6 and 8 project files. > 2) we use NMAKE and MSVC++ 6,7,8,9,10 (any set of them) What we have now. Painful to maintain, and doesn't allow Windows users to work in the MSVC IDE, use interactive debugging, use third-party memory checking tools, etc. > 3) we use cygwin/msys make and MSVC++ 6,7,8,9,10 (any set of them) Over the past couple of years the msys installer has been broken on and off for months. It is not acceptable to rely on a technology that is not itself reliable. Using msys also means requiring Windows developers to learn how to use a *nix shell prompt, maintain builds using autoconf (which is itself a black art), and not use the MSVC IDE and its facilities (as mentioned above). In short it's just keeps Windows as a second-class environment for Tcl development.