From: Daniel A. S. <da...@us...> - 2009-05-17 08:49:08
|
Hi All, as you may know, I have been working on a port of TkAqua to the Cocoa API for some time, with the goal to get TkAqua to run on 64bit, and to move away from Mac OS X Carbon API that has been deprecated. The Cocoa port has now been feature complete for about a month and I believe is of equal or better quality than the existing TkAqua implementation, it has been built, tested and is already being used successfully by various parties, and IMO is now ready to be merged into the Tk mainline. The port is available as patches against HEAD (large!) http://www.categorifiedcoder.info/tcltk/patches/tk-de-carbon.diff.bz2 http://www.categorifiedcoder.info/tcltk/patches/tcl-de-carbon.diff.bz2 or from github with full history: http://github.com/das/tcltk/commits/de-carbon The patch to Tcl only touches the macosx README and the Xcode projects, related generally applicable changes to Tcl (in particular the revised macosx notifier) have already gone in a few weeks ago for 8.5.7. The principal new constraint of the TkAqua Cocoa port is that it requires Mac OS X 10.5 or later (TkAqua currently requires Mac OS X 10.3). After discussion with Jeff and other TkAqua maintainers and distributors, we have decided that the Tk 8.6 release is a reasonable moment to drop support for pre-10.5 OS X, as users who still need to run on earlier OS versions should be able to remain with 8.5 for some time. There is a 8.5 backport of TkAqua Cocoa, which I will continue to maintain as a fork at github (to avoid a system requirements jump in a 8.5 point release): http://github.com/das/tcltk/commits/de-carbon-8-5 There should be no script-visible changes to standard Tk functionality introduced by the Cocoa port; there are some additions of TkAqua-specific functionality (c.f. excerpt from tk/macosx/README below) and a few removals of obsolete unsupported Carbon-specific bits in the tk::mac namespace. Various longstanding missing features have been implemented (e.g. [wm aspect]) and a number of bugs tightly tied to the old implementation are fixed by the rewrite. Drawing performance is also significantly improved (e.g. >2x speedup of a benchmark that draws many short lines on a canvas). At the public Tk C API level, there is a tiny signature change to macosx-specific API in the public plat stubs table (replacing two Carbon pointer types that should never have entered a public x-plat header by void*). Otherwise, public API is unchanged and extensions that use only public Tk API are unaffected and should continue to work unchanged (verified with extensions like TkImg and TkTable). Thus I believe there is no requirement for a TIP for the integration of the Cocoa port changes. There are also no additions/removals to the private plat stubs table, but a significant number of signature changes (mostly turning more Carbon pointer types into void*). However, many of the macosx private stubs API calls had unfortunately exposed details of the internal Carbon implementation that could not be preserved, such calls had to be neutered and are now just NOPs. Tk extensions that rely on these or make other assumptions about TkAqua internals (like the presence of QuickDraw and QD ports) will have to be ported to support TkAqua Cocoa (e.g. Treectrl and Tile are known to be affected). I am planning to move forward with the merge tonight (CEST), so if you have objections, please speak up soon! Cheers, Daniel -- ** Daniel A. Steffen ** ** <mailto:da...@us...> ** ==== From tk/macosx/README ==== - The default metrics of native buttons, radiobuttons, checkboxes and menubuttons in the Cocoa-based Tk 8.6b2 and later preserve compatibility with the older Carbon-based implementation, you can turn off the compatibility metrics to get more native-looking spacing by setting: set tk::mac::useCompatibilityMetrics 0 - TkAqua provides access to native OS X images via the Tk native bitmap facility (including any image file readable by NSImage). A native bitmap name is interpreted as follows (in order): - predefined builtin 32x32 Tk icon name (stop, caution, document, etc) - name defined by [tk::mac::iconBitmap] - NSImage named image name - NSImage url string - 4-char OSType of IconServices icon the syntax of [tk::mac::iconBitmap] is as follows: tk::mac::iconBitmap name width height -kind value where -kind is one of -file icon of file at given path -fileType icon of given file type -osType icon of given 4-char OSType file type -systemType icon for given IconServices 4-char OSType -namedImage named NSImage for given name -imageFile image at given path This support was added with the Cocoa-based Tk 8.6b2. - TkAqua cursor names are interpred as follows (in order): - standard or platform-specific Tk cursor name (c.f. cursors.n) - @path to any image file readable by NSImage - NSImage named image name Support for the latter two was added with the Cocoa-based Tk 8.6b2. - The standard Tk dialog commands [tk_getOpenFile], [tk_chooseDirectory], [tk_getSaveFile] and [tk_messageBox] all take an additional optional -command parameter on TkAqua. If it is present, the given command prefix is evaluated at the global level when the dialog closes, with the dialog command's result appended (the dialog command itself returning an emtpy result). If the -parent option is also present, the dialog is configured as a modeless (window-modal) sheet attached to the parent window and the dialog command returns immediately. Support for -command was added with the Cocoa-based Tk 8.6b2. - The TkAqua-specific [tk::mac::standardAboutPanel] command brings the standard Cocoa about panel to the front, with all its information filled in from your application bundle files (i.e. standard about panel with no options specified). See Apple Technote TN2179 and the AppKit documentation for -[NSApplication orderFrontStandardAboutPanelWithOptions:] for details on the Info.plist keys and app bundle files used by the about panel. This support was added with the Cocoa-based Tk 8.6b2. - TkAqua has three special menu names that give access to the standard Application, Window and Help menus, see menu.n for details. Support for the Window menu was added with the Cocoa-based Tk 8.6b2. - The TkAqua-specific command [tk::unsupported::MacWindowStyle style] is used to get and set Mac OS X-specific toplevel window class and attributes. Note that the window class and many attributes have to be set before the window is first mapped for the change to have any effect. The command has the following syntax: tk::unsupported::MacWindowStyle style window ?class? ?attributes? The 2 argument form returns a list of the current class and attributes for the given window. The 3 argument form sets the class for the given window using the default attributes for that class. The 4 argument form sets the class and the list of attributes for the given window. Window class names: document, modal, floating, utility, toolbar, simple, help, overlay Window attribute names: standardDocument, standardFloating, resizable, fullZoom, horizontalZoom, verticalZoom, closeBox, collapseBox, toolbarButton, sideTitlebar, noTitleBar, unifiedTitleAndToolbar, metal, hud, noShadow, doesNotCycle, noActivates, hideOnSuspend, inWindowMenu, ignoreClicks, doesNotHide, canJoinAllSpaces, moveToActiveSpace, nonActivating Note that not all attributes are valid for all window classes. Support for the 3 argument form was added with the Cocoa-based Tk 8.6b2, at the same time support for some legacy Carbon-specific classes and attributes was removed (they are still accepted by the command but no longer have any effect). - The Cocoa-based TkAqua can be distinguished from the older Carbon-based version via the [winfo server .] command, example output on Mac OS X 10.5.7: Cocoa-based: CG409.3 Apple AppKit GC 949.46 Mac OS X 1057 Carbon-based: QD10R30 Apple 1057 |
From: Daniel A. S. <da...@us...> - 2009-05-17 09:54:28
|
Hi Adrian, On Sun, May 17, 2009 at 11:27, Adrian Robert <adr...@gm...> wrote: > Are there / will there be backports of the PNG and font chooser features (to > be) introduced in 8.6 to 8.5? It would be nice to bring those features to > Tiger users. 8.5 is feature frozen, so not likely to happen > Failing that, what about delaying the merge, if it is going to remove > aqua-carbon as well, it will > until after 8.6b2 is released, so the PNG and zlib > functionality can make it in to a release, albeit a beta one? This would > also allow for a period of wider testing of the Cocoa implementation (from > people using CVS head) before putting it into a release. if it goes into the CVS head now it goes into 8.6b2... IMO delaying the merge post 8.6b2 will significantly reduce the amount of testing the cocoa port receives before 8.6 goes final, so I'm not too keen on that > One functionality question: two major gaps in the aqua-Carbon functionality > were support for Services and support for Asian language text input. Are > these remedied in Cocoa services, no, were you thinking of a Tk app as a service consumer? for what kind of services, modification of text selection in a text widget? there is no provision for that sort of thing in the generic tk text widget code ATM, so it would need generic (TIPable) changes, feel free to write something up (e.g. [clipboard] based), it would probably not be very hard to add once a design is nailed down (services API is pasteboard based and very similar to the pasteboard use in the clipboard code in TkAqua Cocoa). Asian language text input does not work currently, along with other advanced cocoa text input features, mainly because Tk text input is based on raw key events and we do not use the full cocoa text input pipeline. It is not clear to me ATM how we can preserve Tk's requirement to bind to raw key events (with any modifier) without relying on raw key events. Cheers, Daniel -- ** Daniel A. Steffen ** ** <mailto:da...@us...> ** |
From: Adrian R. <adr...@gm...> - 2009-05-17 14:37:52
|
On May 17, 2009, at 4:54 PM, Daniel A. Steffen wrote: >> One functionality question: two major gaps in the aqua-Carbon >> functionality >> were support for Services and support for Asian language text >> input. Are >> these remedied in Cocoa > > services, no, were you thinking of a Tk app as a service consumer? for > what kind of services, modification of text selection in a text > widget? > there is no provision for that sort of thing in the generic tk text > widget code ATM, so it would need generic (TIPable) changes, feel free > to write something up (e.g. [clipboard] based), it would probably not > be very hard to add once a design is nailed down (services API is > pasteboard based and very similar to the pasteboard use in the > clipboard code in TkAqua Cocoa). It would be good to support service provision at the script level -- allow a script to be called when an info.plist-specified service is requested from the app. On the consumer end, some sort of selection modification would be a good long-term goal, but most services are not of this type, but more along the lines of "open XX in YY", or "new window with selection", etc. that only need the clipboard to be sent. If I get some time I'll try to propose something more specific. > Asian language text input does not work currently, along with other > advanced cocoa text input features, mainly because Tk text input is > based on raw key events and we do not use the full cocoa text input > pipeline. It is not clear to me ATM how we can preserve Tk's > requirement to bind to raw key events (with any modifier) without > relying on raw key events. Multi-keystroke input methods (e.g. for Chinese characters) work in Tk under Windows currently, so maybe the raw vs. processed issue for bindings could be handled the same way as there. Implementation- wise, an NSView can implement the NSTextInput protocol and have access to both the raw keys and the characters composed by whatever system input manager is active. (The Cocoa port of emacs does this.) -Adrian |
From: Lars H. <Lar...@re...> - 2009-05-17 12:22:41
|
Daniel A. Steffen skrev: > The principal new constraint of the TkAqua Cocoa port is that it > requires Mac OS X 10.5 or later (TkAqua currently requires Mac OS X > 10.3). > > After discussion with Jeff and other TkAqua maintainers and > distributors, we have decided that the Tk 8.6 release is a reasonable > moment to drop support for pre-10.5 OS X, Ouch! And me not having a single machine running 10.5. > as users who still need to > run on earlier OS versions should be able to remain with 8.5 for some > time. 8.5 won't do for me I'm afraid, but I suppose there's always the 8.6b1 I've got running now. Still, since /my/ 8.6 dependency is entirely in Tcl, I can't help wondering how much work it will be to link Tk 8.6b1 (or last pre-merge CVS version) against Tcl 8.6.0... Lars Hellström |
From: Adrian R. <adr...@gm...> - 2009-05-17 09:27:59
|
On May 17, 2009, at 3:43 PM, Daniel A. Steffen wrote: > After discussion with Jeff and other TkAqua maintainers and > distributors, we have decided that the Tk 8.6 release is a reasonable > moment to drop support for pre-10.5 OS X, as users who still need to > run on earlier OS versions should be able to remain with 8.5 for some > time. > > There is a 8.5 backport of TkAqua Cocoa, which I will continue to > maintain as a fork at github (to avoid a system requirements jump in a > 8.5 point release): > http://github.com/das/tcltk/commits/de-carbon-8-5 Hi, This is great news and thanks for the tremendous work! However, as a Tcl/Tk-based app developer, I'm concerned about the dropping of support for 10.4 (Tiger), though doing it with 8.6 is obviously better than 8.5.x. Are there / will there be backports of the PNG and font chooser features (to be) introduced in 8.6 to 8.5? It would be nice to bring those features to Tiger users. Failing that, what about delaying the merge, if it is going to remove aqua-carbon as well, until after 8.6b2 is released, so the PNG and zlib functionality can make it in to a release, albeit a beta one? This would also allow for a period of wider testing of the Cocoa implementation (from people using CVS head) before putting it into a release. One functionality question: two major gaps in the aqua-Carbon functionality were support for Services and support for Asian language text input. Are these remedied in Cocoa or are they open projects? thanks, Adrian |
From: Donal K. F. <don...@ma...> - 2009-05-18 01:01:04
|
Adrian Robert wrote: > Are there / will there be backports of the PNG and font chooser > features (to be) introduced in 8.6 to 8.5? It would be nice to bring > those features to Tiger users. The font chooser should be easy to backport; it's pretty isolated from the rest of Tk. The PNG support is trickier, since it builds on top of Tcl's embedding of zlib, though just including tkpng would work. Actually making any of these things happen, that simply requires someone to do the work. Donal. |
From: Kevin W. <kw...@co...> - 2009-05-17 15:37:53
|
Daniel A. Steffen wrote: > Hi All, > > as you may know, I have been working on a port of TkAqua to the Cocoa > API for some time, with the goal to get TkAqua to run on 64bit, and to > move away from Mac OS X Carbon API that has been deprecated. > > The Cocoa port has now been feature complete for about a month and I > believe is of equal or better quality than the existing TkAqua > implementation, it has been built, tested and is already being used > successfully by various parties, and IMO is now ready to be merged > into the Tk mainline. > > The port is available as patches against HEAD (large!) > http://www.categorifiedcoder.info/tcltk/patches/tk-de-carbon.diff.bz2 > http://www.categorifiedcoder.info/tcltk/patches/tcl-de-carbon.diff.bz2 > or from github with full history: > http://github.com/das/tcltk/commits/de-carbon > > The patch to Tcl only touches the macosx README and the Xcode > projects, related generally applicable changes to Tcl (in particular > the revised macosx notifier) have already gone in a few weeks ago for > 8.5.7. > > The principal new constraint of the TkAqua Cocoa port is that it > requires Mac OS X 10.5 or later (TkAqua currently requires Mac OS X > 10.3). > > After discussion with Jeff and other TkAqua maintainers and > distributors, we have decided that the Tk 8.6 release is a reasonable > moment to drop support for pre-10.5 OS X, as users who still need to > run on earlier OS versions should be able to remain with 8.5 for some > time. > > There is a 8.5 backport of TkAqua Cocoa, which I will continue to > maintain as a fork at github (to avoid a system requirements jump in a > 8.5 point release): > http://github.com/das/tcltk/commits/de-carbon-8-5 > > There should be no script-visible changes to standard Tk functionality > introduced by the Cocoa port; there are some additions of > TkAqua-specific functionality (c.f. excerpt from tk/macosx/README > below) and a few removals of obsolete unsupported Carbon-specific bits > in the tk::mac namespace. > Various longstanding missing features have been implemented (e.g. [wm > aspect]) and a number of bugs tightly tied to the old implementation > are fixed by the rewrite. Drawing performance is also significantly > improved (e.g. >2x speedup of a benchmark that draws many short lines > on a canvas). > > At the public Tk C API level, there is a tiny signature change to > macosx-specific API in the public plat stubs table (replacing two > Carbon pointer types that should never have entered a public x-plat > header by void*). > Otherwise, public API is unchanged and extensions that use only public > Tk API are unaffected and should continue to work unchanged (verified > with extensions like TkImg and TkTable). > Thus I believe there is no requirement for a TIP for the integration > of the Cocoa port changes. > > There are also no additions/removals to the private plat stubs table, > but a significant number of signature changes (mostly turning more > Carbon pointer types into void*). > However, many of the macosx private stubs API calls had unfortunately > exposed details of the internal Carbon implementation that could not > be preserved, such calls had to be neutered and are now just NOPs. Tk > extensions that rely on these or make other assumptions about TkAqua > internals (like the presence of QuickDraw and QD ports) will have to > be ported to support TkAqua Cocoa (e.g. Treectrl and Tile are known to > be affected). > > I am planning to move forward with the merge tonight (CEST), so if you > have objections, please speak up soon! > > Cheers, > > Daniel Daniel, Congratulations on this major accomplishment. It ensures that Tk will remain viable on OS X for years to come. All of us developing in Tk on the Mac thank you. Best, Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Youness A. <kak...@ka...> - 2009-05-17 19:58:08
|
On Sun, May 17, 2009 at 10:43:49AM +0200, Daniel A. Steffen wrote: > Hi All, > > as you may know, I have been working on a port of TkAqua to the Cocoa > API for some time, with the goal to get TkAqua to run on 64bit, and to > move away from Mac OS X Carbon API that has been deprecated. > > The Cocoa port has now been feature complete for about a month and I > believe is of equal or better quality than the existing TkAqua > implementation, it has been built, tested and is already being used > successfully by various parties, and IMO is now ready to be merged > into the Tk mainline. wow, that's great news for the Tk community! Thanks alot for all of your hard work! > The principal new constraint of the TkAqua Cocoa port is that it > requires Mac OS X 10.5 or later (TkAqua currently requires Mac OS X > 10.3). > That's a big issue for us.. Isn't it possible to have Tk use Carbon on < 10.5 and use Cocoa on > 10.5.. I'm sure it adds more work and maintainance, but it would allow a broader audience to use Tk apps... forcing the use of 10.5 for Tk is not such a great idea...i However, app developers could ship their products with 8.5 bundled for < 10.5 and 8.6 bundled for >= 10.5 (like we currently ship aMSN with tk 8.4 for windows 95 users and tk 8.5 for winXP+ users) KaKaRoTo |
From: <lm...@bi...> - 2009-05-17 20:40:45
|
> The principal new constraint of the TkAqua Cocoa port is that it > requires Mac OS X 10.5 or later (TkAqua currently requires Mac OS X > 10.3). Does this mean that if we upgrade to 8.6 we drop support for anything earlier than 10.5 for _all_ tk apps? Or is it only an issue if you want to use the new stuff? I.e., is it a flag day or a choice? If it is a flag day, that raises serious problems for us, we'll probably have to stay one whatever is the pre-merge. 10.5 is the current release and it's awfully hard to tell customers they have to upgrade their os that is only a couple of years old (we support other platforms with releases as old as 1996, or 13 years). Perhaps we're the only commercial vendor left using tk that is always interested in 8.6. I would have thought there are others but maybe not. Anyway, if it is a flag day let me register my strong vote against that idea. -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
From: Daniel A. S. <da...@us...> - 2009-05-17 21:57:07
|
Hi Larry, On Sun, May 17, 2009 at 22:40, Larry McVoy <lm...@bi...> wrote: >> The principal new constraint of the TkAqua Cocoa port is that it >> requires Mac OS X 10.5 or later (TkAqua currently requires Mac OS X >> 10.3). > > Does this mean that if we upgrade to 8.6 we drop support for anything > earlier than 10.5 for _all_ tk apps? yes, for TkAqua anyway, you could always fallback to TkX11 of course > Or is it only an issue if you want to use the new stuff? I.e., is it > a flag day or a choice? a flag day, IMO it is not feasible to interleave the two codebases into the same sourcefiles via #ifdefs, it would make things even less maintainable than the current Carbon code (difficult enough to maintain as is) the only reasonable other option would be to have a separate source directory in tk for the new cocoa port (or better move the contents of the current 'macosx' directory to tk/macosx-legacy or somesuch) and add a configure flag that lets you switch back to carbon. The main drawback with that idea (other than making a mess in unix/Makefile.in) are lack of maintainer resources. Quite honestly, I have zero interest in continuing to maintain the Carbon code now that the Cocoa port is done, and me being the only active Mac OS X Tk maintainer, the legacy codebase is certain to bitrot fairly quickly on the ever-changing HEAD. As evidence of this, see the rapid bitrot of the mac classic codebase (which still ships with Tcl/Tk 8.4), even though this was on a less frequently changing maintenance branch it became unbuildable pretty much immediately after I removed mac classic support from the mainline and stopped maintenance on the 8.4 codebase, and now is only so much dead weight that has been shipping with the last 10 or so 8.4 releases, all because we wanted to be prudent and not withdraw support for the platform on the stable branch at the time (in effect the users lost support very quickly anyway because nobody was maintaining the code anymore...). > If it is a flag day, that raises serious problems for us, we'll probably > have to stay one whatever is the pre-merge. 10.5 is the current release > and it's awfully hard to tell customers they have to upgrade their os > that is only a couple of years old (we support other platforms with > releases as old as 1996, or 13 years). I'm guessing that none of those have the update frequency and API churn of Mac OS X however, the Carbon API that TkAqua is using currently is EOL and in life support mode. FWIW Omni has some stats on 10.5 adoption at large, over 55% of their users are running 10.5 currently, and once 10.6 is out (which will almost certainly be before Tk 8.6 goes final), the percentage of users still running 10.4 or earlier is certain to decrease even more rapidly http://update.omnigroup.com/ > Perhaps we're the only commercial vendor left using tk that is always > interested in 8.6. I would have thought there are others but maybe > not. Anyway, if it is a flag day let me register my strong vote > against that idea. Larry, you being a commercial vendor and all, if this is a big issue for you, I would suggest you put up and provide maintainer resources for the Carbon port! If one of your engineers takes over maintaining the Carbon codebase, I will put in the time to modify the buildsystem for a parallel carbon and cocoa source dirs (which will still take several weeks to get done however, swamped with work that actually pays the bills ATM) and I will happily be the maintainer for TkAqua Cocoa only from then on and let you guys deal with Carbon... I won't put in that time however just to be left holding the bag with an unmaintained bitrotting legacy codebase that we'll be dragging around for several more years without it doing any good to anybody... Cheers, Daniel -- ** Daniel A. Steffen ** ** <mailto:da...@us...> ** |
From: <lm...@bi...> - 2009-05-19 17:55:42
|
BTW, the distribution of our customer's usage of macos is: MacOS/X 10.5 26% MacOS/X 10.4 66% MacOS/X 10.3 2% MacOS/X 10.2 5% I'm surprised to see the 10.[23] holdouts, but not at all surprised at the 10.4 vs 10.5 distribution. -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
From: Jeff H. <je...@ac...> - 2009-05-19 18:10:40
|
On 19/05/2009 10:55 AM, Larry McVoy wrote: > BTW, the distribution of our customer's usage of macos is: > > MacOS/X 10.5 26% > MacOS/X 10.4 66% > MacOS/X 10.3 2% > MacOS/X 10.2 5% > > I'm surprised to see the 10.[23] holdouts, but not at all surprised at the > 10.4 vs 10.5 distribution. A comparative number based on recent visits to a typical section of the ActiveState website (from gAnalytics): 1. Intel 10.5 14,169 79.06% 2. Intel 10.4 1,042 5.81% 3. PPC 10.4 836 4.66% 4. Intel 797 4.45% 5. PPC 10.5 729 4.07% 6. PPC 330 1.84% 7. Intel 10.6 17 0.09% 8. 68K 1 0.01% Go Mac Classic! |
From: <lm...@bi...> - 2009-05-19 18:14:05
|
On Tue, May 19, 2009 at 11:09:03AM -0700, Jeff Hobbs wrote: > On 19/05/2009 10:55 AM, Larry McVoy wrote: > >BTW, the distribution of our customer's usage of macos is: > > > >MacOS/X 10.5 26% > >MacOS/X 10.4 66% > >MacOS/X 10.3 2% > >MacOS/X 10.2 5% > > > >I'm surprised to see the 10.[23] holdouts, but not at all surprised at the > >10.4 vs 10.5 distribution. > > A comparative number based on recent visits to a typical section of the > ActiveState website (from gAnalytics): > > 1. Intel 10.5 14,169 79.06% > 2. Intel 10.4 1,042 5.81% > 3. PPC 10.4 836 4.66% > 4. Intel 797 4.45% > 5. PPC 10.5 729 4.07% > 6. PPC 330 1.84% > 7. Intel 10.6 17 0.09% > 8. 68K 1 0.01% > > Go Mac Classic! Those are pretty different numbers, you are counting web surfers. I'm counting people who actually have installed our product. Doesn't activestate have those sorts of numbers? There is a big difference between looky loos and real customers. -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
From: Jeff H. <je...@ac...> - 2009-05-19 18:26:41
|
On 19/05/2009 11:14 AM, Larry McVoy wrote: > On Tue, May 19, 2009 at 11:09:03AM -0700, Jeff Hobbs wrote: >> On 19/05/2009 10:55 AM, Larry McVoy wrote: >>> BTW, the distribution of our customer's usage of macos is: >>> >>> MacOS/X 10.5 26% >>> MacOS/X 10.4 66% >>> MacOS/X 10.3 2% >>> MacOS/X 10.2 5% >>> >>> I'm surprised to see the 10.[23] holdouts, but not at all surprised at the >>> 10.4 vs 10.5 distribution. >> A comparative number based on recent visits to a typical section of the >> ActiveState website (from gAnalytics): >> >> 1. Intel 10.5 14,169 79.06% >> 2. Intel 10.4 1,042 5.81% >> 3. PPC 10.4 836 4.66% >> 4. Intel 797 4.45% >> 5. PPC 10.5 729 4.07% >> 6. PPC 330 1.84% >> 7. Intel 10.6 17 0.09% >> 8. 68K 1 0.01% >> >> Go Mac Classic! > > Those are pretty different numbers, you are counting web surfers. I'm > counting people who actually have installed our product. Doesn't > activestate have those sorts of numbers? There is a big difference > between looky loos and real customers. You are right that they are web browsing folk. One point to note is that we recently (6 months ago) dropped 10.3 support across the board (without a single complaint that I'm aware of), so that will self-select to some extent, although they might not know that until they hit the sysreqs page. Our licensing doesn't require server callback, so it's hard to separate out exact versions on installs, but if I actually go to the analytics directly on our download site, the 10.5 number hits 87%, though again that is web hits and not a direct correlation to the platform being downloaded (these are just the easiest to browse through). Jeff |
From: Kevin W. <kw...@co...> - 2009-05-17 21:32:42
|
Youness Alaoui wrote: >> > That's a big issue for us.. Isn't it possible to have Tk use > Carbon on < 10.5 and use Cocoa on > 10.5.. I'm sure it adds > more work and maintainance, but it would allow a broader > audience to use Tk apps... forcing the use of 10.5 for Tk is > not such a great idea...i In general, Mac OS users are much more likely to have the current OS installed than users on other platforms, such as Windows. With 10.6 nearing release, 10.5 is going to become a legacy platform very quickly. > However, app developers could ship their products with 8.5 bundled > for < 10.5 and 8.6 bundled for >= 10.5 (like we currently ship aMSN > with tk 8.4 for windows 95 users and tk 8.5 for winXP+ users) > This is certainly a practical solution, but I wonder how necessary it will be. -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Youness A. <kak...@ka...> - 2009-05-17 21:51:28
|
On Sun, May 17, 2009 at 05:32:32PM -0400, Kevin Walzer wrote: > Youness Alaoui wrote: > >>> >> That's a big issue for us.. Isn't it possible to have Tk use >> Carbon on < 10.5 and use Cocoa on > 10.5.. I'm sure it adds >> more work and maintainance, but it would allow a broader >> audience to use Tk apps... forcing the use of 10.5 for Tk is >> not such a great idea...i > > In general, Mac OS users are much more likely to have the current OS > installed than users on other platforms, such as Windows. With 10.6 > nearing release, 10.5 is going to become a legacy platform very quickly. > Maybe but I'm not really convinced.. it's like people who say noone uses win95 anymore, but actually, we have quite a lot of people still using it.. maybe not in the US/Canada/Europe, but I'm sure that many people in 3rd world countries have very low end computers (because it costs a lot and the salaries there aren't as high as here), and they can't afford to have anything newer than win95... In the same logic, I'm sure many people are still keeping old legacy platforms.. we have a bunch of users complaining about aMSN crashing on Panther (10.3)... Considering that mac os X v10.2 last version was released in october 2003, I think that it's not "that old"... We are proud to say that we are here to support everyone and help everyone get aMSN working on their systems, so having as much compatibility is ncessary unfortunately even for legacy platforms... >> However, app developers could ship their products with 8.5 bundled >> for < 10.5 and 8.6 bundled for >= 10.5 (like we currently ship aMSN >> with tk 8.4 for windows 95 users and tk 8.5 for winXP+ users) >> > This is certainly a practical solution, but I wonder how necessary it > will be. It just might be necessary.. for win95, when we released aMSN 0.97 with tcl/tk 8.5 bundled, we got quite a lot of frustrated users complaining about it not working on win95... so we just had to release a version with 8.4 bundled... I'm afraid we just might get the same issue with mac users and 8.6.. > > -- > Kevin Walzer > Code by Kevin > http://www.codebykevin.com |
From: Kevin W. <kw...@co...> - 2009-05-17 21:38:50
|
Larry McVoy wrote: > Perhaps we're the only commercial vendor left using tk that is always > interested in 8.6. I would have thought there are others but maybe > not. Anyway, if it is a flag day let me register my strong vote > against that idea. I'm a much smaller commercial vendor than Bitmover that also uses Tk (exclusively) on Mac OS, and I strongly endorse the move to support only Cocoa in 8.6. 8.5 will continue to be available if you need pre-10.5 support. I am curious how many of your customers use older versions of Mac OS? The tendency among Mac users is to migrate very quickly to the latest OS release, and with 10.6 due out later this year--even in the next couple of months--10.5 will soon become a legacy platform. More importantly, the Carbon foundation that currently underlies Tk Aqua is nearing obsolescence. It doesn't support 64-bit, Apple is not doing any more development of it, and so on. The move to Cocoa ensures Tk's viability as a native toolkit on OS X for years to come. In my view that fact alone makes this a necessary move for Tk Aqua. -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Youness A. <kak...@ka...> - 2009-05-17 21:53:36
|
On Sun, May 17, 2009 at 05:38:39PM -0400, Kevin Walzer wrote: > Larry McVoy wrote: > > > Perhaps we're the only commercial vendor left using tk that is always > > interested in 8.6. I would have thought there are others but maybe > > not. Anyway, if it is a flag day let me register my strong vote > > against that idea. > > I'm a much smaller commercial vendor than Bitmover that also uses Tk > (exclusively) on Mac OS, and I strongly endorse the move to support only > Cocoa in 8.6. 8.5 will continue to be available if you need pre-10.5 > support. I am curious how many of your customers use older versions of > Mac OS? The tendency among Mac users is to migrate very quickly to the > latest OS release, and with 10.6 due out later this year--even in the > next couple of months--10.5 will soon become a legacy platform. > > More importantly, the Carbon foundation that currently underlies Tk Aqua > is nearing obsolescence. It doesn't support 64-bit, Apple is not doing > any more development of it, and so on. The move to Cocoa ensures Tk's > viability as a native toolkit on OS X for years to come. In my view that > fact alone makes this a necessary move for Tk Aqua. > I agree that the move to Cocoa is important for the Tk community, and I would definitely vote for integrating those patches.. all I'm wondering is if it's possible to have Carbon AND Cocoa support in the core.. if not, then Larry, I guess you'd have to release two bundles, one with TK 8.5 and one with Tk 8.6 for greater compatibility.. KaKaRoTo |
From: <lm...@bi...> - 2009-05-17 22:04:34
|
The issue for us is not that carbon is going away, it's that 10.4 support is going away. I'm perfectly happy to go through the growing pains of moving over to the Cocoa based aqua toolkit. What I'm not happy about is dropping 10.4 support. 10.4 is still an actively supported release, it was a good release, and as a vendor it is not my place to tell people to get off a platform before the platform is end of lifed. One of tcl/tk's claims to fame is backwards compat and platform support. Dropping 10.4 seems to run counter to the goals of the system. -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
From: Michael K. <mi...@mu...> - 2009-05-18 02:25:44
|
FWIW (not much, since our Mac user base is small and we're in no rush to upgrade to Tcl/Tk 8.6), we're still on 10.3, mostly for lacking time/reason to upgrade. But we're also still on Tcl/Tk 8.4.x (and still using separate tile and tkpng), so 8.6 not being compatible isn't likely to affect us for quite a while. We tend to lag a a fair bit in moving to new Tcl/Tk minor versions in part to ensure one of our products (which is a binary package for Tcl) is still usable (stubs-compatible) by customers with older Tcl/Tk versions. Might be different if the stubs mechanism had a way to build against a newer version of Tcl/Tk but target an older version (e.g., #define what version you want to target, and have stub APIs of later versions hidden from the compiler by #if/#endif wrappers so you get an error compiling your package if you try to use an API that didn't exist yet in the target version). But that's a big digression from the topic at hand. -- Michael Kirkham President & CEO Muonics, Inc. http://www.muonics.com/ On Sun, 17 May 2009, Larry McVoy wrote: > Date: Sun, 17 May 2009 15:04:32 -0700 > From: Larry McVoy <lm...@bi...> > To: Daniel A. Steffen <da...@us...> > Cc: tcl mac <tc...@li...>, > Tcl Core <tcl...@li...> > Subject: Re: [TCLCORE] Merging TkAqua Cocoa port into Tk HEAD > > The issue for us is not that carbon is going away, it's that 10.4 support > is going away. I'm perfectly happy to go through the growing pains of > moving over to the Cocoa based aqua toolkit. > > What I'm not happy about is dropping 10.4 support. 10.4 is still an > actively supported release, it was a good release, and as a vendor it > is not my place to tell people to get off a platform before the platform > is end of lifed. > > One of tcl/tk's claims to fame is backwards compat and platform support. > Dropping 10.4 seems to run counter to the goals of the system. > -- > --- > Larry McVoy lm at bitmover.com http://www.bitkeeper.com > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
From: <lm...@bi...> - 2009-05-17 22:08:28
|
On Sun, May 17, 2009 at 05:52:55PM -0400, Youness Alaoui wrote: > On Sun, May 17, 2009 at 05:38:39PM -0400, Kevin Walzer wrote: > > Larry McVoy wrote: > > > > > Perhaps we're the only commercial vendor left using tk that is always > > > interested in 8.6. I would have thought there are others but maybe > > > not. Anyway, if it is a flag day let me register my strong vote > > > against that idea. > > > > I'm a much smaller commercial vendor than Bitmover that also uses Tk > > (exclusively) on Mac OS, and I strongly endorse the move to support only > > Cocoa in 8.6. 8.5 will continue to be available if you need pre-10.5 > > support. I am curious how many of your customers use older versions of > > Mac OS? The tendency among Mac users is to migrate very quickly to the > > latest OS release, and with 10.6 due out later this year--even in the > > next couple of months--10.5 will soon become a legacy platform. > > > > More importantly, the Carbon foundation that currently underlies Tk Aqua > > is nearing obsolescence. It doesn't support 64-bit, Apple is not doing > > any more development of it, and so on. The move to Cocoa ensures Tk's > > viability as a native toolkit on OS X for years to come. In my view that > > fact alone makes this a necessary move for Tk Aqua. > > > I agree that the move to Cocoa is important for the Tk > community, and I would definitely vote for integrating those > patches.. all I'm wondering is if it's possible to have > Carbon AND Cocoa support in the core.. if not, then Larry, I > guess you'd have to release two bundles, one with TK 8.5 and > one with Tk 8.6 for greater compatibility.. So we've got a lot of internal development on top of 8.6 already. It's not really an option to move back to 8.5, then we chew off solving all the problems that are only solved in 8.6. It's more likely that this would be the last straw for us and we'd have to start migrating off of tcl. I'm really not sure but I know I'm going to be raked over the coals by my team and customers when they find out about this. From my point of view, dropping support for a perfectly viable platform throws into question the viability of the tk system as a toolkit. It's a big deal and if the core goes along with this I dunno what we'll do, but it won't be much fun. I wonder what the technical issues are in supporting 10.4? -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
From: Kevin W. <kw...@co...> - 2009-05-17 22:12:35
|
Larry McVoy wrote: > > What I'm not happy about is dropping 10.4 support. 10.4 is still an > actively supported release, it was a good release, and as a vendor it > is not my place to tell people to get off a platform before the platform > is end of lifed. Apple's general practice is to support the current and immediately preceding OS. Last week I downloaded my 10.5.7 update, and I also downloaded a bunch of security updates for my installation of 10.4 OS X Server. Once 10.6 is released, 10.4 will no longer receive security updates if Apple follows its traditional practice and it will be an unsupported OS. -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Daniel A. S. <da...@us...> - 2009-05-17 22:16:33
|
On Mon, May 18, 2009 at 00:08, Larry McVoy <lm...@bi...> wrote: > So we've got a lot of internal development on top of 8.6 already. > It's not really an option to move back to 8.5, then we chew off > solving all the problems that are only solved in 8.6. > > It's more likely that this would be the last straw for us and > we'd have to start migrating off of tcl. I'm really not sure > but I know I'm going to be raked over the coals by my team and > customers when they find out about this. From my point of view, > dropping support for a perfectly viable platform throws into > question the viability of the tk system as a toolkit. It's a > big deal and if the core goes along with this I dunno what we'll > do, but it won't be much fun. > > I wonder what the technical issues are in supporting 10.4? they may not be that large, I haven't looked into it frankly. Feel free to have someone at bitmover look into it, I can't justify spending time on it. FWIW I'm also quite happy to continue with the status quo, i.e. maintain the cocoa port in the gihub fork and let the tk/macosx code in CVS bitrot away, I won't be doing any more work on it, I haven't touched it since last August as is (nor has anybody else). Cheers, Daniel -- ** Daniel A. Steffen ** ** <mailto:da...@us...> ** |
From: <lm...@bi...> - 2009-05-17 22:32:32
|
On Mon, May 18, 2009 at 12:16:31AM +0200, Daniel A. Steffen wrote: > On Mon, May 18, 2009 at 00:08, Larry McVoy <lm...@bi...> wrote: > > So we've got a lot of internal development on top of 8.6 already. > > It's not really an option to move back to 8.5, then we chew off > > solving all the problems that are only solved in 8.6. > > > > It's more likely that this would be the last straw for us and > > we'd have to start migrating off of tcl. I'm really not sure > > but I know I'm going to be raked over the coals by my team and > > customers when they find out about this. From my point of view, > > dropping support for a perfectly viable platform throws into > > question the viability of the tk system as a toolkit. It's a > > big deal and if the core goes along with this I dunno what we'll > > do, but it won't be much fun. > > > > I wonder what the technical issues are in supporting 10.4? > > they may not be that large, I haven't looked into it frankly. Feel > free to have someone at bitmover look into it, I can't justify > spending time on it. I can understand that, everyone is busy. Unfortunately, I'm basically the only person at BitMover that is in favor of using the tcl/tk system. I've fought for years to stay on it for the cross platform cost savings but it's not been easy. We have daily arguments about whether something else would be a better choice. The reality is that if I were not the guy in charge we would have long since moved off. If I show up and tell the team that the tcl core team has decided to drop support for a current major platform and our only answer is to do the work ourselves, they'll crucify me. I'll be faced with a screaming pile of I-told-you-so's. Not your problem, I'm just giving a glimpse into the hell that is my management life. For me, this decision has a real chance of killing our use of tcl, killing the L project, and setting us back a couple of years. Lovely position to find oneself in but it is what it is. > FWIW I'm also quite happy to continue with the status quo, i.e. > maintain the cocoa port in the gihub fork and let the tk/macosx code > in CVS bitrot away, I won't be doing any more work on it, I haven't > touched it since last August as is (nor has anybody else). Just for the record, I'm very grateful for your work, I should have started with that statement. Showing up and raining on your parade is the last thing I wanted to do. And to put some teeth in that, if you wanted to offer up a price tag for maintaining 10.4 support, figure that out. If it's something we can afford I'm happy to cough up the money. Regardless, this is great stuff, and I support it, I just wish it included 10.4. Sorry to be such a downer. -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
From: Daniel A. S. <da...@us...> - 2009-05-18 02:11:27
|
On Mon, May 18, 2009 at 00:16, Daniel A. Steffen <da...@us...> wrote: > they may not be that large, I haven't looked into it frankly. Feel > free to have someone at bitmover look into it, I can't justify > spending time on it. I looked into it briefly, unfortunately as suspected it's not looking good, with the following small patch (backporting some types) http://www.categorifiedcoder.info/tcltk/tk-de-carbon-10.4.diff you'll get the following error log: http://www.categorifiedcoder.info/tcltk/tk-de-carbon-10.4.log (about 100 errors and 100 warnings) the most serious of these is the unavailability of CoreText on 10.4, i.e. the tkMacOSXFont.c errors. This means the total rewrite of the text renderer to CoreText and font handling to NSFont that this represents is not available on 10.4. This was at least one month fulltime work to get right... To add support for 10.4 probably the existing ATSUI renderer would somehow have to be glued back in and amalgamated with the new font handling (native widgets, menus etc also use the NSFont handling so it would need to be there even on 10.4) This would certainly not be a small project, and definitely not something I could take on at present (even as paywork). Benny, the original author of the ATSUI renderer might conceivably be somebody to ask... even with that, there is no guarantee that there won't be some other serious problem that is not as easy to tell from the error log... > FWIW I'm also quite happy to continue with the status quo, i.e. > maintain the cocoa port in the gihub fork and let the tk/macosx code > in CVS bitrot away, I won't be doing any more work on it, I haven't > touched it since last August as is (nor has anybody else). if the cocoa port is merge in, at this point, I think the only feasible option for continued 10.4 support is to maintain a parallel sourcebase with the existing carbon code. If the general consensus is that this is the way to go, cognizant of the fact that I won't be able to maintain it, and that it may break soon if no other maintainer steps forward, I can look into setting that up, but it will take some time. Anyway, I've run out of free time to spend on Tk this week, so the merge won't happen before next weekend at the earliest, so there is some time to hash this out. Cheers, Daniel -- ** Daniel A. Steffen ** ** <mailto:da...@us...> ** |